This is Part I in our series on building responsive website. Part II is here.
I was fresh in through the doors of Head when the rebrand project began and I was delighted when they told me that my first project would be rebuilding our site. To be given a project that you have total free reign over is a developer’s holy grail so this was the perfect beginning. Being new to the company I was fairly determined to showcase the best of front end technology I could master and get my hands dirty experimenting with as much CSS3 or HTML5 as possible.
The latest kid on the web block is responsive design. It’s basically predicated on the fact that our users are no longer bound to a desktop computer. A range of mobile phones and tablets have been released onto the market in recent years and now you can even browser the Internet on your television. So a web design is no longer a simple one-stop solution, it has to service many different needs, not just in terms of screen size but also in terms of what content is to be served and what interaction is available to the user.
The latest iteration of the CSS specification, CSS3 has recognized this by introducing the concept of media-queries. These allow you to detect what the users device is capable of and then direct different styling and layout where appropriate. You can see this in action by taking a look at one of our current case studies. If you resize your browser window using the resize functionality in the bottom right you can see how the content rearranges itself into a suitable layout depending on the screen width available.
Creating a responsive layout was something the design team really wanted to achieve with this project, and experimenting with media queries was something I’d been looking into for some time. So we got stuck straight in to designing and prototyping HTML at the same time to see how the mechanics of this would work in the real world with a mock up of our case study page.
We tried to apply our own design theory to the problem. In early discussions we agreed that normally we’d break out a 960 grid for structuring a page. However trying to implement a responsive layout using a grid system poses a fundamental question. For devices with less display space: do you shrink the width of your columns or do you reduce the number of columns?
We looked into other sites in the wild: Simon Collison’s, Hicks design and information architects, to see how they had implemented their layouts. There were a range of techniques mostly with media queries but we also came across other sites using old school percentages.
Percentage widths are surprisingly effective and have the added benefit of being fully supported across the entire browser landscape (including old IE). However there is something oddly 1995 about it. After having insisted that fixed width designs were the *only* way to go for so many years, it’s strange to step back into the world of fluid designs.
After a couple of rounds of very basic wireframe prototyping we opted for removing columns. A fully percentage controlled design (where you are effectively shrink the width of your columns) is more responsive and reduces the risk of a poor experience for a user trying to view your site on a screen width you haven’t optimized for, but eventually the legibility of your text columns suffer or you have to break out the media queries anyway to gain better control.
We decided it would be best to produce a number of fixed width designs for each layout, based on the most popular devices: 1280px (desktop), 1024px (ipad landscape), 768px (ipad portrait), 480 (iphone landscape), 320px (iphone portrait). This gave the design team much greater control to create compelling flow for the content. It also gave us a visible set of grids and dimensions to build from and that really took away the headache of theorizing the geometry of what we were trying to make.
We based our initial media queries on Andy Clarke’s but in the end we had to customize them heavily. We decided to use max-width as well as max-device-width. This way the responsive effect can be viewed on a desktop by resizing the browser window.
This caused confusion at first because we had to alter the media queries to detect the width at which the design changed, rather than the width of the target device but it did have an unexpected side effect of significantly speed up testing times as we could debug layout issues on a desktop machine before taking the site onto different mobile devices for testing. Also there is something strangely satisfying about watching the layout shift around as the screen size decreases.
We started our build with the desktop site and then worked inwards, removing elements as we went. In hindsight I would recommend going in the opposite direction, particularly in regards to how you structure your CSS but also in terms of how you approach the design of a website intended to be viewed on multiple devices. Andy Clarke has produced a useful set of boilerplate files called 320 and up.
The theory is: you should start with the very minimum reset and typography in your CSS files and then work upwards adding code and functionality as you go. It makes more sense to load as little into the mobile version as possible, enhancing with each larger device in terms of download size and processing capability.
To separate out the CSS and serve different files to different devices would complicate our front-end asset performance optimization during deployment but it’s probably worth the crucial pay off for improving mobile performance where every byte counts.