Responsive Design is Not the Only Good Answer

We are big believers in the importance of mobile devices. But I am troubled by the degree to which responsive design is preached as the only modern approach. Just as clients (who generally don’t know what it means) sometimes ask for “HTML5”, they are now asking for “a responsive design” when what they need is a low-cost way to have a good mobile site. There’s more than one way to skin that cat.

Recently, StatCounter, an analytics service that also publishes browser statistics, announced that the 1024-pixel-wide screen had lost its spot as the most common resolution, with 1366 × 768 taking the crown (thanks to the prevalence of netbooks).

In response, .net magazine published an article titled Browser screen resolution stats rile devs, quoting Jeffrey Zeldman as saying, “The most popular size is every size. If you’re not thinking in a mobile-first, content-first way, if you’re not planning an adaptive or responsive redesign, if you still think we have a standard canvas that ‘everybody’ uses, and if you can’t feel the hot breath of mobile singeing the hairs on the back of your neck, you don’t deserve to be a designer, or a consultant, or whatever these people think they are.”

I’m a great fan of Jeffrey’s (see the short interview I did with him a year ago). His religious fervor about web standards made a great contribution to the web design world, and the various Apart enterprises he leads (A List Apart, An Event Apart, and A Book Apart) all produce great stuff.

Is Responsive Design the Only True Path?

On this topic, however, I must disagree with Jeffrey and the other members of the “every site should use responsive design” club.

First, statistics are just statistics, and it is interesting and useful to know what the most common display size is. To attack the creators of the statistics is just silly.

More significantly, responsive design is not the only thoughtful approach to supporting mobile devices. I don’t disagree, of course, that there’s an increasingly broad range of devices and screen sizes, and that quality websites should adapt appropriately.

There is a very different character to a website on a phone-size screen, however, vs. a tablet or desktop screen. With so much less real estate, you need to think differently about how you lay out content, and about what you put on each page. It’s also important to think about the different needs of people who are on the go, even though people also use their phones when they are sitting on their couch.

To think of phones and desktop screens as part of a continuum, as responsive design requires, unnecessarily constrains the design of the phone experience. There are cases where this works fine, but many others where it creates more pain than it alleviates.

There is no single answer for every context. For the kinds of sites we create, which are typically midrange projects with lots of content, we have come to prefer having one set of HTML pages for phones, and another set for tablets and desktops.

With this approach, we can better optimize the phone experience, for a variety of reasons:

• We can think from scratch about how to optimize the phone and desktop/tablet experience, without the constraint of deriving one from the other.
• We can use different CSS and JavaScript frameworks for the mobile experience. For example, we find jQuery Mobile to be a great framework for building effective mobile sites quickly, but we wouldn’t use it for a desktop site.
• We can easily provide different versions of text, where appropriate. The home-page intro for a mobile site, for example, should be much shorter than the corresponding thing on a desktop site.
• Since we store most content in a database, it is easy to use the same content on both the mobile and the desktop sites, yet use different HTML markup where appropriate.

We’ve incorporated device detection into our server-side code, so we can easily deliver one set of pages to desktop/tablet devices and another to mobile phones. (This can also be done in JavaScript if you don’t have access to modifying the server configuration.)

Another benefit of this approach is that it allows us to serve customers who don’t want to redo their desktop site right now, but want a better mobile experience. Adding a jQuery Mobile site for mobile is much easier that trying to make an existing, fixed-width design into a responsive design. “Mobile First” can be a great strategy when you can do it, but for the majority of our projects, it just doesn’t match the clients’ situation and priorities.

So I find myself agreeing with Jakob Nielsen, in this case; his recent post Mobile Site vs. Full Site argues for this approach from a user experience perspective.

Does “Most Common Screen Size” Matter?

Absolutely. In some cases, such as for a photo site with a big grid of thumbnails, having a fluid page design that fills all of the available space offers a compelling benefit. But for most sites, it is difficult to create a layout that works well for a very wide window, because line lengths become too long, the relationships between text and graphics get out of whack, and there often just isn’t enough content available to fill the width.

It therefore makes sense, for most sites, to pick a maximum width. Today, most sites have chosen something around 1000 pixels, because of the prevalence of 1024-pixel-wide screens. The data now suggests that increasing this to 1300 pixels or so may make sense. You can design for 1920-pixels-wide if you want to optimize the experience for that 5% of the users, but for most sites it just isn’t worth it—it typically won’t deliver a better user experience than a fixed-width page.

For a fixed-width site, the minimum width and the maximum width are the same. This remains a reasonable approach if your budget is small; there’s no getting away from the reality that creating a comparable-quality fluid or responsive design is more work, and it may not yield much near-term benefit.

A better approach, however, is to use responsive design to enable your “desktop” layout to adapt to a modest range of widths, perhaps 768 to 1350 pixels.

Dealing with Tablets

If you don’t depend on hover events and keep your click targets large and far apart, this same design will work well for tablets. Or, you may want to use responsive design (i.e., media queries) to adapt the design for touch-screen devices, so you can make your click targets smaller than your touch targets.

Mobile sites must, of course, use fluid designs, so they can adapt to phones with different screen sizes and to landscape and portrait orientations. This does not require responsive design techniques, since the range of sizes is modest. (Phone screens aren’t going to get much bigger, because you need to be able to hold a phone in one hand.)

Small (7-inch) tablets, such as the Kindle Fire, occupy a borderland that is extra work to serve optimally. We typically serve all tablets with the desktop site, but there is an argument that 7-inch tablets would do better with the mobile site. If using responsive design for the desktop/tablet site, it may be worth adding another breakpoint to deliver an optimized design for small tablets.

The Best of Both Worlds

With a responsive design covering the tablet/desktop range, and a separate design for phones, you have the best of both worlds: true optimization for phones, and good support for a wide range of tablets and desktops.

You might think that this is more work and more expensive than covering the entire range with a responsive design, but we have found that generally not to be the case. The narrower the range of sizes you are worrying about for the responsive design, the easier it is to do a first-rate job.

Mobile (i.e., phone) sites are, in many ways, easier to build than desktop sites, when you build them separately. All the pages are much simpler. And because the sites need to be more functional than design-driven, frameworks and libraries can take you a long way quickly. We can build an effective mobile site using jQuery Mobile in less time than it would take to extend a responsive design to cover mobile phones as well. The end result is a better user experience at a lower cost.