Creation of Hierarchic Text with a Computer Display

A Dissertation Submitted to the Department of Computer Science and the Committee of Graduate Studies of Stanford Unviersity for the Degree of Doctor of Philosophy
 

Abstract

Paper and pencil, the traditional tools for creation of computer programs, assist the programmer very little. Proper punctuation demands precision, review of existing text requires clumsy paper shuffling, text modification is difficult an dmessy. In conjunction with a file storage device and a graphic display unit, a computer can provide a more flexible medium, but early systems still treated text as an unstructured string of characters. Emily, the system described in this paper, avoids these problems because text is created, viewed, and modified in terms of the structure imposed by the syntax of the programming language.

To describe languages for the Emily system, a syntactic formalism was developed. Based on Backus-Naur For, this formalism can describe identifier block structure, indentation, and conditional  display of text. The user creates text by selecting among choices displayed by the system under guidance of a language description in this formalism.

The interface between man and system was designed in accordance with a set of user engineering principles. Thirteen principles are discussed under the headings of 'minimize memorization', 'optimize operations', and 'engineer for errors'.

Results of a rudimentary comparison with a system for unstructured strings shows that the user took slightly longer with Emily, but made fewer mistakes.

---

A route of evanesence
With a revolving wheel;
A resonance of emerald,
A rush of cochineal;

And every blossom on the bush
Adjusts its tumbled head, -
The mail from Tunis, probably,
An easy morning's ride.

Emily Dickinson

After that beginning, the first chapter pretentiously described hierarchies and how wonderful they are for organizing information. (In fact, this later became a theme of the Data Structures textbook I wrote with Ed Reingold.)

The second chapter then showed how hierarchic text can be constructed in a sequence of steps where each step selects a rule from the syntax and expands a token in the growing text by copying the right side of the selected rule. For instance, a screen might look like this:

The three top lines are the growing text with tokens inside angle brackets. The last line shows what is being worked on. The lines between are the possible replacements for the token in the box. Figure 2.3 of the paper presented more steps:

The "personal computer" in question was a fifteen million dollar beast having two mainframes, a "huge" eight megabyte external core memory, and an IBM 2250 graphic display terminal. Fortunately, few applications used the external core so I was able to run for considerable periods. A run consisted of submitting a batch job and then waiting around until it rose to the top of the queue.

As a practical matter, Emily was never used in earnest for programming. The only occasion when it was used for other than a demonstration was when I used a trivial outline grammar to create an outline for the dissertation. It really helped. Before that I had been unable to get my head around the dissertation and after that I just went right ahead and wrote it over the course of a few weeks. The rule was that I only had to write from ten AM to noon, but I had to write during that time.

My use of outlining was a precursor to today's outlining tools. As with today's tools, the great advantage of Emily was in being able to shrink the contents of a node into a single token. I called in a "holophrast," a word which at one time was a little used.

The fourth chapter was the most lasting contribution and has been cited and reprinted a number of times. In it I listed fourteen "user engineering principles." (Today they would be called principles of Human-Computer Interaction.) As shown in the paper's Figure 4.1, they were:

User Engineering Principles

First principle: Know the user

Minimize Memorization

Selection not entry
Names not numbers
Predictable behavior
Access to system information

Optimize Operations

Rapid exution of common operations
Display inertia
Muscle memory
Reorganize command parameters

Engineer for Errors

Good error messages
Engineer out the common errors
Reversible actions
Redundancy
Data structure integrity

My dissertation defense did not go well. I stayed up too long the night before trying to get the system in a state where I could demonstrate it on a system other than the one I developed it on. (Using too much memory was one of the problems.) The committee was unhappy that there was no evaluation of the methodology. Thus was born chapter 6.

In the sixth chapter I compared using Emily to construct a program with using a typical text editor. Emily was a bit slower. And writing the example out by hand takes only half the time of either. Nonetheless, I still prefer typing to handwriting. And I miss Emily's contraction of segments to holophrasts.

I did not at the time have any idea that personal computers would exist. What I did say was:

As the system changes and technology improves, it will become possible to locate consoles in the user's home as well as his office. {Women's lib had apparently not made much of an impression on me back then.} The Emily system is based on the assumption that it is the user's primary means of access to his data. This assumption can only be justified if the user can access his dataq whenever he wants. For the author, at least, this means nights and weekends as well as during 'office hours.' A serious limitation to home consoles is that a large amount of data must be displayed very rapidly. Current telephone lines can handle only a few hundred characters per seconds while instataneous display modification requires at least tens of thousands. This capabaility may soon {!} become available with switchable cable television networks and the telephone circuits for Picturephone® transmission.