Could Web-based PowerPoint-killers be the last straw for MS-Office?

By way of an entry on Bob Sutor's blog, I found CNET editor Rafe Needleman talking about the various entries in the marketplace that could eventually serve as Web-based replacements for PowerPoint.  Microsoft is already getting some pressure on the word processing and spreadsheet fronts (particularly now that Socialtext has taken on Dan Bricklin and his WikiCalc innovation under its open source wing).  Should Web-based PowerPoint replacement get any traction, the implications for Office could be serious.  Said Rafe (and I agree):

Everybody on the Net knows that Google is gunning for the heart of Microsoft's Office business, with its online word processor, Writely, and its spreadsheet, Google Spreadsheets. But Microsoft's most vulnerable application is PowerPoint, since it's used so much by business travelers (who might appreciate not having to lug their own computer around) and because easy access to online presentations could revolutionize sales....Google isn?t yet talking about its PowerPoint killer, but a few startups, like Zoho, Structured Data, and ThinkFree, are testing products that show us what a presentation service will look like online.

But Rafe also zeros in one of the big gotchas that will most definitely slow the acceptance of browser-based applications until something is done about it.  It's affectionately known as the offline problem and if you've been following this blog at all, then you already know that I write about it quite a bit. Wrote Rafe:

A challenge with all these products is that while they will be great for users who can be online to make presentations, things change if you find yourself offline, with nothing but a laptop and a projector between you and your audience.

Given my personal interest in seeing the offline problem solved, my feeling is that you can't have enough editors and bloggers out there talking about how it might get solved.  So, I took the liberty of writing a letter to the editor (in this case, Rafe).  It didn't have to go far since we both work for CNET Networks.  There are a few experiments taking place out there that may solve the offline problem. Although I've covered this ground before, I think its worth repeating in bigger picture terms that might appeal to a broader audience. 

There are a few experiments taking place out there, very early prototyping but there is promise, that may solve the offline problem.  One of these uses JavaDB, Sun's version of Apache's Derby project. The other -- known as Dojo.Storage -- relies on Adobe's Flash technology.  There may be others that I don't know about.  The questions for a browser-based app that could go "Web-less" at any time for any reason (loss of connectivity, or you're in a plane, etc.) is (1) where do I fetch my instructions from (basically, HTML pages, probably with some Javascript on them) and (2) where does the data (documents, form data, whatever) go when I press the submit button?
So, storage is part of the issue. However you decide to solve the storage problem, it'll have to be like support for HTML.  Everywhere there's a browser (your PC, a public kiosk, etc.), you'll need the necessary support. Nothing is in place today. Or is it?

Most places we go, browsers obviously have some sense of storage or "persistence."  For example, in some sort of cache they're storing cookies and history (the back button).  Something else that might be present locally plug-ins or the their equivalent.  Given its prevalence on the Web, most browsers (not all) are configured to handle Flash. How this is done at an appliance driven Web terminal, I don't exactly know.  But the point is that people who are putting terminals out there also know that pure HTML support isn't enough. It has to support a few common plug-ins that users often need to use Web pages and that you find on most PCs. The three most prevalent plug-ins (as far as I can tell) are Flash, Java, and Acrobat Reader (not necessarily in that order).  By their very design, Flash and Java both have a need to cache instructions and content.  So, in both cases, you have a highly programmable environment with access to some sort of  persistence mechanism (some sort of storage) for caching.
This is where the work on Web-less apps is taking place.  People are trying to figure out how to take the persistence capabilities in both Flash and Java, and instead of using that persistence just to handle whatever Flash or Java app you're running, it could be used to store Web pages (for fetching when offline) and user data (for submitting when offline).  The "storage driver" (and I use that term loosely) which is the piece of software that says "oh, the end user just pressed the submit button, hand the data to me and I'll store it in whatever cache I have access to" is written in Flash or Java (depending on which of the two environments is being used). 

The next natural step is to figure how to turn something more dynamic, like a USB-based thumb drive, into the persistence mechanism that such a Flash- or Java-based storage driver uses to handle the persistence of anything that may have to last until the next session or whenever a connectivity returns (cookies, history, the Web pages that normally drive your Web-apps, the data you create with those Web-apps, etc.).  This way, you can take you're computing environment with you, on a thumbdrive.  All you'd have to do is plug it in anywhere you go, and voila, there's you're entire browser-based computing environment just the way you last left it.  Even better, let's say the next place you plug your thumb drive into has a connection to the Internet.  Then, any data that needs to synch into the cloud synchs (imagine your offline authored Typepad blogs going to Typepad, your updates to a WikiCalc spreadseet going to the right WikiCalc spreadsheet, or  the emails you composed for Gmail automatically flowing through your Gmail outbox).
I describe this a bit in (and try clicking through to other links) my recent coverage of Google's Browser Sync software.  GBS is actually somewhat of a precursor to this world in that it's moving some of what you'd want to persist on your thumbdrive (cookies, history, passwords, etc.) to other storage areas or persistence mechanisms.  This isn't as many steps away as it seems from the aforementioned solutions to the offline problem.