Responsive Design: Patterns & Principles

I spent my Sunday afternoon reading Ethan Marcotte’s new book Responsive Design: Patterns & Principles, much of it in front of a fire, under a blanket, gobbling up the words as fast as I could. It was a great way to spend a Sunday. And I’m grateful to Ethan for sharing his wisdom with us yet again.

I’ve read Responsive Web Design, twice in fact. It opened up an entire new world for me as a person interested in design, but making her living doing implementations of designs done by others. And now, with this new book, Ethan is at it again.

I devoured the chapter on navigation, I’ve worked on numerous projects where navigation, complex navigation in particular, was tough to figure out as we worked across screen sizes. I also particularly loved the discussion of advertising and how that fits into the complex systems we are creating. This is hard, really hard. Especially when it comes to advertising, there is a lot of discussion going on, a lot of people working on it, and I for one am interested to see where this all goes.

But it is in the final chapter that I think Ethan’s ideas really shine. Because it’s there that we get to the really hard part, making sure that all these modules and pieces fit together well in a screen. That we don’t get too caught up in the modules that we forget they live alongside each other. The chapter references so many people’s ideas here and it brings them together in a seamless and easy to understand way.

I’m still thinking and contemplating a lot of this, because as a style guide lover I love the lego pieces, but I know they must work together well. And this chapter brought up a lot of interesting ideas from other fields, such as animation, as a way to think through these issues. Which is yet another strength of Ethan’s writing: using things he’s read from other fields to apply them to the world of the web in ways that are unique and helpful.

There is no right or wrong way to do this work, but Ethan gives us fantastic ideas for what to think about as we are working through our designs, both at the modular level and along the seams of those modules as they come together to form what we see on our screens.

This book ties so much of the wonderful research Ethan’s done regarding how teams are working as well as the podcast interviews he does with Karen McGrane, that it’s a valuable resource for anyone working on the web.

On a completely personal note: lately I’ve felt a bit disconnected from the web, and I haven’t been as interested in it as in the past. The ebb and flow of life I suppose. But reading Ethan’s book this past weekend got me excited again. That doesn’t mean that I didn’t still wake up to a slew of Github issues of the mundane fixes that aren’t always fun on Monday morning, but it reminds me there are larger discussions occurring that I find fascinating and want to participate in. Thank you Ethan for all you share with our community. And thank you A Book Apart for all you do to facilitate that, as usual you’ve knocked it out of the park.

I read the epub version of the book in iBooks (love those mini movies!), I’ve got page numbers here, but that’s so dependent on font sizing, etc that I’m not sure it helps, so I’ve broken things down by chapter as well.

Chapter 1

“I’d argue that we’re no longer building pages at all—instead, we need to think of our responsive designs as a network of small layout systems (FIG 1.6). Little pockets of design that can, as Trent says, “be rearranged at any screen size to best convey a message.” (p 14)

…[O]ur interfaces are composed of small layout systems, each with its own rules for how it should change, shift, and grow according to the needs of the content inside it. (p 16)

Designing a responsive grid is wonderful, but how do we ensure our images are as recognizable on the smallest screens as they are on the widest ones? How can we possibly fit dense, complex navigation menus into fluid layouts? Can we incorporate advertising into our responsive grids without sobbing heavily? (p. 17)

…[T]hey’re [style guides] inventories of all the “blocks” used to build more complex interfaces. (p. 21)

…[F]ields as diverse as architecture, automotive manufacturing, and shipbuilding long ago shifted their focus to becoming assemblers of finished components: of building larger, more complex machines out of smaller, more specialized parts. (p 22)

…[I]t seems that whenever we start to figure the web out—even a little bit—the landscape shifts.. (p 26)

Almost each month, hardware and software vendors introduce new interaction models for us to support in our designs. (p 26)

And the network we use to browse the web, publish our work, and connect with our audiences is more widely accessed today than at any other point in the web’s short history. But with sub-3G connections comprising the overwhelming majority of mobile data subscriptions, that network is also far slower, more volatile, and less reliable than we might like to think. (p 27)

Chapter 2

Because if we’ve done our job right, a website’s navigation should act as a kind of compass: it helps new users orient themselves within a site hierarchy, and guides them to their destination. (p 34)

The responsive design of a site’s navigation poses an almost entirely different challenge than a page’s top-level grid. In dealing with challenges of layout, interaction, and visual density, we’re forced to ask ourselves: how can we design navigation that’s as usable as it is responsive? (p 34)

But more broadly, there’s a considerable drawback to using CSS to hide information on smaller screens: namely, that the browser will still download all the HTML for a hidden element, even if the styles hide it from view. (p 53)

It’s worth noting that conditional loading isn’t about providing “desktop” users with more content, or “mobile” users with less. Rather, conditional loading can help us address problems of density in your design, ensuring that the information shown to our readers never overwhelms them. (p 60)

Adopting this “mobile first” mindset won’t necessarily change the implementation, but it will inform the way you plan the design of your conditionally loaded content. It’ll help avoid the trap of thinking of smaller screens as somehow deserving of “less” content—especially when our audiences are becoming increasingly (if not exclusively) mobile-oriented. (p 61)

In the face of some seemingly incompatible results, I think this demonstrates that the hamburger icon, like all design patterns, is worth testing on your site. (p 73)

There’s nothing inherently wrong with the hamburger icon itself—but assuming it’s a safe default for every responsive navigation system can be problematic. After all, what works for one site may not work for yours. So by all means, hamburger your sites! Just be sure to test those hamburgers before serving them up to your audience. (p 73)

On smaller and midsize breakpoints, tapping on the hamburger reveals their site navigation which, if you’ll count, contains every link ever created on the World Wide Web. (p 74)

…[T]heir design illustrates a larger problem with concealing navigation: that, given the option to hide them, our menus can easily become filled with an overwhelming (and perhaps unhelpful) number of links. (p 89)

…[I]f we’re hiding or removing an element because it doesn’t have value on smaller screens, can we simplify the design and content of that element until it works on smaller screens? Or, alternately, maybe it doesn’t have value for any screen? (p 91)

If we’re truly designing mobile-first, we shouldn’t use show/hide toggles to sidestep the potentially difficult discussions about the real value of our content. (p 92)

As you may have guessed, this is a JavaScript-driven solution. When the page loads, resizes, or gets reoriented in a handheld browser, the BBC measures the width of the browser’s viewport and then, based on its width, shows or hides certain links in each menu. The panels that expand when you tap or click on “More” or “Sections” are JavaScript-generated too, populated with any links that happen to be hidden in the parent menu at that breakpoint. (p 98)

…[H]e credits their menu design to three factors: a close analysis of their design goals; rapid iteration of a number of possible solutions; and—perhaps most important—involving their users as early as possible in the design process… (p 103)

But if you happen to work more quickly in a traditional design application, there’s no reason to abandon a tried and trusted app for your nearest code editor. Instead, it’s more important to acknowledge that each tool has strengths and weaknesses, and whichever path gets you to a responsive design first is the one you should take. (p 106)

I think we’re seeing the lessening importance of comps as an end point: as a client-facing design document or the definitive deliverable. Digital agencies and design teams still use Photoshop or Illustrator mockups to discuss aesthetics or composition options—but our industry still lacks a design tool that reflects the instability of the networks we design for, the various interaction modes available on our users’ devices, and the flexibility of the web’s canvas. (p 107)

…[R]ather than taking a complex approach, maybe we should look for opportunities to do less. (p 110)

…[P]atterns don’t have to be universally applied throughout a site. Instead, we can be selective and nuanced in deciding how, where, and why we use those patterns in our work. (p 112)

… [W]ith all the challenges we face on the web, we should constantly search for opportunities to simplify our interfaces. (p 115)

Chapter 3

Now, to be clear: “small screen” does not imply “slow connection.” Far from it. In fact, there is no correlation between the width of a screen and the amount of bandwidth available to it. (p 148)

…[W]hile some things in our responsive images toolkit allow us a higher degree of control, determining the best resolution for our image is best left to the browser. It’ll keep our markup lighter, and our users happier. (p 157)

The problem with CSS-based resizing is that it’s content-blind: it focuses on the shape of the container that holds the image, not the image itself. And sometimes, if we’re not paying attention, those images can be resized past the point of usefulness. (p 167)

…[T]hat feels like the biggest challenge: to reframe the discussion to focus not on a specific technology, but on relinquishing perfect control over the experience. (p 181)

Chapter 4

Responsive advertising is still very much a work in progress, but there are a number of emerging patterns we can use. (p 189)

But Boulton gets to the root of some deeper, business-related issues—namely, the advertising industry operates independently from the rest of the web, and still considers the sale of digital ads in print-centric, position-specific terms. (p 220)

Like our responsive layouts, our ads need to become not just more fluid in shape, but also in delivery. And while the advertising industry has yet to modernize their layout standards or business practices, many organizations have opted to try and fix responsive advertising internally, by designing and developing custom-built, more flexible ad formats in-house. (p 222)

Rather than seeing digital advertising as somehow incompatible with an elegant, reader-friendly design, publishers are suggesting that flexible, responsive-friendly ads result in happier advertisers and readers. (p 224)

Chapter 5

As responsive designers, we need to focus not just on the individual bits of a design, but also the relationship between those elements within a larger layout system. (p 227)

CSS frameworks are conceptually heavy. The layouts they provide are bound to an ideal grid, usually with twelve or sixteen columns of uniform widths. From there, the classes in the markup describe how that grid should adapt at specific breakpoints. (p 235)

These principles were a kind of a shared vocabulary, one that allowed the studio’s animators to discuss how their work measured up to Disney’s famously high standards. Rather than dictating the use of certain animation techniques or emphasizing steps in their production workflow, the principles allowed the studio to discuss and evaluate the quality of its work. (p 250)

In other words, how do we move beyond thinking in terms of columns and rows, and start talking about the quality of our responsive designs? And what would frameworks to support that look like? (p 252)

By understanding the shape of our content, we can create flexible layouts that support connectedness—not just between related pieces of information, but between our layouts and the device. We can make responsive grid systems that don’t just fit on an ever-increasing number of screens—they’ll feel at home, wherever they’re viewed. (p 256)

But first, we need a method of finding an element’s seams, and understanding how it loses its shape. For me, that process begins by looking at four characteristics: width, hierarchy, interaction, and density. (p 257)

…[R]egardless of how you choose to find the seams in your layout, moving beyond simple markup classes will give you considerably more flexibility. (p 271)

As we move away from device- specific breakpoints, and adapt our layout systems according to the location of their seams, we’ll be creating more robust, more future-friendly layouts. In other words, we’ll be better prepared for the devices and browsers we haven’t even imagined yet. (p 285)

We’ve moved far beyond the desktop, but we’re still trying to find the right words to encompass the scope of what we’re designing and where it’ll appear. (p 287)

I find it helpful to talk about features, not device classes. For example, I’ll often talk with clients about how a responsive design performs across a few broad categories, usually focusing on input method, screen size, network speed, and network condition. (p 291)

As our layouts become more flexible and device-agnostic, the words we use to talk about our responsive designs should follow suit. (p 292)