I’ve wanted to write about responsive web design for some time now but the previous post I was writing became very bloated and out of date very quickly over the process of writing it so, I gave up…however after seeing a talk last night by Amber Weinberg at Points Brighton about mobile development and the process she uses I thought I would take 5 mins to look at how I’ve worked when developing responsive sites.

The main point Amber brought up in her talk was whether there is a need for a mobile first approach or a desktop first approach when it comes to development. Now I want to be very clear here that we are both talking about from a development point of view as neither of us are designers. Amber didn’t touch on design aspects but for me web design should ideally be based on mobile first or more accurately, content first; now I am not in a position at my company where I can tell the designers how to go about their jobs but I feel that if you’re going to aim for a responsive website the content needs to be king, and by designing mobile first this focuses the design more around the content. But I’m sure there’s a lot of opinion on this and as I’m no designer I will leave that to the rest of them to fight over.

Right, so back to my point, responsive development. When building the Il Palagio website, I was given only desktop designs and one version of how the homepage might look for mobile, so my options here for development were pretty limited, do I build it mobile first or do I start with designs I’ve been given and work desktop first. Of course I opted for the latter seen as I had a design to work from. So my development starts with a normal desktop build based on fixed widths from the designs I’m working with, which I then turn fluid in the usual manner (with a max-width). This means I now have a fluid website which will at some point break when you shrink the viewport down.

Now this is the bit where it gets more interesting. At the time I was building this site I came across an article on Boagworld which is a transcript of a conversation between Paul Boag and Ethan Marcotte from one of the Boagworld Podcasts, it’s pretty good if somewhat lengthy but there was one question Paul asked Ethan that I think shows a fantastic approach to working with responsive designs from the desktop first:

That’s usually the first thing that I build is I sort of build the desktop view of the site. […] Then what I’ll do is I’ll kind of go back at the top of my style sheets and I’ll actually start going kind of rule by rule and just sort of picking out the properties that actually have to do with layout. […] Then anything that sort of I think is best fit for the top end of the resolution spectrum, right in line, right after that rule I’ll actually just create a media query and then just sort of drop in all those properties that I think are just widescreen only, for example. Then I’ll basically work my way all the way down the style sheet essentially kind of quarantining out anything that’s layout specific. So by the end, there is nothing outside those media queries that has anything to do with something that wouldn’t be accessible to a small screen. So then I go back over the top of the style sheet and I’ll take all those media queries and basically just consolidate them all down at the bottom.

Ethan Marcotte speaking to Paul Boag on his approach to responsive development.

I really like this approach, I take all of my CSS that is layout specific and would only work for a wider viewport and I strip that out and put it in appropriate min-width media queries at the bottom of the styles (or in separate stylesheets that are called after the main). I make sure I spend time looking at which breakpoints each particular part of the layout falls down in the design and strip it out and create this series of media queries (limiting to 3-4 depending on what is breaking where). This way it means that all the original design goes into as many versions of the site before I have to start changing things. And from this point what I’m left with in the main style is as Ethan says in the post, mostly just typography and elements that will fit into any viewport. Now I’ll just work with the styles I have and amend the website to work in the main breakpoints that I have set out in the initial “quarantining” phase.

Also just a quick note on breakpoints, I generally stay away from common breakpoints and device specific sizes because even at the moment there’s such a varied market it’s better to make sure a site works at all sizes, not just the ones we know (also that’s future proof too - go me!).

Where possible with my media queries I also try to mainly use min-width media queries so that any styles I write for different queries cascade into one another so nothing I write goes to waste. It isn’t always possible but I like to try to avoid writing 3-4 min and max-width media queries as essentially it means I’m writing 3-4 different layouts.

One final point I would like to make is that while I may start with the desktop first my stylesheets are always based mobile up, which I think should be fairly common sense but I feel I had better mention this just in case. The whole point of building the CSS up from mobile first is that you’re exposing the smallest amount of CSS possible to smaller devices and then adding more as the viewport size builds up (not that it means speed builds up with it but we haven’t quite got to speed detecting media queries yet), and so are increasing the actual impact on that smaller resolutioned device - something that Andy Clarke has taken into account in the updated 320 and up framework.

So that’s my current approach to responsive development, I’m still fairly new to this whole world - so far I only have about 4-5 responsive builds under my belt - so I’m sure my techniques will develop over time as I take on new ideas and the whole responsive movement matures a bit. I think we’re all still going to have varying techniques and approaches when it comes to responsive web design and development, and I think mostly our methods will depend a lot on the context in which we’re working. This approach works well for me as I’m always going to be served designed aimed at the desktop. If you have any thoughts on this I’d love to hear what you have to say so feel free to leave a comment or tweet me.