Etude and the Folklore of User Interface Design

Michael Good

Laboratory for Computer Science
Massachusetts Institute of Technology
Cambridge, Massachusetts, USA

Originally published in Proceedings of the SIGPLAN SIGOA Symposium on Text Manipulation (Portland, Oregon, June 8-10, 1981), SIGPLAN Notices, 16 (6), June 1981, pp. 34-43. Included here with permission. Copyright © 1981 by ACM, Inc.

1. Introduction

Research in user interface design is like the weather — everybody talks about it, but nobody does anything about it. While this isn’t strictly true. the great majority of guidelines for user interface design that one is likely to come across are based on the experience or gut feelings of a particular designer. These are better than nothing, but they are made less useful since 1) a particular recommendation could be based on factors unique to the designer’s own system, 2) the population for whom the particular system is intended is either not described in detail or is not a generalizable sample of computer users, 3) designers’ gut feelings are notoriously inaccurate sources for human factors guidelines. Thus the main body of recommendations available to the designer of a new system is more in the category of folklore than of readily accepted engineering principles.

So long as one recognizes these limitations, it is still very helpful to consider the recommendations one finds in the literature when designing a new system. Some of these are based on experimental evidence, while others are repeated often enough and with so little opposition that their utility is better than average. In this paper, I will show how these principles have been applied in designing the Etude text processing system. After summarizing the major ideas behind the design of Etude, I will focus on several specific areas of user interface design, comparing Etude’s approach with the appropriate recommendations from the folklore. I will conclude by briefly describing a forthcoming experiment which is intended to determine if adherence to the folklore has in fact produced a system that is easy to use.

2. Etude

The Etude interactive editor and formatter is the first component of an integrated office work station being developed by the Office Automation Group of the MIT Laboratory for Computer Science. It is intended to run on a small, powerful computer system with a high-resolution bit-map display. The interactive nature of the system means that the user can create, edit, and format a document at a terminal and see the results immediately displayed on a full page, high resolution display screen. Other tools, such as an image processing system, a database management system, and an electronic mail system, will be incorporated in an integrated manner so that the user will not be conscious of having to switch between systems in order to perform the necessary tasks.

The design goals of Etude, as described in the specifications [15], are as follows:

• The system should be very easy to learn to use. We expect that a person with no specialized training should be able to sit down in front of the system, and, with system prompts and queries, be able to create, edit, and print out a formatted document. At any time, if the user is unsure of what he can or should do, he may ask the system for help, and the system will display and explain the available options.
• The experienced user should not be encumbered by the facilities which are present to aid the novice.
• When editing and formatting a document, the user will be able to express what he wishes to do in a natural way, so he may easily translate his thoughts into system commands.
• The system will contain a large amount of typographic knowledge so that usual formatting can be handled automatically by the system, with some assistance from the user.

The latter three goals emphasize that the primary design goals are ease of learning and ease of use. While in many systems these two goals may appear to be at odds with each other, Etude provides optional features that make the system easy for the novice to learn without frustrating the expert. For example. while menus may be provided at any point by pressing the menu key, the use of a menu is never required for any operation — alternatives may be specified directly by the experienced operator. Expressing the commands in a natural way and incorporating a large amount of knowledge into the system results in the use of higher level formatting commands than those found in most formatting systems. Letters can be written by specifying a return address, address, salutation, body, closing, and notations. These high level objects are referred to as the components of a document and vary over different document types. Type face, margins, spacing, and indentation are all handled automatically by the system, relieving the user from the burden of creating detailed specifications. These benefits apply both to novices and experienced users.

Another major consideration in the design of Etude is the so-called “anxiety factor” [11]:

Frequently, a long period of acclimatization must elapse before an operator is sufficiently expert with a system to feel truly comfortable with it. In the interim, the user’s feelings are akin to those associated with walking a tightrope while wearing a blindfold. Because of the often obscure nature of the interface that he is forced to employ, the operator cannot fully anticipate the consequences of the actions he performs. This leads to feelings of tension and uncertainty. Moreover, the user develops a fear of committing an unrecoverable error, and thereby becomes overly timid and cautious in his dealings with the system.

Etude attempts to alleviate this anxiety in several ways, most notably by providing an undo key which will reverse the effects of any previous operation or sequence of operations. Also provided are a cancel key, which stops the current operation, and a help key that can be used at any time.

The design of Etude began in 1979, after a large number of text editing and formatting systems were surveyed. Features from these systems which appeared useful in meeting our goals were incorporated into Etude [14]. Three important examples are:

• The command structure, based on Doc [34].
• The idea of using high level formatting objects, based on Scribe [35].
• An internal structure based on the boxes and glue of TEX [19].

After a prototype version was completed early in 1980, Etude was thoroughly reviewed in terms of its compliance to the user interface guidelines found in the folklore. As a result, we changed several features and are reworking the system implementation for greater efficiency. I will now examine how the current version of Etude measures up to the collected wisdom in the design folklore. Relevant features will be introduced as required. Hammer et al. [11] have described the system in more detail.

3. Command Structure

Etude’s basic command structure follows verb-modifier-object form. The most commonly used verbs, modifiers, and objects are placed on special keys. Verbs include commands such as go-to, erase, begin, copy, and change. Modifiers include next, previous, start-of, end-of, and positive integers. Objects include “low-level” ones such as character, sentence. line, and paragraph, typefaces such as bold and italic, and the document components described in the previous section. Commands are formed through combinations such as erase sentence, go-to end-of next paragraph, begin address, and change previous 3 line(s) (to) quotation. Characters shown in parentheses are provided by Etude when echoing the command in a special command line. This prompting is similar to the use of “noise words” in TENEX [41].

This choice of command structure is becoming more popular in computer systems, especially in the area of word processing.  The premise behind this approach is that it is easier for a user to perform complex functions by combining relatively small sets of primitive objects into commands than by having to remember and choose from a much larger set of separate commands. These primitives combine to form English phrases, with system prompts providing the necessary function words (e.g., prepositions and articles [39]). This is intended to present the user with an easy to use natural syntax while avoiding the “user fooling” problems associated with “natural language” systems [33]. As Bennett [2] comments:

Following this line of reasoning, we observe that the choice of a verb-like vocabulary to represent commands and a noun-like vocabulary for labels does have proven value both for establishing an easy-to-teach conceptual framework and for aiding memory during use. This highly desirable practice. drawing on a user’s language habits, can be productive even though it stops far short of the full natural language exchanges envisioned by some.

An experiment performed at the University of Massachusetts at Amherst provides supporting evidence for this strategy [21]:

The results demonstrate that redesigning the surface syntax of a commercial editor so that the commands more closely resemble English phrases resulted in far better performance. On all measures, performance using the English editor was superior to performance using the notational editor. This was true regardless of the experience level of the users.

There is no special “insert mode” in Etude. Text is inserted at the current cursor position (located between characters) as it is typed. This avoids the oft-encountered mode switching problem, mentioned by Newman and Sproull [29]:

Each such state in which a given operation by the user is interpreted differently by the program is called a command mode. The more modes in a command language, the more likely the user is to make mistakes by forgetting which mode he is in. Single-mode command languages avoid this problem completely (p. 451)

4. Abbreviations

In Etude, the most frequently used verbs, modifiers, and objects are located on special keys. Less frequently used objects can either be selected from a menu or typed in during the command. When typing in an object name, only the number of letters that are needed to identify the object need to be typed. Etude will complete the object name in the command window whenever the name can be recognized. Often, the user need only type the first letter of the object name. This abbreviation scheme has several advantages [30]:

The capability for the computer to perform recognition on a partially complete character string effectively combines the principles of concise computer-to-user messages, prompting, and efficient training procedures

It also follows a recommendation of Kennedy [17]:

Communication should be carried out in a terse “natural” language, avoiding the use of codes and mnemonics. Abbreviations should be allowed wherever possible.

This kind of an abbreviation facility is similar to one that Walther provided experimental subjects as part of a flexible interface [43]. His experiment attempted to show the influence of a flexible interface on user satisfaction, taking into account the influence of user experience and terminal type (CRT or teletypewriter). In general, his results were inconclusive, as correlations usually depended on all three variables, not just flexibility. Results also differed depending on the criterion used to measure satisfaction (performance time, different types of user attitudes, or a measure of anxiety). However, the one clear result in his study was that users found the more flexible system to be “friendlier,” independent of the other two variables:

Users of a flexible interface will perceive their system to be more benevolent than will users of a rigid, unadaptable interface. If it is important that users have favorable attitudes to the extent that they regard the computer as being tolerant, flexible, like a person, friendly, and pleasant, the interface program should offer the user options like those used in this experiment. (p. 138)

The ability to use menus, full names, or abbreviated names is one way of meeting the goal that features for the novice not encumber the expert. It is akin to a scheme recommended by Shneiderman [38]:

With careful design a system could satisfy a broad range of users. Novices would get a set of menus. As the users gained experience, a fill-in-the-blank approach could be employed, but if users forgot the choices, a blank entry would produce the menu. Finally, the most experienced users could make parametric command strings and request fill-in-the-blank or menu approaches when they had difficulty. (p 241)

More in line with this recommendation is the abbreviation mechanism. Make abbreviation can be used to reduce any combination of commands and text to a short abbreviation. Some of these may be stored on soft keys. Otherwise, pressing abbreviation signals that the following sequence of characters (terminated by go ahead) should be expanded. This follows a recommendation of Nickerson and Pew [30]:

A means should be provided for the user to modify the language and redefine terms. For example, an individual who finds himself using a small set of commands very frequently might find it economical to replace each of these commands with a single-character abbreviation. Insofar as possible, he should be allowed to establish equivalences of this sort.

5. Preventing and Correcting Mistakes

The idea that an easy to use system should be forgiving is becoming a generally accepted principle in user interface design. It would seem to be self-evident that a system should allow a user to correct mistakes, but it is not clear what mechanism or combination of mechanisms is best for making error correction a simple task. In Etude, there are four mechanisms directly related to error prevention and correction: the use of confirmation, the ability to edit a command before it is completed, the cancel key, and the undo key.

5.1. Confirmation

Commands such as erase and copy require confirmation from the user before being executed. For example, as the user specifies the region to be erased, the region is displayed in reverse video; the user can then press go ahead to confirm that this region is to be erased, or press cancel if the action is mistaken. This follows a recommendation of Engel and Granda [8]:

If a user is performing an operation on some item on a frame. highlight that item so that the user has feedback on which item is to be worked on, which may not be what he thinks he has specified.

It also corresponds to an idea of Rohlfs’ [36]:

There should be a non-final delete function: one that allows the reproduction of deleted items a parallel with pencil and rubber, which leaves a still readable faint mark of the old text.

Confirmation is also used — and abused — in data entry interfaces. The same cautions that are recommended in that area by Gaines and Facey [9] need to be considered in text processing applications as well:

Validation: Validate data on entry by checking syntax and values, but beware of rejecting data, or querying too much as being outside norms. Have the user himself revalidate major updates before acting upon them.

In editing, it has long been recognized that “dangerous” commands should be confirmed [8]:

An extensive, final and permanent change to data should not be allowed without showing and/or indicating to the user the results of his contemplated change.

In Etude, confirmation is required for all commands which cause major changes in a document. Erasing small portions of text (such as a single line or sentence) does not require confirmation.

While there are many methods of highlighting a region, using reverse video is attention-grabbing without being annoying (a fault associated with excessive use of blinking). Engel and Granda [8] comment further:

Provide maximum contrast of a highlighted item with a non-highlighted item. This seems best done with text by reversing the image (dark on a light background, for example) of the item specified.

5.2. Editing of Commands

As commands are given to Etude, they are echoed in the command line. These commands may be edited by using a subset of the editing commands, such as the back-space and back-word keys. The use of back-space is similar to one of Walther’s flexibility options [43] that were previously discussed in the section on abbreviations. Engel and Granda [8] advocate an extensive command editing facility:

A user must be able to alter a line of input during entry and after entry. After back spacing with a non-destructive cursor and retyping, use of a forward tab or the “ENTER” key should signify to the system that the rest of the line should remain intact.

While the advantages in being able to correct errors that one can catch before they do any harm are evident, care should be taken that the command editing facility does not cause confusion with the command syntax. This is especially applicable to commands that require cursor movement.

5.3. Cancel

The cancel key is used to abort an operation that is currently being specified or is in progress. This contrasts with the undo key, described below, which is used to reverse the effects of an already completed operation.

The design folklore contains several references to the idea of a “reset” key which is similar to the cancel operation. These recommendations are based on the desirability of giving the user an easy to understand control over the system. Gaines and Facey [9] state this clearly:

Observability and controllability: Envision the system as an automaton controlled by the user and make it simple to observe and control. In particular, provide a “reset” command which aborts the current activity cleanly.

Gilb and Weinberg [10] elaborate:

Provide an “escape to square one” button or simplest possible procedure that always works to untangle the worst possible procedural knot by simply undoing all that went on since the last “square one.”

Hansen [12] also brings in an issue of keyboard design with his recommendation:

One means of reducing the user’s interaction effort is to design the system so the user can operate it on ‘MUSCLE MEMORY.’ … A button should not have more than a few state dependent meanings and one button should be reserved to always return the system to some basic control state.

5.4. Undo

The notion of an undo function is another idea that is gaining wide acceptance. Many different levels of functionality have been implemented in various systems, ranging from the relatively simple capabilities in Bravo [20] to the far-ranging abilities in INTERLISP [41]. Etude provides an undo key that can reverse the result of the immediately preceding operation or sequence of operations.

The undo operation is probably the single most important factor in relieving a user’s anxiety and alleviating the feeling of “walking a tightrope while wearing a blindfold” [10]:

Protect the system against destruction or damage from wrong procedures. Without such protection, the operator is working under incredible pressure, which will only tend to increase mistakes.

User training for Etude emphasizes the presence of the undo key and encourages experimentation. When demonstrating the prototype system, we are often asked “What if…” questions; the undo key gives us the ability to say “Well, let’s try it and see what happens; we can always undo it if it isn’t right.” A system that encourages experimentation is one major step closer to being more natural to use. According to Jones [16], this step is of greater importance than that taken by attempting “natural language” interfaces due to the basic nature of the experimental strategy:

Just as mathematics is composed of both algorithm and notation, so communication is as much a matter of procedure as it is of language. The search for a near-English vocabulary and syntax will fail to bridge the gap. Instead, we should be seeking to base our dialogues on the procedures and strategies which humans adopt in communicating with each other. These procedures are based on the four principles of expectation, implication, experimentation and motivation.

Any system dealing with tasks as complex as the interactive editing and formatting of documents is going to find the ability to experiment to be a useful capability, no matter how simple the user interface appears to be. And regardless of the complexity or simplicity of the task, people are going to make mistakes [3]:

Whatever the task, users can be counted on to make mistakes. This is especially true for people who are infrequent users. A very important inhibitor to increased use of computer power is a fear, real or imagined, that work will have to be repeated. If a user is hurt for this reason, he is not likely to forget or forgive.

There are several questions involved in the implementation of an undo mechanism for which we have neither experimental data nor folklore to guide us. How far back should a user be allowed to undo something? Restricting undo to the immediately preceding operation seems too strict, but an unlimited undo also poses problems. Besides complicating the means of specifying which operations should be undone, does it make sense to undo an isolated operation performed many minutes ago when the current context may be completely different?

Etude resolves these problems by allowing a user to undo an arbitrary length sequence of the immediately preceding operations. The user interface presents a list of the preceding operations as a menu and asks the user to specify how far back the undo should go. Since undo performs the inverse of the original operation and any operation can be undone, the user can subsequently undo part or all of the effects of a given undo command. This mechanism completely satisfies the goals given by Davies and Yates [7]:

When the user makes an error he wants to backup to the last correct point in his interaction. This may not always be possible but the system should give as much help as it can.

6. On-line Assistance

Another function that is becoming commonly accepted as desirable for nearly any system is that of on-line assistance, typically offered by way of a help function. This usually allows the user to refer to information about the system while he is on-line, rather than forcing the user to refer to manuals or other forms of off-line documentation which would interfere with the conversational nature of the interactive system. Exactly how much information is provided and how it can be selected is a matter that differs considerably from system to system. Related to a help facility is a menu facility, which lists the available options at the particular time. Etude provides both help and menu keys.

On-line assistance can serve several functions. It can be used to provide a tutorial for the new user, as mentioned by Kennedy [17]:

The computer system should give help when requested or whenever it perceives that the user is in difficulty. Self-teaching is recommended.

More typically, on-line assistance can help the user who has lost his place in an operation or who forgets what he should do next. This can be of use to all categories of users, though as Martin [25] suggests, such a facility is most typically associated with novices and casual users:

A red key on the terminal, labeled “HELP,” for example, could be of great value. Most operators, especially new ones whom we want to win over to this way of life, are going to be bewildered occasionally at the terminal and will not know what to do next. Pressing the HELP key will cause the computer to give them the facts they need. A HELP conversation might begin with a “menu” screen asking what help is needed … After being “helped,” the operator must have an easy way of returning to the main dialogue. This will be true after other types of interruptions, and can be accomplished with a CONTINUE key. Pressing this key would return the system to its point of interruption. (p. 131)

The importance of this type of assistance for casual users, especially discretionary users such as managers, is described by Bennett [3]:

The wide variety of functions available through a computer terminal makes it unlikely that a user can sit down and begin immediately to get useful results without some review. The amount of review needed is especially important for discretionary users who are irregular in their time spent at the terminal.

Besides explaining what can be done, on-line assistance can tell a user what he has already done. Etude’s help key will inform the user of the last few operations that have been performed as well as explaining the available options. Information about earlier operations can be retrieved using the query-in-depth method described below. Hayes, Ball and Reddy [13] recommend this type of facility:

A gracefully interacting system should be able to give explanations of both a static and dynamic nature to its user. Static explanations relate to what the system can and cannot do in a general sense, and how the user can ask the system to do a specific task. Dynamic explanations describe what the system is doing and why it is doing it, and the outcomes of past events.

Both novices and experienced users will forget details of system usage or be unaware of all the possibilities within a large number of choices. In Etude, this can especially occur when selecting the class of a component. In this case, menus can be the easiest way to provide assistance, as Hansen observes [12]:

Because the user forgets, the computer memory must augment his memory. One important way this can be accomplished is by observing the principle SELECTION NOT ENTRY. Rather than type a character string or operation name, the user should select the appropriate item from a list displayed by the computer.

Hansen appears to believe that menus should always be used: note the use of “selection not entry” as opposed to “selection or entry.” However, unless the menus are as easy and quick to use as direct entry, their forced use may encumber experienced operators. The required use of menus also violates the Hansen’s own principle of display inertia:

As the system reacts to a user’s request, it should observe the principle of DISPLAY INERTIA. This means the display should change as little as necessary to carry out the request.

If help and menu facilities are adopted, how can they best be implemented? One criteria should be the suitability of the mechanism to a broad range of users. A user might require anything from the briefest reminder of what can be done to the most detailed explanation of a given situation. One way to achieve this goal is to use the query-in-depth method proposed by Gaines and Facey [9]:

Query-in-depth. Distribute information and tutorial material appropriately throughout the system to be accessed by the user through a simple uniform mechanism.

An example of using query-in-depth is a help facility that is invoked by a question mark. The first time a question mark is typed, a short piece of information is provided. Repetition of the question mark results in successively more detailed explanations, until the most detailed level (perhaps advising where to get human assistance) is reached.

To facilitate query-in-depth, Etude treats help and menu in much the same way: information provided in response to help is structured like a menu, but with more verbose description included. In either case, the user can then move around the menu to select an item. Pressing help will provide more detailed information about this particular item.

Some other guidelines for menu implementation may also be useful. For example, menus in many of today’s systems make the user specify items in the menu by number. This is not necessarily the easiest way to do things, especially if the system is designed so that menus are strictly optional. In this case, the following recommendation by Hansen [12] is especially applicable:

The second principle to avoid memorization is NAMES NOT NUMBERS. When the user is to select from a set of items he should be able to select among them by name.

In Etude, for example, the user can type in the name of an item whether or not he has seen a menu. If he uses a menu, then he may also choose an item by using cursor movement commands to move within the menu (the currently selected item in the menu is always displayed in reverse video; when the menu first comes up. the first item is chosen by default as the “currently selected item”).

Only currently permissible items should be displayed in menus; items that might be relevant at other times in similar situations should not be included. Such information generally does not help the user, and in fact may degrade his performance since the extra information increases the length of the menu and consequently increases the time the user needs to find the correct item [1]. One application of this principle in the Etude prototype occurs when a user has typed the first few characters of a name and then asks for a menu; only the items starting with the characters already typed are displayed.

Menus that obscure the portion of text that the user was working on violate the principle of display inertia and may cause the user to fear that his work has been lost. In Etude, menus are positioned so as never to obscure the text surrounding the current cursor position.

7. Feedback and Error Messages

During Etude’s implementation, constant attention was paid to providing immediate feedback to the user. Every keystroke that the user types causes some response on the screen. The following Gaines and Facey principle [9] was strictly adhered to:

Immediate feedback. Give the user feedback by making an immediate unambiguous response to each of his inputs. This should be sufficient to identify the type of activity taking place.

When commands are completed. a form of closure has been reached [27]. Sometimes, in complex commands, the results of the command cannot he displayed immediately. However, any command echoed in the command line (which includes all actions except for text insertion and the use of “arrow” keys for cursor movement) displays an “[ok]” before the command is executed to acknowledge that the user has finished specifying the command. This is in accordance with a guideline suggested by Rouse [37]:

The computer should respond quickly or, if that is not possible, the user should be provided with some feedback that his program is operating.

Etude follows many of Rohlfs’ [36] guidelines for the design of error messages and their presentation to the user, such as always putting error messages in the same place on the screen and avoiding numeric codes, unknown abbreviations, and computer terminology. Messages and prompts are kept straight and to the point. They are never cute and folksy, a fault which Engel and Granda warn of [8]:

No attempts at humor or punishment should be made. People are still threatened by an anthropomorphic machine, and until the optimal ‘personality’ of a computer can be derived, keep dialog strictly factual and informative.

8. Response Time

As the reader may have noticed, efficiency in terms of speed and space requirements was not high on the list of Etude’s design goals. In building the prototype, we were much more concerned with getting the system to function correctly than with getting it to function efficiently. However, response time is involved in several human factors considerations for a user interface. The relationship is not simply “faster is better,” but involves considerations of thresholds of acceptability, response time variability, and pacing of the user. The prototype version did not meet requirements in this area. Major changes in the new implementation should alleviate this problem.

No interactive system is easy to use if it is too slow to keep up its end of the interaction. Robert Miller’s oft-cited paper on response time requirements [27] proposes a 2 second figure as a general rule for many types of interaction. Much faster responses are needed for things such as echoing typed input (instantaneous, <.1 second), and slower responses are acceptable, if not desirable, at points where a major closure has been achieved. However, Miller mentions that there is a clear break in acceptability at the 15 second point:

In any event, response delays of approximately 15 seconds, and certainly any delays longer than this, rule out conversational interaction between human and information systems.

Miller and several other authors hypothesized that variability of response time was perhaps of more importance than absolute response time, assuming that the latter was within tolerable limits. Experimental validation of this hypothesis was later provided by Lawrence Miller [26]:

The effects of varying CRT display rates and output delays upon user performance and attitudes in a series of message retrieval tasks were evaluated experimentally. The results support the somewhat surprising conclusion that doubling the display rate from 1200 to 2400 baud produces no significant performance or attitude changes; increasing the variability of the output display rate produces both significantly decreased user performance and a poorer attitude towards system and interactive environment.

It has also been theorized that response times that are too fast push the user too hard and induce additional stress in trying to keep up with the machine. Others mention that too-rapid interruptions with error messages are both impolite and unproductive. Among those concerned with excessively fast response times is Kennedy [17]:

The rate of exchange must be within the user’s stress-free working range Control of the rate should always appear to belong to the user.

9. Hardware Considerations

While most of this paper has discussed matters that primarily concern the software design of the system, it is important to consider factors regarding the display, the workstation, keyboard layout. and provisions for alternative input and control devices. Cakir, Hart and Stewart’s comprehensive report on visual display terminals and their workstations [5] includes extensive design checklists.

The selection and design of input and control devices for Etude is a lively discussion topic within the design group. Since we are just starting to consider issues of keyboard design in detail, specific implementations of recommendations cannot be listed. However, one simple change to the operation of the standard keyboard that has been incorporated into Etude and many commercial word processors can save the user time and effort [18]:

A system which monitors keystrokes and automatically inserts RETURN codes when the space bar is hit in the “hot zone” at the end of the line will save a minimum of 250 millisec./line, or 27% with almost no operator retraining. Any time spent deciding whether or not to hit RETURN is also saved, and SPACE is frequently struck before RETURN in any case.

There is a danger in relying too heavily on a special keyboard due to the constantly changing nature of most computer systems. Martin [25] warns of this problem:

It is often difficult for the systems analyst to anticipate what change will occur or how rapidly it wilt come. If he designs his dialogue around a custom-built keyboard, he is building resistance to change into the system. (p 143)

Etude tries to circumvent some of these restrictions by emphasizing that only the most common special functions are found on the keyboard, thus eliminating the need for ever-expanding keyboards, and by using soft keys. However, the problem of identifying the most commonly used keys still remains. The problem is not as critical in Etude as in commercial systems since we have a large amount of liberty in redefining keys as design and development progresses.

The question of using alternate input and control devices such as “mice,” light pens, tablets, and touch keyboards seems more an issue of theology than of practical guidelines at this stage. Card et al. [6] report an experiment where the mouse was shown to be preferable to two different types of keyboard mechanisms and one type of joystick. approaching theoretically optimum performance for a pointing device (with the exception of use with single character targets). However, one should note that only one type of joystick (rate-controlled isometric) was tested, and that the arrow keys on the tested system were very slow compared to those provided in Etude and most commercially available CRT’s. Engel and Granda [8] generally recommend using joysticks.

The principle advantages cited for keyboard-oriented approaches such as those found in the Etude prototype are 1) the intended users of the system are more familiar with keyboards than with the alternative devices, 2) the user does not have to move one of his hands from the keyboard to position the cursor, and 3) the added problems with extra equipment are avoided. These problems include placement of the extra equipment at the workstation and potential for breakage and theft.

Etude’s approach to this problematical area is to provide for one or more pointing devices, without constraining the choice of specific devices. The arrow keys currently serve as a pointing device, but the system architecture allows for other devices such as a mouse or a joystick to be added at a later date.

10. Miscellaneous

Many recommendations to be found in the folklore of user interface design are not easily categorized. Some of these can be related directly to certain features of Etude. Others are more general but worthy of mention.

10.1. Log Keeping

The same mechanism which facilitates help and undo is also used to keep a system log, a facility recommended by Gaines and Facey [9]:

Log activities: Use the computer to maintain records of system and user activities to evaluate the behavior of both system and users.

Hansen [12] also emphasizes the utility of a log:

It is not enough to simply tell the user of his errors. The system designer must also be told so he can apply the principle ENGINEER OUT THE COMMON ERRORS. If an error occurs frequently, it is not the fault of the user, it is a problem in the system design.

10.2. Beyond Commands

Thomas [42] has described the need to permit metacomments about the current dialogue in a systematic way within the computer system:

People communicate not only about the topic under discussion. but also regarding direction of the conversation, speed of the conversation and internal state of the conversers … In many computer systems, there are sporadic attempts to provide for some metacomments. Typically, these are added features. They include such items as a “temperature-humidity index” that tells the user how busy the system is, an on-line facility about what is available, a “comments” command, or the ability to change “topics” by always returning to an operating system. An alternative strategy to adding metacomment capabilities to computer systems piecemeal is to recognize from the beginning of systems design that the types of metacomments listed above are found in natural language communication for a reason, and that a computer system should also provide for these functions.

Similarly, Mann [23] claims that current systems are hard to use because their vocabulary is limited nearly entirely to commands, whereas humans state goals, give examples, describe, clarify, hypothesize, use analogies, and make comparisons in addition to using commands. Elevating command usage from a minor portion of dialogue, as it is in natural language, to the dominant portion makes the new type of dialogue unnatural for people to learn and use.

Etude has some ad hoc metacomment facilities. Help, menu, and cancel either influence the direction of the dialogue and/or provide information about the state of one or both conversers. The confirmation facility provides a primitive mechanism for determining the pace of the interaction. In addition, the suggestion for logging facilities given by Hansen [12] and the INTERRUPT key suggested by Martin [25] are examples of metacomment facilities. Integrating these various functions as well as methods for customizing and controlling the pace of the dialogue into a general mechanism would be a challenging task, but one that could pay off handsomely in increased ease of use.

10.3. Simplicity

Shneiderman [38] presents a desiderata of simplicity, though he gives no means for quantifying his goals:

An interactive system is simple if it has few commands and if the commands have a consistent structure. Output should be readable and error messages should have a uniform format. Command structures should match the problem domain and the sequence of user thought processes. (p. 255)

In the same vein, Gaines and Facey [9] issue a plea for consistency which echoes throughout the folklore:

Consistency and uniformity: Ensure that all terminology and operational techniques are consistently applied, and uniformly available, throughout all system activities.

Engel and Granda [8] give a specific example of what not to do:

Nomenclature must be the same for similar or identical functions across components, tasks, and roles for command names, subcommand names, and parameters. For example, don’t use “edit” in one place, “modify” in another, and “update” in a third.

Consistency and predictability are closely related issues, as Pew and Rollins [32] observe:

A critical ingredient of friendliness is consistency. Once the user has learned a procedure or set of simple rules, he or she has the right to expect that they will always work in every context that is perceived to be similar to the context in which it was first encountered.

By combining primitives to form more complex commands, Etude attempts to meet these goals of consistency and simplicity. We believe that these gains will be especially noticeable when additional functions are integrated with the editor and formatter.

10.4. Social Issues

As a final guideline, it is most important to consider the impact of the system being designed on the people who use it. Margulies [24] reminds us that measures other than efficiency are also important when evaluating computer systems:

You will have to change your value system, recognising that the quality of your computer system has to be evaluated not in terms of output and revenue only but also in terms of job satisfaction and quality of life.

11. Future Work

Throughout this paper I have mentioned that a designer trying to produce a good user interface has to rely more on folklore that on sound engineering principles. To avoid falling into the category of those who talk about the problem without doing anything about it, I will soon perform an experimental evaluation of the Etude system.

In this paper I have shown that Etude adheres to a large amount of the folklore regarding user interface design. I have not shown that Etude is in fact an easy to use system, nor has the term “ease of use” been defined. In my experiment, secretaries without any computer experience will be recruited as subjects and taught to use Etude. The following criteria, based on the work of Miller [28], will be used to measure ease of use:

• Ease of learning: The proportion of subjects who can learn to use the system in a given amount of time.
• Ease of use once the system is learned: The proportion of subjects who can complete a set of tasks in a given amount of time.
• The subject’s state anxiety [40] when using the system.
• The attitude of the subject toward the system, measured by a Semantic Differential [22, 31].

If Etude is indeed easy to use, there will be some further experimental validation for the guidelines contained in the folklore. If it is not easy to use, there should be enough information present for the reader to decide whether the fault rests with some of the guidelines or with their implementation in Etude. This study should add to the slowly growing body of literature that is making research in user interface design less like the weather and more like sound engineering.

References

1. Baker, James D. and Ira Goldstein. Batch vs. Sequential Displays: Effects on Human Problem Solving. Human Factors 8 (1966), 225-235.
2. Bennett, John L. The User Interface in Interactive Systems. In Annual Review of Information Science and Technology, Vol. 7, C. A. Cuadra, Ed., American Society for Information Science. Washington, 1972, pp. 159-196.
3. Bennett, John L. The Commercial Impact of Usability in Interactive Systems. In Man/Computer Communication, Vol. 2. Infotech State of the Art Report, Maidenhead, England, 1979, pp. 1-17.
4. Bobrow, Daniel G. et al. TENEX, a Paged Time Sharing System for the PDP-10. Comm. ACM 15 (1972), 135-143.
5. Cakir, A., D. J. Hart and T. F. M. Stewart. Visual Display Terminals. John Wiley & Sons, New York, 1980. Originally published in 1979 by The lnca-Fiej Research Association, Darmstadt.
6. Card, Stuart K., William K. English and Betty J. Burr. Evaluation of Mouse, Rate-Controlled Isometric Joystick, Step Keys, and Text Keys for Text Selection on a CRT. Ergonomics 21 (1978), 601-613.
7. Davies, Donald W. and David M. Yates. Human Factors in Display Terminal Procedures. Proc. Fourth International Conference on Computer Communication, International Council for Computer Communication, Sept., 1978, pp. 777-783.
8. Engel, Stephen E. and Richard E. Granda. Guidelines for Man/Display Interfaces. Tech. Rep. TR 00.2720, IBM Poughkeepsie Laboratory, December 19, 1975.
9. Gaines, Brian R. and Peter V. Facey. Some Experience in Interactive System Development and Application. Proc. IEEE 63 (1975), 894-911.
10. Gilb, Tom and Gerald M. Weinberg. Humanized Input. Winthrop, Cambridge, Mass., 1977.
11. Hammer, Michael et al. Etude: An Integrated Document Processing System. Proceedings of the 1981 Office Automation Conference, AFIPS, March, 1981.
12. Hansen, Wilfred J. User engineering principles for interactive systems. AF1PS Conference Proceedings, Vol. 39, AFIPS Press, Montvale, N.J., 1971, pp. 523-532.
13. Hayes, Phil, Eugene Ball, and Raj Reddy. Breaking the Man-Machine Communication Barrier. Computer 14 (March 1981), 19-30.
14. Ilson, Richard. An Integrated Approach to Formatted Document Production. Master Th., MIT, Aug., 1980.
15. Ilson, Richard and Michael Good. Etude: An Interactive Editor and Formatter. Memo OAM-029, MIT Lab. for Computer Science, Office Automation Group, March, 1981.
16. Jones, P. F. Four principles of man-computer dialogue. Computer Aided Design 10 (1978), 197-202.
17. Kennedy, T. C. S. The Design of Interactive Procedures for Man-Machine Communication. Internat. J. Man Machine Studies 6 (1974), 309-334.
18. Kinkead, Robin. Typing Speed, Keying Rates, and Optimal Keyboard Layouts. Proceedings of the 19th Annual Meeting, The Human Factors Society, Oct., 1975, pp. 159-161.
19. Knuth, Donald E. TEX and METAFONT: New Directions in Typesetting. American Mathematical Society and Digital Press, 1979.
20. Lampson, Butler W. Bravo Manual. In Alto User’s Handbook, Xerox PARC, 1979.
21. Ledgard, Henry et al. The Natural Language of Interactive Systems. Comm. ACM 23 (Oct. 1980), 556-563.
22. Lucas, R. W. A study of patients’ attitudes to computer interrogation. Internat. J. Man-Machine Studies 9 (1977), 69-86.
23. Mann, William C. Why Things Are So Bad for the Computer-Naive User. Tech. Rep. ISI/RR-75-32, USC/Information Sciences Institute, March, 1975.
24. Margulies, F. Technological Change: Its Impact on Man and Society. In Man/Computer Communication, Vol. 2, Infotech State of the Art Report, Maidenhead, England, 1979, pp. 251-261.
25. Martin, James. Design of Man-Computer Dialogues. Prentice-Hall, Englewood Cliffs, N.J., 1973.
26. Miller, Lawrence H. A study in man-machine interaction. AFIPS Conference Proceedings, Vol. 46, AFIPS Press, Montvale, N.J., May, 1977, pp. 409-421.
27. Miller, Robert B. Response time in man-computer conversational transactions. AFIPS Conference Proceedings, Vol. 33, Part 1, Thompson Book Co., Washington, 1968, pp. 267-277.
28. Miller, Robert B. Human Ease of Use Criteria and Their Tradeoffs. Tech. Rep. TR 00.2185, IBM Poughkeepsie Laboratory, April 12, 1971.
29. Newman, William M. and Robert F. Sproull. Principles of Interactive Computer Graphics. McGraw-Hill, New York, 1979. Second Edition.
30. Nickerson, Raymond S. and Richard W. Pew. Oblique Steps Toward the Human-Factors Engineering of Interactive Computer Systems. Appendix to BBN Report No. 2190 by Mario C. Grignetti et al., Information Processing Models and Computer Aids for Human Performance, June 30, 1971. NTIS No. AD 732 913.
31. Osgood, Charles E., George J. Suci, and Percy H. Tannenbaum. The Measurement of Meaning. University of Illinois Press, 1957.
32. Pew, Richard W. and Ann M. Rollins. Dialog Specification Procedures. Report 3129, Bolt Beranek and Newman, Sept., 1975. Revised ed. NTIS No. PB-252 976.
33. Plum, Thomas. Fooling the User of a Programming Language. Software–Practice and Experience 7 (1977), 215-22.
34. Pratt, V. R. DOC Manual. MIT, 1979.
35. Reid, Brian K. A High-Level Approach to Computer Document Formatting. Conference Record of the Seventh Annual ACM Symposium on Principles of Programming Languages, ACM, Jan., 1980, pp. 24-31.
36. Rohlfs, S. User Interface Requirements. In Convergence, Vol. 2, Infotech State of the Art Report, Maidenhead, England, 1979, pp. 165-199.
37. Rouse, William B. Design of Man-Computer Interfaces for On-Line Interactive Systems. Proc. IEEE 63 (1975), 847-857.
38. Shneiderman, Ben. Software Psychology. Winthrop, Cambridge, Mass., 1980.
39. Slobin, Dan Isaac. Psycholinguistics. Scott, Foresman and Co., Glenview, Ill., 1979. Second edition.
40. Spielberger, Charles D. Anxiety as an Emotional State. In Anxiety: Current Trends in Theory and Research, Vol. 1, C. D. Spielberger, Ed., Academic Press, New York, 1972, pp. 23-49.
41. Teitelman, Warren. INTERLISP Reference Manual. Second revision edition, Xerox PARC, December 1975.
42. Thomas, John C., Jr. A design-interpretation analysis of natural English with applications to man-computer interaction. Internat. J. Man-Machine Studies 10 (1978), 651-668.
43. Walther, George H. The On-Line User-Computer Interface: The Effects of Interface Flexibility, Experience. and Terminal-Type on User-Satisfaction and Performance. Ph.D. Th., University of Texas at Austin, Aug., 1973. NTIS No. AD-777 314.

Copyright © 1981 by the Association for Computing Machinery, Inc. Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Publications Dept, ACM Inc., fax +1 (212) 869-0481, or permissions@acm.org.

This is a digitized copy derived from an ACM copyrighted work. ACM did not prepare this copy and does not guarantee that is it an accurate copy of the author’s original work.