Graceful degradation outside the domain of web applications: how significant a problem is it?

Question

Apologies for the long intro - just trying to suitably set the scene to avoid ambiguities and confusion.

Web applications have grown from being dumb browser-based interfaces for server-side logic to being fully browser-based applications with minimal need for server-side logic. It is possible to describe this evolution through identifying clear generations of web applications.

Let's just consider, for the moment, just two generations: pre- and post-ajax. There certainly are other factors, such as those relating to CSS support and Access Control headers, but let's start off simple.

Starting from a style-less JavaScript-less simple system, adding layers of gracefully-degrading enhancements and finishing with a ajax-packed, highly-responsive contemporary application is a challenging and error-prone task. It is by no means easy.

To whichever generation a web application may appear to belong depends on the means through which the application is accessed. The very same web application would appear to be a first generation app if accessed through Lynx and a latest generation app if accessed through FireFox 3.1, with a few levels in-between depending on the user agent used to access the app.

The problem of creating a web application that gracefully degrades depending on the capabilities of the user agent, where something created to take advantage of current browser features would revert back to the functionality of something created perhaps fifteen years ago when faced with Lynx, is very hard.

I can't imagine a desktop application facing such a variance in operating environment.

A single executable (as opposed to a set of OS-specific variants) capable of taking advantage of features in Vista may well cope adequately when run under XP and when lacking certain Vista features. To degrade over a comparable distance as a web app, the same desktop application would still have to function, albeit in a less fancy fashion, when run in a command-line-only environment such as DOS.

Run it under Lynx, it's a first generation web app. Run the same under FireFox 3.1, it's a fancy, shiny contemporary web app. If faced with such a problem, you'd consider it challenging, tricky but feasible.

Run it under DOS, it's a command-line app. Run it same under Vista, it's a fancy, shiny contemporary web app. If faced with such a problem, you'd consider it insane. Or would you?

Do desktop applications ever face such a breadth of variance in operating environments as web applications can?

Is this problem (the breadth of variance, not the variance itself) unique to the domain of web applications, or can it be found in desktop development?

Sneaker

Answer 1

Desktop applications don't have the same problems web applications have in this respect. They are usually made to run on one well defined platform.

This might change in the future. Computing is moving from desktops to mobile phones and smaller laptops. Desktop applications will have to run on a wider variety of platforms in the future. This might cause problems because most frameworks we use to develop desktop applications handle this even worse than framework for web-applications.

Baseler

oh, I don't know .. QT is really rather good for cross platform development. Your biggest problem then will be device capabilities - eg screen size on a phone compared to desktop. – Sufferance

I agree, cross platform development is already possible with several languages and frameworks. But graceful degradation is about scaling down for lower screen resolution, bandwidth, cpu, memory etc. when needed. Qt or other frameworks don't really handle this well. – Baseler

Answer 2

I can't imagine a desktop application facing such a variance in operating environment.

Desktop applications have to deal with variance, just of a different kind. Graphic cards in games are a good example of that: you want decent support for basic customers, but your high-end customer with the shiny new graphic card will want a run for their money. When you enter the realm of on-GPU processing and on-card memory management, you'll have reason enough to curse variance in operating environments.

You also generally deal with more processor and memory intensive software than a web-app, so you'll have to take that into account as well. And I'm not even talking about inter-OS operability (which many desktop software handle very gracefully).

Of course, nothing keeps a desktop software publisher to impose stringent criteria on the environment. It's just a question of business. But nothing forces you to support non-mainstream browsers either (and do most web applications really support Lynx?!?).

Chancey

"And do most web applications really support Lynx?" - Lynx was mentioned to demonstrate the feasible breadth of variance in operating environment i.e. whilst rare, it's not infeasible that support for such variance would be a requirement. – Sneaker

If you want to compare apples to apples, you should consider what's considered "mainstream" in both worlds. To me, the equivalent of supporting Lynx is like supporting Vista and a 10 years old version of RedHat (which could be a reasonable requirement in many cases) – Chancey

Vista/RedHat is not quite the same. You wouldn't have the exact same executable working on both, you'd have very similar OS-specific variants for each. The Vista/RedHat comparison is more akin to having a Lynx-specific version of your web app and a separate FireFox/IE/Safari/Chrome/Opera version. – Sneaker

Answer 3

In the application and operating system (OS) realm, the problem is usually reversed. It is the OS that handles all the complexity of maintaining compatibility. On the other hand the application usualy dictates a minimum OS version.

Another place where applications start to see this problem is the Java world and to a lesser degree all other so called script langages that work on multi OS.

Tactician