The Long View
OpenDoc
One of the greatest things about the Lisa and the Macintosh (and the Xerox Star Office System) was their ability to embed text or images from one program into documents created in another, to create compound documents. In both Apple systems, this was done using public interchange formats for data. If you wrote a graphics program that saved graphics in a proprietary file format, you would still be expected to export graphics to the clipboard or scrapbook in the PICT format. Any program that wanted to be able to import graphics could implement embedding (but not necessarily editing) of PICT data into its documents. Apple documented a standard way to export and import text, sounds and later styled text and moving pictures into the clipboard. Much of the early Lisa and Macintosh promotional material emphasized the ability of their programs to make compound documents by embedding data created in other programs. This was a huge selling point, probably the single most important thing for attracting customers to the new platforms. It led directly to the desktop publishing revolution.
In the 10 years that followed the release of the Macintosh, a lot of programs took advantage of this feature. Apple, and also third party programmers, expanded this capability by adding additional clipboard formats for additional kinds of data. But if you used this capability a lot, you discovered an annoying problem with embedded data. You couldn't easily make changes in the compound document. For example, if you had a Pagemaker document with embedded graphics and you wanted to change a graphical element, you had to go find the file containing the original graphic, open it in whatever program created it, and make the change. Having done that, you now had to go back to Pagemaker, delete your previous graphic, and paste in the new version. In a complex document with embedded data created in a variety of different ways, making even the smallest changes could be a major hassle. If you had embedded the same graphic in a bunch of different documents, you had to locate every document affected by the change, open them and cut and paste (or drag and drop) to update the graphic in every one.
Maybe I shouldn't describe all this in the past tense. This is actually the current state of events for users of most Mac OSX software, and especially for software created by Apple, like Pages or iWeb. It seems strange to me that things remain like this, given that 15 years ago there was a serious and mostly successful attempt to improve the situation. Almost all the technology associated with that effort has been abandoned by Apple. But I predict it will soon be back, in a new form and with a new name. More on that later.
Microsoft -- Olé
For 10 years after the Macintosh was introduced, Microsoft struggled to create a comparable product in Windows, with disappointing results. But the deep ugliness and awkward user interface of Windows 3.1 hid some interesting technical developments. Starting in 1990, Windows contained a technology called dynamic data exchange, whose name was soon changed to Object Linking and Embedding (OLE, pronounced olé). It provided programmers with a way to embed a link to data contained elsewhere, and to display the external data, but not to make a permanent copy of it. This meant that there was only one copy of the original data, and it was displayed live. If a change was made in the original file, that change propagated to all the documents that linked to it. There was no need to manually update them. This didn't solve everything. If you want to change a linked graphic, you still have to go looking for the original file and the original program that created it. But once you did that and made the change, you were finished. The rest of the documents would take care of themselves. Later, OLE was built into the Microsoft Office Suite, and was obligatory for programs to get certification as compatible with Windows 95.
Publish and Subscribe
Apple developed a similar technology that was included in System 7. It was called the Edition Manager in the developer documentation, and Publish and Subscribe for users. As usual, Apple did a better job (than Microsoft) in explaining the technology to users, largely by giving each part of the process a descriptive name.
Making data available to other programs was called Publishing. Part or all of a document could be selected and then published. The published data were saved in a special kind of file called an Edition. Other programs wanting to display the data contained in the Edition could Subscribe to it. Like the Clipboard or Scrapbook, Editions could contain data in a wide variety of formats, and subscribers could query them to determine if they contained a kind of data that they could interpret and display. Publish and Subscribe worked great. If you look around the web to read about it (for example if you read about it on Wikipedia) you'll get the impression that it was not successful, but it really was. During its period of availability (System 7-9), practically every program for which Publish and Subscribe made sense implemented it. The most popular vector graphics editors, like Superpaint, Canvas and Illustrator had great implementations. Photoshop could publish its data for use by everyone else. Word processors benefited greatly, and most implemented it. During this period a lot of word processors (like Nisus and FullWrite) included graphics editors, so that users could make and edit images for use in their word processing documents. Publish and Subscribe made that unnecessary.
Microsoft implemented it especially beautifully in most of their Macintosh products (maybe because they understood the concept so well). The legendary Microsoft Word 5.1 had a great implementation of Publish and Subscribe, as did Microsoft Excel. One of the reasons why I continue to maintain old Macs is to be able to open old documents that have dependencies via Publish and Subscribe. This includes practically everything I did in the System 7-9 era. But both Microsoft and Apple have backed away from this kind of technology. I can still use it in Adobe Illustrator and inDesign, but I think this is Adobe’s own implementation and they have changed the names of everything. Apple has abandoned it altogether in their software, so far as I can tell. The Edition Manager was purged from the Mac OS in Carbon, no reason given.
What was wrong with Publish and Subscribe?
There is a problem with linking to data in files. We forget what files depend on what. Let's say I have created a compound document in Adobe inDesign (which still has this capability via Adobe’s own technology) and I've placed graphics and text in it, all of which were created using specialized programs that make that stuff better than inDesign does. Now I want to put my inDesign document on my thumbdrive and take it home. I can do that. But when I move the file onto my home computer, it opens with placeholders for all those graphics, and there are a bunch of warnings saying that there are missing links and missing fonts. I needed to take copies all the files my document depended on, including fonts. Of course I have no list of those files and fonts. Adobe inDesign has a solution for this. It will package a document along with a copy of each of the files it needs into a folder, with the links set to point at the copies. Then I can put that folder on my thumb drive, knowing everything is there. But neither Microsoft OLE nor Apple’s Publish and Subscribe had anything like that. If your document was dependent on a bunch of editions, you needed to take those with it when it was copied or moved. Most people didn't even keep a list of dependencies for their files, much less know where they were all located in their file system. Basically, this just the same old problem we have always had with the file system. Programs that implemented Publish and Subscribe didn't implement a way of gathering up all the dependencies for the user, and the Edition Manager didn't offer an API for that (or even mention the problem in the documentation). Subscriptions found their Editions via an alias, so were pretty resilient against just moving documents around in the file system. But that couldn't help anything if the Edition just flat out wasn't there. Rather than get organized enough to handle this problem, users often decided that it was safer to embed things in compound documents, despite the hassle required when they needed revision. It still happens with Adobe Illustrator, which can place a Photoshop file (or other graphic) either as a link or as an embed. People at work often ask me how they can make sure they are embedding, and not just linking to a graphic. They almost never ask how to be certain that it is a link.
As always, the problem is that the file system requires too much from the user in organizational skills. It would be different if all linked-to files were placed at some fixed URL on the network. Say, for example, that Apple gave us back Publish and Subscribe (please) and it was designed to store all our editions in our iDisk (or some other appropriate cloud-entity). No matter where we went, our links would never go bad so long as we could find the network. And that is why Publish and Subscribe will eventually come back. Of course, it will have to have a new name, and sound like something new. Publish and Subscribe was one of those things (like the Newton) that Steve Jobs killed when he came back to Apple. To bring it back, it will have to be made to be a completely new thing. It already has started to happen for calendars and things like that.
Compound documents
In the late 1990's Apple and many others were thinking of another solution. Maybe the problem is that we are thinking too much in terms of applications, instead of documents. What if all the data for a compound document was stored in the document, so that if you move the document everything goes with it. Furthermore, make programs that create the components of the document edit and render them in place in the document. The user would always use a single program, but it would effectively be a blank slate, a container for a variety of chunks of data. Each chunk would be rendered by a plug-in made specifically for that kind of data. The plug-ins could have a minimal user interface, just handling the things that were unique about each data type (table, vector graphic, text, pixelmap, etc). Sound familiar? That’s right, it’s what web browsers do. Web sites are compound documents. Web browsers can render some standard components of a web site themselves, and rely on plug-ins to render specialized kinds of data. We barely notice the plug-in renderers, unless we are missing one. Of course web browsers are read-only.
Application or document? Pick one
The Macintosh and Windows are both very application-centric. The Lisa and Xerox Star Office System were more document-oriented. The newest craze is the iPhone and iPad, which are even more application-oriented. They deliver us from our disorganized file system by making us think that we don't really have any documents at all, only programs. Of course our mail messages and photos are documents, but we don't have to think about them that way. Even the photo collection in Photos looks like an application, not like a directory (even though it absolutely is a directory). From this you might think that the applications have won and documents have lost. Documents are just going to disappear. Good riddance.
On the other hand, the world wide web is just as radically document-centric as the iPad is application-centric. We live with both of these and simultaneously think of both of them as the next big thing. This works because for people who are only reading web sites (most people), the web can be presented as just another app -- the web browser. Things look different for those who are creating web pages, though. For them, the web is a document, not an application. For creators of iPad apps the world is likewise document-centered. The programmer (uh, I mean Developer... sorry) has to combine pictures, drawings, sound, and code to make those document-free apps, which are really compound documents themselves. Do I have to even mention website creation? What a contrast there is between the tools we use to make websites and the ones we use to look at them. Wouldn't it be great if I could really make my website in iWeb? I mean wouldn't it be great to be able to edit pixel map images in place in iWeb? Not just stretch and mask, but crop and draw and erase? And why just websites? Why can't I just do all my writing in Pages? I mean, why couldn't I create a Numbers-style table in Pages, and have it display live in my document, along with a graph made from the table, instead of having to cut and paste static, lifeless pictures of those things. One program to rule them all. Of course, writing a program that could do all that would be tough, and the program would be big and hard to maintain. And also, once you bought such a program, you’d would be pretty much locked in. If you wanted to use Excel for your spreadsheet you'd be out of luck when it came to using it in a document. The trend for a long time has been away from integrated software (like ClarisWorks, as good as it was) for all these reasons.
OpenDoc
OpenDoc was a scheme for making a document-centric document creator and viewer. The idea was similar to that of a web browser, in that the main program (OpenDoc itself) is just a container with some simple capabilities common to all kinds of documents. All documents were OpenDoc documents, so no complex relationship between document and creator application. OpenDoc provided the user with a means to specify a place in the document in which to place some kind of data, and to specify a plug-in that could render and edit that kind of data.
As always, Apple clarified things by making up good names for things. A chunk of data living in a particular place in a document was called a Part. The plug-ins were called Part Editors, and they provided all of the rendering and editing capabilities. The Part Editor would display the data in the place provided, and would insert menus, display palettes, etc. Those user interface items would be displayed when a Part was selected to provide tools for editing. Part Editors were executable code modules stored in a directory called Editors within the System Folder. You just had to make sure you had all the Part Editors you would need for your document on each computer you used it on, just like you have to make sure you have all the plug-ins you need in your browser. 
Third parties, Apple hoped, would be excited to write OpenDoc Part Editors, partly because they would be relatively easy and cheap to make. They were lightweight compared to regular Macintosh programs. They should be easier and quicker to write, and Apple provided a complete programming framework (in C++) for creating them. It included great documentation and example programs to get you started writing Part Editors.
I'm sure that the OpenDoc team entertained the idea that this might basically replace the application-centered approach that dominated computers then and now. They imagined a future in which a computer might run only a single program, OpenDoc, and users would not have to learn how to use a half-dozen programs just to create a brochure or an annual report. One indication that they were thinking this way was the fact that you could not quit OpenDoc. It had no Quit menu item. In for a penny, in for a pound. If you've seen the Knowledge Navigator video Apple created during this period, you saw the professor character using a single program displaying a compound document to read his email, engage in a video-chat with his colleague, review his notes, search for recent published scientific papers, examine his calendar, and a bunch of other things. Not once did he go searching through his directory tree looking for some file.
What happened?
OpenDoc is one of those Apple technologies that are always listed in those lists of famous Apple failures. I hate those lists, because some of my favorite things keep recurring in them. But there is no doubt that OpenDoc was not popular with users, and there were few Part Editors sold. It was released with System 7.5 in September 1994, and it was terminated with extreme prejudice by Steve Jobs (he said he put a bullet in its head) when he came back to Apple in March of 1997. It is true that it hadn't taken off, but it only was out there for a little more than 2 years, and had not been very aggressively revised during that time. Apple was in turmoil the entire time OpenDoc was under development. You can read about it in the account by Greg Maletic, who was the OpenDoc Product Marketing Manager. The various software groups at Apple were pulling in different directions and there was no commitment to any of them. There was a big concern that OpenDoc might mess up the business model for the entire Mac software market. It probably would have (in a good way), but with Apple market share and perceived coolness at a low ebb, that sounded risky. The OpenDoc project also got embroiled in Apple's attempt to make it an industry standard by engaging a motley group of other companies, most destructively, IBM. Trying to make fragile temporary cooperative arrangements between warring computer companies (to hurt others) was all the rage among business executives at that time. Apple has never been good at that.
It's not too late
You can still try out OpenDoc and see what a document-centric system would be like. It is easy to install it, but it’s best done on a Power Mac, or on a power mac emulator like Sheepshaver. It is available in OS distributions starting with System 7.5. For System 7.5 look for it in the CD Extras directory. I don’t have a System 7.6 CD. It’s in the Software Installations directory on the Mac OS 8 installation CD. I can’t find it there in the Mac OS 9 installer. Maybe it had already been disappeared by that time. The real problem now is that it is almost impossible to find any of the part editors that were written at the time. If you have Apple's ETO programming tools disks from this era (e.g. ETO 23 or thereabouts) you can get a bunch of example part editors from the examples. If you can, get a copy of Nisus, version 5. Nisus was a serious adopter of OpenDoc, and it came with some useful Part Editors, not just demos. Or, you could write one of your own using MPW or Codewarrior. It really is pretty easy. OpenDoc was a great idea. Application-centric computer systems will be fine for creativity consumers, using the iPhone or iPad. But somewhere somebody has to be making the stuff that everybody else is looking at on those things. Those people are concentrating on their documents.
-- BG (basalgangster@macGUI.com)
Saturday, April 17, 2010
