Resilient Web Design

Jeremy Keith’s talks are some of my favorite I’ve seen over the course of my career when I’ve been lucky enough to be at a conference where he’s speaking. He’s taken a lot of the elements of those talks and put them into a wonderful online book, Resilient Web Design. It’s well worth the time to read it, think about what he’s saying, and consider our past as we move forward.

I’m already a believer in progressive enhancement and much of what Keith covers in the final chapters of the book, but the first two chapters on the history of the web are a great summary of all that has happened to get us to where we are. Keith then goes into the languages and I love how much time he spends on my favorites, HTML and CSS may be declarative, but they are awesome in so many ways, one of which is the simplicity.

If, like me, you like history, you like the web, and you want to take a bit of time to read about them, you should.

In the spirit of the book, I read it in a browser, and I broke up my highlights by chapters. As usual, you should read the book yourself, these highlights are taken out of context and better when you’ve read the whole thing.

Introduction

I didn’t do this purely out of historical interest (although I am fascinated by the already rich history of our young industry). In learning from the past, I believe we can better prepare for the future.

Ideas are more resilient than code.

Chapter 1

Even the most dramatic bounds in technological advancement are only possible when there is some groundwork to build upon.

The protocols underlying the transmission of data on the internet—TCP/IP—describe how packets of data should be moved around, but those protocols care not a whit for the contents of the packets. That allows the internet to be the transport mechanism for all sorts of applications: email, Telnet, FTP, and eventually the World Wide Web.

As soon as there were two web browsers in the world, interoperability and backwards compatibility became important issues.

Chapter 2

This liberal attitude to errors allowed the vocabulary of HTML to grow over time from the original 21 elements to the 121 elements in HTML5. Whenever a new element is introduced to HTML, we know exactly how older browsers will treat it; they will ignore the tags and display the content.

Most HTML elements exist for a reason. They have been created and agreed upon in order to account for specific situations that authors like you and I are likely to encounter.

There are obviously special elements, like the A element, that come bundled with superpowers.

Think for a moment of all the sites out there on the web. There’s a huge variation in visual style: colour schemes, typographic treatments, textures and layouts. All of that variety is made possible by one simple pattern that describes all the CSS ever written

Just because a language is elegant and well‐designed doesn’t mean that people will use it. CSS arrived later than HTML. Designers didn’t spend the intervening years waiting patiently for a way to style their documents on the web. They used what was available to them.

Seeing the same HTML document styled in a multitude of different ways drove home one of the beneficial effects of CSS: separation of concerns.

Designing a loosely‐coupled system can take more work. The payoff is that the overall result is more resilient to failure. Individual parts of the system can be swapped out with a minimum of knock‐on effects.

So HTML and CSS aren’t completely decoupled. They form a partnership but they also have an arrangement. The markup document might decide that it wants to try seeing other style sheets sometimes. Meanwhile, the style sheet could potentially be applied to other documents. They are loosely coupled.

Using CSS for presentation is materially honest—that’s the intended use of CSS. It also allows HTML to be materially honest. Instead of trying to fulfil two roles—structure and presentation—HTML can return to fulfilling its true purpose, marking up the meaning of content.

Chapter 3

Designers had grown accustomed to knowing the dimensions of the rectangles they were designing within. The web removed that constraint.

It was as though the web design community were participating in a shared consensual hallucination. Rather than acknowledge the flexible nature of the browser window, they chose to settle on one set width as the ideal …even if that meant changing the ideal every few years.

The web is not print. The known constraints of paper—its width and height—simply don’t exist. The web isn’t bound by pre‐set dimensions. John Allsopp’s A Dao Of Web Design called on practitioners to acknowledge this

There is another reason why web designers clung to the comfort of their fixed‐width layouts. The tools of the trade encouraged a paper‐like approach to designing for the web.

If web designers wished to remain true to the spirit of One Web, they needed to provide the same core content at the same URL to everyone regardless of their device. At the same time, they needed to be able to create different layouts depending on the screen real‐estate available.

If you can prioritise your content and make it work within the confined space of a small screen, then you will have created a robust, resilient design that you can build upon for larger screen sizes.

Relinquishing control does not mean relinquishing quality. Quite the opposite. In acknowledging the many unknowns involved in designing for the web, designers can craft in a resilient flexible way that is true to the medium.

Chapter 4

HTML and CSS are both examples of declarative languages. An author writing in a declarative language describes a desired outcome without providing step‐by‐step instructions to the computer processing the file.

That’s a pattern that repeats again and again: a solution is created in an imperative language and if it’s popular enough, it migrates to a declarative language over time. When a feature is available in a declarative language, not only is it easier to write, it’s also more robust.

JavaScript gave web designers the power to create websites that were slicker, smoother, and more reactive. The same technology also gave web designers the power to create websites that were sluggish, unwieldy, and more difficult to use.

Web designers would do well to remember what the advertising industry chose to ignore: on the web, the user has the final say.

Whereas HTML can be rendered piece by piece as it is downloaded, a JavaScript file must be downloaded in its entirety before its contents can be parsed. While it’s tempting to think that only a small minority of visitors will miss out on a site’s JavaScript, the truth is that everybody is a non‐JavaScript user until the JavaScript has finished loading …if the JavaScript finishes loading.

It’s tempting to apply the knowledge and learnings from another medium to the web. But it is more structurally honest to uncover the web’s own unique strengths and weaknesses.

Thinking of the web as a platform is a category error. A platform like Flash, iOS, or Android provides stability and certainty, but only under a very specific set of circumstances—your software must be accessed with the right platform‐specific runtime environment. The web provides no such certainty, but it also doesn’t restrict the possible runtime environments.

Platforms are controlled and predictable. The World Wide Web is chaotic and unpredictable.

Chapter 5

Those layers can be loosely‐coupled, but they aren’t completely independent. Just as a building cannot have furniture without first having rooms and walls, a style sheet needs some markup to act upon. The coupling between structure and presentation is handled through selectors in CSS: element selectors, class selectors, and so on. With JavaScript, the coupling is handled through the vocabulary of the Document Object Model, or DOM.

Each of the web’s shearing layers can be peeled back to reveal a layer below. Running that process in reverse—applying each layer in turn—is a key principle of resilient web design.

This layered approach to the web allows the same content to be served up to a wide variety of people. But this doesn’t mean that everyone gets the same experience. Champeon realised that a strong separation of concerns would allow enhancements to be applied according to the capabilities of the end user’s device.

Progressive enhancement asks that designers start from the lowest common denominator (a well marked‐up document), but there is no limit to where they can go from there.

Progressive enhancement means providing core functionality to everyone. After that, it’s every browser for itself. Far from restricting what features you can use, progressive enhancement provides web designers with a way to safely use the latest and greatest features without worrying about older browsers.

Chapter 6

But very few people wake up in the morning looking forward to a day of scrolling and tapping. They’re more likely to think in terms of reading, writing, sharing, buying and selling. Web designers need to see past the surface‐level actions to find the more meaningful verbs beneath.

These are modern browser features that we should be taking full advantage of …once we’ve made sure that we’re providing a basic experience for everyone.

Instead the service, the URLs, and the components you are designing could be experienced in any number of ways. And that’s okay.

Chapter 7

It’s all‐too tempting to quickly declare that an approach is naïve, overly simplistic, and unrealistic. The idea that a website can simultaneously offer universal access to everyone while also providing a rich immersive experience for more capable devices …that also seems hopelessly naïve.

The floodgates are ready to open. We just need you to create the poster child for resilient web design.

If you’re not used to working this way, the first time you do it will take quite some time. But the second time won’t take quite so long. After a while, it will become normal.

A tool is supposed to help people get their work done in a more efficient way. The tool should be subservient to the workflow. All too often, tools instead dictate a preferred way of working.

When I’m confronted with a problem, and I have the choice of making it the user’s problem or my problem, I’ll make it my problem every time. That’s my job.