When Should You Use Progressive Enhancement?

by Brian Fegan

Recently, a client approached us with a project that presented an interesting challenge…we were asked to build a robust, data-driven site, behind a user login, that would sit on their JavaScript-based framework. That’s right, a website built entirely out of JavaScript.

There would also be no traditional middleware layer. No PHP, no JSP, no ASP, or the like. All the data for this site would be retrieved via Ajax requests returning XML, which we would then parse, and either store in JSON for later use, or use DOM manipulation to immediately display the data as something useful for the user in the browser.

And there was one final catch: cut down on the number of calls to the data server. So when a user logged in, we would store a vast amount of data one time in memory as a reference for later use, and use JavaScript to navigate to new pages, as opposed to making a traditional page request where we would need to retrieve all that data again with each request.

Needless to say, this site consists of a lot of JavaScript.

But let’s switch gears for a moment and talk a little about what the site looked like. True to practice, the designs we came up with for the site looked spectacular.

With so much data to display on the page, our designers came up with a page layout and data table design that is a pleasure to look at, including plenty of rounded corners, subtle gradients, alpha-transparent borders, and box shadows.

Which brings me to the topic of this article; progressive enhancement.

For those of you who need a quick definition, progressive enhancement is a development technique that “uses web technologies in a layered fashion that allows everyone to access the basic content and functionality of a web page, using any browser or Internet connection, while also providing those with better bandwidth or more advanced browser software an enhanced version of the page.”  –Wikipedia

As a result of the sheer amount of JavaScript this site would require to serve up page screens to the user, we soon realized that the experience in modern browsers (Firefox, Chrome, Safari) would far exceed the experience in older browsers. Forget IE6, even IE7’s JavaScript and DOM rendering would be visibly slower than the performance you’d see in the modern browsers mentioned.

In cases like this, progressive enhancement screams out at you as a developer.

Traditionally, to implement all those design techniques mentioned above, you would need to use a series of sprites across the site, adding to the number of images being requested by the browser. And in most cases, as much as it can be avoided, extra markup still makes its way into the page to accommodate those design techniques. I’m looking at you alpha-transparent borders!

And since each page of this site was being built by manipulating the DOM via JavaScript, that extra markup means extra JavaScript, and extra DOM rendering. All of which compounds the problem of slowing down the user experience in older browsers visibly, and adding unnecessary complexity to the way modern browsers will render the document.

So, with a site that requires the browser do so much heavy lifting already, why not use all those fancy CSS3 attributes that are all the rage these days to help cut down on all the elements required for the page to render true to the design.

Below you can see an example of one of the table designs from the site. Notice the rounded corners on the first and last rows, the gradients on the table cells, the way the background colors bleed through the cell borders, the highlighted column gradient, and lastly the highlighted row gradient (which can change color according to each user). All of these required the use of a sprite containing the graphical pieces of this particular design puzzle.

Now click here to see that design implemented with CSS3 techniques. Look ma, no images...

So long as you’re using Chrome, Safari, or Firefox 3.6, these will look near identical. (Older 3.x versions of Firefox will be missing the gradients.)

If you view the page using our old friend IE, you’d see this…

(Note: Microsoft claims IE9 will have the same level of CSS3 support that other modern browsers currently have.)

Is this slightly less fancy design in IE an acceptable sacrifice?

For some clients, the answer might flat out be “Absolutely not!!” Especially if the particular project in question is largely a showcase site. However, in cases like this – a data-driven, user-based site – if the site requires so much of the browser already, doesn’t it make sense to give the browser a little less to do for the sake of the user experience?

What do you think?

Brian Fegan is a Web Developer at Fi.