By Eric Armstrong, 22 Jun 2000
I finally got a chance to review the NLS video. The video's subtitle describes it as a "System for Augmenting Human Intellect", and it clearly lived up to its name.
Note:
No where on the video was "NLS" defined. It stands for [TBD...]
It was astonishing to see a young Doug Englebart, seated at a console, in December of 1968 -- 1968, mind you -- displaying:
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. [TBD: The use of the mouse buttons was not explained. One of gaps in the video (while they changed cartridges) occured 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 intrisically 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:
The basics entities in the systems 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.
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
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.
The ability to control the view of material was displaying included:
Note:
Many outliners in the 80's supported this operation. StreamLine did, as well. But I found it to be something that sounds better than actually works. In practice, if a subtree is large enough, you hardly ever see things below it anyway and, when you do, they are outdented so far that the "end" of the subtree is clearly discernible. If the subtree is small, in contrast, you generally benefit more from seeing the context it resides in than you gain from "focusing in on it".
The system actually supported printing, which is pretty remarkable when you consider the kinds of graphics it was capable of (coming up next).
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:
(Old timers will understand that. More modern types can visualize as a diagram of a class hierarchy.)
The last one was particulary 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.)
[TBD: 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.]
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.
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 timesharing 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, oscilliscopes. Those were the output devices, and they were physically co-located with the server. (In other words, they were in the same room!) In front of the oscilliscopes were cameras, which fed off to monitors in the user's office. So the keyboard was wired to the computer, which generated output on an oscilliscope, which was delivered back to the user via television camera! Amazing.
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 person B. From then on, they are both looking at the screen Person A has in front of him, each on their own montitors.
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 montiors 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! [TBD: 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.]
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. [TBD: What's a plex?]
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 they grew up with the system, adding 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.)