There seems to be a common belief among front-end developers that progressive enhancement is either old fashioned or has simply been replaced by single page applications. This is a problem of perception. We’d like to explain why we use progressive enhancement to build GOV.UK.
What is progressive enhancement?
Progressive enhancement means building the interface of a website or application in layers. If the user’s browser only supports HTML they get content and forms. If the user’s browser also supports styles and fonts the application looks better. If it can run JavaScript the user gains extra interactions. Only the core HTML though is required in order to meet users’ basic needs.
Obviously there are many places where JavaScript could be seen to be a requirement. It’s hard to imagine intensive web applications like games and online office suites working without JavaScript. Even in these cases though there are possibilities to use progressive enhancement to benefit the user.
For example, take Google’s spreadsheet web application Sheets, which would seem at first glance to be an obvious place where JavaScript might be required. Sure enough, if you load a spreadsheet without JavaScript enabled you get a notice at the top of the page warning you of problems. What’s good though is that in the absence of JavaScript the user is presented with a non-editable view of the data. This feels like a good compromise: without a script layer the interaction is curtailed, but the document still exists.
Progressive enhancement improves resilience
As our previous GOV.UK technical architect said: “progressive enhancement is about resilience as much as it is about inclusiveness.”
Building in resilience is also known as defensive design: a system shouldn’t break wholly if a single part of it fails or isn’t supported.
We have a mandate to provide digital services to everyone in the UK and many beyond. Many users access services in different ways to the configuration tested by developers. If a person visits GOV.UK we want them to be able to complete their service or access the information they need, regardless of whether we’ve tested their configuration or not.
If you arrive on GOV.UK without web fonts support you get a base sans serif instead of our chosen web font New Transport. If GOV.UK is accessed without stylesheets (these describe how documents are presented on screens), the page’s appearance will change, but it’s still usable because we build on semantic HTML. If a user doesn’t experience style in the same way as the majority, for example if they’re using a screenreader or a Braille display, then they’ll be able to access everything they need. Even if a user turns up using Lynx or another non-graphical browser they’ll still get a completely usable experience (as you can see in the image).
It’s important to understand that it’s often not the conscious choice of users to arrive at your site without JavaScript. We did some research and discovered that 0.9% GOV.UK visits are by people who don’t have JavaScript available and haven’t chosen to turn it off. Stuart Langridge gave an excellent explanation of the many ways your JavaScript can fail to run. A non-exhaustive list includes the:
- script hasn’t finished loading, or has stalled and failed to load completely
- application route is up, but the route to the Content Delivery Network is broken
- user has chosen to install a plugin that interferes with the Document Object Model (DOM)
- user has been infected with a plugin that interferes with the DOM
- user’s company has a proxy that blocks some or all JavaScript
- user’s hotel is intercepting the connection and injecting broken JavaScript
- user’s telecoms provider is intercepting the connection and injecting broken JavaScript
- user’s country is intercepting the connection and injecting broken JavaScript
- JavaScript code has functions not implemented by your user’s browser (older browsers, proxy browsers)
There’s also the small number of users who choose to turn off JavaScript manually. What with rampant cross-domain user tracking by advertisers, as well as tracking through analytics and through social media, not to mention malware installation through ad networks, the receipt of unwanted email and the impact on page speed and battery life, it’s not surprising that some people choose to do this. The NoScript Firefox add-on is now the 5th most popular extension with over 2 million users.
Thinking about users leads to progressive enhancement
It’s only natural that as front-end developers we want to flex our technical skills. We can reach new and better solutions to existing problems by pushing the limits of what a browser can do. There’s an issue with lending more of your focus to the possibilities promised by new technology though: your focus moves away from your users.
Meeting our many users’ needs is number one on our list of design principles. We can’t know every different setup a person might use while building our systems, but we can build them in a way that gives all of our users the greatest chance of success. Progressive enhancement lets us do this.
When we say that user needs rarely dictate complexity, that doesn’t mean they never do. Recently we prototyped a web chat system using React. It’s difficult to imagine a base level of web chat that doesn’t require JavaScript, but we will make sure any webchat system we develop has a standard contact form as its barebones.
We’ve also investigated the possibilities that modern JavaScript APIs (especially Service Workers and the associated technology that make up Progressive Web Applications) could give us. These are especially interesting as they’re designed with progressive enhancement at their core.
It’s possible to build single page applications in a progressively enhanced way (also known as Universal Javascript). Instead of a typical blank page when JavaScript isn’t available, the system can fall back to rendering a normal web page on the server, and then progressively enhance that with a full client-side application. This type of build can even benefit users who have JavaScript as they can start interacting with the application before the JavaScript has started to run. Having said that, just because you can doesn’t mean you should. In our experience attempts to build progressively enhanced single page applications are fragile, harder to maintain, and can have unforeseen accessibility issues that need additional work to fix.
In the rapid technical evolution that’s happening in front-end development at the moment user needs are getting left behind. We feel that front-end developers owe it to themselves and their users to pick technologies that help provide a better service, rather than those that are currently trending. That isn’t always easy, but the long-term benefits are worth it.
You can follow Robin on Twitter, sign up now for email updates from this blog or subscribe to the feed.
If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.
8 comments
Comment by Bob posted on
You should consider just using plain html, as Tim originally designed. It loads quickly, is supported by all browsers and should meet nearly all he needs of gov.uk.
I see you already stick to blank and white - you'll be really pleased to cut out the last remnants of styling.
Comment by Ryan Carson posted on
This should be the core prinicple of website design, but sadly is looked over by most design companies nowadays, which is a shame as the majority tend to be chugging as many javascript files through popular plugin based systems without noticing the potential damage to viewers in terms of compatability, usability and speed of loading, let alone accessability.
Glad to see the support for Lynx in particular!
Comment by Jason posted on
This methodology may be appropriate for a general service that should be accessible by everyone (as is the case for GOV>UK), but this doesn't mean that everybody should do the same.
We, as front-end developers, should always be on a quest to improve user interfaces and make them more exciting and engaging for the majority of our users. Which road we take depends on our user base and what other services they use.
Comment by Tim McCormack posted on
And as a user, I can tell you that "exciting and engaging" is often done at the expense of "wow, I can actually use this website". 🙂
*Every* website should start with a baseline that is accessible as described in this post. Making a website that hosts a 3-D FPS game, where the core content totally relies on JS? Well, the rest of your site doesn't. I still want to get to the contact info, about page, FAQ, login, leaderboard... In general, the parts that really need JS are the exception, and they should be built that way.
(And again, as the blog post notes, it's not just about JS -- low page weight, fallbacks when styles are disabled, etc. are important to large segments of the internet.)
Comment by Rikki posted on
Interestingly, this blog has navigation that is not progressively enhanced. Without JS, there's no way to use the right-hand navigation.
Comment by Robin Whittleton posted on
It’s like giving a demo, something will always go wrong! Thanks for the report, I’ll investigate.
Comment by John posted on
Bravo! Far too many web pages are truly horrible and it's encouraging to see GDS making a real effort to produce pages that are accessible to all. Keep up the good work; I hope to see an increase of progressive enhancement across the web.
Comment by Lee posted on
Not an argument against progressive enhancement but, for the cases where javascript had been injected into the page via the network, the GOV.UK sites should be less susceptible if they're enforcing https-only.
And also services should possibly be investigating adoption of Content Security Policy declarations. The last time it was mentioned on this blog was in Feb 2015.
https://gdstechnology.blog.gov.uk/2015/02/12/experimenting-with-content-security-policy-on-gov-uk/