There’s been a lot of conversation lately about reinventing desktop office applications on the web. The first (and sometimes second) versions of all the stalwarts are out there: Word processors, spreadsheets, databases. I can think of Writely and Writeboard and NumSum and JotSpot and of course there’s dozens of others if you go out and do some research. (Good roundups and good analyses abound.)

But I spent a lot of time watching, learning about, and customizing office applications the first time they were rapidly evolving and picking up steam. I even made a living for a few years building on top of them. And there’s some mistakes being made by this generation of web apps that I hope get corrected.

We can all learn a lot of lessons from the history of DDE/OLE/ OLE3/COM /ActiveX/DCOM /COM+ (you can start reading upon Wikipedia to get some background) and how we went from everyone using best-of-breed standalone apps to one integrated, nearly monolithic Office.

It basically all started with copy and paste. People who never spent a lot of time in singletasking, character-mode operating environments like the DOS command line don’t recall that simply copying-and-pasting information between apps was difficult at the time. And part of the revelation of Windows for mainstream users (or Mac, for leading-edge tech fans), was being able to easily share data in that way. This was different than what Unix users were used to with the command-line pipe, or from what most applications do with feeds today, in allowing structured information flows between applications.

There’s a desire to combine data from different sources in an arbitrary way, and to have the user interface display the appropriate tools for whatever context you’re in. The dominant model here, probably because of the influence of the early PARC demos, is to have toolbars or UI widgets change depending on what kind of content you’re manipulating. Microsoft was really into this in the early 90s with OLE2, where your Word toolbars would morph into Excel toolbars if you double-clicked on an embedded spreadsheet. It was ungainly and ugly and slow, especially if you had less than an exorbitant 8MB of RAM, but the idea was pretty cool.

And it still is. People are so focused on data formats and feeds that they’re ignoring consensus around UI interoperability. The Atom API and Metaweblog API give me a good-enough interface if I want to treat a discrete chunk of information (like a blog post) as an undifferentiated blob. But all the erstwhile spec work around microformats and structured blogging (I forget which one is for XML and which one’s for XHTML) doesn’t seem to have addressed user experience or editing behaviors.

All of this is a long winded way of saying, we don’t have much beyond copy and paste right now. If I want to put a NumSum or JotSpot spreadsheet into a Writeboard document, I basically can’t do it. Maybe I can do it if all the apps are made by the same vendor and are made available as part of a suite, but we had that with Halfbrain seven years ago.

Now, nobody really adopted the interop specs for embedding rich objects between apps when there was the chance to do this on the desktop fifteen years ago. And this was part of the reason Microsoft Office was able to so completely dominate on the Windows platform by the mid-90s. Nobody else would interoperate in a way that let you easily swap in, say, Quattro Pro for Excel, and nobody else had a consistent way of scripting actions between apps. Of course, the point is moot, because Microsoft used bundling, some brutal and possibly unfair pricing, and an almost pathological underdocumentation of the specs to solidify their lead anyway. And that gave them the time to standardize around VBA as a cross-app scripting language, which took years longer than they had planned.

I can’t even imagine trying to debug cross-app scripting on Ajax apps. If it’s possible, it sure can’t be pretty.

But the battle for office app supremacy on the desktop may have actually been a fight instead of a rout if all the also-rans had added up to something more than the sum of their parts. What was needed was not just mixing and matching at the monolithic suite level, but more granular control over which components would edit particular types of information. It took Microsoft until Windows 2000 for apps to stop just grabbing each other’s file formats indiscriminately, and most regular computer users still probably aren’t sure what the hell application is going to start up if they click on an MP3. And if you want to automate the simple act of copying and pasting from Lotus 1-2-3 to WordPerfect today, more than 20 years after those applications launched? It’s basically just as difficult as it was when Windows 3.1 came out.

So, I’d love to see, as a user, a way for real rich data exchange to happen between the new wave of online applications. I’d like to see some efforts by (at least!) this group of vendors to make it possible to make compound documents between their applications, and then to choose from one or more tools for editing the discrete objects that make up those documents. And I’d like to be able to automate actions between these multiple tools without resorting to Greasemonkey hackery or convoluted browser tricks.

What can I offer in exchange for these features? Well, I’d pay to use the apps that are useful, of course, and I’d help promote the apps by sharing those documents with people. But I can also offer some tiny bit of defense over being completely obviated by the inferior, less open web office applications of the future that have better distribution due to the bundling that will inevitably come to this space. And scriptability means you can get features for free that you haven’t even thought of, which is a nice way to combat the bundled single-vendor suites that sacrifice flexibility for consistency and integration.

My theory is that the current wave of web office application developers, like the last one during the dot com bubble, has ignored the lessons of the desktop office suite battles. I’m hoping to be proven wrong.

Other links: Some pieces on this and related topics from the past couple years include my own stories and tools, an overview of web-app tech so naive it makes me wistful for my more innocent days. It’s remarkable how similar it is to Dave Winer’s What is a Web Application?, which predates it by two years. I found Dave’s piece as a link from his review of the state of the art in web office apps six years ago. It reads an awful lot like Richard’s review, only now we have feeds on everything and there actually seem to be some users.