I've been building up a few of these entries in my head as I run across things, so this will be the first of a recurring series of "prior art": technologies and ideas we use today that had earlier, different paths and implementations. For this inagural entry we'll be looking at OWL Guide, an early hypertext system for the Macintosh, and contrasting it with HTML and the modern Web.
Of course, hypertext didn't start with the microcomputer; one of the earliest document-oriented forms (as opposed to card- or frame-oriented like HyperCard or KMS, as well as other concepts) was the 1967 Hypertext Editing System, running on a partition on an IBM System/360 Model 50, contemporary with the baroque but much celebrated oN-Line System which formed the basis for the 1968 Mother of All Demos. However, the microcomputer was where it started to gain steam, with early text-only implementations like the DOS-based 1983 PhotoQuery, which became TIES in 1984. TIES' key innovation was advancing the convention that the text itself contained the links embedded within it, rather than navigating using external numbered menus, codes, icons or other gadgets. (TIES later evolved into HyperTIES, which in 1988 introduced early implementations of imagemaps and style sheets using its own "HTML" [HyperTIES Markup Language] for screen design, also based on SGML. HyperTIES was credited as the first instance where hyperlinks are blue.)
This was a natural fit for GUIs, and hypertext/hypermedia flourished on the early Macintosh. Naturally everyone remembers HyperCard and its various clones, the archetype (but not the prototype) of card-based hypermedia, but one of the earliest hypertext systems on any desktop computer was OWL Guide for the Mac, dating to 1986.
OWL Guide started as the Guide hypertext system project in 1982 at the University of Kent in the UK, under Peter J. Brown. Brown described the project aim in
a 1987 UNC-ACS paper (PDF) as to "break away from the constraint of paper and rethink from scratch how best to display documents on screens. In particular it was desired to take advantage of the high bandwidth of communication between user and computer offered by a graphics workstation. As a result, the user should be able to interact closely with a document and tailor it to what he wanted to read." Not originally intended as an explicit implementation of hypertext, it nevertheless implemented it, as Brown felt "the needs of the application have led Guide into including increasingly, more hypertext features." The 1983 prototype ran on Three Rivers PERQ workstations under PNX, International Computers Limited (ICL)'s port of UNIX System III, and was
used as an online help system.
As part of the Kent Software Tools collection with release on request to the wider Common Base Community, Guide became well-known to other PERQ users and ICL in general. When ICL announced their Dalkeith facility in Scotland was moving to Kidsgrove in 1983, most of the staff chose to accept golden handshakes instead, and five of them formed Office Workstations Limited (OWL) in Edinburgh in 1984.
OWL's first project was to port Guide to other platforms, starting with the Mac, by shrinking it down and adapting it to the "house style" of the new system. This is the version we'll look at in a moment and the easiest version to obtain, though the later Microsoft Windows port arguably had greater contemporary traction (because HyperCard).
Back at the University, Guide was subsequently ported to SunOS 4 (both X11 and SunView), and later Solaris, HP-UX and IRIX, and was thus renamed UNIX Guide (PDF). UNIX Guide proceeded along its own separate evolution path to become KST Guide, but its source code was never publicly available — at some point it too became a paid product — and the editor-less Guide Reader binaries which were publicly released as part of the old UK HENSA archive don't seem to have been mirrored anywhere. Sadly, Dr Brown himself died of cancer in 2007, though his later Exeter contact information persists. (If you have these files or better yet know where their source code might be found, please post in the comments. Several local SunOS 4 and IRIX systems here at Floodgap can't wait to try it.)
At the time it was comparatively unusual to implement hypertext as a continuously scrolling document, and while Guide doesn't appear to be the first such implementation, it was probably the most advanced one of that type up to that point. This screenshot from a later version of UNIX Guide shows the three types of interactive elements (which it calls buttons) that Guide supported.
Not all of these have direct analogues with HTML5 (in fact, action buttons could even run shell scripts!) and some of their core conceits are rather different. Indeed, its most pervasive and interesting navigational mechanism is the concept of
replacement: embedding the content referred to by a link ("replace button") directly where it was referenced. This provided spatial context within a single master document. A menu-document hierarchy like Gopher, where only menus can contain other menus and documents are always linked to by a menu, can do this merely in a limited sense. Consider this gopher menu in the old OverbiteFF extension for Firefox (eventually I intend to implement this feature into
OverbiteWX or OverbiteNX):
Plus signs appear where the content of a menu item can be viewed inline, meaning you can click the plus sign and embed the text file, image, etc. that the terminal menu item points to, as below.
However, the concept in OverbiteFF is not recursive; there is no sub-embedding of other menus. Instead, Guide goes further with its hierarchical nature because it can embed fully functional fragments, not just terminal static content, and these can be made completely navigable:
If we click on
...More, we get ... more:
As an alternative example, the Mac OWL port of Guide was itself used for this mock-up of an on-line "future"
Wall Street Journal (the headlines were compiled from
earlier articles, although the stated DJIA is
approximately period-correct).
Here articles appear inline when selected (and notice that additional documents also appear in the revealed article, which themselves can be linked to). Notice that Guide had full image support which was used for the WSJ masthead logo.
Despite OWL being a separate concern, tight integration remained with Dr Brown's group, and the products tended to cross-pollinate. Brown notes that the idea with replacement was to make a single document with "no
gotos" and thus avoid linkages outside of a unified document, though practically this capability already existed as an edge case and became more explicitly visible in OWL Guide. Additionally, UNIX Guide at least initially had no Find command (Brown observed "there is a lot of wisdom in the statement 'You can only extract information from a database if you know that it is there'"), but this was first added in OWL Guide presumably due to the smaller screen real estate on desktop microcomputers, and eventually made its way back to UNIX Guide (though Brown rued puckishly that "[t]he Find command is, after all, a user-controlled
goto").
OWL Guide for the Mac neatly fits on a single floppy disk, so it runs nicely in Mini vMac. It is not available for sale from any MACINTOSH vendor but in the GARDEN of Mac retroenthusiast sites you can easily find it by searching for OWL Guide. This is the original version 1.0. It runs just dandy in System 6 but I'm using System 7.1 in these screenshots.
Although UNIX Guide had a text markup system not unlike
troff/
nroff, Mac OWL Guide documents use strictly binary markup and completely lack a resource fork. If we open up
Guide Buttons, OWL Guide shows its own three basic interactive elements. Action buttons were removed for reasons of complexity (and adapting them to the Mac environment, which in those days completely lacked any scripting facilities) and replaced with an HTML anchor-like element called a
reference button, but replacement and note buttons remained.
Replacement remains the core navigational method. These three replacement buttons — really, the entire document — are actually grouped into a unified composite control called an
inquiry where selecting any one of its component replacement buttons sets new text for the entire inquiry section. We can see the markup in icon form by selecting Display, Show Symbols (or Command-Y):
With symbols on we note large target icons surround the replacement buttons, with smaller "double targets" showing the extents of the inquiry section. (The mouse pointer turns into a target icon over replacement buttons to remind you.) Because the inquiry surrounds the whole document and there is nothing that says replacement buttons can't replace
everything, clicking on any of these links is effectively like navigating to a completely new page (so much for "no
gotos"), though a flashing outline blinks to let you know what changed:
If we select the first link to explore replacement buttons in more detail, which is part of another inquiry encompassing all but the title header, we then come to this menu.
Clicking on Example 1 replaces the text solely in that section, not being grouped with anything else.
If we Show Symbols, we no longer see any inquiries, but we do see sets of square icons (which can be nested, as shown here) indicating what we can "fold away." The mouse pointer turns into a square over these sections too. (These are internally called generic "buttons," but we'll talk about that a little later.)
The concept of "folding away" a block of replaced text demonstrates Guide's strong hierarchical orientation that we briefly explored before, but this time we'll take it a step further: not only can you always fold away text to navigate immediately back a single step (like a back button), but you can also fold away at higher levels of the "tree." Folding away the replacement text for Example 1 restores the original button, but "Click Here to fold the examples away" takes you entirely back to the beginning of the replacement button tutorial. What's more, if we then explore replacement buttons in more detail again but left the text for Example 1 replaced, it will still be replaced when we return, and can be folded away at that point too — i.e., the hypertext engine remembers the state of every control, and every control has independent state.
The other two types of interactive controls are a bit less exotic. What we would nowadays call a tooltip is a note button in Guide, and functions more or less the same way. You could of course use a replacement button for this purpose, but the note would probably be less disruptive visually.
Finally, the
reference button is just about semantically identical with the HTML anchor element, even to the point of allowing navigation to a fragment in a separate document (which Guide calls a
reference point).
If we click that reference, a new document appears at the designated spot, in a separate window.
A little back button in the scroll bar is also activated (the
backtrack icon), which has up to 32 levels of history (called the
Guideline). You can also enable this for replacements and notes, but these are less necessary since you can always fold away replacement text and notes don't seem to be nestable in any case.
What's not identical with the HTML anchor element, however, is that the text we've connected to is actually replacement text, as Show Symbols makes clear:
In other words, the link not only went to a particular part of the document, it went to a particular
state of that part of the document, and that state is live. As proof, we can fold that text away like any other replaced text anywhere else:
And here we are at the beginning of the new document. If we click the backtrack icon, we still go back to the previous document, no matter what the state of the new one is.
OWL Guide was capable of producing some sophisticated interfaces for the time. The Guide Commands file implements an animated mockup of the Mac menu bar which you can click on for help on any option:
The replacement animation shows that the newly revealed mock menu is actually a whole set of small bitmap graphics stitched together and the "menu items" are all individual controls (in this case reference buttons). Graphic elements can be placed at any coordinate in the document and can overlay other graphic elements.
And, having selected a menu option, here we are at the chosen article about it.
Still, even more noteworthy about Guide is that Professor Brown believed strongly in users creating as well as consuming. ("A fundamental principle of Guide is that the author is the reader and the reader is the author," he declared, emphasis his. "The reader (i.e. end-user) can therefore freely edit the document, thus acting as author, and the only way an author can see a document is to see it as the reader does.") How does one author with a system like this?
First off, markup is less sophisticated than you might think. Document text is in one global font and style (yes, even superscript and subscript are global) with separate fixed styles for the controls, though the nature of the Mac at that time made this less of a liability because bitmaps could stand in for arbitrary text with little functional difference. The control "style sheet" can be set from Display, Set Options.
But the controls give you a measure of TMTOWTDI, because you can define buttons "forward or backward" depending on how you conceive of your document flow. Let us construct a useful glossary of commonplace, completely ordinary Spanish phrases that you can employ at your next staff meeting, bar mitzvah or funeral. Because of Guide's replacement mechanic the glossary becomes a bidirectional translator, letting you go back and forth between English and Spanish at will.
The "backwards" method is to create a replacement button directly. The idea is to have in your document the
replacement content first, and then replace that (ow, my head hurts) with the
initial content the user will select to reveal it. Let's use the second phrase as an example. We have highlighted it in the editor and will now make it into a Replacement Button under the Make menu.
It then becomes a field we can type into.
We then replace it with the initial, prompt text.
I understand it is somewhat more compelling a statement in the original Hungarian.
Our first phrase, however, has at least two totally valid translations, as any speaker of Spanish is well aware. Replacement buttons do not allow other controls to nest within them, so we'll need a composite control; since we have multiple valid choices to become the final translation, the logical control to use here is an inquiry.
This didn't appear to do anything, but if we turn on Show Symbols, we see the text has been surrounded by the double target icons.
We will now enter our two completely accurate and valid translations and turn them into replacement buttons of their own.
A problem now presents itself: we don't have any way of getting back the Spanish text (inquiries are not intrinsically navigable, only their components), so we need a third control. Here we will use a generic button control (which is still a replacement element) with the Spanish text as the replacement text.
Now we can choose either of the alternate translations (which being part of an inquiry will replace the entire text), and navigate back and forth.
Alternatively, we could construct it "forwards" using the generic button control as a wrapper for the inquiry instead. Unlike specialized replacement buttons, general buttons are also containers like inquiries, but unlike inquiries, general buttons are navigable.
Now we turn the translations into an inquiry. The text "Fold away these options" stays outside of the inquiry and becomes what connects back to the Spanish text.
Finally, the replacement buttons.
And now we can navigate either back to choosing a different English translation, or directly into the Spanish version. This is arguably more "Guide-like" though our use of different control wrappers may require us to modify styles a bit for visual consistency.
Notes are much simpler. A secondary, hidden document contains the definitions, in any order (Display, Show Definitions).
We enter the tooltip definition text, highlight it, and make it into a definition.
Back in the main document, we then select the text we want to link to that definition, and make it into a note.
Ta-daa:
References, however, are clunky to create and have a big design flaw we'll uncover in a second. Let's say that we wanted to distribute this useful translation page to a wider audience who might not be familiar with Guide, and so we'd like to add a link inside the document to automatically start Guide's Help.
In the main document, I typed in the content (the phrase
Help with Guide...) that will become the reference button/anchor. In a second window I opened up the Guide Help document, highlighted the hero image and made it into a
reference point. If I had turned on Show Symbols, you would see little "return arrows" with the kinked tail around it.
This is how we can link to a particular state, by the way: in the destination document, we navigate until the desired element is visible, and then make that a reference point. The state of the document is then encoded in the reference point so that element becomes automagically available (along with any others at the time), even if those elements don't display by default.
Going back to our main document, we now make Help with Guide... into a reference,
and with the reference point still highlighted, go to Make, Start Link, and then Link to Reference Point.
(Alternatively, you can just Link To Reference Point directly, since we've already selected where; the menu changes to make that possible.)
Unfortunately, the act of creating a reference point changes the destination document. That means we need to include our own modified copy of Guide Help if there wasn't already a reference point at the document element we wanted.
If we don't do this, and try to use the document as it was, the link is lost because the reference point it's indicating doesn't exist:
Presumably this was less of an issue at the time since you'd only be linking between your own documents, and there was no absolute location for a standard set of documents to link to anyway, but I still found it to be a curious design limitation.
That said, although I'm trying not to be too hard on a version 1.0 of a very innovative tool, that wasn't actually the most annoying thing about creating documents with it and editing in particular leaves a lot to be desired. Among other petty annoyances the arrow keys don't work and it's hard to select text that's part of a wrapped control without triggering it (Edit, Freeze toggles this behaviour, but it's not immediately obvious to a new user what this option does). The worst part, however, is that you can't edit controls once they're finalized and there is only one level of undo. While experimenting with Guide I had to keep a couple different versions of the document around or I ended up doing a lot of rekeying to get back to a previous state. Yes, you could probably edit the text directly in the file itself with a hex editor but I doubt the late Professor Brown would have found this to be an acceptable workaround.
Like UNIX Guide, OWL Guide had its own (presumably distributable) reader application. Conveniently, the Mac version's was a desk accessory called MiniGuide, included as an installable suitcase. System 7.1 naturally runs it directly. It supports all of the features of standard Mac Guide except of course for editing and showing the internal structure of documents, and at only 49K easily fits with anything.
In 1987
OWL introduced Guide 2.0, which directly competed with Apple's HyperCard (a very different motif) and debuted a Microsoft Windows 2.0 port, shown here.
Mac OWL Guide 2.0 expanded at the same time to support colour on the new Macintosh II series, shown in this 1989 screenshot of a medical education application at Cornell University (InfoWorld July 31, 1989). Cornell used Guide instead of HyperCard because, according to pathologist and lead developer Dr. Steven Erde, it supported colour (HyperCard didn't), could work over a LAN (the clients connected to a 485MB file server and each workstation had its own videodisc player) and individual HyperCard cards weren't large enough for the 19" displays and were limited to 32K. A tool called G-Convert could interchange between the two platforms.
OWL had a 1985 subsidiary in the United States, OWL International, Inc., which later became independent after an internal management buyout. As for the original parent company, OWL itself was purchased in 1989 by Matsushita (owners of the Panasonic brand and at the time part-owners of
Solbourne Computer) to become the new Panasonic Office Workstations Ltd division, and the now separate American subsidiary continued development of "just plain Guide" independently. While the Mac version eventually stalled out when Apple started bundling the better-known HyperCard with Macs for free, OWL International continued on PCs with Guide 3.0 in 1990 and support for the new Windows 3.0, shown here. Guide 3.0 introduced a new SGML-based format called HML, or Hypertext Markup Language, jettisoning the earlier binary format.
This development all occurred separately of UNIX Guide, which continued on its own separate development and version timeline but doesn't seem to have made a release past version 5.1.x in 1995.
OWL International subsequently renamed itself to InfoAccess, but although InfoAccess first introduced an HTML-native product called HTML Transit also in 1995, they continued to sell and develop Guide until 1999 when the company was bought by IntraNet Solutions and the old product line was discontinued. This is a 1998 screenshot of what was probably the last version of Guide (Reader), on Windows 95. By then Guide documents were more like "regular" web pages than the bidirectional nature of the original Guide and could even have links to Internet resources.
IntraNet Solutions
changed its name to Stellent in 2001 and was bought out by Oracle in 2006; Panasonic OWL, for its part, was absorbed into its parent corporation and shut down in 2005.
As innovative as Guide was, OWL itself wasn't very forward-thinking, though of course hindsight is always 20-20. In a famous 2011 TED talk by OWL founder Ian Ritchie, while demonstrating Guide 3 at a trade show in 1990 he first met Tim Berners-Lee, then a relatively obscure researcher at CERN, who was developing a new networkable hypertext system.
Berners-Lee asked Ritchie about developing the client for it, since, in Ritchie's words, "his system didn't have any graphics or fonts or layout or anything; it was just plain text" and Guide already had all of this and was a shipping product. Ritchie didn't see much potential in it (certainly not any commercial one, given CERN) and thought the concept was "pretentious" since the entireity of the network then consisted of just a single machine. He politely declined and Berners-Lee continued on with his own bespoke client on his office NeXT workstation. In fairness to Ritchie, no one else saw any potential in it either until 1993 when Marc Andreessen demonstrated Mosaic, and the rest is history.
Nevertheless, even if the document model it popularized later came to the Web more through convergent evolution than direct descent, OWL Guide's position as one of the first, if not the earliest, commercial hypertext products means it certainly qualifies as prior art (as does UNIX Guide before it). Indeed, some of its more outstanding features have never been natively duplicated in HTML, and the bidirectional stateful navigation it naturally implements by virtue of its design is all but unique in hypertext systems. It would have possibly been a very different World Wide Web if we were all using Guide-descended clients today, and one wonders what features we've been missing out on since in these JavaScript-choked runtimes that today we call web browsers.
0 Comments