If you aren’t familiar with Kickstarter, it is a company that enables crowdsourced funding for projects. Kickstarter’s success has naturally propagated to creative entrepeneurs across the world, powering some incredibly successful projects and startups.
Instead of focusing on how awesome Kickstarter is, though, we will instead be discussing the technical approach the Kickstarter team took to create their Team page.
We’ll talk some about specifics, and we’ll also talk from a high-level perspective. Let’s get started!
An Overview of the Source
The next thing we can see is a consistent reliance on CDN-powered assets. Six (or seven if you’re IE) external stylesheets and eight external scripts (some loaded asynchronously) are all coming from various CDNs. We can also immediately see that Kickstarter at least partially supports IE, all the way back to IE6. All of these assets are minified and, when applicable, compressed.
Further inferences can be made about the Kickstarter Team’s approach to CSS; a
compass.css file is loaded just after a
fonts.css file, likely generated by Compass and Sass. These are the first two style files loaded.
Kickstarter utilizes Facebook connect as well as the Apple touch/iPad link icons for saving web apps to the home screen of iOS.
Not surprisingly, Kickstarter relies on jQuery and/or Zepto, depending on the situation.
Okay, on to the Cool(est) Stuff
(Particularly, those awesome videos)..
The first thing we immediately notice is the 600px tall video element of the Kickstarter team, front and center. Each of the 46 members are casually hanging out in front of some wooden panels.
The video (which is actually six separate videos stitched together) is set to loop automatically. For browsers that don’t support the video element, the poster element is used; for instance, the furthest left video uses this poster:
a frame from the video that still displays the team. This is a prime example of graceful degradation.
The basic structure of the video strip HTML is as follows:
<div id="video_header" class="kinetic-active" style="cursor: move; "> <div class="video_scroll"> <video height="600" id="video_1" loop="loop" onended="this.play()" poster="https://ksr-assets.s3.amazonaws.com/team_still_1_alt.jpg" width="770"> <source src="https://ksr-assets.s3.amazonaws.com/team_vid_1_alt_2.mp4" type="video/mp4"> <source src="https://ksr-assets.s3.amazonaws.com/team_vid_1_alt_2.webm" type="video/webm"> You need an HTML5 capable browser to view this video. </video> <video height="600" id="video_1" loop="loop" onended="this.play()" poster="https://ksr-assets.s3.amazonaws.com/team_still_2_alt.jpg" width="770"> <source src="https://ksr-assets.s3.amazonaws.com/team_vid_2_alt_2.mp4" type="video/mp4"> <source src="https://ksr-assets.s3.amazonaws.com/team_vid_2_alt_2.webm" type="video/webm"> You need an HTML5 capable browser to view this video. </video> <!-- ... more videos ... --> </div> </div>
#video_header element is set to be a width of 100% (the screen width) with an overflow of hidden, with the
.video_scroll div having a width that holds all of the videos (over 7000px), which are each set to
float:left; the scrollTop or scrollLeft of an element with
Take a look at this CodePen for an example of a “draggable” paragraph:
Note: this example won’t work for touch devices, and doesn’t have any functions for kinetic scrolling, which hints at the attention to detail Kickstarter employed.
So how would you go about implementing kinetic scrolling? A combination of setTimeout-based functions (or, if available, requestAnimationFrame) to figure out the speed at which you are scrolling when you release the drag handle are used to define a starting “velocity”, which then decreases over time based on an easing function until the element stops.
A good exercise is to think about how different easing functions may apply. For instance, a bouncing ball would be, of course, a bouncing function. But what would an ease-in, ease-out function be used for? Perhaps if you are simulating a ball rolling down and back up a hill; the speed at the top of a hill would be slow, then fastest at the bottom, then slow towards the top of the second hill.
What Else is Cool on This Page?
The footer has a neat little Easter egg; clicking the scissor span (which has three different “scissor positions” enabled by class changes) animates the scissors across the screen;
Click it three times, and it “cuts” the footer off the bottom of the page, revealing a grid of squares (implying a Photoshop blank canvas). All of this is done with fairly simple jQuery animations and callbacks, and is stylistically powered with CSS classes and jQuery inline style declarations.
While the Kickstarter Team page isn’t currently utilizing media queries for responsive design, they are making provision for the accessibility of touch devices. It is possible that Kickstarter is developing an iOS app, based on the team’s experience and GitHub repositories. They are also making some provision by using Zepto in place of jQuery conditionally.
Because nobody’s perfect..
4 CSS Files?
The main criticism we can offer is about the presence of four CSS files. Splitting CSS across four separate files increases the number of HTTP requests, which should be avoided; however, there are multiple possible reasons the Kickstarter team decided to do this. They likely have good reasons, considering the measures they have taken towards optimization otherwise; in particular, they could have been using something like Bless CSS. IE will only allow a certain number of selectors per CSS file; Bless CSS automatically counts your selectors and splits your CSS files accordingly if they go over the limit. Another possible reason is to avoid loading code that is unnecessary in other places; for instance, it may be the case that the least used selectors (across the site) end up in the 4th CSS file, and thus all four files may be loaded in very few cases.
Lack of Responsive Design
Responsive design via the use of media queries would be nice to see, but it may be the case that Kickstarter is dividing their audience and encouraging desktop visits based on some of their (apparently extensive) data collection and analysis. It could also be the case that Kickstarter would prefer to invest in a native app, but we don’t know that for sure just yet.
Who are These people?
The final critique we have is simple: who are each of the team members? Sure, we have the names, but I don’t know which person matahces with which name. It would have been interesting to somehow highlight the names when you hover over a team member’s name, for instance. Another simple solution would be to say that the people are listed in “order of appearance”.
However, this may also have been a specific decision by Kickstarter, to protect the privacy of the individual team members. If even one team member didn’t want to be identified, it is the right choice to not identify any of the team members. It may also be a message Kickstarter wants to propagate, that this team is a single unit; this, however, might be better served by not showing the names at all.
The Kickstarter Team page has received some very positive feedback from the design community and we can learn from this page in many ways. Specifically, we should take away the fact that combining a few simple ideas in a new way (such as a content scroller and video) can lead to some very interesting and compelling content-driven interactions. This page doesn’t employ anything that is particularly “immersive” or complicated, but it captures our interest and holds it. The content is placed on a pedestal, once again, and users are invited to explore that content in a fun but simple way.
What else do you notice about Kickstarter’s Team page? Are there other similarly interesting pages you found on Kickstarter? What do you think about their decision to avoid media-query-based responsive solutions? Let us know in the comments!