It’s time to progress
There are few people who can discuss progressive enhancement without mentioning isomorphic applications, JavaScript and performance considerations.
It’s a loaded narrow term and I’m going to discuss how we can change that.
The way forward
Many believe we should leave the term “progressive enhancement” behind and start anew, but why not educate developers, clients and stakeholders and change many of the misconceptions surrounding it? Changing the name won’t change anything unless we address the real fundamental problems we have when describing the underlying concepts.
It’s not a one size fits all solution
There isn’t a definitive solution that will fit every problem, it’s a concept, a movement; a way of understanding how we should build for the web that makes content available to everyone.
The idea of progressive enhancement being about availability is powerful; it’s technically agnostic and asks “how can everyone access this?”, whether it’s a Single Page App (SPA), a review website, blog or government portal, you want to provide content to your users.
Making that content available to everyone should be a priority for you, but technology gets in the way.
CSS is automatic
Probably one of the most irritating counter-points whenever CSS’ role in progressive enhancement is mentioned, particularly because it’s not justifiable to say CSS doesn’t fail like JavaScript does.
Using this point to strengthen the PE = JavaScript on/off argument is like saying people who can’t drive cars, can’t repair them.
CSS doesn’t give the browser a horrible error in the console, but it’s just as visible to the user. If a document isn’t semantically structured correctly because you are using CSS to force a particular layout, when the styles structuring that layout don’t load and I can’t read your content, that’s a failure.
Cost-benefit analysis
You have to justify the cost to the business, it’s what stops developers from building rocket ships — that sucks, but it’s a reality we all need to live in.
Progressive enhancement should be part of the fundamentals of what you build and not as a separate line item, when costs need to be cut it won’t be a contact form or feature that gets removed, it will be the item that in their mind doesn’t add value to the business.
So let’s remove it as being an addition and make it part of everything we deliver.
Isomorphic to the rescue
No. It’s not rescuing anyone, just stop. It’s so far removed from being progressive that it’s actually hindering it. Isomorphic apps are apps built to solve a problem that we’ve created, that doesn’t need to be there in the first place.
We’ve built something which can’t provide a basic experience to everyone, because of the tools we’ve used. So trying to solve that problem with the same tools is counter-productive to the ideology of progressive enhancement.
There are other ways we can solve this problem by taking more consideration for the way we write our code.
Stay focused on the user
Developers do what’s easiest for them, we all do it, it’s selfish. As developers we like to invest in the hipster tax and build the shit we want. This is where we begin to fail our users.
..it’s our job to give them that great experience…We want to have stubborn empathy for what they need, and what they want, and what they’re going through — what can we do to make all that better?
— Nate Koechley’s “Professional Frontend Engineering”
Our toolbox includes a lot of JavaScript heavy tools, creating barriers between your content and the user. Admission is having JavaScript enabled, so begins the narrow conversation of JavaScript availability, when we talk about progressive enhancement.
This post by Tim Kadlec (he does point to other sources of perspective) which identifies the dangers of JavaScript being turned off, is an example of the on/off argument that dominates the progressive enhancement landscape, we need to step back and see there’s more to it than the availability of JavaScript.
Context vs Availability
I have a modern device, but I’m connected to an airport/coffee shop/open WiFi access point that restricts access to external resources or has proxy issues, either way JavaScript doesn’t load. My browser reports to your code/server that it can support the latest APIs and your site proceeds in “turned on mode”.
The browser struggles to load the resources it needs, I’m unable to use your site. You have just failed to make your content available to me as a user.
What went wrong here? My browser is trying to download all of those nice images, JavaScript files and that huge concatenated CSS file you thought would save on requests (because too many are bad). The browser has to wait before it can render anything, but all I want is a bus timetable.
All of those external resources should “enhance” my experience, not be required in order to provide one. We need to ensure we provide at least a baseline experience.
Accessibility as a baseline
We should be focused on building a baseline experience. What that baseline should be is a difficult question to answer, but is often more about feature availability than the context of the user when they are trying to access your content.
A baseline experience should be accessible and by using screen readers, assisted devices and even games consoles (brilliantly discussed by Anna Debenham) as a tool to understand how our experiences hold up in a number of different contexts, we can begin to strip away what isn’t part of the core user experience and provide a platform to build upon that allows for enhancements which provide value but aren’t essential for the user.
Manifesto
When we talk about progressive enhancement we should try to be technology agnostic, what’s bleeding edge today will be legacy debt tomorrow.
We should talk about the importance of availability, reaching our users and giving them a valuable experience as standard, no matter what context they are using: mobile, desktop, emerging markets and high-end super modern devices.
We shouldn’t be led to believe or make others believe it’s a ‘nice to have’, it should be a standard we follow and hold ourselves and our peers accountable for using.
We should make it part of our daily routine, not something we come back to over time.
We need to understand progressive enhancement is about creating layers of engagement and value on top of our content, not just turning features on and off.
We should remember that progressive enhancement is about building for the future, as much as it is supporting the past.
If we can at least follow some of these guidelines then we can start to change the way ourselves and our peers approach progressive enhancement and create more value for our users, clients and stakeholders.
This post was inspired by the conversations and debates that I was privileged to be apart of at Edge Conference 2015 held at Facebook’s London HQ.
As a profession and a community, events like Edge provide a forum where experts, beginners, thought leaders and opinionated fools like myself can come together and contribute to finding solutions to problems, like the ones discussed in this post. In the spirit of that I welcome any and all constructive comments, notes and ideas that can help us affect real change when it comes to the ways in which we approach progressive enhancement.
