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!

Reply with a tweet or leave a Webmention. Both will appear here.