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.