Unless you’ve always had the privilege of an ultra-fast fibre internet connection, you’ll know the pain that comes with a dodgy connection. Turning the router on and off again, refreshing and re-refreshing your browser to get your fix of cat videos, and being greeted with a slow loading page, possibly with some broken images that don’t display.
It can be incredibly frustrating. Even more so if the website you’re trying to access isn’t for cat videos but for sorting your council tax bill, registering to vote, or something even more urgent like getting the council to repair a problem in your house. As more and more public services have moved online, having a slow internet connection can put you at a real disadvantage. What if you’re unable to pick up the phone or find another offline alternative to accomplish tasks like this?
As builders of digital public services, it’s our responsibility to make sure that what we put in front of users works for everyone, regardless of the speed of their internet connection or other technical issues that might arise. Everyone should be able to access the essential services they need online.
A bit about the work I do as a developer at dxw
For the past year, I’ve been working with the Ministry of Justice (MOJ) on the user interface component of “Refer and Monitor an Intervention”, a service for Probation Practitioners to schedule people on probation onto “interventions”. Interventions are rehabilitative programmes that aim to reduce the risk of reoffending.
Before working at dxw, most of my development work was “full-stack”, covering both what you see in your browser (the frontend) and the underlying data sources behind the scenes (the backend), but with a heavy lean towards the backend side of things like databases, rather than the user interface side of things.
Since joining dxw however, I’ve worked on mostly frontend-heavy projects, including Hackney Council’s Manage a Tenancy service, Mind’s online community called Side by Side, and now, MOJ’s Refer and Monitor an Intervention service. Until recently, I’d always thought of frontend development as being about building a slick user interface with the latest technologies available.
What happens if your users don’t have the fastest internet, the latest technologies, or something goes wrong with your flashy scripts?
Parts of your service could fail to load, essential information may not be displayed to users, the user journey may be straight up broken, or users might not be able to use your site for their needs at all.
How can we protect against this and make our services resilient when things might go wrong?
Enter progressive enhancement
One of the design principles we’ve been following closely on Refer and Monitor is “Progressive enhancement”. Progressive enhancement is a way of building web services following the Rule of Least Power, a design principle by which you write your software in the least powerful language, rather than the most powerful. As Tim Berners-Lee puts it in Principles of Design:
The less powerful the language, the more you can do with the data stored in that language. […] If, for example, a web page with weather data has RDF describing that data, a user can retrieve it as a table, perhaps average it, plot it, deduce things from it in combination with other information. At the other end of the scale is the weather information portrayed by the cunning Java applet. While this might allow a very cool user interface, it cannot be analyzed at all.
Progressive enhancement is easy, thanks to GOV.UK components
We’ve been using lots of these components in Refer and Monitor, so a lot of the hard work has been done for us.
What if you can’t rely on GOV UK components?
There are a few places we’ve introduced our own components in Refer and Monitor, ones that require a bit more user input than, say, the conditional radio button above.
One prime example of this is our filters component. We have a long list of interventions users can select from, and we wanted a way of allowing Probation Practitioners to filter this list based on the needs of the person they’re referring.
At dxw, we build a lot of betas that start out as a minimal viable product and iterate from there. Refer and Monitor had a tight fixed deadline for launch since the very beginning of the project so could we really justify building 2 versions of a filter component with this time pressure?
While we could have opted for the better looking, interactive component like the one above, we decided to design and build a simple filter component adhering to the principle of progressive enhancement. It wouldn’t even have the flashy real-time filtering, it would simply be a (perhaps fairly unexciting) list of checkboxes with a submit button. This meant that even if a script failed to load on a page, we’d at least have the pure HTML filter component available for use.
Here’s how it looks:
We could have done all this the other way round using graceful degradation, but then we’d have launched something without the fallback, which may not have been accessible to all users. It could have been de-prioritised and forgotten about in favour of “more critical” core features.
Start simple and iterate
Working on betas, time is often short and there’s not always time to iterate on what you’ve built to make it flashier once you have something working. We’ve not yet had time to add the additional styling and interactive behaviour to as many pages as we’d like to, but by starting out simple and iterating from there, we’ve made sure our service is accessible to as many users as possible.
A guide about using progressive enhancement on GOV.UK
A blog post about why GOV.UK uses progressive enhancement
The post Progressive enhancement: why we build things from the ground up appeared first on dxw.