Lessons for devs from a responsive build

Warning This article was written over six months ago, and may contain outdated information.

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.

4 comments on
“Lessons for devs from a responsive build”

  1. […] Lessons for devs from a responsive build (Broken Links) […]

  2. Hi, thanks for share it first of all…,
    I am wondering, if you start from the mobile site, you’ll provably need less html than on tablets or desktop devices. (at least this is my sensation).
    If it is my case, is it still worth in your opinion keep the process starting from the smallers resolutions?…
    If I need add html stuff afterwwards i’ll need keep adding css rules on my media queries all the time…
    could you clarify?
    thanks!

  3. Hi Jordi,

    I’m not sure if that’s definitely true that you need less HTML for a mobile site; the build we did was exactly the same across all platforms, there was no more or less on mobile or desktop; the only extras we added was an animated carousel, which was added using JS on desktop sites.

    I think what you’re proposing is that the mobile site has less content than the desktop site; that shouldn’t always be the case, but if you want to do a very targeted mobile site then you might be better off not using media queries. But then you have to think about UA sniffing, which is full of its own problems.

    Does that help?

  4. Hi,
    thank you very much, and yes, it does help, I am going for a fluid web rather than target it to a concret devices, it is for sure (tha’t my boss desire :) ), so I think that my “wrong assumption” was that I was gonna need more content on the “descktop” version, but if I think it again, it doesn’t need to be like that, and if I really have any issues with the content on the smaller resolutions I always have CSS.
    So, let’s create that new site form the small to the big and see what happens :)
    cheers, your help is very much appreciated.