Reinventing the office suite

The controversy over office document formats heated up again this month when Microsoft and Massachusetts tangled over the state’s firm intention to standardize on the OpenOffice.org XML format. Personally, I think everyone’s barking up the wrong tree. Office suites haven’t felt like the center of the computing universe for a very long time. The network’s where the action is.

Today that means e-mail, and the majority of office documents I receive as attachments in e-mail are absurdly gratuitous. Word documents that substitute for plain text e-mail bodies are rarely formatted in ways that couldn’t be accomplished in a WYSIWYG HTML editor, or even using simple ASCII conventions. If the document includes tabular data, it usually arrives in Excel format.

We’ve known for a long time that a yawning gulf separates power users from the rest of us. I include myself in the latter group because, for fancy data analysis, I defer to experts like the guys at Juice Analytics. When I blogged recently about a stunning animated data visualization they accomplished using Excel, several folks wrote to say it was an eye-opener for them, too.

I don’t think the real problem here is the inability of an OpenOffice.org user to render such visualizations, whether because of patent encumbrance or format incompatibility. Instead, the problem is that few people are likely ever to receive such documents in the first place, because the ability to create them is not widely distributed.

Historically we’ve attacked this problem by creating wizards that encapsulate the necessary expertise. I suspect that the wizards of the future will be services that live mainly in the network, that receive and emit fairly simple XML formats, and that perform local processing (when needed) using portable run-time environments.

I saw a glimpse of this future when the folks at the Japanese software company Justsystem showed me xfy, a Java-based system for editing compound documents made up of mixtures of XML vocabularies, including XHTML, SVG, and MathML. An xfy component that’s used to visualize a chunk of XML data as an SVG graphic can be invoked locally through a Java interface, or remotely through a Web-services interface. And although the built-in SVG editor can’t yet be swapped out for another editor, the xfy folks agreed that ought to be possible, too.

We’ve seen all this before, of course. Compound documents, embedded objects, and specialized data type editors are ancient ideas. But this time around we’re not painting on a Macintosh or a Windows canvas, we’re painting on a universal canvas. And compound documents are no longer the static files they used to be. Nowadays they’re as likely to be dynamic query results drawn from a collection of data sources.

Don’t get me wrong. It’s great news that Microsoft will make its XML formats the default for Office 12, and will enable legacy versions to read and write them. This move will open up vast reservoirs of content for search and recombination.

I’m likewise jazzed about the growing maturity of OpenOffice.org. The world needs a good alternative to Microsoft’s word processor and spreadsheet.

But arguing about whose XML format should be the office document standard feels awfully retro. Instead, let’s reinvent the office suite for a networked world.