A single website for All types of Internet User: Progressive Enhancement

Progressive enhancement is about building robust products and being paranoid about availability. It is about asking “if” a lot. That starts even before you think about your interface.

1. What is progressive enhancement?

Progressive enhancement means building the interface of a website or application in layers. If the user’s browser only supports HTML they get content and forms. If the user’s browser also supports styles and fonts the application looks better. If it can run JavaScript the user gains extra interactions. Only the core HTML though is required in order to meet users’ basic needs.

Obviously there are many places where JavaScript could be seen to be a requirement. It’s hard to imagine intensive web applications like games and online office suites working without JavaScript. Even in these cases though there are possibilities to use progressive enhancement to benefit the user.

2. The Past: Progressive Enhancement is Born

Progressive enhancement has been around since at least 2003. Back then, the web was still transitioning to using CSS instead of table-based layouts. JavaScript was an untamed beast, with exciting power but unpredictable behavior. Progressive enhancement provided an approach that allowed web professionals to deliver content everywhere and still take advantage of newer features where possible.

It was during this time that the idea of web “applications” started to become popularized (although nothing actually changed, they’re still just websites). The demand for dynamic pages connected to databases couldn’t be met with JavaScript alone, so server-side application programming became paramount. In a framework like Ruby on Rails, HTML is constructed on the server and then delivered to the client. When you visit a friend’s profile on a social network, for example, the server uses a “profile” template and fills in the blanks (like the person’s name, photo, and so forth). Even with the advent of AJAX towards the middle of the decade, server-side programming still dutifully took requests and delivered the necessary data.

3. Markup progressive enhancement

Web technologies and standards have this concept at their very core. Take for example the img element in HTML:

<img src="threelayers.png" alt="Three layers of separation - HTML(structure), CSS(presentation) and JavaScript(behaviour)">

By adding an alt attribute with a sensible description you now know what this image is supposed to tell you. If it can be loaded and displayed, then you get a beautiful experience. If not, browsers display this text. People who can’t see the image at all also get this text explanation. Search engines got something to index. Everybody wins.

By adding an alt attribute with a sensible description you now know what this image is supposed to tell you. If it can be loaded and displayed, then you get a beautiful experience. If not, browsers display this text. People who can’t see the image at all also get this text explanation. Search engines got something to index. Everybody wins.

<h1>My experience in camp</h1>

This is a heading. It is read out as that to assistive technology, and screen readers for example allow users to jump from heading to heading without having to listen to the text in between. By applying CSS, we can turn this into an image, we can rotate it, we can colour it. If the CSS can not be loaded, we still get a heading and the browser renders the text larger and bold as it has a default style sheet associated with it.

4. XHTML had to die, HTML5 took its place

When XHTML was the cool thing, the big outcry was that it breaks the web. XHTML meant we delivered HTML as XML. This meant that any HTML syntax error – an unclosed tag, an unencoded ampersand, a non-closed quote meant the end user got an error message instead of the thing they came for. Even worse, they got some cryptic error message instead.

HTML5 parsers are forgiving. Errors happen silently and the browser tries to fix them for you. This was considered necessary to stop the web from breaking. It was considered bad form to punish our users for our mistakes.

If you don’t progressively enhance your solutions, you do the same thing. Any small error will result in an interface that is stuck. It is up to you to include error handling, timeout handling, user interaction like right-click -> open in new tab and many other things.

This is what progressive enhancement protects us and our users from. Instead of creating a solution and hoping things work out, we create solutions that have a safety-belt. Things can not break horribly, because we planned for them.

Why don’t we do that? Because it is more work in the first place. However, this is just intelligent design. You measure twice, and cut once. You plan for a door to be wide enough for a wheelchair and a person. You have a set of stairs to reach the next floor when the lift is broken. Or – even better – you have an escalator, that, when broken, just becomes a set of stairs.

Of course I want us to build beautiful, interactive and exciting experiences. However, a lot of the criticism of progressive enhancement doesn’t take into consideration that nothing stops you from doing that. You just have to think more about the journey to reach the final product. And that means more work for the developer. But it is very important work, and every time I did this, I ended up with a smaller, more robust and more beautiful end product.

By applying progressive enhancement to our product plan we deliver a lot of different products along the way. Each working for a different environment, and yet each being the same code base. Each working for a certain environment without us having to specifically test for it. All by turning our assumptions into an if statement. In the long run, you save that way, as you do not have to maintain various products for different environments.

We continuously sacrifice robustness of our products for developer convenience. We’re not the ones using our products. It doesn’t make sense to save time and effort for us when the final product fails to deliver because of a single error.