I’ve recently finished a build of a fully‐responsive site for a client, made with a group of friends (the site’s not online yet, it’s being integrated with their systems by their internal web team). I’ve built mobile‐optimised, fluid and semi‐responsive sites before, but this was the most complete responsive build I’ve worked on to date, so I thought it would be worth discussing some of what we learned and had confirmed.
‘Mobile first’ means just that
Mobile‐first is not a methodology, it’s a mandate. If you decide to build mobile‐first you must commit to it completely — you must not only plan and architect mobile‐first, but also build and test mobile‐first. Make changes to your base stylesheet and let them propagate through the others.
Think of it as like dropping a stone into a pond; changes you make in the base stylesheet are the splash, and those changes will ripple out into all of your other stylesheets.
Don’t build and test in desktop first just because it’s more convenient. It’s a false economy. You’ll have much less work to do if you use media queries to alter solid base values, so develop in a mobile browser (or at least a desktop browser resized to mobile dimensions).
Let content dictate code
As well as (or instead of) device breakpoints, you’ll also want to let content dictate breakpoints. It’s not sufficient to just have the page layout change between device breakpoints, you must also consider that within the defined device ranges there’s huge variability. There will be occasions when content breakpoints will need to be created to span device breakpoints.
Thierry Koblentz’s Device‐Agnostic Approach To Responsive Web Design and Stephen Greig’s Deciding what Responsive Breakpoints to use advocate using content breakpoints only, although I found a hybrid approach worked best for me.
Make time for testing
Make sure you get more testing time in the schedule and budget. I don’t think I’m exaggerating when I say that testing could be 50% of the front‐end build time. 40% at least. Testing is part of the build now, it’s ongoing. Of course you can (should) have a QA phase (or phases), but it’s no longer sufficient to wait until the end of the project before serious testing occurs. Test early, test often.