Responsible Responsive Design

Last week, just before the holiday, I finished Scott Jehl’s book, Responsible Responsive Design and it is a great book. I was blown away from the very first chapter. I love smaller books because all the information that makes it into them is usually the most useful and this book came through in that department. In addition to what Scott writes himself, he links to so much more on the web that you could get lost for days in reading about performance and techniques for making your RWD site faster.

But in addition to this, the thing I realized as I read this book, is that I really love the way the A Book Apart editors are so fantastic at bringing out the personalities of the writers in their series. Each book feels so much like I am sitting over beers talking with the author. This is the true genius of both this book and the entire series. Well done ABA.

I read the epub version of the book and my highlights are below:

We’d been building an app for users like us. But we were the exception, not the rule. (p. 13)

We web developers tend to be an exceptional bunch. Our work demands fast, reliable networks to stream enormous amounts of data, and we have access to the latest, most capable devices. But while many of us work in relatively ideal conditions, we can’t just build for users like us; we can’t forget that for most of the world, the web doesn’t function like this. (p. 13)

Accessing the web reliably and efficiently isn’t a given for many of our neighbors, our users, our customers. As web designers, we’re well poised to improve this situation. I mention customers to emphasize that pushing for better access is not only an appeal for empathy, but also an opportunity to expand the reach of our services, making them more resilient for everyone (p. 14)

This book is about accessibility: broadening access to the services we make without compromising features that push the web ahead. Diversity is a defining feature of the web, not a bug. We should strive to make our content and services accessible to all capable devices. If that sounds hard, well, sometimes it is. I intend to convince you that it’s possible, and that it’s worth it. (p. 14)

The goal is to move into the browser as quickly as we can to make design and interaction decisions in context, which translates to more informed recommendations for our clients. (p 43)

… [W]e shouldn’t choose breakpoints at all. Instead, we should find them, using our content as a guide. (p 45)

… [W]e should build and document our components from the inside out, as standalone pieces that play nicely with others. (p. 50)

This doesn’t mean we should avoid building custom gestures, but it highlights the importance of developing for many input modes. If one fails for any reason, we’ll have alternate ways to access our content. (p 72)

As we continue to push HTML toward new interactivity, it’s critical that we think of access as something we constantly risk losing, as something we must retain throughout our development process. (p. 80)

Any time you venture beyond standard browser rendering of HTML into building your own presentation and interactivity, you’re responsible for accessibility…. (p. 81)

It’s a fine line between an enhancement and a hindrance, one that we as responsible developers must carefully walk. (p. 103)

… [S]o a browser may receive a bells-and-whistles A-grade experience for one component and a less-enhanced B-grade experience for another. (p. 106)

Designing for features and constraints allows us to see how patterns that may otherwise seem distinct are shared across devices, and to build in a modular manner to create unique experiences that feel appropriate to each device. (p. 124)

Thinking mobile-first also pairs nicely with the mindset of progressive enhancement, aka starting small and layering in more complex layout as space permits. (p. 125)

… [S]upports is pretty handy: it offloads feature detection work to the browser, removing the need for us to write custom—and often slow, unreliable—tests to produce similar results…. (p. 156)

… [O]ur sites are too heavy, and they’re often assembled and delivered in ways that don’t take advantage of how browsers work…. (p. 199)

Responsive design’s very nature involves delivering code that’s ready to respond to conditions that may or may not occur, and delivering code only when and where it’s needed poses some tricky obstacles given our current tool set. (p. 200)

So blocking page rendering until the CSS is ready is certainly desirable as long as the CSS loads in a short period of time—which isn’t always an easy goal to meet. (p. 209)

Good performance is good design, and performance should be a priority from the start rather than an afterthought saved for developers to handle. (p. 221)

Every blocking HTTP request is a barrier between our users and the content they seek. (p. 224)

It’s helpful to identify what portions of the content are absolutely necessary and load the rest later on, after the essentials have been served. This practice is known as deferred or lazy loading. (p. 224)