Progressive enhancement

So far I have touched on the topic of emerging semantic web structure, outlining the appropriate way in which we should layer web technologies.

This approach is often refered to as ‘progressive enhancement’.

It is the development approach designed to make sure that a web page works no matter which end user client it is accessed by.

When using progressive enhancement, you should make sure you code up your (X)HTML as semantically as possible first, then style things up with CSS and at the very end add JavaScript behaviours or AJAX enhancements.

This approach ensures that a web page is fully accessible even when JavaScript is not present or not fully supported by the client accessing the web page.

Progressive enhancement is more work?

Following progressive enhancement approach, however, can prove to be much more cumbersome and time consuming, compared to not following it.

This is especially the case when building web applications, such as GMail or Google Calendar.

Web applications can often require two parallel solutions to be engineered for circumstances where JavaScript is available and for circumstances where it is not.

This is one of the reasons why GMail, for example, has an ‘HTML only’ version available as a separate link, while the main version of GMail does not work with JavaScript switched off.

Another likely reason why GMail does not work without JavaScript is the fact that Google engineers use GWT (Google Web Toolkit written in Java) to create all their interfaces with.

GWT spews out user interface code which completely breaks the above outlined good practices, yet creates code which still works cross browser.

Since Google engineers tend to think about back end logic of applications as a matter of priority, their outlook on web application development can be described as graceful degradation.

Graceful degradation

Unlike progressive enhancement, graceful degradation approach assumes all technologies are supported and ensures that users have best possible experience when they are enabled.

Once this is achieved, the considerations are given towards circumstances where certain technologies are not supported and how to deal with them.

Graceful degradation is arguably more appropriate approach in the short term, as the main business objective is to create a working interface for the main user group as soon and as cheaply as possible, while serving the minority user group if and when possible.

This is how most of the very profitable web sites have been developed.

Hard to maintain software is dead software

In the long term, however, graceful degradation approach will more than likely mean that a given application is much harder to maintain and update, as the code is not developed according to semantic standards.

This can mean that future development and progress can only be achieved by completely re-writing a solution from scratch, which can lead to long down times, difficult migration processes, massive costs of re-development, stifled innovation and many other unwanted side-effects.

An extremely good example of this is MySpace, which is one of the worst applications ever developed, which has seen very little to no improvements in the last few years. This is more than likely due to the poor quality of the initial development and extremely bad User Interface code quality.

MySpace’s poor quality user interface code also means it is very tricky to create nice skins for MySpace profile pages using CSS, as the underpinning HTML code is very poor.

This means that MySpace’s very sales pitch of enabling users to customise their profiles however they like is flawed due to the inflexibility in the coding deployed by MySpace developers.

Using graceful degradation also creates a harder environment for developers of various skill sets to work within, as within Google setup any developer working on GMail will have to be a wizard in GWT.

In semantically developed interfaces (i.e. progressively enhanced) a company can employ a relatively cheap CSS developer to develop themes for their CMS or web application without ever needing to touch HTML or JavaScript.

In this environment the company developing the solution has the ultimate flexibility and control over their toolsets.

In progressively enhanced interfaces it is also much easier to delegate work amongst developers, as one person can work on CSS, another on HTML and the third on JavaScript, without developers stepping on each other’s toes all the time.

Written by Jason Grant, BSc, MSc on 11th June 2009

You can leave a response, or trackback from your own site.