I'd been experimenting for a few months with Gmail, Google's Web mail system, without really taking it seriously. But this week I decided to take the plunge and try using Gmail not only as a mail search engine, but as a replacement for Outlook (on Windows) and Mail (on OS X). Now I'm ready to join the chorus singing the praises of GMail's user-interface technology. Its combination of HTML, JavaScript, and the DOM makes the browser do some remarkable tricks.
...
As early adopters discovered long before I did, there's an architecture behind this JavaScript/DHTML wizardry. The best description I've found is from Johnvey Hwang, who deconstructed Gmail's JavaScript code and created a .Net-based Gmail API. As Hwang described in his July 5 write-up, Gmail loads a JavaScript UI engine into your browser at the beginning of each session. Oddpost, he noted, was the first Web mail application to perfect this technique. That was a prophetic statement: Just four days later, on July 9, Yahoo acquired Oddpost.
Because Gmail's behavior is embedded in the UI engine, all subsequent interaction between the browser and the Gmail service is just an exchange of data. What Hwang calls the DataPack format is not XML, though; it's JavaScript. When you make a request to the Gmail service, whether to refresh your inbox or to modify the list of labels you can attach to messages, the response is a minimal set of JavaScript function calls and associated data objects that the engine uses to update the display.
...
So is Gmail a rich Internet application? Sure. Although that label most often applies to Java, .Net, and Flash clients, Gmail shows that Web clients can join the club too. But crucially, Gmail's architecture is open to other kinds of rich clients, too. It doesn't have to be a zero-sum game. [Full story at InfoWorld.com]
There's been a fair bit of blog commentary about this column. I've also received a number of emails, several noting that even an envelope-pushing Web UI such as Gmail's can be fruitfully enhanced with Java, .NET, or Flash.
I couldn't agree more. This morning, while testing some new screen-recording tools, I cooked up a nice A/B comparison in the application domain of photo sharing. As a test, I made and viewed an album in two1 different applications. Webshots is a straight HTML/JavaScript app2, and Flickr3 is an HTML/Flash hybrid.
Here's the five-minute video: Flash, high-res, 30MB, Flash, low-res, 6MB, QuickTime, high-res, 10MB4
I think you'll agree that Flickr's selective and strategic use of Flash is enlightening. So what's this got to do with Gmail and the future of Web UI? I suggest there's no one-size-fits-all solution. In many cases, what will make the most sense is a hybrid application that uses Web 1.0 for all it's worth, pushes the DHTML envelope, and weaves in rich-client technology where it adds the most leverage.
1 Webshots album here, Flickr album here.
2 Yes, I'm aware that Webshots' strong suit is its downloadable/installable photo management application. For my purposes here, though, I'm just exploring what can be done through the Web and on the fly.
3 Full disclosure: I know, and have hung out with, some of the Flickr folks.
4 I'm still sorting out the tools situation here. Too many players, too many formats, too many moving parts.
Former URL: http://weblog.infoworld.com/udell/2004/10/26.html#a1102