The Only Constant is Change: A Q&A with Ethan Marcotte

It’s here: a new edition of Responsive Web Design is now available from A Book Apart! Our editor-in-chief, Sara Wachter-Boettcher, sat down with Ethan Marcotte—who first introduced the world to RWD right here in A List Apart back in 2010—to talk about what’s new in the second edition, what he’s been working on lately, and where our industry is going next.

The first edition of Responsive Web Design came out in the summer of 2011. What projects have you been working on for the past three years?

I’ve been fortunate to have worked on some really great stuff. I’ve worked on client projects for publishers—like The Boston Globe and People Magazine—as well as for some ecommerce and financial companies. I cofounded Editorially, a responsive web application for collaborative writing. (And a product I dearly miss using.) More recently, I’ve been doing some in-house consulting to help companies planning to go responsive, including the responsive design workshops I’ve been doing with my friend and colleague Karen McGrane.

Also, Karen and I have a podcast! (Which is an entirely new thing for me to say!) New as the experience might be, it’s been ridiculously fun: we’re interviewing the people who oversee large responsive redesigns at large organizations, and I’ve learned quite a bit.

So I’d say the years since the first edition have been a blur. But it’s been a happy, wonderful blur, and I’ve been learning so much.

Those are some pretty big projects. What have you learned by applying responsive principles to major media sites?

A couple things, I guess.

First, the importance of flat, non-interactive comps has been lessening—at least in my practice. They’re still incredibly valuable, mind—nothing’s better than Photoshop or Illustrator for talking about layout and aesthetics—but prototypes, even rough ones, are much more important to early discussions around content, design, and functionality. So yeah, I’m with Dan Mall: we need to decide in the browser as soon as we can.

Related to that: since working on The Boston Globe back in 2011, I try to incorporate devices as early as possible in design reviews. Does a great job reinforcing that there’s no canonical, “true” version of the design. Getting a prototype in someone’s hands is incredibly effective—it’s worth dozens of mockups.

All right, let’s talk about the book. What changes will readers see in the second edition?

The second edition’s changed quite a bit from the first, but the table of contents hasn’t: as in the first edition, the chapters revolve around the three “ingredients” of a responsive design—fluid grids, flexible images, and media queries—and how they work in concert to produce a responsive design.

But if you look past the chapter headings, you’ll see a slew of changes. As ALA’s readers probably know, tons of people have written about how to work responsively—whenever possible, tips and resources have been pulled in. (I mean, heck: we now have a responsive images specification, which gets a brief but important mention.) On top of all of that, errors were corrected; broken links fixed; figures updated; questions I’ve received from readers over the years have, whenever possible, been incorporated. I can’t tell you how good it feels to have those edits in—it feels like it’s the book it should’ve been.

But even more than that, it was incredibly exciting to revisit the sheer volume of responsive sites that’ve been launched since I first wrote the article. Pulling in screenshots of so many beautiful responsive sites was, well, a real joy.

And finally, I’d be remiss if I didn’t mention that Anna Debenham was the technical editor. Anna is a talented writer, speaker, and front-end developer; she’s also the co-founder of Styleguides.io, and responsible for invaluable research into the various web browsers on handheld game consoles. I don’t know how she found the time to review my second edition, but I’m impossibly grateful she did: the book is better for her criticisms, her insightful questions, and her great suggestions.

You mentioned your podcast with Karen earlier. I’m personally a huge fan. It’s fascinating to hear how all kinds of different organizations, like Harvard, Fidelity, and Marriott, have gone responsive. What have you learned from having diverse teams tell you about their projects?

I think part of responsive design’s appeal is we realized our old ways of working weren’t, well, working. Siloing our designs into device-specific experiences might work for some projects, but that “mobile site vs. desktop site” approach isn’t sustainable. So as we began designing for more screens, more device classes, and more things than ever before, the device-agnostic flexibility at the heart of responsive design—or, heck, at the heart of the web—is appealing to many.

But as teams and companies design responsively, they often find their challenges go beyond the code—advertising or content workflows need to be optimized for multi-device work, both of which are infinitely more challenging than flexible layouts and squishy images.

Frequently, one of the biggest challenges is the relationship between design and development: in many organizations and project teams, they’re discrete groups that only overlap at certain points in a project. That old idea of “handoff” between design and technology is where problems most commonly pop up.

In other words, I think we’re at a point where treating “design” and “development” as discrete teams is a liability. The BBC wrote about this problem beautifully: when we’re designing for a web that’s not just flexible, but volatile—“in a constant state of flux,” even—we need to iterate more quickly, and collaborate more closely. And a closer relationship between design and development is a large part of that.

What do you think is the biggest misperception about RWD?

If you’ve read anything about responsive design, you’ve probably come across it: this suggestion that responsive design is somehow incompatible with performance. In other words, if you care about building a site that loads quickly for your users—and you do, right?—then you should steer clear of responsive design.

So, what’s the reality, then?

The idea that responsive design can’t be fast is, bluntly, false. As everyone from Filament Group to The Guardian to the British Government have shown us, you can have responsive designs that are as fast as they are flexible. It just takes careful planning, as well as an acknowledgement that performance isn’t just a technical issue—it’s everyone’s problem. There’s even data to suggest that responsive sites are faster than mobile-specific “m-dot” sites. But even so, the suggestion still floats around.

That said, I confess I’m not too worried. Because when it comes to the whole “responsive design is bad for performance” myth, I’m with Tim Kadlec: anything that gets people discussing performance, even a misconception, is great. And on most of my projects, the result of that conversation is usually a site that’s both lightweight and responsive.

(Thankfully, Scott Jehl’s new book, Responsible Responsive Design, dives into these questions with gusto.)

It’s awesome to see people making such great strides on performance. What other challenges do you see RWD needing to overcome in the next year or two?

It’s a bit difficult to focus on one in particular: process is a big concern, as I mentioned above; there are lots of discussions around the best way to do multi-device QA/testing; and I get lots of questions about how to tackle more challenging design patterns.

More broadly, I often say the most common words you hear in a responsive redesign—“mobile,” “tablet,” and “desktop”—are also the most problematic. Quick example: “mobile” is frequently used as a proxy for a “small touchscreen, limited bandwidth.” But what if the “mobile” user’s connected to wifi? Or the “desktop” user’s tethered to a spotty 3G connection? Shorthand terms can be helpful, it’s true, but it’s often more productive to discuss specific challenges: challenges like screen size, CPU/GPU quality, input mode, network quality, and so on, and design for each independent of specific device classes.

I mention this because, now more than when I wrote the book, responsive design isn’t about designing for “mobile.” It’s about designing for the web, a medium that’s both flexible and device-agnostic by default. And while we’re looking ahead with excitement (and maybe some trepidation) to the next big thing, I think it’s worth remembering that thinking device-agnostically can be a real, real strength.

It sounds like we’ll be busy figuring this stuff out for a while. What would you recommend to a reader who’s just getting started—besides cough buying your book, of course? How can they keep from losing their shit at all the new stuff to learn?

First of all: if someone figures out how to not freak out at how quickly things change? Please do email me. I’d love to know your secret. (Please.)

When the browsers are especially bad, when the layout doesn’t seem to be gelling, I reread John Allsopp’s “A Dao Of Web Design.” Really. Honestly, the idea that we can’t control the display of our work is actually pretty freeing. We can guide it, shape it, but we can’t know if the user’s network connection is reliable, or if their browser runs JavaScript, or whether our layout will be shown on a screen that is large or small (or very, very small).

The only constant we have on the web is the rate of change. And progressive enhancement is the best way for us to manage that. That’s why I always turn back to “A Dao Of Web Design.” Not just because it was a huge influence on me, and a direct influence on responsive web design: but because now, more than ever, we have to accept “the ebb and flow of things” on the web.

Let’s get started.

Pick up your copy of the second edition of Responsive Web Design from A Book Apart.