The art of designing command languages for interactive systems lags by at least a decade behind the state of the art in programming languages. Today's command languages tend to give the appearance of ad-hoc collections of individual commands, rather than of structures designed according to general principles.
Observation of the behavior of many casual users suggests that the following questions most often characterize the difficulties experienced by users unfamiliar with a given interactive system:
A well designed system allows the user at all times to obtain conveniently a clear answer to the above questions.
He present a framework for the design of the user interface of interactive systems, and a specific instance of a command language, based on three concepts that mirror the questions above:
In terms of these concepts many common user operations appear naturally as special cases of general features, such as:
An interactive system based on these concepts has been implemented in the Self-Explanatory School Computer XS-0.
Experience with interactive systems has lead to acceptance of some guidelines for the design of command languages, such as:
A statistical evaluation of the relevance (estimated by a few hundred users) of dialog qualities which result from such rules has been done by a project group of the GMD, Institut fur Software Technologie ([DZ 77]}.
Considerations such as the ones listed above apply mainly to single commands, but do not tell the designer what the overall structure of the language should be. The lack of an accepted framework for designing a command language as a whole leads to widely observed deficiencies even in systems that are carefully designed, such as:
This paper shows how a comprehensive approach to designing command languages can avoid pitfalls of the type above. The development of a universal model of the user-system dialog, which transcends particular applications, hardware, and syntax of commands, is the major contribution of this paper, and differentiates it from other approaches. Our model is based on a few intuitively powerful concepts rather than on a large collection of behavioral principles or interaction techniques. A brief survey of the existing literature serves to clarify this point.
The majority of contributions to the design of man-machine dialogs (or, perhaps more generally, to the user interface of interactive systems), can be classified into three categories.
Our attempt at a universal model of man-machine interaction starts by characterizing the user's situation in the dialog. The user operates on some data by means of some commands. Which data is being affected and which commands are available is his first concern. The next section analyzes this situation.
The casual user (as opposed to the skilled user) is the most sensitive indicator of good or bad dialog design decisions. Observation of hundreds of casual users has shown that they are mainly concerned with knowing what kind of things they are dealing with at any given instant during the dialog, and what they can do with them. The user's situation is best characterized by asking the following three questions:
Let's consider more closely what an adequate answer to these questions requires. As an example, assume a user is interrupted in the middle of a dialog, such as editing a text file. When he returns to his work, minutes or hours later, his first task is to identify the current state of the system. Even assuming that the state remained unchanged during his absence, the user has to convince himself of this fact. This observation must be done without altering the state. For example the user should be able to see which file is currently being affected by editor commands without leaving the editor; he should not be required to type any characters simply to find out whether or not he is in insert mode. Many systems allow so-called status inquiries, such as requests for a list of all available files; but often these are possible only at a certain level of the dialog, and only convey information on a few specific aspects of the dialog session.
An appropriate status display during editing might include some of the following information:
file: a
section: 3.1
owner: b
you have: read/write permission
last modified by: c
on: 1/2/78
current mode: text-edit
submode: insert
====================================================
.................................
......................
..................
.......
.
====================================================
Press
X to leave insert mode
HELP for a list of active commands
In order to be easily understood, the wealth of information which the user may want to know about the state of the dialog must be structured. We observe that the information in the example above has to do with three aspects of a dialog:
The question where am I? has a clear and short answer you are at site such-and-such only if the environment, i.e. the collection of all available data, has a systematic structure. Organizations with long experience in providing services impose structures on their data that are appropriate for their intended use. Libraries, for example, have evolved subject matter classifications (such as the Dewey Decimal System) and subject, author and title indexes to structure a collection of documents in such a way that the most frequent queries are easily answered. Perhaps the single most important aspect of the conventional library catalog is the fact that it allows retrieval of a relevant document even if the user does not know its name (author, title, etc.). Some knowledge about the information being sought may suffice for following an access path leading to this document. In contrast to this invention of old, many of today's computer filing systems allow access to a file only via its (unique) name.
Similarly the question what can I do here? is most easily answered if the collection of all possible actions is structured in a meaningful way. An exhaustive list of commands is usually too long to be of great help. A casual user expects to be guided in his choice of an appropriate command through different decision levels, whereby an initially vague idea gradually becomes specified in detail. The next two sections show how this can be done.
The questions how did I get here and where can I go? do not require any structuring mechanism beyond those introduced for sites and modes (data and commands). They are taken care of by making time an explicitly manipulable dimension of a dialog.
Based on the considerations of section 2, the following three concepts are introduced as the fundamental structuring tools for the design of man-machine dialogs.
At any moment a user wants direct access to only a relatively small part of the data present in a system. For example, if he just compiled a program, he may want to have the source text and the compiler messages at his finger tips. Other data should be invisible at this moment, as it would only interfere with the active data and make his selection of what he wants to see harder. A collection of data which is likely to be of simultaneous interest to a user for some purpose can be attached to a site. Thus it becomes a unit that can be operated upon as a whole in certain ways (such as copying); for other purposes the data attached to a site can be regarded as being hierarchically structured into subsites. A site may be identified with the set of data attached to it and a description of its type and structure. By means of this description the data becomes accessible, as the following pictures are intended to show.
Sites are linked to each other and thus form a space of sites. The topology may be that of a general network, or a restricted type of graph such as a tree; in any case it is made to reflect the semantic neighborhood relation assumed to exist on the underlying set of data. A user moves around this space of sites, can see a map of parts of it, and can edit (modify) the space when he wishes to impose a new structure over his data.
At any moment a user needs only a small part of all the commands available in the system. If he is editing a picture, for example, only graphics commands are of immediate interest. In response to a request for a list of active commands, only these and a few general commands used for mode changing should be displayed; a larger menu only makes the user's selection more difficult. Thus the set of all commands must be structured into a space of modes.
The commands grouped together in a mode must correspond to a meaningful activity in the user's mind, such as editing. A mode may have submodes, such as text editing, picture editing, or program editing. The natural relationship among these modes give the space of modes its structure, which governs the allowable transitions between the various modes.
A collection of commands which is likely to be of simultaneous use should be grouped into a mode. Thus it becomes a unit which can be operated upon as a whole in certain ways (such as enabled, disabled, protected). For other purposes the commands active in a mode can be regarded as being hierarchically structured into submodes. A mode may be identified with the set of commands active in it and a description of their effect and structure.
Modes are linked to each other and thus form a space of modes. A user moves around this space of modes, can see a map of any part of it, and may even extend the space by adding new modes and their definition in certain cases.
The order in which a user visits various sites is a relationship among the sites which is likely to be important for the current task - a relationship which may be too transient, or too special purpose, to have been embedded into the links of the space of sites. The same can be said for the order in which modes, submodes, and commands are entered.
In order to make this relationship, which is created during a dialog, available for further use, the notion of a trail as a manipulate object is introduced. A trail is a feasible time sequence of pairs {current mode, current site), which describes a user dialog (actual or contemplated). Trails can be named, stored, edited, and invoked (re-used).
Trails are the expansion of the first two concepts into the dimension of time. Each pair (current mode, current site) is viewed as the state of the dialog at a specific instant. By making the dimension of time manipulable it is now possible to contemplate the dialog in the past, at a given moment, or as a set of alternatives for the future.
The projection of a trail onto the spaces of sites results in the trace of the sites: the path of the cursor during an editing session is an example. The projection of a trail onto the space of modes results in a trace of modes: a history of commands entered, or a command macro, are examples.
The next section shows one way of realizing these abstract concepts in an interactive system.
The concepts just introduced are sufficiently general to apply to many existing systems. Let us now describe one particular system whose design was based entirely on these concepts: a school computer designed to let users of varied background learn and practice programming. The primary design goal of this system, XS-0, is concisely expressed by the attribute self-explanatory: a casual user, even one without prior computer experience, should be able to browse through a public library of lessons; if he is a beginning programmer, he should be able to learn the language of XS-0, Pascal, and get excellent diagnostics when his programs run. The concepts of site (at the level of files) and mode were emphasized from the beginning; trails, and operations on them, entered into the design gradually, beginning with the possibility to mark a current state to facilitate a later return to it.
The intended application, as a school computer, forced us to choose a low cost hardware: a PDF 11/03 with 56 kbytes of memory, dual floppy disk drive, an operator console and printer, and several graphics terminals, each one controlled by a microprocessor. The capacity of central memory as well as the floppy disks turned out to be the bottleneck. The implementation of XS-0 on such a small hardware configuration shows, however, that the organization proposed makes efficient use of resources.
The space of sites represents a filing system that accommodates public files, and private files that belong to one user or are shared by a group of users. Thus the structure of the space of sites reflects the partition of all files into public and private files, and for each of these subgroups appropriate further subdivisions. Public files are subdivided according to a subject matter classification; private files according to the structure of the different user groups found in a school environment. A tree results, whose top part is shown in Figure 1. The structure of this tree can be modified by means of a site editor.
As a consequence of this organization the normal way of accessing data consists in moving along meaningful paths, rather than in identifying data by name. A mode called Explore contains motion commands such as those shown in Figure 2.
It is possible to move directly to any site whose name is known by means of a goto command. The current site can be marked by pushing its name onto a stack; the command return causes a return to the last site stacked, and pops the stack.
As a further consequence the user may have structured information about the available data, which exceeds the mnemonic value of a name, without having to look explicitly at the data. This is done by means of a descriptor attached to each site.
The descriptor of a site lists all sites directly linked to it, i.e. the immediate neighborhood of this particular site. It also lists the files attached to the site, i.e. all and only data accessible at this particular moment. The access of the data is done by simple selection from the list mentioned above.
SITE: pascal lessons on pascal ============================================================= ALLOCATED FILES: SHORT ABSTRACT INFORMATION 1. introl introduction to the structure 2. intro2 of the Pascal course SUCCESSOR SITES: 3. syntax different chapters 4. structure of the course 5. execution
The modes group the different services offered by the system into meaningful units. The space of modes exhibits a hierarchical tree structure. The user may consider this to be a decision tree that allows him to select a specific command by repeated menu selection from meaningful groups of command.
The space of modes is organized along symmetric principles to those applied in the space of sites. As a main consequence the user need not memorize the name and syntax of commands - in selecting a command he traces a meaningful path in the space of modes. As an example, imagine that he wants to delete the last message that was left in his mailbox, which is a special file attached to his home site. He moves to his site and selects the mailbox file. This already brings him into the appropriate mode for reading, writing and sending messages, i.e. the mode mail-editing. A single key press selects the submode modify, where he presses D for delete and then selects the message to be deleted. Notice that all information necessary to perform this action was always displayed on the screen. Notice also that the user is unconcerned with the fact that there are other delete commands besides the one he used; the current site, of type mailbox, and the current mode, mail-editing, guarantees that only actions that affect messages are executed.
Several dozen users have used XS-0 extensively to perform different tasks such as writing course material, learning to program, or preparing text and graphics documents. Some major points learned from this experience are the following:
The shortcomings of the system XS-0 may be removed to a great extent by generalizing the space of sites and the space of modes, and by introducing more powerful operations on trails.
The use of cursors in editors shows quite well the presence of an implicit site concept at all levels of data representation. The space of sites in a system should therefore permeate the whole data space and structure data down to the lowest level. A character in a text file is a site with potentially an equivalent description to that of the site containing all text files of the system. Complete symmetry between sites and modes permits independent motion on the two spaces by means of the same set of motion commands.
Introducing the concept of trail in its full generality has a beneficial impact on the simplicity and power of an interactive system. While sites and modes allow the user to be in an appropriate environment for each specific task that may be performed in the system, trails give him a consistent means to control the dynamics of his dialog. The main features which allow him to achieve this control are the following:
A new version of our system, called XS-1, is currently under development. The basic design concepts have not changed; we now think we know how to apply them consistently.
A close study of existing command languages reveals many examples where a useful concept has been introduced in an ad-hoc, usually timid, fashion: the sporadically active HELP command, the occasional advice concerning plausible next actions or warning about impending events, the rare notification to the user what the current state of the system is. This situation suggests that the state-of-the-art in command languages is analogous to that of programming languages one or two decades ago, before concepts such as orthogonality or principles such as a constant may be replaced by an arbitrary expression of the same type had been widely accepted.
A first stage of systematic treatment of man-machine dialogs is described well by Martin in [MA 73], who emphasizes technical and physiological aspects rather than the overall design of command languages.
Since then, a considerable amount of research on widely differing aspects of man-machine communication has been done - the papers presented at this conference give a good indication of the breadth of the field. In general, research in this field appears to have progressed in a bottom-up fashion: from physiological factors to devices, to individual commands, to entire command languages. It is now appropriate to aim at a comprehensive model of how an interactive system should present itself to the user.
This paper presents a framework for structuring the resources (data and services) offered by an interactive system. The model is based on the three fundamental questions which a user of any interactive system, regardless of application, needs to have conveniently answered at all times:
The concept of sites, mode and trail, available for user inspection at all times, provide the convenient answers. Designers aware of these concepts will bring command languages from the stage of ad-hoc collections of individual commands to the long-overdue stage of systematic design.
[BE 73] John L. Bennett; "Spatial concepts as an organizing principle for interactive bibliographic search" in: Interactive bibliographic search / the user-computer interface, pp 67-83 edited by D.E. Walker, AFIPS Press, Montvale, New Jersey (1973)
[DZ 77] Wolfgang Dzida, Siegfried Herda, Wolf D. Itzfeld, Helmut Schweizer: "Was ist Benuetzerfreundlichkeit?" Der GMD - Spiegel, 3 (1977), pp 11-21
[EL 78] R.A. Ellis: "On the interactive use of a macroprocessor to generate operating system batch streams" IEEE Transactions on Software Engineering, Vol. 4, No. 2, (March 1978), pp 146-148
[FO 74] James D. Foley and Victor L. Wallace: "The art of natural graphic man-machine conversation" Proceedings of the IEEE, Vol. 62, No. 4 (April 1974), pp 462-471
[HA 71] Wilfred J, Hansen: "User engineering principles for interactive systems" Fall Joint Computer Conference, AFIPS Conference Proceedings, Vol. 39, AFIPS Press, Montvale, New Jersey, (1971), pp 523-532
[KA 76] David J. Kasik: "Controlling User Interaction" ACM SIGGRAPH / Computer Graphics, Vol. 10, No. 2, (Summer 1976), pp 109-115
[MA 75] William C. Mann: "Why things are so bad for the computer naive user" National Computer Conference, AFIPS Conference Proceedings, (1975), pp 785-787
[MA 73] James D. Martin: "Design of man-computer dialogues" Prentice-Hall, Englewood Cliffs, New Jersey, (1973)
[MI 77] Lance A. Miller and John C. Thomas, Jr.: "Behavioral issues in the use of interactive systems" Int. J. Man-Machine Studies, 9 (1977), pp 509-536
[MU 77] R. Muchsel: "Kommando-Sprachen - Wunsch und Wirklichkeit" Angewandte Informatik, 9 (1977), pp 369-374
[NI 69] R.S. Nickerson; "Man-computer interaction: a challenge for human factor research" IEEE transactions on Man-Machine Systems, Vol. 10, (1969), pp 164-180
[NI 77] J. Nievergelt, H.P. Frei, H. Burkhart, Ch. Jacobi, B. Plattner, H. Sugaya, B. Weibel, J. Weydert: "XS-0: A self-explanatory School Computer" Berichte des Instituts flir Informatik /Nr. 21, (August 1977) Eidgenbssische Technische Hochschule Zurich
[RO 75] William B. Rouse: "Design of man-computer interfaces for on-line interactive systems" Proceedings of the IEEE, Vol. 63, No. 6, (June 1975), pp 847-857
[$H 78l Alan C. Shaw: "On the specification of graphic command languages and their processors" Paper for the Seillac II Workshop on the Methodology of Interaction (May 1979)
[ST 73] C.J. Stephenson: "On the structure and control of commands" ACM Operating Systems Review, Vol. 7, No. 4, (October 1973), pp 22-26, 127-136
The self-explanatory school computer XS-0 has been the test bed for many of the ideas presented in this paper. We acknowledge the cooperation of H. Burkhart, H.P. Frei, Ch. Jacobi, B. Plattner, H. Sugaya, B. Weibel on this project ([NI 77]).
We are also grateful to A. Schmitt of the University of Karlsruhe for discussions which have given us much insight into the problem of man-machine communication; and to A.C. Shaw of the University of Washington, J. Encarnacao of the Technical University Darmstadt, and an unknown referee for useful comments on an early draft of this paper.