I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

Progressive Enhancement reading list 2021

In March I am going to teach the Progressive Enhancement course of the Web minor at university for the third time. I decided to expand the reading list for this course, and here I present the version I’m going to use in 2021.

Defining progressive enhancement

Let’s start at the original definition of progressive enhancement.

In 2008 Aaron Gustafson published Understanding Progressive Enhancement at A List Apart, and placed progressive enhancement at the forefront of web developer thinking. Aaron did not invent the concept — he points to prior art (slides) by Steve Champeon and Nick Finck. Still, Aaron’s article popularised the concept.

Aaron compares progressive enhancement to its precursor graceful degradation and finds that PE is the better approach — something that has become generally accepted since then. He also described progressive enhancement comprehensively, and we essentially still follow his definition.

Chris Taylor sees progressive enhancement as technical credit, the opposite of the technical debt you incur when you quickly insert some hacks to get the system to work and solemnly resolve to fix them “later.” (Hint: later never comes.) PE is the opposite: it prevents problems from arising, and thus saves you time in the future. The article also contains a useful overview of progressive enhancement principles.

Progressive enhancement also helps you combat browser incompatibilities. Justin Crawford, Chris Mills, and Ali Spivak make the web work for everyone by addressing cross-browser problems and their causes (which mostly come down to web developers not quite knowing what they’re doing). Better browser compatibility leads to better accessibility, and also to better results, since users will switch sites if they encounter problems. The best way to get these results is to practice PE. (And there we go again: PE and accessibility are clearly related. But how exactly?)

Their browser market share notes are worth repeating. Although Chrome is the largest browser, in January 2021 it still has only 63% of the market according to StatCounter. That sounds like a lot, but it means 37% of your users do not use Chrome. Don’t leave them out in the cold.

Does this sound theoretical? Let’s get practical. Robin Whittleton explains why we use progressive enhancement to build GOV.UK and walks you through the decisions. This is still a high-level overview, but it was actually used in an actual major website. We’ll see gov.uk in action later in this reading list.

Progressive enhancement and UX

The Nielsen Norman Group discusses the role of enhancement in web design and shows that progressive enhancement is useful in non-technical contexts as well. Where the previous articles focused on technical issues, this one gives a good theoretical overview of PE from a UX perspective.

What is progressive enhancement’s purpose in user interface design, and how do you decide which functionalities should be progressively enhanced? The article offers a few hardware examples, for instance the mouse wheel, which was a progressive enhancement when it was introduced, and still is, because touchscreen devices as well as keypads lack a wheel (and, in fact, a mouse). Input modes are ruled by PE, too.

Two excellent general rules are worth quoting in full:

1. Don’t add other enhancements that provide the same functionality. [...] You want to give people the chance to practice and strengthen the enhancement; if you add other enhancements for the same interface functionality, it will be less likely that any one of them will get enough use.
2. Be consistent. Use the same enhancement everywhere you can. That is, try to give users many opportunities to practice and thus strengthen the association between the enhancement and its effect in the interface. (Remember, repetition is the mother of retention.) Ideally, designers should use the same enhancements across many different sites, to allow people to learn them.

Aaron Walter created the Hierarchy of User Needs model, which forms the basis of a theory of user delight: why usability is the foundation for delightful experiences, also by the Nielsen Norman Group (image below borrowed from this article).

Delight is all very well, but without a solid foundation of usability, reliability, and functionality it falls flat. If something looks gorgeous but is incomprehensible, doesn’t always work, or doesn’t work at all, it is useless. The relationship between the four layers of user needs is pure progressive enhancement: the next layer is only useful if the layers below it work, and for each functionality you have to decide in which layer(s) to put it.

The PE layers

Let’s return to the technical aspects of progressive enhancement.

In order to progressively enhance a site you first need to define its core functionality. As Andy Bell says, a minimum viable experience makes for a resilient, inclusive website or app. He argues that porting the idea of a minimum viable product to the website experience is a good starting point for your PE project. Which core functionalities are required to give any user the opportunity to finish the task at hand? How do we identify a minimum viable experience, and how do we layer JavaScript functionalities on top of them?

Speaking of layers, Hidde de Vries explains why it's good for users that HTML, CSS and JS are separate languages. He argues that separation of concerns between structure, presentation, and behaviour remains a good thing. This impacts progressive enhancement by forcing you to think about which functionalities you should implement in which layer(s).

So let’s go through the layers.

Layer 1: HTML

Terence Eden discusses the unreasonable effectiveness of simple HTML by telling a story about a user being forced to work on a government-related task on the PlayStation browser (which is — let’s call it not good and leave it at that). The user managed to do what she set out because the site she needed had a simple, good HTML structure that works in any browser. This is what core functionality and minimum viable experience are all about. And you just need HTML to do it.

Dave Rupert created an indispensable list of HTML: the inaccessible parts, where he gives a round-up of accessibility problems with HTML elements. If you want to use any of these HTML elements you should apply the principles of progressive enhancement to make sure they work everywhere. This shows that HTML is not necessarily restricted to the lowest, functional layer but can also enhance (or detract from) the reliable, functional, and pleasurable layers. (Also, it shows yet again there is a close relationship between progressive enhancement and accessibility.)

Léonie Watson wrote a short note on progressive ARIA where she shows that changing the role of an element (here a link to a button; why?; but this happens all the time) also means you should make sure users can click it with the Space key. This is possible for buttons, but not for links, and if you change a link to a button the browser doesn’t automatically add the Space key. So you have to progressively enhance it.

Layer 2: CSS

I have not been able to find specific articles about CSS and progressive enhancement, although they must be out there. I’ll update this section when I find any.

Layer 3: JavaScript

Then we come to the elephant in the room: JavaScript. I mean, everyone has JavaScript, right? As Stuart Langridge shows, this is untrue. Even if the user doesn’t disable JavaScript explicitly there may be many reasons why they don’t have JavaScript.

Incidentally, measuring the number of users who turn off JavaScript is very easy. Just tweet something like “No one turns off JavaScript anyway,” wait for about a day for people to tell you in no uncertain terms they do in fact turn off JavaScript, count these reactions, and you know how many people turn off JavaScript.

Given that JavaScript is a progressive enhancement challenge, not only because it can be absent but also because “modern” web development uses such an incredible amount of it, Jeremy Keith’s 2014 call to be progressive remains relevant today. This article summarises an interesting discussion from those days and contains a lot of excellent points about how to view progressive enhancement, browsers, JavaScript, and more.

Jeremy calls for more server-side components:

Personally, I try not to completely reinvent all the business logic that I’ve already figured out on the server, and then rewrite it all in JavaScript. I prefer to use JavaScript—and specifically Ajax—as a dumb waiter, shuffling data back and forth between the client and server, where the real complexity lies.

I also think that building in this way will take longer …at first. But then on the next project, it takes less time. And on the project after that, it takes less time again. From that perspective, it’s similar to switching from tables for layout to using CSS, or switching from building fixed-with sites to responsive design: the initial learning curve is steep, but then it gets easier over time, until it simply becomes normal.

Did anyone listen to him in the years since 2014? (Hint: no.)

Chris James gives a quick overview of the past web, when things were still good, and describes the Web I Want. Then he gives a useful overview of why we don’t need that much JavaScript in our pages: HTML is already perfectly suited for showing content pages.

Finally, Thomas Steiner explains how to progressively enhance your Progressive Web App by digging into layers of JavaScript support in an advanced article. Assuming JavaScript is present, he gives an example where a simple but insufficient JavaScript is enhanced when the browser supports the File System Access API. He then gives a few other examples of modern APIs and how to feature-detect them. This is on a site by the Chrome devrel team, so it’s Chrome-centric in the features it treats, but the techniques Thomas teaches are applicable anywhere.

Practical examples

Jim Nielsen shows how he is progressively enhancing a small widget. This is a simple, first PE mini-project that is well suited to understand the basic concepts. He uses JavaScript to progressively enhance a static page, and the key takeaway is how the script changes the page’s static content.

Andy Bell (again) studies the power of progressive enhancement. He discusses a (no longer existing) web app in PE terms: start with the core functionality, then layer extras on top. Contains an excellent, simple bit of advice on how to handle the fact that some browsers don’t support CSS grid. This article highlights practical PE decisions and how they work.

Chris Scott created a practical Progressive Enhancement and Data Visualizations example project where he progressively enhances a timeline by first creating a solid HTML structure, then adds some presentational CSS, and then layers JavaScript and SVG on top that changes the presentation considerably.

That’s it. That was the reading list.

If you know of more good articles for the next version you can reach me via Twitter or my contact form.