Advertisement
  1. Web Design
  2. Case Study
Webdesign

How They Did It: Build Windows

by
Length:MediumLanguages:

Today, we'll dive into the Build Windows site and look at the practical code philosophies, tools, and strategies used by this highly trafficked, highly praised conference landing page. We'll get into the nitty gritty, but we will also be covering some things from a mile-high perspective.


Who's Responsible?

The Build Windows site was a collaboration between the three-person Paravel team and Windows's Nishant Kothary. (Take a look at Trent Walton of Paravel's post, the official post from Paravel, and Nishant's post about the project.)


An imposing first impression

The turnaround for the front-end side of the project was about 10 days.


Methodology

As the posts from the team suggest, their primary methodology was getting the design into the browser as fast as possible. For Paravel, this is absolutely essential, as much of their work revolves around media-query-based responsive design.

The iteration process was incremental and fast; two people focused on layout and content, while the other two focused on front-end code.


Toolset

The Build Windows site relies on a few important tools and libraries.

JavaScript Tools

  • Modernizr using this custom build
  • jQuery - Used throughout the main script.js file
  • Lea Verou's PrefixFree.js - Used throughout the CSS to automatically add vendor-prefixes to animations/transitions and other CSS properties that require them
  • Responsiveslides.js - Used for the "Meet the family" image fading rotator
  • Webtrends.js - Analytics (note: NOT Google Analytics)
  • An awesome ascii file - This may serve another purpose, but none that we can see other than being awesome

CSS Tools, etc

  • Basic Reset - Commonly seen all over the web
  • @font-face - used to import the Windows Segoe UI font

A lot of the markup and styling looks very similar to HTML5 Boilerplate's recommendations.


Strategy for Responsive Design

BuildWindows.com makes extensive use of media queries, with 8 total break points:

  • 480px
  • 680px
  • 780px
  • 900px
  • 1280px
  • 1500px
  • 1700px
  • 1950px
build
build

The biggest changes happen between 680px and 1280px. Above 1280px, the main changes that occur are section padding and margin changes and, most importantly, font-size adjustments (up to font-size: 200%;). The "metro tiles" account for a large amount of the CSS; in particular, these tiles adjust from 4 to 8 columns throughout the media queries.

Graceful Degradation

A total of 15 ".lt-ie9" rules are present, 7 of which are for ".lt-ie8". In general, these are margin, padding, width, and font fixes, as well as a rule for the ".button" background color.


Interactions

There are three main animations that occur, all accomplished with CSS transitions and animations triggered by watching the scroll event and adding classes to "in-view" sections. For example:

This, slightly modified from the script.js file, shows the primary function that watches for the scroll and adds classes accordingly. We then can see, for instance, the bottom "countdown" animation defined in the css.

An important note here is the ".no-js" class, which is applied to the body class in the markup. Modernizr removes this class when it runs, but if Modernizr never runs, we know that the browser's JavaScript is turned off, and therefore we can't trigger the animation to bring the countdown widget into view. Instead, we show it by default without the animation.

Similar animations are defined for the tiles and logos, and the Responsiveslides image fader is started when that section is scrolled into view. The "metro tiles" also have tilts defined for the "active" pseudo-selector, which uses a transition on the transform property. Ex:

Taken directly from http://www.buildwindows.com/css/style.css.

Exception

The team building this site decided to immediately add the "in-view" class to all appropriate sections on DOM ready on any iOS device.

This is most likely a decision made to increase performance and avoid scrollTop issues in Mobile Safari. Generally speaking, mobile browsers do not emit a scroll event until the scroll has come to a complete stop. Check out this writeup about the issue and some potential workarounds: onscroll Event Issues on Mobile Browsers.

Most of the JavaScript in script.js is dedicated to adding these classes and updating the timer on the bottom. The countdown is set to use a serverTime and tells the user, down to the minutes, how much time is remaining until the event begins. Server time is much more reliable, as the user's computer clock (which JavaScript's Date() function uses by default) may be set to anything.

Other functions are a scale bug fix for iOS and sub-pixel antialiasing on Mac Webkit.


What to Learn

The Build Windows site has received a lot of positive review from the community. What can we take away from reviewing this site, and seeing how it was made from the ground up?

All bets are off if you’re experienced. In fact, focusing consciously and “taking your time” will actually hurt your performance if you’re someone with much experience in the field at hand. - Nishant Kothary

Build Fast

As Nishant's post about the project indicates, trusting your first instinct and rapidly building and incrementally revising a design project can be very rewarding for experienced developers and designers.

Build: Simple, Graceful and Responsive

The Build Windows site is very simple, employing a single landing page that relies on a few large sections to communicate a limited amount of information and incite a single call to action. This kind of simplicity allows for a solid and focused voice and brand, the backbone of any good design.

... we designed, prototyped, and built the majority of the site in the browser so that we could ensure the site hierarchy & layout was ideal at any screen size. - Paravel

The site gracefully degrades, so that browsers that are old or don't have JavaScript can still retrieve the necessary information. It also is progressively enhanced (CSS animations are used when possible, for instance).

The site also employs responsive design techniques to allow for accessibility across an array of devices without limiting the "prime" experience to a single device.

Strong Focus on Type and Content Framing

While the site employs some animation and behavior, the content and typography are the kings of this design. The imagery and other graphical design elements (such as Reagan Ray's illustrated Seattle skyline) simply support the typography and content strategies.

segoe
Microsoft’s humanist sans typeface, Segoe UI

And while you might at first think the build logo is text made fluid with Paravel's own fittext.js, it's actually just a massive transparent .png; 1,700 px wide, but weighing in at a paltry 13Kb.


Critiques

Because nobody's perfect..

Optimization

While the site employs many "best practices", there are some aspects that could have been further optimized, such as the concatenation and minification of JavaScript files and CSS, the use of sprites where possible, etcetera.

However, the site doesn't suffer from these particular issues in any significant way, and the team most likely made the choices they made to allow for a more maintainable codebase. Beyond this, The team might have anticipated that other developers and designers would look into the source code, and thus left pieces of it unminified.

Minor Best-Practice Issues

This is mainly a critique of the use of userAgent. It should be known to all readers of this article that navigator.userAgent is not a reliable way to detect what browser someone is using.

However, this site does not use and abuse the userAgent browser sniffing; they use it for two primary purposes. The first is to set a text anti-aliasing CSS rule on Mac Webkit. The second is to immediately add the "in-view" class to iOS devices. Both of these particular use-cases are legitimate, as neither compromises the content heavily.

Some of the jQuery-based JavaScript isn't as optimized as possible:

Could be:

And the addInView() function could also be optimized in a number of different ways. That said, these are nit-picky concerns that certainly flirt with the fringes of over-engineering; the decision could have been made to ignore these optimizations for many reasons:

  1. The gains are insignificant
  2. Code readability could suffer
  3. The short turnaround likely means that the project could better benefit from more focused attention in other areas, such as refining each responsive breakpoint with higher precision and detail

Conclusion

Paravel and Nishant at Windows paid close attention to detail on this project, despite the short timeline allowance for the project. Their rapid development approach and trust for their own instincts paid off in this modern design, a far cry from Windows design of old.

What are some insights you gained by looking through this site? How do you feel about the optimization? How about the vast array of responsive breakpoints? Let us know below!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.