Like many of you, probably, I tire-kicked Google Spreadsheets when it first arrived on the scene, then forgot all about it.
A nice bit of AJAX hackery, I thought, but no serious competition for Excel. I was wrong, though, and here’s an anecdote that
explains why.
At InfoWorld we report vacation days in the following way: Every quarter, the HR folks e-mail me a blank spreadsheet with one cell for
each day in the quarter, I fire up Excel, type the letter V into each of the cells corresponding to a vacation day, save the
spreadsheet, then e-mail it back. It’s quaint, to say the least. But I’ll bet that somewhere in your company, some equally
quaint Excel sheet is performing a mission-critical function.
Last week, I e-mailed HR to find out if I’ve accrued more vacation than I can carry over. HR obligingly e-mailed me back my
two outstanding quarterly spreadsheets along with a polite invitation to file them so they can do the tally. When I picked
up that message in GMail, though, I wasn’t on my home PC that runs Excel; I was on a friend’s Mac that doesn’t.
No problem. GMail helpfully offered to open the attachments directly in Google Spreadsheets. I dutifully typed in the Vs,
saved the files to my local disk, and then attached them to an e-mail reply.
That transaction only hints at the real opportunity. If HR had created those sheets on Google’s server (or an equivalent enterprise
appliance), there would have been no need for anyone to upload or download files. HR would just invite me to annotate a sheet
it created online. The invitation would include a link. I’d follow it, perform my edits, and save the spreadsheet in situ
on the server. Related discussion could spool up in the persistent chat associated with each spreadsheet.
If you think this example is a corner case, I violently disagree. The most common workflows, by far, are mundane collaborations
involving chunks of semi-structured data. Despite its warts, we continue to rely on e-mail with attachments as the standard
enabler of these collaborations because it is a universal solvent. Our HR folks, for example, work for a different organizational
unit than I do. Implementing a common collaboration system would require effort. Exploiting the e-mail common denominator
requires none.
But while e-mail dissolves barriers to the exchange of data, we need another solvent to dissolve the barriers to collaborative
use of that data. Applied in the right ways, that solvent creates what I like to call the “universal canvas” -- an environment in which data and applications flow freely on the Web.
Here’s the best definition of the universal canvas: “Most people would prefer a single, unified environment that adapts to
whichever environment they are working in, moves transparently between local and remote services and applications, and is
largely device-independent -- a kind of universal canvas for the Internet Age.”
You might expect to find that definition in a Google white paper from 2006. Ironically, it comes from a Microsoft white paper from 2000, announcing a “Next Generation Internet” initiative called .Net.
So Google got there first, but we’re still in the early innings of this game. Google’s office apps, while collaboratively
adept, are functionally lame. Microsoft’s apps are adept and lame in precisely the opposite ways. Everyone needs to converge
on solutions that deliver the best of both.