The large interactive system user interface issues discussed in this paper reflect experience at Stanford Research Institute (SRI) over the past twelve years in the evolution of the user interface to the NLS system. NLS is a prototype collection of tools in a growing workshop of tools and services to aid knowledge work [1][4]. NLS provides facilities to support activities such as document creation, study and publication, message handling, information filing and retrieval, and software engineering. We expect the number of tools and the vocabulary that controls the use of these workshops to grow. We further expect that the use of such workshops will spread throughout those occupations involved with information in various forms and that there will be infrequent and casual users of such systems, along with many people who will spend large fractions of their day using such workshops. One goal is to match the speed of system responsiveness to the natural speed and flow of man's thought processes. It is from these basic expectations that our user interface work has developed.1a1

The sections below enumerate several assumptions and areas of concern around which the NLS user interface has developed to date. A key point to mention is that we do not consider the NLS user interface a static, finished product. It will change, based on analysis of usage experience, and the technology and media available.1a2

The user interface has two sides: the input side by which the user inputs information, indicating by various conventions and controls what he wishes accomplished; and the output side by which the machine provides feedback and other assistance to the user in command specification, and provides various forms of information portrayal. Man has many motor and other capabilities that could be the basis for input and command specifications; similarly he has his full range of senses that could be targets for system output.1a3

To date, computer information systems make use of only a few motor and sensory capabilities in their man-machine dialog. An important area of research involves exploring the advantages to be gained and the techniques to be used to extend this range. There is interesting research going on in areas of speech, eye movement, brain wave control, hand written script, and video graphics that will undoubtedly be integrated into the truly multimedia systems to be built in the near future.1a4

We call the user's collection of input-output equipment, and arrangement of work tables and work space, the workstation. At the present time, input to interactive systems centers around various types of keyboard devices: standard typewriter-type, function button, keyset (chord), and graphical pointing devices (mouse, electronic pen-tablet, light pen, joystick). The dominant output means are teleprinters and displays of varying capabilities.1a5

The present NLS user interface has been developed around this equipment, although many of the principles used in its design can be easily extended for use with other media [3]. The prime motivation for the use of the mouse for pointing and two keyboards (standard typewriter-like and keyset) as the input devices for the display version of NLS (DNLS), are described in references [2][3]. NLS can also be used from typewriter terminals (TNLS). In this paper, we concentrate on describing some of the motivations behind the design of the NLS command language and the forms of information portrayed to assist the user in command specifications. Forms of general NLS information portrayal are described in reference [1].1a6

First we describe a few high-level assumptions about the system usage environment that affect the user interface design and then discuss some of the lower level issues and the specific techniques used to deal with them.1b1

Coordinated Set of User Interface Principles1b2

Grades Of User Proficiency1b3

Ease of Communication Between Subsets and Addition of Workshop Domains1b4

User Programming Capability Or User Interface Extensibility1b5

Range of Workstations and Symbol Representations1b6

Distributed Nature of The User Interface Processes1b7

Tools Embedded in a Computer Network1b8

Problem Orientation of the Command Language and Tolerance for Ambiguity1b9

Given the above general considerations as background, we can move on to examine features of the NLS user interface in more detail.1b10

A command language must allow unambiguous specification of what the user wishes accomplished. The operation to be performed, and the entities or information items (arguments) to be acted upon, or used to determine what is to be acted upon, must be specified. These can be specified in a variety of ways: by typing them in in full or in some form of abbreviation, by pointing at them on a screen, by pronominal reference, by implication from context, or by use of default values automatically assumed by the system where appropriate. The order of their specification, the syntax or grammar of the language, can have various forms. For example, operational command-words can be specified, followed by the arguments, or vice versa. Arguments can be in fixed positions or explicitly named and occur in any order. Some arguments or command-words can be optional and require special characters to indicate their presence. Arguments or command-words can have defaulted values under certain conditions. Pronominal references can be allowed to refer to previous occurrences. Arguments may be given types by the system and language designer for more extensive error checking and feedback.1c1

Arguments and keywords can be specified by complete or partial typein (there are a variety of forms of command recognition that are discussed later) or designated by pointing to representations on a display or by use of specially coded function keys. Or, the machine may ask questions and the user just fill in the blanks.1c2

Depending on the characteristics of the computer and communications system, it may or may not be possible to provide command word or keyword completion, prompting or other feedback, argument checking, default value fill in, and so forth, during the command specifications.1c3

For example, in line-at-a-time, half-duplex systems, the user usually must complete the entire specification of the command before transmission to the system, while in character-at-a-time, full-duplex systems, the system can react to each character received and provide more extensive aids to the user during command specification.1c4

The above discussion outlines just a few of the many choices available to the language designer. As the purpose of this paper is not to be a complete tutorial on all possible choices available and their advantages and disadvantages, the following discussion gives only the main NLS command language features and the motivation for their adoption.1c5

The NLS command language generally has the following form, where angle brackets group meta symbols:1d1

As much as possible NLS makes the operational specification of the form verb-noun followed by arguments and possibly other keywords. We have also tried to maximize the fullness of the verb-noun matrix.1d2

Four forms of command keyword recognition are provided to enable the user to choose the one most appropriate to his terminal type, system response, previous system experience, and present NLS experience level. We have worked to pick an operational vocabulary for the present system that guarantees keywords to be unique in a maximum of three characters:1d3

A single-character mode allowing high-speed single-character recognition of the most commonly used command keywords; less commonly used command keywords require an escape character followed by enough characters for unique recognition: With large and expanding command sets one cannot choose keywords with mnemonic value and guarantee uniqueness in the first character. This mode is generally preferred by experienced users because of the conciseness and speed with which frequently used operations can be expressed. We find that experienced users are very concerned that commands be formed with the minimum number of input operations, and that commands have the richness needed to specify adjective or adverb type operations as needed. There is thus some conflict in certain commands between these goals for the experienced user and the need for command simplicity for the novice. 1d3a

A demand mode requiring a special character to initiate recognition: This has proved to be popular for new users of typewriter terminals, particularly those with experience using the TENEX operating system, under which NLS currently runs [13].1d3b

An anticipatory mode requiring the user to type just enough characters for the command to be uniquely specified; the system then automatically fills in the remainder of the command word. 1d3c

A fixed mode that guarantees recognition on entry of three characters.1d3d

Operand argument specification is contained in a number of fields that are variable with the type of command. All commands of a similar type have the order of the operands as consistent and as natural (relative to normal English usage) as possible. Infrequently used operand fields are optional and novice users need not be aware of their existence.1d4

There are three flavors of command completion.1d5

Command Accept:
Completion of the command indicating execute the command and return to the base state to await input of the next command. The default indication for this form is one of the buttons on the mouse in DNLS, which is translated into a control character. Command completion is defaulted to be CR in TNLS. The use of CR in TNLS is quite natural and generally does not conflict with textual input as most text in NLS is typed in without explicit CRs and is appropriately formatted by the system for various output devices. If the TNLS user wishes to input an explicit CR in his text file, he must precede it with an escape character. If he has need to enter many CRs in his text string, he can redefine the completion character, Command Accept, to be some other character.1d5a

Repeat:
Completion of the command and return to an appropriate intermediate command state for quick repetition of the command. Repetition mode continues until explicitly commanded to escape out of it. This mode is very useful when a delete or other operation is repeated several times.1d5b

Insert:
Completion of the command and entry to insert-statement mode for addition of new paragraphs or other text statements. This mode is like command repeat above except that it always takes you to the insert command. It is used frequently when one adds, replaces, or moves text, and then wants to follow it with new statements. It speeds text input when inserting sequences of paragraphs.1d5c

The system is to be used from a variety of terminal types, including both typewriter-type terminals and displays. The two-dimensional displays are to be the preferred workstation types whenever a design decision must be made between language forms possibly favoring one type or the other. 1d6

The system has been organized into clearly defined subsystems with uniform rules for their entry and exit. Any subsystem can be entered from any other, either to "execute" a single command with automatic return or to perform a chain of commands. The user can return either to a specifically named subsystem in the path of subsystems traversed, or enter a new subsystem. The issue of how to group commands into subsystems has to do with training and patterns of use rather than system constraints. It relates to learnability and, to some extent ease of command specification using single characters as switching subsystems switches vocabularies, and to "knowing where you are" in a command or operational space.1d7

Provision has been made for options that the user can control as he wishes for the amount of prompting, feedback, recognition mode, and for setting other user interface parameters whenever it seemed a standard interface might not be appropriate to some significant class of users.1d8

All operations that have a natural inverse command have been given one (although NLS still does not have an "undo" facility [14]). A general undo/redo facility has a number of technical difficulties and its value might be questioned. However, the ability to undo or redo the last one, two, or three commands would clearly be useful.1d9

As indicated earlier the ability of the user to extend the system himself is important. There is a tradeoff between ease of extension specification and operational efficiency. In providing such a facility one does not have to be deeply concerned with efficiency if the task handled by the extension is performed infrequently. If the operation is performed frequently, then it should probably be inserted as a system feature and implemented efficiently by professionals. This area is ripe for much additional development. The extensions must be specified in some language to indicate what sequence of events is to take place, what arguments to collect, and so forth, when a given user action is performed.1d10

The user interface must implement a man/machine dialog. In this section, we discuss issues from machine to man. The discussion centers around the use of displays, with comments on how the problems are dealt with for typewriters. Let us examine some of the types of information that the user needs in order to keep his bearings.1e1

There are three main areas or dimensions along which the user needs information to help him a) to know where he has been, b) to know where he is, and c) to know where he can go from here. Clearly the command language and user interface must offer provisions to move in these spaces as well as obtain status.1e2

Information Space
The user needs to know where he is in his information space, and what view or portrayal of the many possible is being displayed to him. Generally he arrived at his present position from previous points and he may want to be able to return to previous points or views as well as to move on.1e2a

Subsystem or Tool Space
In workshops containing many tools and commands, the user needs to know which tool or tools are active, which ones he was in previously and their order, and which ones he can enter from here.1e2b

Command Syntax Space
During the specifications of a command, the user may need to know what he can or is expected to do next and how to back up to a previous point.1e2c

The NLS display screen is organized into windows, as described in some detail in [9]. These windows are arbitrary rectangles. Windows can be displayed essentially all the time or overlaid with others. Windows can grow dynamically. Some windows are allocated and displayed or not displayed under system control for status and feedback information. Others can be created and manipulated by the user for display of his information space. Items selected from the screen by pointing at them with the mouse are indicated with an appropriate feedback mark. With typewriter terminals, one does not have this two-dimensional random display capability. While the same information can be given to the user, less can be given automatically, or at least the information must be given in an altered form.1e3

Information Space1e3a

The present NLS information space is hierarchically organized. A user has a directory or directories within which there are files. A file can contain notes on many subjects stored under various headings, his mail, or single documents. Files in turn are hierarchically organized as a tree of information nodes containing text, graphics, or both.1e3a1

Files can contain cross citations to specific points within other files or the same file, thus creating networks. NLS has appropriate commands for moving within and between files and for obtaining a display of the path over which one has traveled, and commands for backtracking along this path [1].1e3a2

Display screens have a limited number of lines within which to display information, and typewriters, even at 30 chars/sec or higher, cannot quickly and easily print out large documents. Also, the user often wants to see a summary or overview of a document or have it formatted in special ways to aid his understanding. To meet this need for easy control of information portrayal, NLS has a concept called "view specification." The user can change his "view" within the commands for moving in information space or by separate command. So that he can be reminded of his current view, the most commonly used view parameters are fed back to him in a small window in the upper ringight hand corner of the screen. When he is at a point in a command where it is permissible to change views, this fact is fed back both by prompt (if prompts are turned on) and by enlarging the characters in the view-feedback window. For more discussion on moving, viewing, and portrayal in NLS see [1][4].1e3a3

Subsystem or Tool Space

NLS is viewed as a collection of tools (subsystems) that can be used cooperatively. Each subsystem contains a number of logically related commands and has a name, such as Base (the collection of editing and file manipulating commands), Calculator, and so on. All the tools work on information in the same file structure and the user can move from one tool to another, or execute commands on a single command basis in any tool from any other tool, as mentioned earlier. The user can receive a display of subsystems available to him or an ordered list of the subsystems in which he has previously been.1e3b

The name of the current subsystem within which he is operating is fed back in a small window in the upper left-hand corner of the screen in DNLS and as a four-character prompt in TNLS. 1e3b1

Command Syntax Space

Several levels of feedback and types of "help" are available to the user in formulating a command to the system. Each is described below. The Help database, to be described, clearly is also generally useful for understanding the system as a whole.1e3c

Command-Word Recognition:
The options here were described earlier and this mode is primarily useful in minimizing keystrokes and in triggering additional feedback.1e3c1

Noise Words:
When the system recognizes a commandword or field, it generates what we call "noise words" set off in parentheses so the user can distinguish between what he has entered and what the system has added. For example, INSERT STATEMENT (to follow), MOVE WORD (from) aid the user to remember to designate a statement in the first case, or select the word to be moved. In the latter case, after selection, the characters (to) will be fed back to prompt for the destination of the move. The noise words aid the user in remembering what to do next. Novice users report that noise words are one of the most useful initial aids. As more experience is gained, the other aids take on more importance. This is an important point to note: users at different levels of experience value different forms of feedback. Usefulness is not only determined by the inherent characteristics of the aids, but also by how they are implemented.1e3c2

Prompts:
When the user completes the specification of a field in a command, he is prompted with some terse characters indicating the type of thing expected next and the alternatives available to him for specifying, selecting, or addressing the needed argument. In DNLS the promts are displayed on the line below that used to feedback the state of the users command specification and appropriately positioned horizontaly. In TNLS the prompts appear in the command specification feedback as appropriate. Users can turn prompts off, which some users of TNLS do when they reach a certain level of proficiency, although many highly skilled users always operate with them on. DNLS users tend to always operate with them on because the high speed of the display does not slow down work while providing useful information. Users can also specify terse prompting, in which case optional fields are not prompted for. Beginning users have indicated that prompting is useful, but would like prompts to be more mnemonic and of English type and word length.1e3c3

Next Options and Syntax:
If the noise words and prompts are not sufficient to jog a user's memory about what options are available to him next, he can strike a ? or a . If he strikes a ?, the system displays, in alphabetical order, all the command-words that are legitimate for the next field or more extensive information than is available in the prompts for other fields. If he strikes , the system prints out the syntax of the command from his present position to the end of the command. The ? facility is extensively used and is very useful in refreshing one's memory about infrequently used commands or new commands for a user with only a basic knowledge of command system concepts and vocabulary. The feature does not seem to be extensively used at present and may indicate that the ? facility is sufficient.1e3c4

Help Data Base:
If the above facilities are not sufficient because of uncertainty about a basic concept or vocabulary word or the user wishes more information about the effects or use of a command, he can enter the the Help tool. Entry can be from the basic command level or from any point during command specification. In the latter case, the system utilizes the information input up to this point to take the user to an initial point that describes the specific command and field where he is located [10].1e3c5

Once in the Help Database, a simple set of command conventions and the organization of the database allow the user to easily examine related subjects or move to higher level descriptions [10]. There are many unanswered questions about the best structure of a help database, how to mesh online and offline documentation properly, and what forms of accessing mechanisms to provide for novices and skilled users. We are just beginning to review our experience with online help facilities to this point.1e3c5a

Active Tutorial Help:
The next level of Help facility would be an active tutorial facility. We have not yet implemented such a facility but can see its value. An example of such a facility is the work going on at BBN on the NLS-Scholar system [11].
1e3c6

Error messages indicating an incorrectly spelled file name or improperly specified entity are fed back to the user in a window at the top of the screen. The user is left at an appropriate point within the command specification or, where necessary, he must start over again to respecify the command. The text of error messages is important and should be as specific to the problem as possible. This has implications within the system design for trapping error conditions as early as possible and determining the appropriate message for the specific error and total context of the user. While we have made progress in this area, there is much more that could be done to meet the need stated above.1f1