I’m a developer, not a designer, so pretty much 100% of my clients already have their designs finished by the time they come to me. Most of them don’t really start thinking about a device centric web until they come to their developer, which means the designs are often not designed with mobile in mind. More than that, there’s often only mockups for the largest desktop size.

With that in mind, it’s nearly impossible to go mobile first – sure I could try and rack my brain for a simple design to match the full desktop size before I even know how I want to code the regular part of the site – but why should I? That’s work I neither charge for, nor want to do. Instead, I think I found a route just as good as mobile first – doing it last in the development stack. And here’s why “mobile last” isn’t really mobile last.

Going Top Down

Coding the largest size first allows us to set up the design principles and grid at the start, which means things flow a whole lot nicely as we reduce our viewports down in size. Coding in percentages (I still use pixels for fonts) means things already start contracting nicely. The real advantage “mobile first” activists claim to have is that because they’re starting with mobile first, you don’t get a lot of the “overhead” that you supposedly get from going top down – this of course, isn’t necessarily true. You can create a bloated site as easily in “mobile first” as you can in others, and it’s up to us developers to make sure we’re not loading 50mb images, regardless of which route we choose to use. You can easily load larger images using media queries for the larger sizes only. Think something like:


@media only screen and (min-width: 1025px) {
     body { background: url('bkg-large.png'); }
}

@media only screen and (max-width: 1024px) {
     body { background: url('bkg-small.png'); }
}

For browsers without media query support, you could simply call in an IE stylesheet or use one of the million other ways to detect browsers and load in an optimised background. To be honest, I don’t often do this unless it’s an image that’s really, really large and noticeably slows down the whole site in 3G. I subscribe to keeping CSS simple (and glad to hear Eric Meyer does too). I try to avoid hacks, detections and doing something 5 times as much as possible. It’s just ridiculous. Sites don’t have to look or act the same in browsers (didn’t we establish this already?) so we should be making front-end development less complicated these days, not more. But I’m getting off track.

Responsive design (or responsive development as I like to call it) can sometimes be a pain to wrap your head around when you’re first getting started, but by starting with the final design first, it makes it easier to make good design and usability decisions as your viewport gets smaller and smaller. It’s sometimes impossible to envision how to get from the one-column simpler design for mobile to the 4 column mega design of a 1600px viewport, but when viewed from the other direction, it becomes a lot clearer. I suggest trying this out.

Hear More

I’ll be speaking about this exact topic at Breaking Development in Nashville this October. Y’all should come visit my hometown and see it!

Amber Weinberg

Amber is a freelance front-end developer specializing in semantic and accessible custom WordPress themes. She works with agencies and other freelancers to bring their designs to life using custom ACF flexible layout builds - making them more performant and less buggy while allowing the client easy customization without breaking the design system.