This delicate karma was shattered the other day when I needed to bang out an invoice for my customer. Rather than succumb to the siren call of office bloatware, I decided to give Google Docs a spin. What could be cooler than a free, lightweight web wordprocessor, I thought. Unfortunately the experience proved to be a deep disappointment.

Some issues were relatively trivial. For example, the clipboard commands don’t seem to work on Mac and kept prompting me to use the operating system’s keyboard shortcuts. Annoying but not showstopping. Much more serious was the table management, which is atrocious. I kept bumping into a bug that prevented me from adding normal text underneath my table; it just wanted to tack on additional rows. Resizing columns is a total nightmare and getting the text in the columns to line up properly went beyond the nightmarish into the realm of sheer horror. When I went to export my document as a PDF, it in no way resembled the “WYSIWYG” of my actual document. I spent what seemed like hours (and might actually have been hours) tweaking and exporting in a soul-sapping orgy of trial-and-error until I got something that vaguely resembled a professional-looking result.

So now I know why Google Docs hasn’t encroached more significantly on Microsoft’s turf: it kind of sucks. Don’t get me wrong, I don’t need or want the zillions of bizarre features that traditional shrink-wrapped vendors insist of pushing on users in order to drive revenue from useless “upgrades”. But something as basic as table management should just work, and the exported output should look like the original document, dammit. Concerns about the dismal state of browser-based editors are not new, of course. Clay Shirky was frothing at the mouth years ago over the lack of auto-save (though modern web apps seem to handle that pretty well), and I’ve whinged at length about various other aspects of the same issue myself.

Luckily, Google has a weapon in its arsenal that is perfectly suited to addressing this problem: Gears. Gears honcho Aaron Boodman blogged recently about Google’s ambitions for the product. Basically, the idea is not to replace existing browsers or preempt nascent standards. Instead, it is a platform for providing missing functionality in a cross-browser manner while vendors and standards catch up. So how about it, Google? A really kick ass editing component for Gears would fill a gaping hole in current browser feature sets and give Docs a fightly chance of competing effectively with its desktop-based counterparts.

Remember the rumored GBrowser? Well it looks like Google decided instead to build a stack of web application-focused services that run in a range of browsers using plugins or ActiveX. After all, why buy the cow when you can have the milk from all the cows for free? From where I’m sitting this was a very smart decision. Even Google doesn’t have the market power to impose a new browser brand on the world, so supporting third-party browsers is a reality that it has done well to embrace.

Most significant may be the mooted Desktop Shortcut API. Right now this creates a shortcut that runs in the browser that created it, but it’s not too much of a stretch to imagine it launching a standalone browsing process of some sort in the future. This would put Google smack dab in the middle of the site-specific browser game. Note also that the createShortcut function is attached to a Desktop class which is positively screaming to be the beneficiary of new desktop integration functionality in the future.

Does this mean that Google is rejecting nascent web standards like those of the WHAT WG? Someone pointed out to me that Ian Hickson, the brains behind WHAT WG and the Acid web compatibility tests, is a Google employee. You can hardly blame them for forging their own path, however, considering the frustration inherent in most standardization efforts. My guess is that they’re planning to fold their work into WHAT WG at some point in the future, but they don’t want that to slow them down.

Personal computing is currently in a state of transition. While traditionally users have interacted mostly with desktop applications, more and more of them are using web applications. But the latter often fit awkwardly into the document-centric interface of web browsers. And they are surrounded with controls–like back and forward buttons and a location bar–that have nothing to do with interacting with the application itself.

[Author's note: I am a contributor to Prism.]

The reality is that the current generation of web apps are trying to shove a square peg into a round hole. The fact that they’ve managed to jam it in there as far as they have is a testament to the ingenuity of the software developers involved, but it’s not a particularly satisfying solution. One possibility would be to address this by adding more and more application-oriented features to the web browser. But why bother when many years and countless investment in R&D have led to modern operating systems like Windows and OS X that already give us everything we need?

There are a number of other reasons to prefer running a web app on the desktop rather than in the browser. By giving it its own operating system process, you isolate it from other applications. If it locks up or crashes, it doesn’t bring down the whole browser. You can use all the fancy docks and taskbars that the operating system provides to gain easy access to your applications. You can use tools like the Windows Task Manager to see how much memory and CPU power it is consuming. Once again, we could theoretically add these capabilities to existing web browsers, but the effort would be massive. Clearly the idea of fusing web apps with the desktop is a promising one.

The other main contender (besides Prism) in what have come to be known as site-specific browsers is Adobe AIR. Both products integrate a standalone browser engine (Gecko in the case of Mozilla and WebKit in the case of AIR). Both support SQLite so you can store application data locally. In other respects, however, the products are quite different.

The aim of Prism is to provide the aforementioned benefits to web developers with minimal effort on their part. In fact, you can run existing applications in Prism without any modification at all. In the future, developers will be able to write special configuration files that adapt the application to make it fit more comfortably into the desktop paradigm, adding things like a menu bar, drag-and-drop capabilities and popup notifications.

AIR is more about getting Flex, which lets developers write Flash applications using markup similar to HTML (and even more similar to Mozilla’s XUL), to run on the desktop. The product does support HTML as well, but the clear focus is on all-singing, all-dancing Flex-based user interfaces.

This distinction has already led to a minor skirmish between the principal actors. Mozilla’s Prism blog post claims that “unlike Adobe AIR and Microsoft Silverlight, we’re not building a proprietary platform to replace the web.” In the comments, Adobe’s Mike Chambers takes offense:

Adobe AIR is built on top of web standards and can run existing web applications and content. It runs on Windows and Mac (and soon Linux), and it also provides additional desktop functionality.

This is correct but somewhat disingenuous. It’s no coincidence that Adobe is showcasing an array of slick-looking Flex-based applications while Mozilla is touting its support for web stalwarts like Gmail, Facebook and Meebo. This doesn’t mean that one is bad and the other is good. Blind adherence to standards is not always the best way to drive innovation, and it’s hard to deny the visual appeal of Flash when compared with plain-jane HTML. Some canny moves on Adobe’s part might even lead to Flex becoming a standard in its own right.

There are other players entering this space, notably Fluid, which currently runs only on Mac OS 10.5 (Leopard). It’s also worth keeping an eye on Google Gears. Originally announced as a way to let web apps function without a live internet connection, it is being extended to support features like placing a shortcut to the application on the desktop. The implication is that Gears will evolve into a direct competitor to Prism, AIR and Fluid.

It’s extremely early days for all of these products. I wouldn’t recommend any of them for use by mainstream users, but if you’re technically minded enough to be reading this you’re definitely a good candidate to take a look at them in their current form. By the end of the year, I expect them to have matured considerably. Soon enough we won’t know how we got along without them.

As web apps have continued to encroach on what was previously the sole realm of the desktop, the “airplane problem” has become increasingly evident. Although Ajax applications actually download their code onto the client before running it, they are still impossible to use if you’re not connected to the internet. In part this is because browsers don’t yet have the smarts to hold on to code that might be needed later. Leave your Gmail inbox and you won’t to be able to get it back without a live net connection. Moreover, you wouldn’t be able to do anything interesting anyway since all of your data is stored on some remote server and thus inaccessible when you’re offline.

The iPhone is a poignant illustration of this problem. When Apple announced that Safari would be the SDK for its new phone, industry observers were skeptical. Although the central theme of this blog is that the distinction between web apps and their desktop-based counterparts is eroding, Safari is simply not yet up to the task. One of the main lacks is the need to be online to use third-party web apps. There are many instances when this is impossible or inconvenient: on airplanes, as mentioned, but also when roaming, when you don’t have an unlimited data plan (you dirty hacker you) or any time you’re away from a wifi connection and have to rely on the glacial EDGE network.

Mozilla began tackling the problem at the beginning of 2007. Browsers already store JavaScript downloaded from web sites in their cache to speed subsequent loading of these sites, but not in a way that makes it usable when offline. What is needed is a persistent cache specifically designed for this purpose. The new functionality, which is based on a specification being fleshed out inside the WHATWG, is slated to be included in Firefox 3. Complex applications like Zimbra have already been adapted to take advantage of it. According to Ars Technica, Apple is “jamming on adding offline storage capabilities to Safari” for use on the iPhone. Since Apple is an active participant in the WHATWG, it’s reasonable to expect that their implementation will be compatible with Mozilla’s from the perspective of web developers.

The other contender is Google Gears, which also provides capabilities for storing code and data locally for use without internet access. Google has a couple of advantages over the WHATWG. For one thing, it controls some of the most popular Ajax applications on earth. Also, Gears is distributed as a browser plugin and supports Internet Explorer as well as Firefox (with Safari support on the way). This gives Google end-to-end control analogous to that enjoyed by Apple with iTunes (both the music store and the client) and the iPod. The WHATWG crowd has to convince web application developers to support its specification, and it has to deal with the fact that IE users are currently out in the cold.

So where is Microsoft in this story anyway? I couldn’t find any indication that they have offline capabilities at all, existing or planned. I suspect we may be in for a big surprise announcement when IE 8 is released this year. Perhaps they are even planning to support the WHATWG spec. That would be a real shocker but might make sense if they perceive their real rival in this game to be Google rather than Mozilla or Apple.

No discussion of offline capabilities for browsers would be complete without mentioning SQLite. Every solution in this space has one thing in common: they all use this small, fast, reliable embedded SQL database. Adobe has also adopted it for use in AIR, its platform for standalone web apps. It’s safe to say that SQLite has accelerated the rollout of offline-capable browsers by at least a year or two. It also has some of the most liberal licensing terms out there. D. Richard Hipp, its creator, is a genuine tech hero.

Next time in browser trends we’ll explore the rise of site-specific browsers and rich internet applications.