the onda

Almost one year in, one of the biggest surprises about my new execujob is how little I've come to like the senior "technology architecture & strategy" discussions that I'm invited to sit in on. I had originally thought that being at the biggest tech company in the world would provide some unique perspective on the hot topics of the day (cloud computing, green computing, the semantic web, the blurring of the desktop and the web) that you wouldn't get out in the wild. In reality all I've done is develop an ability to breathe in really shallow atmosphere situations, as most of these discussions take place at such high altitude that I've taken to bringing Kleenex in order to stem the nosebleeds.

Naturally one of the hottest topics these days is the definition of the runtime for the next generation of Internet applications. With Microsoft and Adobe and their vendor sports death match (Silverlight versus AIR) fueling most of the recent debate, and Google/Yahoo/everyone else who matters looking to get more life out of the heavy server/light browser architecture that has become predominant over the last 10 years, it should actually be an interesting discussion.

But alas at 100,000 feet, all of the platform tradeoffs look like small dots in the distance. Everyone's got their favorite example: Microsoft is pushing the whole rich interactivity concept with their zoomable Hard Rock demo (and upcoming Olympics Silverlight-based coverage), and just today Adobe has entered their canonical example into the ring with Photoshop Express. I'm personally much more interested in every day applications that regular folks have gotten used to compromising on, either in their desktop version, or in their browser-based one. Apps like: email, instant messaging, or even word processing.

When considering the web versions of these guys, everyone gravitates towards the offline story because that is the place where the current generation of web-based applications falls down most dramatically. However, with every browser vendor embedding SQLite and efforts like Google Gears well underway, and with the ever expanding reach of the network into every offline nook and cranny, it is unlikely that this will remain a problem for much longer.

Where there tradeoffs get more interesting however, is when it comes to desktop integration. It is ridiculous that 24 years into the evolution of the GUI, the browser makes us take a step back when it comes to simple things like uploading files to a web service or slightly more ambitious ones like integrating across applications. Yet that is exactly where we find ourselves today.

To see how much I missed proper desktop integration in my everyday consumption of one of these apps (Gmail), I recently downloaded a $25 OS X program called Mailplane which puts a very thin rich client wrapper around the Gmail experience. Ideally this is the kind of thing that Google itself could build with something like AIR or Silverlight but while those guys take their time getting to the useful applications (instead of the eye-catching ones), I figured I would skip to the blended desktop/web future by tinkering with Mailplane.

My conclusion (after two weeks): integration really does make for a much better experience. Here are the things that Mailplane does that make me feel happier:

1. All of the standard keyboard shortcuts work as you would expect (i.e., command-N gives me a new message)
2. Inter-application stuff works as expected as well (i.e., "Mail this link" opens a new message in Mailplane with the link in the body)
3. Notification works: on OS X, the incredibly useful Growl notification system can show incoming/outgoing messages like Outlook does along with the icon in the Dock showing the number of new messages)
4. File attachment works as well: unlike the goofy behavior that most web browsers implement when you drop a file on them (to open said file), dropping a file into Mailplane results in it being attached to the outgoing email. This is a huge deal, especially as we rely more on apps and less on the Finder/Explorer to wrangle our data.

There are two downsides to Mailplane. First, because it spins up a separate process with a browser in it (an embedded version of Webkit), it does consume RAM galore, especially in an AJAX-heavy webapp like Gmail). More importantly however, it is a traditional desktop application which means that in this case you have to pay ($25 per seat seems a bit steep in today's world) and that your app preferences are ghettoed in the client computer that you originally installed it on. Ideally, the rich runtimes would help to solve both of these problems.

While researching whether there might be something better out there that might address some of these shortcomings, I ran into this Mozilla Prism inspired project, Fluid, which allows you to create site-specific browsers that approach some of the same functionality that Mailplane provides (through the embedded Greasemonkey functionality). As I played with this "Site Specific Browser" approach however, I found that I wasn't getting enough of 1-4 to make it any better than keeping these webapps in separate tabs.

Here's what I'd love to author of Fluid to do (or some other such force out there on the Lazy Web): wrap a Javascript API around each of my points above so that if a website (or even a user via the built in Greasemonkey functionality) wanted to implement notifications or file uploads or whatever, it would be as easy as testing for the presence of the objects in Javascript and writing to their Javascript API. With a little luck, and a Windows version, you might get some serious traction with a project like this.

I first heard about this custom browser approach when Flock (remember the "social browser") first launched a couple of years ago and found it utterly idiotic that someone might replace their browser with one of these tweaked out custom jobs. But I've got to admit that using Mailplane has made me reconsider.

Or maybe it's just all of that lack of oxygen...

Update: It turns out that Fluid is making nice progress to exactly what I was asking for already as you can see from their developer page. The big missing feature for me at this point is webapps being able to register for keyboard commands (think command-N for new Message not new instance of Gmail).