The people of the world Iix had 8 arms, and interesting keyboards. They also had no hierarchical filestores, and it was this difference that made their usage of computers so very different from ours.
All computing was done with completely flat filestores; they had magnetic media where they could store data: hard disks, floppy disks and so on, but since disks were only a sequence of bytes for storing information, each program had to separately structure its data on disks. Though there were hard disks, only the operating system could use them since it could not allow its security to be compromised.
Consequently, programs only wrote to floppy disks; and each user had a stack of floppies, one or more for each program. If a program, such as a word-processor, needed to structure data, or create different documents, then the program had its own format on the floppy, a format designed by the programmer of the program, and in general not readable by other programs. Some more successful programs were so successful that other programs could also read their floppies, but in general there was very little consistency between data-formats.
Programming was a very hard task for programmers: they had to design their document structures, and the code for a simple task like finding a file on a disk and opening it was an immense task, especially since disks sent all kinds of events, like DiskIsAtSpeed and BlockRead.
One day however, a bright programmer noticed that she was often writing very similar code for reading and writing data to disk, and that she structured data in a number of very similar ways. So she did a very bright thing: she created a library of code that allowed her the maximum of flexibility to design her document structures, and that she could re-use each time she had to write a program. She then packaged them together in a library that she called a 'toolkit', with a large batch of documentation on how to use it.
And then one day - better late than never - a research group in a major corporation invented hierarchical filestores! They immediately created a toolkit that implemented them, wrote a large manual of guidelines, and passed it on to the marketing division.
Unfortunately the product flopped. But not the idea! It had gained the interest of researchers around the world, and was used by another company on their new computer. This product didn't flop, and in the shortest time the computer was a great success, and research groups around the world were imitating this implementation of hierarchical filestores. And not surprisingly, other companies came out with similar implementations. But alas there were many lawyers there, and these other companies got taken to court for imitating the idea.
As a result, companies started releasing almost-but-not-quite implementations of hierarchical filestores. One released a hierarchical filestore that only had two levels: less useful than unlimited depth, but hey! better than nothing, and anyway 90% of data stored by their users was no deeper than 2 levels anyway.
Another company released a toolkit where the filestore was actually flat (so that no two files over the whole store could have the same name) but where files could still be grouped together in directory look-alikes. And these differences seemed to save the companies from any further legal difficulties.
These hierarchical filestore toolkits saved programmers quite a lot of work. They still had to design their document structures and handle events, but the toolkits allowed them to program the structures much faster than before, with a much more professional result.
Of course, with all these competing toolkits, a programmer had to decide which one to use, and once the choice was made there was no going back, since the toolkits were all mutually incompatible. A program written with toolkit X couldn't read data from toolkit Y. So the poor users weren't much better off, though several companies made a handsome profit selling data-conversion programs.
Industry, realising the advantages of exchanging data between programs, got together to try and decide on a toolkit that would allow more consistency between programs. Unfortunately, they did it twice, and emerged with two standards. Both did roughly the same work, but they were mutually incompatible. The rest was left to market forces. Some companies chose the one, some chose the other, and some put their irons in both fires, and supplied both toolkits with their computers and let the users decide.
Software manufacturers had also to make a choice, though some wrote their programs twice, once each for each toolkit, in order to be able to sell to the largest number of customers. Some bright software houses produced a toolkit that allowed you to write your program once and then link with either standard. Now you still had two executables, but at least only one set of sources.
And now at least there were only two standards, so that all programs using the same toolkit could at least exchange data - assuming of course that the programmer used the toolkit correctly: the toolkits had a lot of parameters, and huge manuals explaining their correct use which the programmer had to fully understand before programming, otherwise their data could only be read by their own programs, but not by other users of the same toolkits.
At nights, philosophers dreamed of a world without toolkits and events...
© Copyright Steven Pemberton, Amsterdam, 1994. All rights reserved.
First published in the SIGCHI Bulletin, April 1994