The state of rich Web apps

In my Oct. 22 column, I argued that Gmail's aggressive use of DHTML qualifies it as a kind of RIA (rich Internet application). As e-mail correspondents and bloggers pointed out, the technique has a fairly long history. Many wonder why it remains on the fringe. The reason, I think, is partly a weakness common to all RIA technologies. Whether it's based on DHTML, Java, Flash, .Net, or just a standard GUI, an RIA has a client/server architecture. Unlike a Web application that manages state information almost entirely on the server, an RIA achieves a more balanced distribution of that information between server and client. The benefits that flow from this arrangement can include responsiveness, context preservation, and offline capability.

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

To achieve these benefits, though, we have to make some painful trade-offs. First, there's no easy way to observe and measure the use of your RIA. A developer once asked me, in a discussion of Flash as a front end to Web services, "Where's the clickstream?" Great question. Web server logs are important sources of interaction data, and Web analytics tools know how to mine that data. But when interaction is localized to the client, you're flying blind. You need to find another way to observe and measure what users do.

This is a general issue that GUI software has never handled gracefully. In my Sept. 17 column, I discussed the weak tradition of event logging on the Windows desktop. It's a problem not only for security auditors but also for developers who need to understand in detail how users interact with their software. Failure scenarios can be maddeningly hard to reproduce, as I'm reminded every time I try to pinpoint the glitch that prevents my wife from printing address labels in Microsoft Word.

A related issue is integration. RIAs are protocol-driven. A programmer who masters an application's protocols can extend it or combine it with other applications. But there are no integration hooks available to the user. In a Web application, those hooks are simply URLs. Consider what happens when you include a MapQuest URL in an e-mail to someone. A piece of state information -- namely, the state of the MapQuest viewer when displaying a given location -- has been reduced to a token that one person can hand to another. The same thing can usefully apply to the state of a shopping cart or an airline reservation.

In a Java-based map viewer, a .Net-based shopping cart, or a Flash-based airline reservation system, it's possible to expose these states to the user so that they can be saved or exchanged. But this doesn't happen automatically, as with standard Web-based software. Such uses must be anticipated and explicitly prepared. Many, though, just can't be foreseen. My best example here continues to be LibraryLookup, an ad-hoc integration between book-buying sites and library catalogs. Because these two classes of system are URL-driven, it took only a snippet of JavaScript to automate the manual technique -- URL cut and paste -- that was already available. Replace either system with an RIA, and this integration opportunity goes up in smoke.

The idea that an application wears its state information on its sleeve, readily available for users to bookmark, modify, and trade, is an underappreciated strength of Web-based software. As the RIA bandwagon picks up steam, let's honor that idea and find a way to move it forward.