I write for a couple of different sites. Including this one, write and have written for CompuServe/AOL, Pocket PC Thoughts, Lockergnome, The Gadgeteer, CMPNet’s File Mine, WUGNET: The Windows User’s Group Network, and Gear Diary. Honestly, life is all sunshine and daisies when the site is up and your backup app is working.  However, when things go south, and you find out that your data is gone due to some sort of corruption or backup problem, life can get very complicated. 

Gear Diary had a problem like this not too long ago, if you remember.  Judie, the site owner, ran around like a nut trying to work with the hosting company to get things turned around.  Some things went well, but others did not, and we had to rebuild the site from scratch.

Gear Diary is a WordPress enabled site, so many team members use the online WYSIWYG editor to create and edit content. It saves drafts, allows you to upload (and even watermark) graphics/pictures, and is, for all intent and purposes, an online word processor, much like Google Docs.  When the site went belly up, most of the content headed south the border as well.  Most team members had not saved a local copy of their work…which got me thinking…

One of the biggest and hottest trends I’ve been hearing a lot about lately is software as a service, a la Google Docs, Office Live, etc. If you take the Gear Diary site issue as a point of reference, and apply software as a service (which is basically what WordPress is acting as), you get an interesting and fairly destructive situation.  WordPress doesn’t offer any kind of method of saving its documents locally, or in a format that can be read (or edited) by any other local application. Despite the fact that WordPress creates HTML documents, all data stays on the server.

If you bump into a server issue, i.e. you go down, your data gets lost. It happened to Gear Diary. It can happen to any user that uses a software as a service app. what bothers me more, is that unless there’s a specific viewer or offline editing tool for the document type, the data is useless.  Further, if the app doesn’t allow you to save data locally, an off line viewer isn’t going to do much good anyway.

Many users here (those that work right on the server) have taken to copying the code out of WordPress and saving it as a text or HTML file. That at least gets the data out and saved to your local hard drive.  However, it doesn’t address disaster recovery on the client side (which was one of the big draws, aside from cost savings and the lack of deployment problems…all you need in most cases is a compatible browser…).

Interestingly enough, Google may be planning changes to their online suite that would allow users to do just this: save data locally. As I noted above, the ability to save data to the server is nice, but if you’re on a laptop and not connected to the ‘Net, you might be out of luck if you’ve got work to do.

If Google Docs users have downloaded Google Gears, they should be able to edit a copy of a locally stored or cached version of the data, when they open a browser, and "navigate" to docs.google.com. Users will be able to transfer the updated data back to the server when the computer goes back on line, which is huge; but I don’t necessarily want to rely on data that’s still in my Internet cache.  The browser needs to save the file locally…and it would be nice to have it saved in an industry standard format.

I’d love to hear everyone’s opinion on this.  Why don’t you join us in the discussion area and give us your thoughts?  I just have one request…I’d like us to NOT get into a debate over software as a service vs. a client side app, if possible.  I’d like to hear everyone’s thoughts and ideas on getting past the problems and challenges I’ve outlined: saving data locally and to a server, local file viewing and editing and disaster recovery; but if we MUST debate the entire issue, that’s cool too!