Is it time to re-think OpenDoc?

I've been doing a lot of thinking lately about human-computer interaction. In my quest to learn the art of iPhone app development (which, mind you, is going poorly; I can't seem to get out of the blocks, as they say), I attended a CHIFOO presentation given by James Keller of Small Society, a local iPhone development agency of some note. Wearing a different hat, I've also been chipping away at a bit of science fiction for the last couple of years. I started it as a short story, but it seems to be heading for novel length all on its own. I'm not sure what length it will end at, but, like Spalding Gray's Monster in a Box, I'm just waiting to see how it comes out. The story involves people living and working on the moon, and I addressed the difficulties of interacting with a modern computer while wearing a space suit.

So, as I said, I've been thinking a lot about HCI lately. My thoughts took me back to a concept that Apple held forth back in 1992 called "OpenDoc." To quote Wikipedia:

The basic idea of OpenDoc was to create small, reusable components, responsible for a specific task, such as text editing, bitmap editing or browsing an FTP server. OpenDoc provided a framework in which these components could run together, and a document format for storing the data created by each component. These documents could then be opened on other machines, where the OpenDoc frameworks would substitute suitable components for each part, even if they were from different vendors.[2]

Browsing an FTP server. Um... yeah. Well, like I said, it was 1992. The latest release of the software, which never made it out of the 1.x series, came out in 1997. In short, it was a neat idea, but it didn't last, partly because of the "giant" (1 MB) footprint it took to load up the basic framework. There were other problems, such as problems opening documents that used elements for which you had no component, a poor implementation of a transportable file format, and (probably the biggest hurdle) competition from Microsoft. Indeed, OpenDoc was a direct response to Microsoft's OLE (Object Linking and Embedding). If you've heard of OLE but never OpenDoc, it's because Microsoft won the war. So far, anyway.

But perhaps OpenDoc was an idea ahead of its time. The basic concept, as stated above, was to create documents with an ad hoc set of tools that the writer calls up as they need them. Need to write a letter? Bring up a text editing toolset. Graphics? Call up a painting palette. In a connected, post-web world, this seems very achievable. Vendors like Google could provide a basic environment for document creation, much like they do with Google Apps now. But if the document format were changed to be non-proprietary and standard, and the basic environment allowed for other vendors' tools to be loaded and used, then small development shops, open source project groups, and even competing large companies could provide add-ins via remote services that would be transparent to the user. From the user's perspective, they would add widgets to the environment, selecting the widgets from a catalog of those available from all over the web. Using the tools at their disposal, they would create complex documents of all types (text, graphics, spreadsheets, web pages, etc.) and save them into a storage system, share them, or publish them for broad consumption.

Storage in the modern era doesn't have to be in a monolithic, single-source file system, either. We're already seeing storage services based in the "cloud" model. Current offerings are targeted at large firms and their IT services, but there's no reason they couldn't be scaled down to accommodate individual users. The idea of cloud-based storage is that it de-couples the location of the data from the application acting on it. Users of web-based e-mail services are familiar, whether or not they know it, with having their data stored "somewhere," but not having any physical access to it. For most people, where their data is stored really doesn't matter just so they can have access to it when they want and they can feel secure that no one is looking into it without permission.

Notice that I keep mentioning "data" instead of "files." Since the dawn of computing, people have been getting used to the idea of discrete files containing individual datasets. We open and close files, save files, organize files (well, okay, not so much), attach files to e-mail messages... We're lost in a forest of files, and frankly the concept is outdated for most purposes. People create and consume content, and today, the vast majority of the consumption is done via the Internet. None of the web-based services such as e-mail, message boards or blogs use traditional file systems in any way that's perceivable to the content creator or consumer (the writer or the reader, if you prefer), and those systems are thriving. In an online, connected world, there is no reason to manage files any more, only content. If a discrete piece of content needs to be exported from the cloud for some reason, a file may be the storage method to use. But saving something to a file should be the exception rather than the rule. Users need to realize that there's a new set of rules; ones they've been working under for some time.

From a technical perspective, an open standard is needed to describe the complex content that people are going to create. This is the only way to be certain of interoperability across editing environments, toolsets and storage systems. XML is a viable format to choose as a base to build from, and its possible that current schemas like ODF would support the system with little or no modification.

For users, the shift in the way they do things wouldn't necessarily have to be that great. As I said above, many people (possibly most computer users) already use some form of online content creation tool. And Microsoft Office products have for years used OLE to embed objects from different applications into documents, for instance inserting an Excel spreadsheet into a Word document. Users who need to be able to work offline or work behind a firewall could have the option to cache toolsets or work in an editing environment that's installed as an application.

The general ideas and practices to support a modern implementation of what OpenDoc set out to do have been around for quite some time, and the infrastructure is now here to support a more integrated approach to content creation and distribution. Microsoft, who won the early technology battle with OLE, has focused more on building on their Office suite than changing the way people use computers. But when you have a product that is in a leadership position for the market it's in, deciding to make a sea change in the way the product operates is not a decision to be made lightly, or at all, so it's understandable that they've held course. But for others, the story is different.

Almost twenty years after Apple released OpenDoc to the world, it's time to re-evaluate the pros and cons of the technology and see how they can be re-addressed in this post-web, connected world of online editors and cloud-based storage. It may not be Apple that creates the next great shift in the way we work, but they're in a good position to bring it about. Open source development could certainly produce the technology, but the mindshare of the computer-using world would have to be changed to accept the new way. Google is probably the logical choice to carry the banner, with their existing Google Apps suite, and an uncountable number of users around the world. But if they build it, will anyone come? I certainly would. How about you?