Issues in the Design of Human-Computer Interfaces

  • Jurg Nievergelt
Conference paper


Interactive use of computers in many different applications by users with a wide variety of backgrounds is ever increasing. This proliferation has increased the importance of designing systematic human-computer interfaces to be operated by casual users. Novel styles of interfaces that exploit bitmap graphics have emerged after a long history of interactive command languages based on alphanumeric terminals. This development is repeating, with a 20-year delay, the history of programming languages: Large collections of unrelated operations are being replaced by systematically structured modes that satisfy general principles of consistency. This tutorial illustrates some general issues that designers of human-computer interfaces encounter, by means of examples chosen from one particular research project. We do not attempt to give a comprehensive or balanced survey of the many approaches to human-computer interface design.

A survey and classification of design errors common in today’s command languages leads to concepts and design principles for avoiding such errors. But the very notion of command language, which emphasizes the input, is of doubtful utility for understanding the principles that govern the design of good human-computer interfaces. Observation of users shows that the most common difficulties experienced are expressed well by such questions as: Where am I? What can I do here? How did I get here? Where else can I go and how do I get there? Such questions reveal the fact that the fundamental problem of human-computer communication is how to present to the user what he cannot see directly, namely the state of the system, in such a manner that he can comprehend it at a glance. If the output language of a system what the user sees or can get onto the screen easily, is rich and well structured, the command language proper, or input language, can be simple — ideally the minimum set of selecting the active data, selecting the active operation, and of saying “do it”, all by just pointing at the proper places on the screen. Instead of emphasizing the command part of the interface, designers should focus their attention on the display part.

The questions above also provide hints about how the display of an interactive system should be structured. Where am I? and What can I do here? refer to the state of the system. A good design answers them by displaying to the user on demand his current data environment (site) and his current command environment (mode). The questions How did I get here? Where else can I go? refer to the past and future dialog (trail). A good design presents to the user as much of the past dialog as can be stored: to be undone (in case of error), edited and reinvoked. And it gives advice about possible extrapolations of the dialog into the future (help). This Sites, Modes, and Trails model of interaction has been implemented in two experimental interactive system. They presents the state- and trail information by means of universal commands that are active at all times, in addition to the commands of an interactive application. This gives the user the impression that “all applications on this system talk the same language”.

With the current spread of personal computers to be operated by casual users for short periods of time, the quest for systematic, standard man-machine interfaces must proceed beyond the design of “user-friendly” operating systems. It will be necessary to identify the most important dialog control commands, and to standardize these in a minimal piece of hardware that the user can carry with him and plug into any personal computer. We describe an experiment in this direction, which involves a “mighty mouse”.

Programming methodology has emphasized different criteria for judging the quality of software during the three decades of its existence. In the early days of scarce computing resources the most important aspect of a program was its functionality — what It can do, and how efficiently it works. In the second phase of structured programming the realization that programs have a long life and need permanent adaptation to changing demands led to the conclusion that functionality is not enough — a program must be understandable, so that its continued utility is not tied to its “inventor”. Today, in the age of interactive computer usage and the growing number of casual users, we begin to realize that functionality and good structure are not enough — good behavior towards the user is Just as important. The behavior of interactive programs will improve when the current generation of commercial software has outgrown its usefulness, and the next generation of programmers is free to make a fresh start.


Interactive System Command Language Insertion Mode Logical Command Dialog Control 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. [Be 82]
    G. Beretta, H. Burkhart, P. Fink, J. Nievergelt, J. Stelovsky, H. Sugaya, J. Weydert, A. Ventura, XS-1: An integrated interactive system and its kernel, 340–349, Proc. 6-th International Conference on Software Engineering, Tokyo, IFFE Computer Society Press, 1982.Google Scholar
  2. [Ki 82]
    Y. Kitahara, Information Network System · Telecommunications in the 21st century, The Telecommunications Association, Tokyo, 1982.Google Scholar
  3. [Mi 56]
    G. A. Miller, The magical number seven, plus or minus two: Some limits on our capacity for processing information, Psych. Review, Vol 63, No 2, 81–96, March 1956.Google Scholar
  4. [NW 80]
    J. Nievergelt and J. Weydert, Sites, Modes, and Trails: Telling the user of an interactive system where he is, what he can do, and how to get places, in Methodology of Interaction, R. A. Guedj (ed), 327–338, North Holland 1980.Google Scholar
  5. [Ni 82]
    J. Nievergelt, Errors in dialog design, and how to avoid them, in Document Preparation Systems · A Collection of Survey Articles, J. Nievergelt et al. (eds), North Holland Publ. Co., 1982.Google Scholar
  6. [No 81]
    D. A. Norman, The trouble with UNIX, 139–150, Datamation, Nov 1981.Google Scholar
  7. [St 84]
    J. Stelovsky, XS-2: The user interface of an Interactive system, ETH dissertation 7425, 1984.Google Scholar

Copyright information

© Springer-Verlag Tokyo 1986

Authors and Affiliations

  • Jurg Nievergelt
    • 1
  1. 1.University of North CarolinaUSA

Personalised recommendations