If you have been following my latest tweets, you’ll notice this is simply the execution of a longer explanation why I think concepts such as progressive enhancement are often very problematic. In the style of a ppk rant, and with the fear of making people angry, disappointed, mad, excited or unbelievably happy, here it goes.

What is Progressive Enhancement?

First, let’s discuss what I’m actually talking about. Progressive enhancement is a programming concept that simply says you should start building your product or website with the “Lowest common multiple approach”, so it runs in browsers like Internet Explorer 6 or with JavaScript disabled, and then continue to enhance functionality, interaction and UI for more capable browsers, devices and users. When well executed, this means that your site is targeted and usable by a maximum audience.

..but isn’t this awesome?

Indeed it is! That’s what’s great about progressive enhancement. It makes sure your website runs on every device or browser if executed well, which is definitely something admirable. It also has a multitude of positive side effects – such as possible accessibility benefits and it is really well suited for a junior programmer, as it teaches the layers of a web app in a direct way. … so what am I complaining about?

PE limits creativity

My first thesis is actually very easy to explain and to follow. So you’re a student of a famous painter, and you’re learning how to draw basic forms. After the art class, the teacher decides to draw something in front of the class to show off his skills. Unfortunately, all canvasses are used by the class, so he has to pick yours and paint on top of it. I’m pretty sure he succeeded in making it awesome based on your painting, but what if he had a clear white canvas to start with?

I’m positive that most people will come to my conclusion that the second painting would have been truly his, unleashing all his creativity. The situation is, as you might imagine, extremely similar with progressive enhancement. Since you always improve upon the lowest layer of your implementation, you’re not inventing new user interfaces, new metaphors or interactions – you’re merely improving the old ones. Even more unfortunate is the fact that we accepted to live with this fact. It is pretty likely you wouldn’t even have noticed this if you didn’t read about it here.

So we want to start drawing on a clear white canvas. Wouldn’t Graceful Degradation fit the bill?

Graceful degradation

Graceful degradation is basically the opposite of PE. It says “start on a free canvas and build crazy shit, then make sure it runs in less charming situations”. While in theory definitely a great improvement to PE, it doesn’t always work out, since there are many complex UX patterns and ideas that cannot be reproduced easily in a lower metaphor. In general you could therefore say that it also simply requires a lot more time than PE. That being said, I still use GD to a great extent in many of my projects, and I’m pretty happy with most outcomes.

You are the problem!

Uh well…not personally. Let me explain: I fully endorse the concepts of Progressive Enhancement and Graceful Degradation. In fact, PE for instance is a vital concept for jQuery UI to follow and implement. The real problem comes with the usage. Web developers misuse PE and GD to a great extent. And it is very easy to follow the wrong path if every “Best practise” powerpoint slide tells you to always follow PE. Let me make that crystal clear: “Always follow” = guaranteed misuse of PE.

So what? I should just screw IE6?

Actually yes, you should screw IE6. …errr, let’s start over: First off, in many instances, you will never need an alternative. If you’re targetting iPhone Safari as platform for your web app for instance, or if you’re working on an intranet application to be used with only a single browser. However, there is a great alternative to PE & GD: Instead of adding layers on top of your current site or app and let it become a big fat hard to maintain blurb, how about developing a second client? I will argue that it doesn’t take longer than the GD approach, and quite important players have done so: Gmail, anyone?

The bottom line: Start thinking!

As mentioned, it is really not a problem of the concepts themselves, but of how they’re used. If you’re reading this, give it some serious thought and start thinking yourself. Think back in time and look at the projects you’ve done so far. Is there a chance to improve your workflow by not following every best practice advise blindly? I bet!


T  on April 12th, 2010

On the whole I agree with you regarding blindly following best practice (though I do tend to always lean towards PE, mostly out of habit I guess), but your PE analogy seems flawed – it assumes whoever is doing the final layer of enhancement had no input in the original.

In fact, if the master painter started from a blank canvas he would still be using progressive enhancement – painting a base first and adding more layers until he reach his final piece.

I think you have made a good point, you just didn’t notice it. From what I read into your master painter example is that PE doesn’t have to limit creativity as long as later stages of enhancement had input in the preceding ones. You are limited only by the canvas you choose, not the technique.

Paul  on April 12th, 2010

@T: What I actually meant is that the great painter is not forced to start with a basic shape, and instead can focus on abstract and non-existant shapes (for instance). You’re right that a drawing process usually requires layering, but it is a different kind of layering. In the web world, you could best compare it with unstyled vs. styled content.

Thanks for your good comment!

HB  on April 12th, 2010

PE and GD are both fine given unlimited resources. GD may even encourage more creativity because you’re not “restricted” by an underlying no-behavior, no-style structure.

But these days PE is more widely preached than GD because of its practicality. On a project where sudden time or budget constraints may arise, or clients may change their minds halfway through a project, you lose less with PE than you do with GD.

Say you’re working on a large web application for a client, and 2/3 of the way through the project ends prematurely (for whatever reason). With GD, many visitors may be completely unable to use the application because you never made it to the accessibility phase. With PE, your app works 100% of the time, for 100% of the visitors. It may not have reached its full creative potential, but it works. And without unlimited resources, that is the more important factor.

Scott  on April 12th, 2010

Paul, I assume you’d expect me to disagree with this article, but I do think you’ve got the PE process a little mixed up. If you approach an interface design based solely on what’s available in the HTML4 form toolbox, you’re probably right that it’s going to influence and limit the creativity of the design. However, I don’t think that is how most designers approach a problem these days, and PE itself certainly doesn’t require that approach.
Progressive Enhancement isn’t there to get in your way during the design process. On the contrary, it’s purpose is to let you design freely while acting responsible to your users when it comes time to make it functional. It’s a methodology for *implementing* a design, and given the tools at our disposal, it’s pretty rare to see a design that can’t be implemented using these best practices.
You should design on your blank canvas if it helps you think more freely, then after that, consider how to map your enhanced components back to simple HTML so the important parts are usable without JavaScript (slider manipulates an input or select element, ). Then to really follow-through, you’ll need to also consider the usability and accessibility of the components for those who receive the ideal experience as well (with reasonable affordance, ARIA, keyboard control, focus management, etc), since simply making it work without JS does not mean it’s accessible or usable. In our book on PE, we call this part of the design process the “X-Ray approach.” It’s a planning phase between static design and implementation where you figure out how to make it all work, regardless of what it is.

Sander Aarts  on April 12th, 2010

PE is basicly the best method to achieve GD.
In most cases you know at the start of the building proces what the the final result will have to be like. Therefor any PE immediately starts as a GD from that target.

Btw. targeting a single platform is never cool, not even (or especially) for intranets. By doing so you almost certainly establish some level of vendor/version lockin, which is essentially why we’re still stuck with IE6. Let us not repeat that mistake.

Paul  on April 15th, 2010

@Scott: Thanks for your insightful comment. I actually agree with your point – if you’re separating the planning/design process from the implementation (which, unfortunately, not all people do..), this definitely might work out. So I think what you’re saying is to basically use GD on the planning/design phase, and then use PE in the implementation phase. I didn’t think of that yet, but I’ll definitely give it a try! And I guess I should finally read your book :)

Paul  on April 15th, 2010

@Sander Aarts: Re lock-in: I agree when it comes to intranet applications (I know the pain!). I disagree when it comes to highly specialized platforms, like TV’s, smartphones, etc. most web software on consumer hardware should be targetted.

Have a comment or question?