the Onda

Though I am really happy to see Google experimenting with revenue models outside of advertising, yesterday's launch of their premium business applications left me thinking that they are either a) gleeful about the possibility of putting a stick in Microsoft's eye or b) not yet clued in to what makes things work on the web if they don't have a search box in them.

Software as a service (SaaS) delivered in the form of dynamic and rich web applications is a really great thing— in fact probably the most significant thing to happen on the Internet since the coming of the web itself. However this does not mean that every possible thing someone wants to do with a PC can be crammed down the HTTP-pipe and decorated with pretty Javascript effects. Below are some of the standard reasons:

1. FIOS-enabled homes and offices notwithstanding, there is still just too much latency on the Internet, plain and simple. This is the main reason why taking any old desktop application and webifying it usually doesn't work. Word is faster than Writely, Excel is speedier that Google spreadsheets, and no matter how hard we may try, iPhoto or Picasa will always be faster than Tabblo for manipulating photos. Therefore, if you've got an application which sits open on your desktop all day ready for you to edit, compose, and otherwise author 20-50 times a day as is the case with Word, Excel, and Outlook for most office workers, taking that online is a big bet to make.

2. There are things you just need calls into the OS for which most modern browsers do not give you access to yet. For instance, office applications often produce documents that people want to print, and yet most browser-based printing is still stuck in the stone ages (how many times have your printed Mapquest directions only to get that hanging chad of a last turn on the last page?) Ditto for really rich APIs into other sources of data that live on the local filesystem (Outlook pst files, OSX Spotlight index), or even for rich access to the local filesystem itself. Try as we might, if you have things that you need to either source from the local disk or output to the local peripherals (printers, CD burners), the browser is not your friend. Interestingly enough, Adobe's Apollo project may solve this (a big "may" though as many have tried).

3. Where the data lives is a pretty important thing to think through, especially if you are a business. Sure no one backs things up properly, and for sure your office is more likely to be burglarized, burned down, etc. than a world-class datacenter, but for most people knowing that the data is under their control is more important at times than the data itself. Sure, a service provider can encrypt the data and partition it accordingly, but in much the same way that big financial institutions with liability exposure don't allow their employees to use standard IM, I suspect most big companies will be leery of trusting Google with sensitive, mission critical data. On the consumer side this is also a problem, albeit one that is mitigated by the fact that most consumer data that makes is to the web is not as sensitive (and the fact remains that most savvy consumers see uploading the data to a service as a poor man's backup).

These reasons by themselves should serve as powerful motivators for thinking carefully about trying to move any major desktop application to the web. If an application is going to take on the encumbrances mentioned above, the benefit of living on the network have got to be very high— in terms of ubiquitous access, collaboration, or best of all, the symbiotic relationship that the application can have with its users as it grows up.

Ephraim Schwartz interviewed me about Tabblo recently and wrote a nice piece on this co-development process where I make all sorts of bold claims about the productivity improvements that come from having an online app that lives and grows directly based on the use patterns of the community around it (which is itself growing). That same thin HTTP pipe I mentioned as a problem above becomes your best friend in this regard— by serializing every action into a very digestible set of log entries for subsequent analysis, it gives one a much better real-time view of what is working and what isn't. And because the user-facing application runtime is the web browser, UI flows can be changed near instantly without having to redeploy to an installed base.

The overall mental image I have of the process is that of an acelerated time-lapse movie of coral growing according to its environment and the actions of its co-habitants.

The main problem with trying to grow a coral from a word processor, a spreadsheet, or an email client is that the specs for these products are fairly known and have been pretty fixed in users' minds for about a decade now. Witness Gmail— every time I hear complaints about it, it is from someone who comes from the Outlook worldview and is almost certainly around the most innovative (and web-native) parts of the interface. The patterns are already well-worn so it becomes difficult for the application/community to take on a life of its own.

Paul Graham wrote an essay a while ago about Web 2.0 that argued that Google was succeeding because it was aligned with the "grain of the web." I completely agree which is why it is strange that they would use the office suite as their first beachhead into for-pay SaaS.

Post a comment