Just a difference of view? Progressive enhancement vs graceful degradation
With the deadline for replies to COI’s consultation on browser testing support looming tomorrow (Friday 17 October, folks! Get your views in now!) an A List Apart article on progressive enhancement caught my eye.
Ever since I’ve been working in web development, the key theme to ensuring browser compatibility has been graceful degradation: that means you can optimise your site for the latest whizz-bang browsers on the market, but you should also ensure that the site will still work – and look good – if used in an older browser.
So you can see why graceful degradation has been such an effective way of thinking about web development best practice. But it’s not without its flaws: having to create a website with so many levels of multiple redundancy takes time and money to create, and is hard to do testing on when it is released because of the many different factors involved. And all that alternate coding can end up tripping over itself, leaving a stray line of code here and a stray line there, which when put together can mean your coding looks shambolic – and possibly even wreck the page. And the big problem is: graceful degradation is all about the browser. It’s about the technology leading the development, rather than the user needs or the project requirements.
That’s why the buzz phrase for web development, first used in 2003, is progressive enhancement – which focuses on building from the content out, which in turn is developed by referring to user needs.
The A List Apart article uses a brilliant metaphor of a coated M&M peanut to show how progressive enhancement works, which I’m not going to attempt to relay in detail or find an inferior way of describing them, but in the highest of high level: instead of burrowing back through layer upon layer of jury-rigged patches, you concentrate instead on creating excellent content, then wrapping it in XHTML, then CSS, and so on – each of them done to the highest web standards at every stage. And in this way you end up with the pefect final result that you just know will work with any well-behaved browser around.
This has been the gist of a lot of the feedback to the COI consultation on user support: that we were misguided to even frame the consultation as being all about browsers, when it should have been about web standards and building from the ground up. And it’s a very good point, well taken, that I’m sure the COI team responsible for drafting the next version of the guidelines will take into account.
But the difference between graceful degradation and progressive enhancement is lessened somewhat if you add to the former the overriding requirement to be web standards compliant, and underline that accessibility can only be achieved first and foremost by coding to best practice standards. That’s what COI has always tried to advocate in its digital media projects, and I hope we’ve made a positive difference to the standards of websites in general and usability/accessibility in particular over the years.
If your top requirement is web standards, and then you put on graceful degradation after that, does it really end up far away from being – to all intents and purposes – the same as progressive enhancement? Maybe I’m missing something, but I don’t think there’s much difference between the two in practice; you could argue that all things being equal progressive enhancement it the more elegant way of putting it, whereas graceful degradation plus web standards means you have to keep your eye on separate ends of the development process.
But there is certainly a difference in ethos: there’s no way I can argue against the principle that the user – and the content – come first, and the technology should be an invisible facilitator. I say it time and again to clients every day. And so the basis for testing certainly shouldn’t be the technology; but we still need to know what technology we should check our sites on to ensure that the developers have delivered on web standards and progressive enhancement. That means there still needs to be a way of quantifying how we check the end product, and on what. And I’m afraid it doesn’t absolve you of supporting those badly behaved browsers with special jury-rigging, too, if enough of your users are using IE6 a non-standards compliant mess of a browser. You can’t argue that progressive enhancement is about centring on the user and then turn round and say that what browser the user is seeing the site with is irrelevant.
In the end, maybe the most important thing about progressive enhancement is that it’s shiny and new. And I don’t mean that in a remotely facetious or sneering way, either: we all get jaded, we all get lazy, and we all sink into bad habits from time to time. What we quite often need is a new perspective on things, a kick up the backside – and a shiny new toy to play with.