More Responsive Design, Please
Responsive design is blowing up the internet. Here are a few must-read examples, if you don’t believe me.
- The original article: Responsive Web Design, by Ethan Marcotte (A List Apart)
- A case against: Not a mobile web, merely 320px-wide one, by James Pearce
- Start with mobile (slides): Rethinking the mobile web, by Bryan Rieger and Yiibu
- Another case against, sort of: Making Mobile Mistakes, by Paul Boag (the comments on this post are outstanding)
- Recent defense/explanation: Sea change, by Jeremy Keith
Ethan, the guy who kicked off the craziness, defines responsive design in part by @media queries—I think they count as necessary but maybe not sufficient. Responsive design is all about how we build a site to respond to information. And I think we’re confused about what kind of information we have, how we get it, and the relationship between it all. So here’s a pretty picture to get us started.
This colorful table demonstrates two ways a site can respond, based on two types of information.
When layout responds, we adjust how the content is displayed, ordered, or styled.
When content responds, we adjust what’s being pulled from the server and displayed by the client (usually a browser).
Capability is information about what can be done, based on the device, the internet connection, the browser, etc.
User intent is information about what should be done to meet the users’ needs as best as we can.
We’re getting all these things mixed up.
Layout by capability
This is the genius of Ethan’s A List Apart article. We can use CSS to determine a few things about the width of the viewport, the orientation, etc. and build our sites to respond to that information by adjusting the layout accordingly. This is the heart of responsive design right now because this is the information we’re most accurately able to gather with the tools we have.
Content by capability
This seems to be a big reason why people fight against responsive design. Sure, we can push some pixels around the page, but what good does it do if we’re shrinking down 1300×900 pixel images for a 320px wide screen? Using @media queries can optimize layout, but what about optimizing the content, too?
This is probably the area with the most room for responsive innovation, and until that innovation happens, people are suggesting we optimize content based on what the user wants. Which is really a conversation about intent, and not capability. See? It’s confusing.
Layout by intent
User intent is the holy grail of user experience design. We make a series of guesses (some more educated than others) about what people might want to find on our site, how they might want to find it, and how to organize and label everything so it’s easy to find.
But here’s where the biggest mix-up almost always happens.
We can’t reliably determine a user’s intention based on the capability information we collect from her device or internet connection.
By pretending we can, we’re like a shop owner who rearranges his entire store every time a car pulls into his empty parking lot. He notes the make and model of the customer’s car and makes a few appropriate changes. Mini-van drivers want milk and gum and mac and cheese, of course, so these get pushed to the front. And of course they don’t want to see those nudey magazines in the display racks, so they get stashed away in the stock room. And so on.
Even if those things were true in the shop owner’s case, he could achieve a similar effect by keeping those magazines out of direct plain sight and making sure the food aisles are neatly labeled for people to find. It’s easy to forget that the mini-van driver pulled into your parking lot, so they obviously intend to shop at your store. It’s probably not necessary to guess exactly what they want to do on each individual visit, especially when a wrong guess can hinder them from doing what they want to do (Uncle James may have taken the mini-van to the store to pick up his nudey magazine, after all).
Content by intent
If we assume we can accurately guess the user’s intentions based on capability information, we might be tempted to remove irrelevant content from that user’s view. Jeremy Keith responds to this kind of assumption better than I can, so I won’t try to duplicate it.
We have once again created a consensual hallucination. Just as we generated a mythical desktop user with the perfect viewport size, a fast connection and an infinite supply of attention, we have now generated a mythical mobile user who has a single goal and no attention span.
More and more people are using mobile devices as a primary means of accessing the web. The number is already huge and it’s increasing every day. I don’t think they’re all using their devices just to look up the opening times of restaurants. They are looking for the same breadth and richness of experience that they’ve come to expect from the web on other devices.
Hence the frustration with mobile-optimised sites that remove content that’s available on the desktop-optimised version.
Making drastic changes to content based on what we assume a user wants on any particular visit gives more credibility to our assumptions than I want to give.
The point about user intent: it’s design, stupid
We can be responsive to what our users want, but we do it at the point of design, not at the point of visit. In other words, when a user visits a site, we can gather information about the capabilities that user has available to him, and rearrange layout and content accordingly. But we can’t reliably and accurately use that information to determine what the user wants, enough so that we can remove content that we assume he doesn’t need.
Again, a pretty picture, this time with a few more words.
Some people go so far as to say that all web design is responsive design, which is hard to argue with, but there are subtle differences. Build a site that works for your users (design) and build it with enough flexibility to adapt, subtly, to various capability levels (responsive design). The semantic difference is trivial, but the end result is the same: we need more responsive design, not less.
One web to rule them all
You either build for a device or you build for the web. You can’t build a web-app that’s just for the iMac. If you try, people will access it from other devices and rightfully expect to be able to use it, because that’s what the web is. When we build for the web, our initial design should respond to what we know about our users, and the layout and content should be able to subtly respond to a user’s capabilities on the fly.
That’s how we build a more responsive web. Not a mobile web, or a desktop web, or an iPad web, or any other kind of web we might try to predict.