Progressively enhanced fat client
I love the idea of progressive enhancement. If kept in mind throughout design and development, the product will be more accessible to those with disabilities and most of the awkward challenges that the Internet drag in. The fact is that what little work I have done to make a site progressively enhance, has turned out to save me lots of time down the road. You will just have to take my word on the last one.
So how does this relate to some of the fat client style applications that I have been working with lately? If you don’t know, a fat client, in the javascript world, refers to an app that relies mostly on client side code to run and communicates with the back-end through asynchronous data exchanges. These apps are able to use client side technologies to give a similar experience to a desktop application. Lack of proper “low-fi” states, where the app can be useful without javascript enabled, are not generally considered when building fat clients with client side libraries like YUI and SproutCore. The makers of these libraries obviously try to keep their products accessible but it is difficult to keep maintain this accessibility as the fat client features are added. I could not reconcile that I could Both be making progress and ignoring progressive enhancement when working on these types of applications. The truth is that we can’t make an application that can both contain all of the interface convenience features that modern browser users expect and have a low-fi case to fall back on for accessibility.
The best way I have found to get around the gap between accessibility comes in the form of a compromise. There are sites that will redirect a user to a low-fi version, if a browser does not meet the minimum requirements of the fat client. The same approach is often taken to redirect mobile users to mobile versions of an interface. This allows every user to get an ideal experience for their client type as long as their client type matches the requirements. It is very important that if the client does not meet the minimum requirements, is of unknown type, or an error occurs preventing client detection, the page is served in simple HTML, with no JavaScript enhancement.
I do understand that most of us do not have the time to build two or more versions of an application. There are clever ways to organize an app to minimize the amount of duplicate work that needs to be done when building both a low-fi and fat client version of your interface. Ruby on Rails particularly comes to mind so it will be my example. First, you want to create a simple Rails application. This would not need to be much more then a scaffold. Apply some style though the site should be readable without CSS, even if it is not pretty. Make sure that your controllers are set up to return a JSON representation of the rendered data if requested. This JSON output will be the rest service that your fat client will use to communicate with the back-end along with the necessary ability to accept AJAX form posts. This seems to be the least evil way to provide functionality for specific clients.
–EG–
PHOTO CREDIT: Uploaded to Flickr on December 20, 2007 by Paul.c.Redmond