Responsive design, screens, and shearing layers

Luke Wroblewski wrote a blog entry that’s been rattling around in my head for a couple days now. In it, he raises some concerns he has about responsive design’s “over-reliance” on screen width. Go check it out, if you’re interested, but I’ll excerpt a bit:

So if adapting to different screen sizes can have that kind of positive impact for a business, what’s the risk? As the kinds of devices people use to get online continue to diversify, relying on screen size alone paints an increasingly incomplete picture of how a Web experience could/should adapt to meet people’s needs. Screen size can also lead to bad decision-making when used as a proxy for determining…touch or other capabilities

(A minor nit: where Luke refers to “screen” above, I’d use “viewport”. But! Moving on.)

Luke raises, as he so often does, some thoughtful points. A few highlights, for me:

• He sounds a cautionary note about how we often conflate the size of a screen with the capabilities of the device. I’ve noticed this happen with some frequency lately, actually: where, for example, it’s assumed the small screen view of a responsive site only needs to be “touch-enabled,” rather than accommodating non-touch interfaces. A small screen doesn’t immediately denote “Android” or “iOS”, folks.
• Luke notes there’s a relatively recent explosion of emerging input modes and, from that, the potential for new browsing contexts. And these contexts may or may not be served by responsive design because, he suggests, “an interface that tries to be all things to all devices might ultimately not do a good job for any situation.”

It’s not possible for me to agree more with the first point. I have, perhaps unsurprisingly, some thoughts on the second.

Because where Luke sees an “over-reliance” on screens, I see a foundation.

---

First of all, it’s worth noting that we’ve been here before. The BBC, who’ve been publicly experimenting with responsive design for a year or so now, wrote this some time back:

The early responsive design literature talked about fluidity of the layout and embracing uncertain and uneven properties of web browsers but the early pioneering efforts have stopped at responsive web design, in essence an interaction and CSS problem ignoring the other aspects of the many and varied types of http clients.

I think over the coming months responsive design will evolve in to other areas, responsive bandwidth design, responsive cpu design, responsive content design, taking the mobile first approach to more than just screen width and applying it to all the properties a web client might possess.

I’m not sure we need to start slapping a “responsive” prefix on everything web-related. But what the BBC’s saying is that thinking responsively about your layout doesn’t encompass all the complexity we need to plan for on a daily basis. A well-built responsive site will work just about anywhere—even on devices that weren’t around when the site launched—but it’s just the first step. Because at this point, the common thread between the overwhelming majority of these weird, wonderful devices is still the screen, and our work begins there.

That’s not to say problems of physical location, bandwidth usage, gestural or voice-driven interfaces, or [noun] aren’t interesting—they absolutely are—but that doesn’t diminish just how important it is to start with the screen. It’s most accessible to us, perhaps, given how much time our industry’s spent designing for it. But just because the screen is “easier” than those other, newer problems doesn’t mean that it’s less important. (Or, you know, “easy” to design for in its own right.) So, yes, the landscape’s getting more interesting, and much more complex, but screens are still very much our baseline. Our foundation.

Because to consider a design “responsive,” you only need three things:

1. A fluid or flexible grid;
2. Flexible images and media;
3. Media queries.

That’s it. A fluid layout that, through some CSS3 magic, responds to a resizing browser window, or the changing size of a device’s viewport. But from there, the rest of the design’s execution is left as an exercise to the reader. You could produce a site that’s a few megabytes too heavy, or you could build for speed and aesthetics; your responsive design could break if JavaScript doesn’t reach the user’s browser, or you could ensure your site’s available to just about every web-accessible device on the planet. Heck, you could even use server-side device detection, if you find some value in it. (I do not.)

In other words, responsive design’s emphasis on screens isn’t a liability, or a risk…unless we stop there. There’s always more you can do to produce better, more adaptive content; to ensure you’re delivering assets responsibly; to design for new and emerging input modes; and so on.

---

If you’ve seen me speak in the past year or two, chances are I’ve gushed about this book by Stewart Brand called How Buildings Learn. I love it dearly, and reread from time to time. It’s one of those books that has nothing to do with web design, but every working web professional should really read it. (Also, it’s a great fucking read.)

Early on, Brand introduces this notion of shearing layers to describe how a building might age and change at different rates of time:

1. The site is the legally defined lot on which the building stands;
2. The structure is the foundation and load-bearing elements: this is, basically, the building;
3. The skin is the exterior surface;

…and so on, and so forth, moving further toward the interior until you reach the stuff—the lamps, chairs, toothbrushes, small dogs, and so on—that actually occupies the building.

In Brand’s mind, these layers are a mix of “slow” and “quick” systems: some layers are fairly resistant to change, but they provide boundaries and scope for the faster-moving, churn-heavy systems. So while a building’s geographical boundaries are incredibly expensive to redesign or change, they provide a shape for the foundation, which shapes the façade, and so on.

Anyway, Brand boils all this down into one design principle:

Slow constrains quick; slow controls quick.

As I read it, Brand’s arguing that to plan for future growth in an architectural system, you have to understand the slow layers in front of you. You can develop a building that ages, one that meets the needs of its current residents, but can also evolve over time.

I was thinking about Brand and his shearing layers when I read Luke’s concern about responsive design’s perhaps too-broad focus:

Once again, this kind of “support everything” thinking embraces the diversity of the Web whole-heartedly. However it puts the burden on each and every user to understand different modes, when they are appropriate, and change things accordingly. (Personally I feel we should be able to provide an optimal experience without requiring people to work for it.)

Maybe unsurprisingly, I disagree. I’ve argued that, in a responsive design, our true slow system isn’t layout or interface, but content: the information the user came to read, or the tasks they came to perform. We should, whenever possible, be designing for content parity across the web, ensuring users can access their words and perform their tasks—regardless of the device they have on hand, or the context they’re currently in.

There are, of course, always exceptions: while there might be broad agreement across all the views of your site, you might decide that certain segments of your audience actually need different content, or that users of a certain device class would benefit from different features. But the deciding factor in figuring that out isn’t the devices themselves, but ample research and a well-informed content strategy. Otherwise, if we’re focusing on the devices themselves, I worry we’re looking for opportunities to fragment by default.

More importantly, I think we’re looking at a false dichotomy: device-optimized experiences and a more holistic design approach aren’t necessarily incompatible. It’s not an either/or proposition. If you’re designing responsively, it doesn’t preclude you exploring other, more device-focused strategies like the ones Luke outlines. For example, if that app store visibility is a benefit to your business needs and your audience, why not provide both a responsive web site and a native mobile application?

But there’s a larger point here: in the midst of all these emerging input modes and the constant development of new device classes, I wonder if the role of the designer might be changing subtly.

When Craig Mod released Bibliotype, a typographically lush set of HTML templates designed for reading on tablets, he explained that:

The most important point to consider in tablet editorial design is that tablets are some of the first digital screens to be engaged at a variety of distances. Until now, a desktop screen was always a few feet away from one’s face. Or, with smart phones, at arms length. No longer with tablets.

Now, Craig couldn’t detect the distance of the tablet from the reader’s eye. No amount of code, front- or back-end, would have allowed him to do that. So instead, he designed for three different reading distances—“Bed”, “Knee”, and “Breakfast”—and allowed them to customize the experience. In other words, he exposed a seam in his work, gave the reader control some measure of control over the experience and, in doing so, made that seam more valuable.

Now, I agree with Luke to a point: foisting preferences on our interfaces is potentially inelegant and, of course, should be done delicately. (If at all.) But I really think our job, as designers, will increasingly involve looking for options like this. For example, it’ll still be our responsibility to design some smart defaults for how some piece of the interface might adapt—but we might also give the user an easy override, so she might make the experience more valuable to her.

In other words, the ever-evolving device landscape isn’t something we get to “manage”. This is not a game we win. We will, of course, come up with new and innovative approaches, and Luke does a beautiful job outlining a few. (He’s even directly responsible for dreaming up some of them.) But let’s take the longer view: given how problematic and fuzzy this notion of “context” really is, the number of problems we can solve automatically for our users is dwindling. We can’t know reliably how much bandwidth a user might have available to them, whether they’re outside or stationary, or whether they’re mirroring their display to a wider screen—or, or, or. No amount of code—front- or back-end—is going to fix that. What I think we can do, however, is solve the problems we can, and then acknowledge the gaps. Let’s invite our users into some of these problems, and let them help us provide that “optimal experience”—the one they want at that point in time.

As we do, and as we’re given more tools to address those new capabilities, we’ll be able to better cater to them. We’ll be able to do a better job of ensuring our work’s as bandwidth-sensitive as possible, and can even begin tinkering with new input-friendly ideas of our own. But by focusing on that flexible layout first, I think we’ve got a strong foundation for the future.

Responsive design might begin with the screen, but it doesn’t end there. I can’t wait to see where it goes next.

---