Fellow ZDNet blogger Garrett Rodgers:
Online word processors aren't as "handy" as one installed on your computer because if your internet goes away, so do your documents — so I will start with the most interesting piece of code I found. Google is working on a solution that will allow you to install [it's Writely Web-based word processing solution] on your local machine.
So, what Garrett is getting at is that a lot of people have poo-pooed the idea of Web-based productivity applications because of the so-called "offline problem." When your connectivity disappears for whatever reasons, you have no access to the code that drives the user interface of a Web-based word processor, nor do you have access to the storage where documents can be save to or retreived from. So, from Garrett's post, it appears as though Google's code for Writely has some built-in contingency plans for loss of connectivity that rely on the local host (eg: your desktop or notebook computer) to take over when Google's servers can't be accessed (again, for whatever reasons).
This is nothing new. Perhaps the best solution I've seen that does roughly the same thing and that makes synchronization between the local and network-based storage (and just requires a low-overhead local HTTP server) is Userland's Radio blogging solution (credit to Dave Winer). More and more, solution providers will recognize the genius in that design as they look to deal with the offline problem as elegantly as possible given today's constraints. Radio even works across platforms (Mac and Windows).
Short-term, relying on the thickness of a desktop or notebook to solve the offline problem make sense since we all seem to be happy to keep mainframe-like compute power nearby. Longer term, I expect lighter-weight solutions to emerge; ones where the persistence mechanism for both code and data is a USB key (or something like it) and, instead of taking a notebook computer with you everywhere, you just carry your USB key and plug it in to whatever "kiosk" is nearby (note, a kiosk could be mounted into the seatbacks on aircraft and the tray in front of you could easily have two sides: one is flat and the other is a keyboard).
A world like that implies the ubiquity of certain technologies in certain contexts (most of which doesn't exist yet). In terms of interfacing public compute facilities with portable memory, is USB the transport? For the code in that memory to work everywhere, what's the ubiquitious execution environment that would accompany every browser? The three leading choices are Java, .Net, and Flash. Francois Orsini has already demonstrated, using a Web-based tax application, how Java could enable something of this nature. But we're a long ways off from seeing that sort of infrastructure turn up everywhere it's needed. In the meantime, harnessing the power of Windows, Mac OS, or desktop Linux to solve the off-line problem makes perfect sense.
If Google takes it a step further with auto-synchronization between offline and online documents and enables it wiki-style for network-based collaboration, Microsoft Office will have a new set of challenges on its hands given that it's closest competing solution currently requires very thick solutions like Microsoft Office and Sharepoint (note: in addition to installing it locally on a Windows Server, Sharepoint server functionality is also available as a service from Microsoft and other parties).