Responsive Web Design, Second Edition

I read the first edition of Ethan Marcotte’s Responsive Web Design when it came out and just today finished reading the second edition. Ethan is a wonderful writer, making me laugh and keeping my attention, even when the division sign is used a lot.

I love this book. As I’ve said before, the A Book Apart crew are fantastic at working with an author so the books always seem like I’m hanging out with a friend. This new edition of RWD is no different. Ethan, as I’ve come to know him over the past few years, is super smart and one of the most humble people I’ve ever met. Those qualities shine through, along with his sense of humor.

I highlighted away in this book, but some of what I highlighted were sentences I particularly enjoyed. Yes, the techniques and approach of RWD are fantastically explained, but I also read this book as a writer trying to learn more about how to write well, and I wasn’t let down on that score.

If you aren’t quite sure if you should read this book, I believe the second edition is worth your time. It reinforced many of the things I do every day as I work with clients, while at the same time reminding me of other concepts that I may not use as often, but maybe I should.

Well done Ethan and thank you for the update.

I read the epub version and my highlights are below.

Because let’s face it: once they’re published online, our designs are immediately at the mercy of the people who view them—to their font settings, to the color of their displays, to the shape and size of their browser windows. (p 17)

The long and short of it is that we’re designing for more devices, more input types, more resolutions than ever before. The web has moved beyond the desktop, and it’s not turning back. (p 23)

But I do think fragmenting our content across different “device-optimized” experiences is a losing proposition, or at least an unsustainable one. As the past few years have shown us, we simply can’t compete with the pace of technology. Are we really going to create a custom experience for every new browser or device that appears? (p 24)

Rather than creating disconnected designs, each tailored to a particular device or browser, we should instead treat them as facets of the same experience. In other words, we can craft sites that are not only more flexible, but that can adapt to the media that renders them. (p 29)

If you’re already a front-end developer, well, pretend you’re also wearing a pirate hat. (p 48)

Quick aside: If you’re at all like me, the word “math” causes immediate and serious panic. But speaking as someone who took a philosophy course for his college math credit, don’t run screaming into the hills quite yet. I rely on my computer’s calculator program heavily, and simply paste the result into my CSS. That keeps me from really having to, you know, do the math. (p 54)

…[B]rowsers are perfectly adept at rounding off those excess decimal places as they internally convert the values to pixels. So giving them more information, not less, will net you a better result in the end. (p 58)

But the first time I had to build on a flexible grid, I had no idea where to begin. So I did what I do every time I’m faced with a problem I don’t know how to solve: I avoided it entirely, and started working on something else. (p 60)

In other words, every aspect of our grid—the rows and columns, and the modules draped over them—can be expressed as proportions of their containing element, rather than in unchanging, inflexible pixels. (p 60)

But building a flexible grid isn’t entirely about the math. The target ÷ context = result formula makes it easy to articulate those proportions into stylesheet-ready percentages, sure—but ultimately, we need to break our habit of translating pixels from Photoshop directly into our CSS, and focus our attention on the proportions behind our designs. It’s about becoming context-aware: better understanding the ratio-based relationships between element and container. (p 98)

(Sharp-eyed readers will note that I’m using a b element for a non-semantic hook. Now, some designers might use a span element instead. Me, I like the terseness of shorter tags like b or i for non-semantic markup.) (p 101)

Now, as you can see, this isn’t really a workable solution. In fact, I’ve found that in the overwhelming majority of cases, overflow is generally less useful than scaling the image via max-width. But still, it’s an option to consider, and one you might find some use for. (p 142)

Flexible or completely fluid, it didn’t matter: I felt that building some measure of fluidity into our designs better prepared them for the changes inherent to the web: changes in the user’s browser window size, in display or device resolution. What’s more, I’d often use words like “future-proof” and “device-agnostic” when describing the need for this flexibility. Often while standing alone at parties. (p 150)

This isn’t a problem unique to flexible layouts, however. No design, fixed or fluid, scales well beyond the context for which it was originally designed. (p 165)

The moral of this story? Research your target devices and browsers thoroughly for the query features they do support, and test accordingly. (p 181)

By conditionally loading style rules that target these ranges, media queries allow us to create pages that are more sensitive to the needs of the devices that render them. (p 182)

…[T]hat only highlights the need to build your responsive design atop a flexible foundation, ensuring your design has some measure of device and resolution independence. (p 226)

A truly responsive design begins with a flexible layout, with media queries layered upon that non-fixed foundation. There are a number of arguments for this, most notably that a flexible layout provides a rich fallback for JavaScript- and @media-blind devices and browsers. (p 227)

…[S]tarting from a flexible foundation means we have less code to produce. When working with media queries, fixed-width layouts often need to be re-coded at every resolution breakpoint, whereas a design built with percentages, not pixels, maintains its proportions from one resolution to the next. As we’ve seen in this chapter, we can selectively remove or change the properties at each breakpoint, optimizing our layout with a few quick edits. (p 228)

But this is the challenge facing us: we simply can’t keep up with the different resolutions and form factors entering the marketplace. The web is, after all, meant to be viewed everywhere. A flexible layout provides us with a foundation for the future: it allows us to step back from targeting individual resolutions, and better prepare our designs for devices that haven’t even been imagined yet. (p 229)

…[T]he flexibility of a design doesn’t have to be a liability. Instead, it can be another opportunity to practice our craft, to better communicate with a certain class of users, or to solve another set of problems affecting a particular type of device. (p 238)

It’s absolutely fair to assume a user’s context from their device, but it’s just that: an assumption. (p 245)

And it’s not just the “mobile context” that’s fuzzy, either: what does a “desktop” user look like, anyway? Sure, they might be seated at a desk, with a high-speed connection available to them—or they might be tethered to a phone, or connected to a spotty hotel network. “Mobile” and “desktop” are useful shorthand terms, but they’re just that—shorthand terms that can, if we’re not careful, mask a lot of complexity. (p 245)

…[R]elying upon all-too-convenient terms like “mobile” and “desktop” is no substitute for conducting the proper research into how your audience accesses your site: not only the devices and browsers they use, but how, where, and why they use them. (246)

So while I agree with mobile web designers who say that certain users of certain sites deserve different content, I think the reverse is also true: many sites can benefit from serving one document up to multiple contexts or devices. And those are the perfect candidates for a responsive approach. (p 248)

But just because desktop users can sift through more content, does that mean they need to? In other words, why is easy access to key tasks only the domain of mobile users? Why can’t all users of our sites enjoy the same level of focused, curated content? (p 253)

In other words, designing for mobile devices first can enrich the experience for all users, by providing the element often missing from modern web design: focus. (p 257)

“Prototyping before the designs are final, you say?” Absolutely, I say. Our goal is to get beyond the pixel limitations of Photoshop, and begin building a design that can flex and grow inside a changing browser window, that can scale to different devices. (p 262)

If you want to test how your page is going to perform on a given device, there’s no substitute for viewing it on the actual device. (p 265)

During this development process, a prototype begins to take shape. It’s based on the initial mockup supplied by the design team, of course, but as the development team codes they begin making recommendations about how the design should respond to different devices. In other words, during this collaboration the developers act as designers, too; they’re just designing in a different medium. They’re making design recommendations within the browser, rather than in Photoshop—recommendations that will be shared, tested, and vetted by the entire team. (p 266)

The key is to make this design/development cycle as iterative as it needs to be, with both groups constantly refining their work, and then sharing it with the group for review. (p 275)

If a browser without media query support accesses the Globe, they’re given an attractive, single-column layout if our JavaScript patch isn’t available to them (p 290)

…[P]rogressive enhancement has been the cornerstone for most modern responsive designs. (p 299)

…[T]hey’re designing for experience tiers: a basic design served to every device; and a more enhanced version, conditionally served to more capable browsers. The result is a responsive design that loads quickly in every HTML-capable device, but then upgrades to a more robust interface—but only if the browser is deemed capable of handling the more enhanced experience (p 302)

…[W]eb design is about asking the right questions. And really, that’s what responsive web design is: a possible solution, a way to more fully design for the web’s inherent flexibility. (p 321)