In 1968, Douglas Engelbart gave “the mother of all demos”, demonstrating an early version of time sharing, distributed computing, graphic terminals, a mouse, hyperlinks. and many other features we take for granted. ( Segments from the original video can be seen here.) The video’s subtitle describes it as a “System for Augmenting Human Intellect”, and it clearly lived up to its name.
Originally published 2000
Note:
Nowhere on the video was “NLS” defined!
Contents
Overview
Reviewing the video, it was astonishing to see a young Doug Engelbart, seated at a console, in December of 1968 — 1968, mind you — displaying:
- Outlining capabilities that would not appear in commercial applications until the mid-80’s.
- Linking capabilities that would not become part of “business as usual” until the early 90’s.
- Inline video capabilities that would not be in common use until the late 90’s.
- Linking of graphics to text that is not part of any standard applications even today, as we approach 2001.
- Parameterized links that included view-control information, which also do not exist today.
- Cut/copy/paste functionality that would not be standard until the late 80’s
Note:
There was also a very young Jeff Rulifson. Hee hee hee…
In addition to a monitor, Doug’s workstation consisted of a keyboard and two additional devices, one on either side. On the right was a three-button mouse. On the left was a “chord set”. The chord set looked something like 5 white keys from a piano. Each combination of chord set keys generated one character, for a total of 31 combinations. Since the system was driven largely by single-character commands, this device worked to accelerate most operations. [The use of the mouse buttons was not explained. One of gaps in the video (while they changed cartridges) occurred in the middle of the chord set explanation, so some of that usage notes for it were unavailable, as well.]
Note:
I particularly like the chord set device because, in the late 70’s, when I was doing a lot of system administration, I wanted a musical keyboard to invoke “fingertip macros”. I realized that a lot of the moves I made at the computer keyboard were similar to each other — only filenames changed, for example. The sequences were short enough that it didn’t make a lot of sense to write special macros. I figured a piano keyboard would give me the ability to rapidly generate common sequences of operations — and generate musical tones to boot. I figured the tones would help provide feedback to advertise mistakes and recognizable patterns that would be intrinsically appealing in themselves. Doug’s chord set, being 5-keys, could be set up to chime a pentatonic scale, so all combinations would sound good. (Joe’s idea of commercializing that product as a programmable USB device is a good one. Ideally, it would augment the keyboard and generate any sequence of characters that was programmed for individual keys.)
The remainder of this post outlines the features Doug demonstrated, under the headings of:
- Basics
- Outlining
- Linking
- View Controls
- Printing
- Graphics
- Searches and Scripting
- Display Hardware
- Collaboration and Video
- Command Syntax
Basics
The basic entities in the system were statements and words. It was clear that statements were addressable. Words did not appear to be addressable, but they could be “marked” and referenced that way later. (See the section that covers searches.) Cut, copy, and paste operations were supported.
Outlining
The system had the full complement of outlining instructions. Entries could be added to a list and their position changed. New headings could be added, and entries moved under those headings. Entries were numbered starting with 1. The next level of entries used uppercase alphabetics, after which numbers were used. The numbers were displayed without punctuation, which made for a nice compact number on each entry, like “3A2”. Presumably, additional levels used lowercase alphabetics, continuing to alternate with numbers.
Linking
The system supported references to numbered entries. But of course, as you changed the outline, items were renumbered. To solve that problem, the system let you define labels. You could then reference the labels. An important addition to links as we know them today was the ability to specify the view that should be used to display the targeted material. (The next section covers views.) This is important in a view-controllable system, but not part of any system in common use today.
View Controls
The ability to control the view of material was displaying included:
- Number of outline levels displayed
- All text in entries, or only the first line
- “Zoom In” so that an entry and its subtree become, in effect, “the whole document” until you zoom back out.
Note:
Many outliners in the 80’s supported this operation. StreamLine did, as well. But I found it to be something that sounds better in theory than it actually works in practice. If the subtree is small, you generally benefit more from seeing the context it resides in than you gain from “focusing in on it”. And if it’s large, focusing in on it makes little
difference, since it already dominates the window you’re viewing it in. - Whether or not numbering was displayed
- The numbering used (I think. It was clearly possible for printing.)
- Whether or not labels were displayed.
- Whether or not word-marks were displayed.
Printing
The system actually supported printing, which is pretty remarkable when you consider the kinds of graphics it was capable of (coming up next).
Graphics
This is the one that we do not see in any product, even today. The system let you create line drawings. Click one point, then click the next, and a line would appear. You could type in labels anywhere. And those labels could be linked to other material. Several examples of line drawings were shown, including:
- A map of a shopping route. Each destination linked to the items to get at that stop.
- A tree depicting the program’s overlay structure
(Old timers will understand that. More modern types can visualize as a diagram of a class hierarchy.) - A conceptual map, showing related concepts
The last one was particularly interesting. Somehow (probably by making use of the ability to specify the view as part of a link), different sections of the concept map appeared dynamically, one after the other. So you started with a small piece, then built up the picture step by step, much as you would do today in a PowerPoint presentation.
Note:
These diagramming capabilities would obviously be useful for depicting cognitive maps.)
[It was not entirely clear whether hierarchies and maps were two separate kinds of display, or whether they could both co-exist in a single display.]
Searches and Scripting
The system managed to provide real search capabilities. It provided for full text search, as well keyword searches. Keywords could be added to any entity, thereby placing those entities in various categories. Those categories could then be searched. The search mechanism was somewhat cumbersome, by today’s standards. To initiate a search, you first had to compile a pattern. (Today, we take regular expression searching for granted. The fact that somewhere in there some engine is interpreting that pattern — or possibly compiling it) goes completely unnoticed.
The ability to mark a word for later reference was demonstrated as part of the search capability. Instead of typing in the word, you could reference it and use it as the pattern for your search. Since the whole system consisted of combinations of one-letter commands, the ability to create a “word” that was in reality a series of commands, mark it, and reuse it, created a clever scripting mechanism.
Display Hardware
Having described many of the pretty incredible capabilities that were developed in this system. Let’s pause to take a look at the display hardware. (If I had described it earlier, you wouldn’t have believed such capabilities were possible. In fact, you might have stopped reading at that point. So I saved it until we got here.)
We’ve already looked at the Control Console (keyboard, etc.). What’s left is the display system. At the time of the demo, the time-sharing server was running 6 consoles. But the way it was running them was a tribute to human ingenuity, if nothing else.
The server had, as output devices, real CRTs — cathode ray tubes. Basically, oscilloscopes. Those were the output devices, and they were in the same room with the server! In front of the oscilloscopes were cameras, with cables that ran down the hall to monitors in the user’s office. So the keyboard was wired to the computer, which generated output on an oscilloscope, which was delivered back to the user via television camera! Amazing.
Collaboration and Video
Since the system was running on a single server, they added commands that would let two monitors share a single view. That allowed person A to call person B, and give his view to person B. From then on, they are both looking at the screen Person A has in front of him, each on their own monitors.
Each person had their own cursor on the display. (Called a “bug” in 1968.) But the original user’s cursor was more powerful, and would dominate the proceedings until and unless control was turned over to person B.
As a fascinating addition, the system made use of the fact that the montitors were in reality television viewing monitors. So they added video cameras to each workstation, and could inset a picture of the other person on the screen! [If that inset capability was a general feature, then it would clearly be possible to display a hierarchy and a map on the same screen.]
Command Syntax
For 1968, the command syntax was state of the art. It consisted of single letter commands that could be combined into “words”. So “D” meant delete something. A “W” following the D meant “delete word”. A “P” meant “delete plex” and so on. [It wasn’t explained what a “plex” was, but presumably it is some constellation of elements.]
Unfortunately, though, there weren’t enough mnemonic letters to go around. So “DE” deleted something and “DF” deleted something else — but it would be hard to remember which combination of letters did what.
Note:
In 1968, there weren’t many options. So the command syntax is understandable. But the abbreviated commands made programs look like a series of algebraic equations, only without the punctuation. This is the kind of system that it’s authors usually love, because it is so abbreviated and powerful. But their understanding grew with the system, little by little, as complexity was added complexity little by little. New users of such system find it confusing and difficult to remember — not to mention unreadable. So such systems rarely have a user base that goes much beyond the original authors, and those authors typically fail to understand why. (As an author of such systems myself, I have fallen victim to the same trap.)
Resources
- https://sloan.stanford.edu/mousesite/1968Demo.html
Video segments from the original NLS demonstration
- https://www.bootstrap.org/augment-71279.htm
Doug Engelbart: Toward Integrated, Evolutionary Office Automation Systems
Copyright © 2000-2017, TreeLight PenWorks
2 Comments