wissel.net

Usability - Productivity - Business - The web - Singapore & Twins

Graceful degradation


Web development is a curious thing. We constantly push ourselfs to upgrade skills and capabilities, we learn Dojo, jQuery and HTML5. We make friends with Websockets and Webworkers only to subject our creations to a runtime environment (a.k.a. the browser) we can't predict and that in many cases might not be up to the task.
So our play-it-save strategy is to look for the lowest common denominator a.k.a. only legacy supported functions can be used. This limits what we can deliver and frustrates user and developers (interestingly corporate decisions to inflict this suffering onto colleagues by sticking to old versions go unpunished).
I suggest: NO MORE!
Every organisation today has the latest modern browser actually in use: just grab the iPhone, iPad, Androids from any executive. Those are the platforms to aim for. The right approach going forward (besides responsive design) is:

Graceful Degradation

When you lookup the term in Wikipedia you get redirected to the entry for fault tolerant systems. And this is the exactly the view point you need to take:

A missing html5 capability in a browser is a runtime fault, NOT a system constraint

. The task now is to build your application so it degrades gracefully (to a point).
About.com has a nice definition: " Since web browsers have been around as long as the Web, it is possible to have customers viewing your web pages in browsers that are extremely old and missing features of more modern browsers. Graceful degradation is a strategy of handling web page design for different browsers.
A web design that is built to gracefully degrade is intended to be viewed first by the most modern browsers, and then as older, less feature-rich browsers view it it should degrade in a way that is still functional, but with fewer features.
"
The IBM OneUI is a nice example how this can work. It is still workable, but not pretty, when seen through Lynx, the mother of all browsers - available, maintained and text only until today.
So your new application can be designed with all the shiny features, as long as you include your degradation path. One degradation endpoint can be that little infobox that explains the manual steps or " feature xy (that would be your application feature not a technical thingi) is not supported, sorry". Luckily the big libraries contain already a lot of that degradation code.
Just some thought: HTML5 provides local storage and caching. Why not design the app to take full advantage of that and fall back to loading of every page if that's not available?
The discussion around graceful degradation isn't exactly new, read for yourself: As usual YMMV

Posted by on 05 December 2012 | Comments (0) | categories: Software

Comments

  1. No comments yet, be the first to comment