Replacing the old client server architecture with the web application architecture made quite a few folks very happy. Besides hard- and software sales people who were given new arguments to sell new stuff, the IT guys were just lovin' it. Zero admin on the client side had finally become reality.
Users of all the new and cool web desktops on the other hand slowly discovered some serious flaws. Many of those much-appreciated conveniences like right mouse-clicks, re-ordering columns, stretching column widths, fast scrolling, etc. or just keeping state, were gone.
Ask yourself, why do most users prefer an e-mail client like Outlook or Thunderbird over mail.yahoo.com or hotmail.com. GoldMine over salesforce.com, Quicken over ..bank.com, the list goes on an on.
It's not over before the fat client sings...
Don't read into this that I would like to see us going back to the old fat client days. However, there is a pattern here. Deploying the web application architecture we have sacrificed usability for maintainability. Considering that mostly IT-departments make the decision what solution to buy/deploy and that they are the once benefiting the most, it's no surprise to see the growing number of web desktop driven solutions.
The success of the web desktop however, brings another disadvantage to light, which is its uniqueness in design and lingo. Where is the menu? Top, bottom, left, or right? What was that called? Open, enter, perform, submit, commit? Long gone seem the days, where an application style guide was used that ensured that if you knew how to navigate one app, you'd know it for all, but hey wasn't that one of the reasons why Windows 3.0 was successful in the 1st place?
Old fashion MS-DOS apps, while looking very differently, had some of the same problems we experience today with web desktops: the absences of a uniform nomenclature and look and feel.
Zero-Admin distribution
One of the most compelling advantages web desktop offer, is that changes made on the content / app server are immediately available to all clients, without explicitly installing or updating any software.
A distribution solution like Java Webstart (embedded part of any Java Runtime (JRE) since Java 1.4) however, is capable of providing the same user experience. Client applications like the
Theodore Editor or the
Verity-LiquidOffice-Management-Console check for updates on every launch. If updates are available, they are force onto the user, which ensures that a server never has to deal with outdates clients, protocols, etc.
Thin means distributable - patch day mean p.o.s.
Even with broadband being available almost everywhere, client applications requiring more frequent updates have to be thin. Updating a couple mega bytes on a weekly basis is hardly acceptable - if you are on Windows and install Mircosoft's security patches regularly (MS'
patch day) you know what I mean.
Fortunately, GUI rendering engines like
Thinlet or
SwixML are extremely small (50k) and were built with thin client architecture in mind.
When is a thin client also rich client?
While Java Webstart combined with Thinlet or SwixML allows creating small client application, the richness is not inherited but has to be designed into the application by the developers.
Where to go from here?
Alternative approaches to the afore mentioned would include:
-
Mozilla.org's XUL: Mozilla's cross-platform user interface working with XPCOM components, written in C, C++, and JavaScript, and can be used from C, C++, JavaScript, Python, and with Perl extensions.
-
Eclipse Rich Client Platform RCP, which looks promising but is everything but thin. The runtime alone is 6.7 MB (about 137 times the size Thinlet). Moerover, no automatic update capabilities have been built-in yet.
A Look at Rich Internet Applications
This
article [published in ORACLE-Magazine, Aug-2004, pp.59] features Thinlet and the Theodore Thinlet Editor, describing technologies for going beyond the aging HTML standard.
Any thoughts?
