The ups and downs (as in connectivity is down) of using Google documents
As the Consumer Electronics Show draws closer, we're trying to establish what's known as an "editorial budget" for the event. Please, no, that's not an invitation to all you PR folks out there to send more e-mail... we have a sea of e-mails to wade through as it is. In fact, that's what we're doing right now... wading through the e-mails and coming up with a plan that makes sense of it all.
In the media world, an editorial budget has nothing to do with money. It's sort of a carry-over from print where you have a budget for how your column-inches (the measure of real estate in print publications) are going to be spent. But the editorial budget also clearly articulates the editorial plan for everyone involved in the editorial process right back to the original content creators and, as best it can, it spells out what the final editorial package for some piece of coverage will include. To bloggers, an editorial budget is the sort of fat that needs trimming from the traditional journalistic process because it represents the sort of overhead that can slow things down (blogging, to some extent, is about speed). Even so, when you have a show like CES that covers multiple convention centers (the Las Vegas Convention Center and the Sands Conventions Center), throngs of people, and long cab lines, it helps to have a bit more of a plan than just "walk around."
Spreadsheets, as it turns out, are the perfect application for throwing an editorial budget together. Since multiple people are involved in our planning, we're giving Google Spreadsheets a try. One advantage of Google Spreadsheets is how it's readily accessible to everybody that needs access to it (in or outside the corporate firewall), those who have access to it can edit it, and it's great for straight text (we don't need formulas or anything fancy like that). So, today, just asstarted adding stuff to our first Google Spreadsheet, I went to make a change and here's what happened:
<tip>If you ever get the "Try Again" option when filling out a blog or other Web form and you're afraid of losing your whatever you've plugged into the form (which could be substantial the the case of a blog), DO NOT hit the back button. Leave the Web browser exactly as it is, try to re-establish connectivity (and test it with some other application or other browser window), and then go back to the browser window where the try again option exist and click the try again button. In most cases, it will attempt to resubmit the information that you entered into the form. I've done this many times with Wordpress and it works. But if you hit the back button, most of your information will be lost.</tip>
So, short of a "try again" option, I picked the first of the two (Discard Changes and Reload). Here's what happened next.
As best as I can tell, somewhere in the midst of working with the spreadsheet, Google Documents thought I lost connectivity and, since I had yet to save my work, it had nothing on record (no URL that would normally associated with the spreadsheet)... a situation that was reflected in Google Doc's list of spreadheets that I had access to:
I didn't lose much work. I had entered data into about three cells when this happened. So, it was no big deal. But it certainly is reminder of two issues when it comes to working in the proverbial Office 2.0 world. First, save and save often (and just maybe, double check the status of your connectivity before you save by pinging some other Web site in another browser window or sending someone an instant message). Second, this is really about the infamous "offline" problem that proponents of locally installed software like to talk about.
I honestly think that 2007 is the year that we'll see a lot of movement on that problem. For example, how to make sure work doesn't get lost even when it's a browser-based application. Early on, what you'll see are platform specific solutions to this problem. For example, if you're not connected to the Net or your connectivity suddenly disappears on you (like it apparently did me), the application will save it locally to what is in essence a backup Web server running on your desktop and notebook.That server will not only be capable of having information saved to it (it eventually goes to your hard drive). It will also be capable of serving up the forms as though you were connected to the actual Web site. Then, when connectivity is re-established, synchronization between your local "store" and the one "in the cloud" will automatically happen. If the document is a shared one (as it might be in the case of a Google Documents document) and the one in the cloud has changed since the last synch, the application will be smart enough to detect that, point out the differences (what 'Nix folks know as "diff"), and check with you before overwriting the changes that someone else made.
Since having local Web servers to handle data persistence (for offline work) implies a significant amount of local bloat -- the one thing that would be nice to get away from if possible -- longer term, you should expect to see other persistence mechanisms that involve portable memory devices (perhaps smart USB keys, SD cards, or Compact Flash) and persistence technologies (ie: Flash, Java, etc.) that can run within the context of most any browser installation and that don't necessarily require a specific, full-blown local platform (ie: Windows, Mac, or Linux).