I got an email from Ben Frain recently asking if I’d answer some questions for an upcoming article in MacUser UK about responsive design. Seeing as this is a topic I could natter on about endlessly, I happily obliged.
Here are my answers to his questions. There’s a good chance that much of this will get trimmed or altered for the final article so I figured I’d share my verbatim responses here.
When you first looked at responsive web design methodology, can you remember your initial reaction?
Before Ethan wrote his seminal article in A List Apart, I saw him giving a presentation at An Event Apart in which he outlined the ideas of responsive design. My reaction was “Yes! Yes! Yes!”
Ethan was essentially describing all-round best practices for the web in general, taking progressive enhancement to the next level. But the reason why people started paying attention was because of the timing; the idea of websites being accessed by browsers with all sorts of screen dimensions was no longer an abstract concept, it was a very real description of web browsing demographics.
So my overall reaction to responsive web design was “Finally! Maybe now web designers and developers will really start embracing the web as its own medium.” It’s no surprise that Ethan’s article in A List Apart referenced A Dao Of Web Design by John Allsopp—a piece of writing that should serve as a manifesto for everyone working on the web.
Have you been surprised that responsive web design has become the zeitgeist of the front end community for the past 18 months or so?
I’m not surprised that responsive web design has struck a chord. I only wish it could have happened sooner. While media queries are a relatively recent innovation, we’ve always had the ability to create fluid layouts. And yet web designers and developers have wilfully ignored that fact, choosing instead to create un-webby fixed-width layouts.
In taking a batch of related technologies—liquid layouts, media queries, and fluid images—and then grouping them together under one banner—responsive web design—Ethan made it a lot easier for people to talk about this approach to designing and building web sites. There’s a real power in naming related technologies like this. We saw the same explosion of discussion and creativity when Jesse James Garrett coined the term Ajax.
How long after understanding it did you create your first working example (either client work or ‘playground’ work)?
I was already making liquid layouts. In fact, every single site I’ve ever built for over a decade has used percentages by default. Because of that, I was already familiar with the challenges of fluid images and the work done by Richard Rutter (which Ethan references). I had started to dabble with media queries on my own personal projects but seeing Ethan’s proof-of-concept was just the incentive I needed to start implementing them on client sites.
As the methodology gained traction, it started to get a lot of flak from some quarters, often mobile developers. What do you put that down to?
I think a lot of people misunderstood what problems responsive design was claiming to solve. It was never specifically about mobile devices or users in a mobile context; it was always about adapting layout to varying viewport sizes.
A lot of people seemed to be angry that responsive web design didn’t appear to solve any issues relating to bandwidth or context. It’s true that responsive web design doesn’t solve those problems …it also doesn’t cure cancer. It never claimed to.
Responsive design isn’t about mobile. Neither is it about the desktop. It’s about the web.
Whilst no one set of principles can be considered a panacea or magic bullet - are there specific instances where you’d argue against a responsive web design for a clients site?
Honestly, no. But the reason I say that is that, once you’re used to creating responsive sites, it’s really no extra effort. So I’m not saying that every project needs to go that extra mile—quite the opposite. I’m saying that sites that adapt to the user’s device should be the default (and should have always been the default).
The only time I would argue that a client shouldn’t have a responsive site is if the client shouldn’t have a web site at all.
Just to clarify: I’m not saying that the client couldn’t also have subdomains or apps targeted at specific classes of device as well as their responsive web site. But the baseline to having any presence on the web should be a website that works for everyone, everywhere.
That said, it’s a lot easier to create a responsive site from scratch than to attempt to retro-fit an existing desktop-centric site. In that situation, where the desktop-centric site is just too big and bloated to serve up to mobile devices, a separate mobile-specific site can be a good stop-gap measure. But in the long run, maintaining multiple silos just doesn’t scale. Also, the fact that the site is too big and bloated for mobile probably means it’s too big and bloated for anyone, regardless of their device.
For a client who has neither the business necessity or budget for a ‘mobile specific’ website (let me qualify that by saying that I term a ‘mobile specific’ website as one that has some server side functionality to ‘sniff’ the device and serve up entirely different experience based upon it), is there any better option for clients to get themselves a mobile ready presence?
Well, yeah: a responsive web site! It might not be specifically targeted at mobile devices but, if it’s done right, it won’t be specifically targeted at any particular class of device.
At present, although server (e.g. adaptive-images) and JS (Scott Jehl’s <picture>) based solutions exist, responsive design struggles when it comes to responsive images as there is no way to provide alternate images based on media capability or connection speed (one day please!) through markup alone. What would you like to see happen to combat this issue?
There’s some great work being done by the W3C Responsive Images community group. I’m hoping to see some rapid adoption by browsers. But mostly, what I’d like to see is exactly what’s going on: a bunch of really smart people getting together to collectively solve this problem in a backwards-compatible way. I find it quite inspiring, actually.
What are some obvious pitfalls people should avoid when implementing a responsive design?
The biggest mistake I’ve seen is when developers try to treat responsiveness as an add-on, something to be bolted on at the end of the development process. That’s going to lead to a world of pain.
Responsive design makes most sense when it’s paired with the idea of Mobile First. Thinking about the screen size and capabilities of mobile devices first forces you to focus and really think about what’s absolutely essential to deliver. When you don’t have the luxury of a large viewport or a fast connection, you’ll quickly find that complicated navigation and unnecessary page cruft will quickly get trimmed.
In fact, that approach isn’t really about mobile specifically, it’s about focusing on the content. Content First.
Personally, I’d like to see some ability to visually re-construct the DOM through CSS alone - so media queries could literally place anything anywhere. Do you feel that specs like CSS Regions hold the answers to that problem?
I’m much more excited about flexbox, but that might just be because I haven’t examined CSS Regions in any depth.
Flexbox is going to be a game-changer, I think. Source order will still matter for older browsers, but we’ll be able to serve up just about any layout regardless of source order. It’ll be great to finally have that real separation of concerns.
Whether it’s flexbox or regions, I look forward to the day when we can stop using layout hacks like floats, because let’s face it, floats are a hack: they were never intended for layout.
Although tools like Adobe Shadow (Weinre) are emerging, existing prototyping tools like FireWorks are limited when it comes to fluid designs - do you prototype/design there or do you do a lot of designing in browser?
Fireworks and Photoshop are useful tools for designing elements of a site’s design but they are woefully inadequate at conveying the fluid dynamic nature of the browser. For that reason, I think it makes a lot of sense to get into the browser as soon as possible (it also means you can start testing your designs sooner).
Spending a lot of time making high-fidelity comps isn’t very efficient, I feel. A lot of that time would be better spent trying things out in the browser and reacting to how they behave at different sizes.
Some people have claimed that designing in the browser is much more limiting than designing in Fireworks or Photoshop, but I think that just comes down to what you’re used to. Those tools come with their own constraints (a fixed-width canvas and lack of interaction being the obvious ones).
Also, if there are certain things that can only be done in a tool like Fireworks and not in a web browser, then what’s the point of doing them? Unless you’re planning to just export your design as one big image, you’re going to have to translate that Fireworks comp into markup and CSS at some point. There’s no point in creating something that can’t be translated.
Graphic design tools still have their place. One of the techniques I find works really well with responsive design is the creation of Style Tiles. These allow you to nail down the visual vocabulary of a project without getting into the nitty-gritty of page layout. They are less wishy-washy than mood boards but not as time-consuming and high-fidelity as page comps.
Can you sum up, in general terms, the key things you think people should consider when building sites today?
I’ve found that it makes sense to apply the principle of progressive enhancement to everything: layout, images, and content:
- Use small images by default.
- Don’t apply any layout in your CSS.
- Start with the content that is absolutely essential.
Once you’ve got that baseline working well, then you can start to progressively enhance the site:
- Load in larger images if the screen size permits it.
- Use a grid for page layout, but keep the CSS declarations for the grid within media queries.
- Use Ajax to conditionally load non-essential content for larger screens.
Don’t start a design by thinking about the desktop layout. But don’t start by thinking about the mobile layout either. Instead, think about the content. And when I say “content”, I don’t mean “copy.” Your content could be a task, like adding an item to a shopping cart. Focus on the core task that your user wants to accomplish.
Separating out the content (reading an article, buying a pair of shoes) from the delivery mechanism (a desktop browser, a mobile browser, a tablet) requires a different mindset to the way web sites have traditionally been built. But much like the change in mindset that was required when we changed from tables for layout to CSS, it’s incredibly rewarding.