Personal Distributed Computing: The Alto and Ethernet Software

5.2.Input

User input comes from the keyboard, the mouse buttons, or the cursor position, which is controlled by the mouse. The crucial notion is clicking at an object on the screen, by putting the cursor near it and pushing a button. There are three mouse buttons, so three kinds of click are possible; sometimes multiple clicks within a short interval have differ­ent meanings; sometimes the meaning of a click is modified by shift keys on the keyboard; sometimes moving the mouse with a button held down has a different meaning. An interface for novices will draw sparingly from this variety of mouse inputs, but one designed for ex­perts may use all the variations.

If the screen object clicked is a menu button, this gives a command that makes something happen; otherwise the object is selected, in other words, designated as an operand for a command, or some point near the object is designated, such as an insertion point for text. The selec­tion is made visible by underlining or reversing black and white; the insertion point is made visible as a blinking caret, I-beam, or whatever.

Many interfaces also have scroll bars, thin rectangles along one side of a window; clicking here scrolls the document being viewed in the window so that another part of it can be viewed. Often a portion of the scroll bar is highlighted, to indicate the position and size of the region being viewed relative to the whole document. A thumbing op­tion scrolls the view so that the highlight is where the mouse is; thus thumbing a quarter of the way down the bar scrolls a quarter of the way into the document.

Frequently commands are given by keystrokes as well as, or in­stead of, menu clicking. Nearly always the commands work on the current selection, so the selection can be changed any number of times before a command is given without any effect on the state. An expert interface often has mouse actions that simultaneously make a selection and invoke a command, for instance to open an icon into a window by double-clicking on it, or to delete an object by selecting with a shift key depressed.

Figure 1: A Smalltalk screen. Note the overlapping windows and the browser at the top.

Figure 2: A Bravo screen. Note the formatted document. (not a screen shot, but a faithful representation rendered at high resolution)

Figure 3: A Cedar screen. Note the two-column tiling, the icons, and the whiteboard.

Figure 4: Typical Markup pictures. The popup menu is at the upper right.

Most Alto system interfaces are modeless, or nearly so: Any key­stroke or mouse click has the same general meaning in any state, rather than radically different meanings in different states. For example, an editor is modeless if typing the ‘A’ key always inserts an ‘A’ at the current insertion point; an editor is not modeless if typing ‘A’ some­times does this, and sometimes appends a file. A modeless interface usually has postfix commands, in which the operands are specified by selections or by filling in blanks in a form before each command is given.

Many of the user input ideas described here were first tried in the Gypsy editor (see section 6); others originated in Smalltalk, yet others in the Markup or Sil drawing programs (also de­scribed in the Applications section). One of the main lessons learned from these and other experiments is the importance of subtle factors in the handling of user input. Apparently minor variations can make a system much easier or much more difficult to use. In Bravo and Ce­dar this observation led to schemes that allowed the expert to rear­range the interpretation of user input, attaching different meanings to the possible mouse actions and keystrokes, and redesigning the menus. This decoupling of input handling from the actions of an appli­cation has also been successful in EMACS [46].

5.3.Views

More subtle than windows, menus, and double-click selections, but more significant, is the variety of methods in the Alto system for pre­senting on the screen a meaningful view of an abstract structure, whether it is a formatted document, a logic drawing, the tree structure of classes in Smalltalk, a hierarchical file system, or the records in a database. Such a view represents visually the structure and content of the data, or at least an important aspect of it. Equally important, it allows the user to designate part of the data and change it by pointing at the view and giving commands. And these commands have immedi­ate visual feedback, allowing the user to verify that the command had the intended effect and reinforcing a sense of direct contact with the data stored in the machine.

There are many ways to get this effect; all the methods that have been developed over the centuries for presenting information visually can be applied, along with others that depend on the interactiveness of the computer. A few examples must suffice here.

Perhaps the most familiar is the “what you see is what you get” editor. The formatted document appears on the screen, complete with fonts, subscripts, correct line breaks, and paragraph leading; page lay­out should appear as well, but this was too hard for the Alto. The formatted text can be selected, and the format as well as the content changed by commands that show their effect immediately. Figure 2 is an example from Bravo.

The Smalltalk browser shown in Figure 1 is a visual representation of part of the tree of Smalltalk classes and procedures. The panels show successive levels of the tree from left to right; the highlighted node is the parent of all the nodes in the panel immediately to its right. Under­neath the panels is the text content of the last highlighted node, which is a leaf of the tree. Again, subtrees can be selected and manipulated, and the effect is displayed at once.

The list of message headers in Figure 3 is another example. Each line shows essential properties of a message, but it also stands for the mes­sage; it can be selected, and the message can be deleted, moved or copied to another file, read, or answered. The same methods are used in Gypsy and Star to represent a hierarchical file system, using the visual metaphor of files in a folder and folders in a file drawer. The icons on the screen in Star, Cedar, and more recent systems like the Apple Macintosh repeat the theme again.

The idea of views was first used in Sketchpad, which provides a graphical representation of an underlying structure of constraints [48], but it was obscured by the fact that Sketchpad was intended as a draw­ing system. In the Alto system it appeared first in Gypsy and Bravo (for formatted text and files), then in the Smalltalk browser, and later in nearly every user interface. It is still a challenge, however, to devise a good visual representation for an abstraction, and to make the point­ing and editing operations natural and fast.