|
Introduction | | | Data Entry | | | Data Display | | | Sequence Control | | | User Guidance | | | Data Transmission | | | Data Protection | | | Table of Contents |
|
GUIDELINES FOR DESIGNING USER INTERFACE SOFTWARE
ESD-TR-86-278
|
| by Sidney L. Smith and Jane N. Mosier |
|
|
Introduction | | | Data Entry | | | Data Display | | | Sequence Control | | | User Guidance | | | Data Transmission | | | Data Protection | | | Table of Contents |
This report offers guidelines for design of user interface software in six functional areas: data entry, data display, sequence control, user guidance, data transmission, and data protection. This report revises and extends previous compilations of design guidelines (cf. Smith and Mosier, 1984a).
If you are a teacher, a student, a human factors practitioner or researcher, these guidelines can serve as a starting point for the development and application of expert knowledge. But that is not the primary objective of this compilation. The guidelines are proposed here as a potential tool for designers of user interface software.
If you are a system analyst, you can review these guidelines to establish design requirements. If you are a software designer, you can consult these guidelines to derive the specific design rules appropriate for your particular system application. That translation from general guidelines to specific rules will help focus attention on critical user interface design questions early in the design process.
If you are a manager responsible for user interface software design, you may find in these guidelines a means to make the design process more efficient. Guidelines can help establish rules for coordinating individual design contributions, can help to make design decisions just once rather than leaving them to be made over and over again by individual designers, can help to define detailed design requirements and to evaluate user interface software in comparison with those requirements.
The design of user interface software will often involve a considerable investment of time and effort. Design guidelines can help ensure the value of that investment.
This report was prepared by The MITRE Corporation. The work reported here was sponsored by the Directorate of Computer Systems Engineering, Deputy for Acquisition Logistics and Technical Operations of the Electronic Systems Division (ESD) of the United States Air Force Systems Command, Hanscom Air Force Base, MA 01731. Continuing funding for this work was provided by the Air Force Computer Resource Management Technology Program, Program Element 64740F, under ESD/MITRE Project 5220. Final publication of these guidelines was funded under Project 5720.
The Computer Resource Management Technology Program supports development and transition into active use of tools and techniques needed to cope with the explosive growth in Air Force systems that use computer resources. The objectives of that Program are:
In designing computer-based information systems, special attention must be given to software supporting the user interface. For the past several years, guidelines for designing user interface software have been compiled as a continuing effort sponsored by the Air Force Electronic Systems Division (ESD). Five previous ESD reports have dealt with this subject (Smith, 1980; 1981a; 1982b; Smith and Aucella, 1983a; Smith and Mosier, 1984a).
This present report revises and expands previously published material, and proposes a comprehensive set of guidelines for design of user interface software in computer-based information systems. Although a great many changes have been made, much of the text and guidelines material in this report will seem familiar to the readers of previous reports.
Different people will read this report for different reasons -- teachers and students, human factors practitioners and researchers, system analysts and software designers, and their managers. Each reader will bring to the task a unique background of experience and interests. Thus some introductory comments are needed to help familiarize readers with the general problems of user interface design and the particular need for guidelines to design user interface software.
For the skeptical reader, this introduction offers arguments in favor of guidelines for user interface software design. For the enthusiast who may imagine that guidelines can solve all design problems, this introduction will note some of their limitations. For those readers who wish to apply design guidelines, this introduction describes how the report is formatted, how the guidelines are presented and annotated, and concludes with some recommendations for how the guidelines should be used.
Computers today are used for a broad range of applications. User interface design guidelines cannot be applied usefully in every case. Some computers may be embedded as components in larger systems, so that they communicate only with other computers and not directly with human users. When there is no user interface, then no user interface design guidelines are needed.
Some computers are designed as general tools which can be adapted by skilled users for whatever purpose they desire. The particular tasks for which a general-purpose computer might be used are not defined in advance by the designer. Instead, a user must provide exact instructions to program the computer to perform any task at hand. The designer may try to ensure that the computer can process appropriate programming languages, but otherwise is not concerned with explicit design of a user interface.
Other computer systems are designed to help particular users perform specific tasks. Such computer applications are referred to here as information systems. Applications of information systems range from relatively simple data entry and retrieval (e.g., airline reservations) through more complex monitoring and control tasks (inventory control, process control, air traffic control) to jobs requiring long-term analysis and planning. Military command, control and communication systems span that broad range of information system applications.
To the extent that information systems support human users performing defined tasks, careful design of the user-system interface will be needed to ensure effective system operation. The guidelines proposed in this report are intended to improve user interface design for such information systems.
Users of information systems interact with a computer in order to accomplish information handling tasks necessary to get their jobs done. They differ in ability, training and job experience. They may be keenly concerned with task performance, but may have little knowledge of (or interest in) the computers themselves. Design of the user-system interface must take account of those human factors.
What is the user-system interface? In common usage, the phrase is broadly defined to include all aspects of system design that affect system use (Smith, 1982a). This report, however, is concerned more narrowly with the user interface to computer-based information systems, i.e., with those aspects of system design that influence a user's participation in information handling tasks.
This report focuses even more narrowly on those design features of the user interface that are implemented via software (i.e., the design of computer program logic) rather than hardware (the design of equipment). The guidelines proposed here are generally worded in terms of the functions that a user must perform, and the functional capabilities that a designer should provide, rather than the particular physical devices that might be used to implement those functions. Thus a particular guideline might deal with "pointing" as a function, with no necessary recommendation whether pointing should be accomplished via touch display or lightpen or any other physical device.
It is obvious that software is not the only significant factor influencing user performance. Other aspects of user interface design are clearly important, including workstation design, physical display characteristics, keyboard layout, environmental factors such as illumination and noise, the design of paper forms and written documentation, user training courses, etc. To achieve a good user interface design, all of those factors must be designed with care. But designers must look elsewhere for advice on those topics. They are not covered in this report.
The significant role of user interface software in system design poses a special challenge to human factors practitioners, recognized early by Parsons (1970, page 169):
p. . . what sets data processing systems apart as a special breed? The function of each switch button, the functional arrangement among the buttons, the size and distribution of elements within a display are established not in the design of the equipment but in how the computer is programmed. Of even more consequence, the 'design' in the programs establishes the contents of processed data available to the operator and the visual relationships among the data. In combination with or in place of hardware, it can also establish the sequence of actions which the operator must use and the feedback to the operator concerning those actions.
Continuing concern for user interface software is suggested by phrases such as "software psychology" (cf. Shneiderman, 1980). But user interface design cannot be the concern only of the psychologist or the human factors specialist. It is a significant part of information system design that must engage the attention of system developers, designers, and ultimately system users as well. Those who look to the future of information systems predict that user interface design will become a specialty area; designers trained in both computer science and human factors will be employed to develop user interface software (Williges, 1984).
User interface software can represent a sizable investment of programming effort during initial system development, and later when a system is upgraded. In a recent survey (Smith and Mosier, 1984b), information system designers were asked to estimate the percent of operational software devoted to implementing the user interface. Overall, the average estimate was that user interface design comprises 30 to 35 percent of operational software. Estimates for individual systems ranged from 3 to 100 percent, reflecting the fact that some computer systems require a much higher investment in user interface design than others, depending upon their purpose.
The design of user interface software is not only expensive and time-consuming, but it is also critical for effective system performance. To be sure, users can sometimes compensate for poor design with extra effort. Probably no single user interface design flaw, in itself, will cause system failure. But there is a limit to how well users can adapt to a poorly designed interface. As one deficiency is added to another, the cumulative negative effects may eventually result in system failure, poor performance, and/or user complaints.
Outright system failure can be seen in systems that are underused, where use is optional, or are abandoned entirely. There may be retention of (or reversion to) manual data handling procedures, with little use of automated capabilities. When a system fails in this way, the result is disrupted operation, wasted time, effort and money, and failure to achieve the potential benefits of automated information handling.
In a constrained environment, such as that of many military and commercial information systems, users may have little choice but to make do with whatever interface design is provided. There the symptoms of poor user interface design may appear in degraded performance. Frequent and/or serious errors in data handling may result from confusing user interface design. Tedious user procedures may slow data processing, resulting in longer queues at the checkout counter, the teller's window, the visa office, the truck dock, or any other workplace where the potential benefits of computer support are outweighed by an unintended increase in human effort.
In situations where degradation in system performance is not so easily measured, symptoms of poor user interface design may appear as user complaints. The system may be described as hard to learn, or clumsy, tiring and slow to use. The users' view of a system is conditioned chiefly by experience with its interface. If the user interface is unsatisfactory, the users' view of the system will be negative regardless of any niceties of internal computer processing.
A convincing demonstration of design improvement has been reported by Keister and Gallaway (1983). Those authors describe a data entry application in which relatively simple improvements to user interface software -- including selection and formatting of displayed data, consistency in wording and procedures, on-line user guidance, explicit error messages, re-entry rather than overtyping for data change, elimination of abbreviations, etc. -- resulted in significantly improved system performance. Data entry was accomplished 25 percent faster, and with 25 percent fewer errors. How can that kind of design improvement be achieved in general practice?
It seems fair to characterize current user interface software design as art rather than science, depending more upon individual judgment than systematic application of knowledge (Ramsey and Atwood, 1979; 1980). As an art, user interface design is best practiced by experts, by specialists experienced in the human engineering of computer systems. But such experts are not always available to help guide system development, and it is clear that they cannot personally guide every step of design. What is needed is some way to embody expert judgment in the form of explicit design guidelines.
For military information systems, Military Specification MIL-H-48655B (1979) calls for a system development sequence starting with requirements analysis, functional specification and verification before any software design begins. The actual course of user interface software development will sometimes depart from that desired sequence. There may be no explicit attempt to determine user interface requirements. Specifications may include only rudimentary references to user interface design, with general statements that the system must be "easy to use". In the absence of effective guidance, both the design and implementation of user interface software may become the responsibility of programmers unfamiliar with operational requirements. Detection and correction of design flaws may occur only after system prototyping, when software changes are difficult to make.
Human engineering standards and design handbooks have in the past been of little use to the software designer. The popular human factors design handbook by Woodson (1981) is typical. Its nearly 1000 pages include only three pages of general material on information processing, and there is no reference to computer systems in its index.
MIL-STD-1472B (1974), for many years the major human engineering design standard for military system procurement, was concerned almost exclusively with hardware design and physical safety. In 1981, MIL-STD-1472 was published in a revised "C" version. That version included nine pages dealing with user interface software design, in a section titled "Personnel-Computer Interface". That material was later expanded to 19 pages, titled "User-Computer Interface", in a revision of MIL-STD-1472C (1983). Thus a beginning has been made, but much more is needed. The question is, what guidance can be offered for user interface software design?
Until several years ago, there had been no serious attempt to integrate the scattered papers, articles and technical reports that constitute the literature of user-computer interaction. A first step was made, under sponsorship of the Office of Naval Research (ONR), in compilation of an extensive bibliography on this subject (Ramsey, Atwood and Kirshbaum, 1978). A significant follow-on effort culminated in publication by Ramsey and Atwood (1979) of a comprehensive summary of this literature.
In reviewing the literature, it is apparent that most published reports dealing with the user-computer interface describe applications rather than design principles. A popular early book on the design of user-computer dialogues offered stimulating examples, covering a range of on-line applications, but was disappointing in its failure to emphasize design principles (Martin, 1973). The ONR bibliography cited above includes 564 items, but identifies only 17 as offering design guidelines.
Although accepted principles for user interface design have not been available, some work has been accomplished toward that end. As experience has been gained in the use of on-line computer systems, some experts have attempted to set forth principles ("guidelines", "ground rules", "rules of thumb") for design of the user-computer interface. If experts cannot yet assert tested principles for user interface design, they might still offer sensible recommendations as a guide for designers.
Military agencies are not the only organizations seeking guidelines for user interface design. There is keen interest in this topic within industrial and commercial organizations, and throughout the general community of people who develop and use information systems. David Penniman, writing for the User On-Line Interaction Group of the American Society for Information Sciences, has cited the need for "an interim set of guidelines for user interface design based on available literature and pending the development of better guidelines as our knowledge increases" (1979, page 2). Penniman goes on to remind us that interim guidelines are better than no guidelines at all.
In a survey of people concerned with user interface design (Smith and Mosier, 1984b), respondents generally support Penniman's activist position. Given a choice between trying to develop a complete set of user interface guidelines now, when many of them must be based on judgment rather than experimental data, or else accepting only a partial set of guidelines based on evaluated research, most respondents would go with judgment now.
It is clear, of course, that system developers cannot wait for future research data in making present design decisions. To meet current needs, several in-house handbooks have been published to guide user interface design within particular organizations (NASA, 1979; Galitz, 1980; Brown, Brown, Burkleo, Mangelsdorf, Olsen, and Perkins, 1983; Sidorsky, Parrish, Gates, and Munger, 1984). These in-house guidelines draw heavily from those in earlier publications, especially the influential IBM report by Engel and Granda (1975), as modified by the authors' own good judgment.
The ESD/MITRE compilation of user interface design guidelines over the past several years has drawn from the work of our predecessors, and will help support the work of others to follow. Each year our guidelines compilation has grown larger. In this present report there are 944 guidelines. This compilation represents the most comprehensive guidance available for designing user interface software, and for that reason this report is recommended as a basic reference for developing information systems.
In the numbered sections of this report, guidelines are organized within six functional areas of user-system interaction:
| Number of | Section Functional Area Guidelines | | 1 Data Entry 199 | 2 Data Display 298 | 3 Sequence Control 184 | 4 User Guidance 110 | 5 Data Transmission 83 | 6 Data Protection 70
Each section of guidelines covers a different functional area of user-system interaction, although there is necessarily some overlap in topical coverage from one section to another. Within each section, guidelines are grouped by specific functions. Each function has its own numeric designator, as listed in the table of contents for this report.
In adopting this functional organization, we have established a broad conceptual structure for dealing with the range of topics that must be considered in user interface design. Such a conceptual structure is urgently needed to help clarify discourse in this field.
Each section of the guidelines begins with an introductory discussion of design issues relating to the general functional area. That discussion provides some perspective for the guidelines that follow. The discussion concludes with brief definitions of the various user interface functions covered in that section of the guidelines, along with an internal table of contents for that section, which may help to lead a reader directly to functions of immediate interest.
Function definitions are repeated in boxed format to begin the listing of guidelines under each function. Those definitions should aid reader understanding of the material, and the boxed format will provide a notable visual indicator that a new series of guidelines has begun.
The guidelines themselves are numbered sequentially under each function, in order to permit convenient referencing. Under any function there will usually be guidelines pertaining to various subordinate topics. Each guideline has been given a short title to indicate its particular subject matter. Sometimes one guideline may introduce a new topic and then be followed by several closely related guidelines. Each of those related guidelines has been marked with an plus sign next to its title.
Following its number and title, each guideline is stated as a single sentence. Guidelines are worded as simply as possible, usually in general terms to permit broad application, but sometimes with contingent phrasing intended to define a more limited scope of application.
In many instances, a stated guideline will be illustrated by one or more examples. When an example includes some sort of imagined computer output, such as an error message, prompt, menu, etc., that output has been marked with enclosing vertical strokes:
| sample computer output |
There is no question that specific examples can help clarify a generally-worded guideline. Sometimes a reader will say, "I didn't really understand the guideline until I saw the example." But there is a potential hazard in examples. Because any example must be narrowly specific, a reader who relies on that example may interpret the guideline as having a narrower meaning than was intended. It is important to emphasize that examples are presented here only to illustrate the guidelines, and are not intended to limit the interpretation of guidelines.
Where the validity of a guideline is contingent upon special circumstances, examples may be followed by noted exceptions. Those exceptions are intended to limit the interpretation of a guideline.
Where further clarification of a guideline seems needed, examples and noted exceptions are followed by supplementary comments. Those comments may explain the reasoning behind a guideline, or suggest possible ways to interpret a guideline, or perhaps note relations between one guideline and another.
Where a guideline has been derived from or is related in some way to other published reports, a reference note may be added citing author(s) and date. Complete citations for those references are listed following Section 6 of the guidelines. Where a guideline corresponds with other published design standards or guidelines, which is often the case, reference citations are given by letter codes. Those codes are explained in the reference list.
Where a guideline is specifically related to guidelines in other sections, appropriate cross references are given. Those cross references permit an interested reader to explore how a particular topic is dealt with in different sections of the guidelines.
Toward the back of this report, following the guidelines is the reference list. Following the reference list is a glossary. The glossary defines word usage in the guidelines, for those words that are used here differently or more narrowly than in the general literature on user interface design. There is no question that we need more consistent terminology in this field.
Following the glossary is a list of the titles for all 944 guidelines, which may help a reader who is trying to find guidelines that pertain to a particular topic.
Following the list of guideline titles, and concluding this report is a topical index of the guidelines material. That index is intended to help readers find guidelines on a particular subject, independently of the functional organization that has been imposed on the guidelines material.
These notes on organization and format should serve to allow a student of the subject to skim the guidelines material and find information on different topics. For those readers who seek to apply the guidelines in software design, some further comments are needed.
Not all of the guidelines proposed here can be applied in designing any particular system. For any particular system application, some of the guidelines will be relevant and some will not. In a recent survey of guidelines application (Mosier and Smith, 1986), respondents indicated that they actually applied only 40 percent of the guidelines published in a previous report.
There is another problem to consider. Design guidelines such as those proposed here must be generally worded so that they might apply to many different system applications. Thus generally-worded guidelines must be translated into specific design rules before they can actually be applied.
The process of selecting relevant guidelines for application and translating them into specific design rules is referred to here as "tailoring". Who will do this guidelines tailoring? It should be the joint responsibility of system analysts and human factors specialists assessing design requirements, of software designers assessing feasibility, and of their managers. It may also be helpful to include representatives of the intended system users in this process, to ensure that proposed design features will meet operational requirements. To simplify discussion, we shall call all of these persons "designers".
As a first step in guidelines tailoring, a designer must review this report in order to identify those guidelines that are relevant. For example, if an application will require menus, then the 36 guidelines in Section 3.1.3 dealing with Menu Selection are potentially relevant. For a large information system, the list of relevant guidelines may be quite large.
Once all relevant guidelines have been identified, a designer must review them and decide which ones actually to apply. There are two reasons why a designer might not wish to apply all relevant guidelines. First, for any given application some guidelines may conflict, and the designer must therefore choose which are more important. Second, budgetary and time restrictions may force the designer to apply only the most important guidelines -- those that promise to have the greatest effect on system usability.
As noted above, because guidelines are intended for use on a variety of systems they are worded in general terms. Before a guideline can actually be applied it must be translated into specific design rules. For instance, a guideline which states that displays should be consistently formatted might be translated into design rules that specify where various display features should appear, such as the display title, prompts and other user guidance, error messages, command entries, etc.
Any guideline can have different possible translations. A guideline which states that each display should be uniquely identified could be translated into a design rule that display titles will be bolded and centered in the top line of the display. Or it could be translated into a design rule that display titles will be capitalized in the upper left corner of the display.
What would happen if guidelines were not translated into design rules, but instead were given directly to interface designers? If designers do not decide as a group what design rules will be used, then each designer will decide separately in the course of applying guidelines. The result will surely be an inconsistent design.
After design rules have been specified for each selected guideline, those rules should be documented for reference by software designers and others involved in system development. Documentation of agreed rules, subject to periodic review and revision as necessary, will help coordinate the design process. Documented rules can then be applied consistently for a given application. With appropriate modifications, rules adopted for one application might later be used for other applications.
In the course of design, it may be determined that a particular design rule cannot be used. Therefore, some means must be provided to deal with exceptions. If a design rule is not appropriate for one particular display, then an exception can be made by whoever has been appointed to make such decisions. But if a design rule cannot be implemented at all, perhaps due to other design constraints, then all designers for that particular system must be notified, and perhaps another design rule must be substituted.
Finally, after the design is complete, it must be evaluated against the original design requirements to ensure that all design rules have indeed been followed. To help in the exception process and in the evaluation process, it may be useful to assign different weights to the various rules, indicating which are more important than others. Such weighting will help resolve the trade-offs that are an inevitable part of the design process.
If guidelines are applied in the way described here, there are some significant implications for the role of guidelines in system development. Generally stated guidelines should be offered to designers as a potential resource, rather than imposed as a contractual design standard (Smith, 1986). It is only specifically worded design rules that can be enforced, not guidelines.
Design rules can be derived from the guidelines material, but that conversion from guidelines to rules should be performed as an integral part of the design process, serving to focus attention on critical design issues and to establish specific design requirements. Once agreed design rules are established, those rules can be maintained and enforced by the managers of system development projects.
Specific design rules probably cannot be imposed effectively at the outset of system development by some external agency -- by a sponsoring organization or by a marketing group. It is the process of establishing design rules that should be imposed, rather than the rules themselves. A software design contractor might reasonably be required to establish rules for the design of user interface software, subject to review by the contracting agency. Available guidelines could be cited as a potentially useful reference for that purpose.
Some other cautionary comments about the application of guidelines deserve consideration here. Guidelines in themselves cannot assure good design for a variety of reasons (Thimbleby, 1985). Guidelines cannot take the place of experience. An experienced designer, one skilled in the art, might do well without any guidelines. An inexperienced designer might do poorly even with guidelines. Few designers will find time to read an entire book of guidelines. If they do, they will find it difficult to digest and remember all of the material. If guidelines and/or the rules derived from guidelines are to be helpful, they must be kept continually available for ready reference.
Guidelines cannot take the place of expert design consultants, or at least not entirely. A design expert will know more about a specific topic than can be presented in the guidelines. An expert will know what questions to ask, as well as many of the answers. An expert will know how to adapt generally-stated guidelines to the specific needs of a particular system design application. An expert will know how to trade off the competing demands of different guidelines, in terms of operational requirements.
For maximum effectiveness, guideline tailoring must take place early in the design process before any actual design of user interface software. In order to tailor guidelines, designers must have a thorough understanding of task requirements and user characteristics. Thus task analysis is a necessary prerequisite of guidelines tailoring.
The result of guidelines application will be a design for user interface software that may incorporate many good recommendations. However, even the most careful design will require testing with actual users in order to confirm the value of good features and discover what bad features may have been overlooked. Thus prototype testing must follow initial design, followed in turn by possible redesign and operational testing.
Indeed, testing is so essential for ensuring good design that some experts advocate early creation of an operational prototype to evaluate interface design concepts interactively with users, with iterative design changes to discover what works best (Gould and Lewis, 1983). But prototyping is no substitute for careful design. Prototyping will allow rapid change in a proposed interface; however, unless the initial design is reasonably good, prototyping may not produce a usable final design.
Considering the system development process overall, guidelines application will not necessarily save work in user interface design, and in fact may entail extra work, at least in the initial stage of establishing design rules. But guidelines application should help produce a better user interface. Because guidelines are based on what is known about good design, the resulting user interface is more likely to be usable. Certainly the common application of design rules by all designers working on a system should result in more consistent user interface design. And the single objective on which experts agree is design consistency.
Anyone involved in compilation of design guidelines must begin and end by acknowledging the significant contributions of other people. No one person, no matter how wise, can know everything about the complexities of user interface design. Nor will any one person have the perfect judgment and find the perfect words to express that knowledge to an interface designer. Thus when we propose guidelines we must build upon the work of others.
That is a good thing. All design guidelines are necessarily based in some degree on judgment. Thus guidelines development must properly be a collaborative effort. The collective judgment of many people will often prove sounder than the ideas of just one person.
When many people contribute to guidelines development, we must find ways to acknowledge that contribution. One way is to cite previously published papers that pertain to the guidelines. Citations in this report are represented in the reference list that follows. But in the next several pages we also try to acknowledge more direct contributions to our work.
Many of the user interface design guidelines proposed in this report were not invented here, but derive from the ideas of other people. Where the idea for a guideline came from a particular source, an appropriate reference citation has been included for that guideline. Such citation offers credit where credit is due. More importantly, cited references may permit a reader who questions a particular guideline to explore its antecedents, perhaps to gain a better understanding of what is intended.
Citing an external reference in connection with a guideline does not necessarily mean that there is convincing data to support a guideline. Although the references cited here all contain worth-while ideas, only some of these references report results from systematic data collection.
Furthermore, citation of references does not necessarily mean that their authors would agree with the wording of guidelines presented here. In some instances, an idea has been borrowed intact. In many more instances, however, ideas have been modified, sometimes drastically, perhaps beyond the intent of their original authors.
In this report, in both the text and the guidelines, citations of specific references are in conventional form, showing author(s) and publication date. Those references are listed in the pages that follow. The particular format used here for citation and listing of references conforms in most respects to the standard referencing practice recently adopted by the Human Factors Society (1984).
However, four reference sources are used generally throughout the guidelines. Those sources are cited so frequently that they have been indicated simply by initials:
These four general references share a common characteristic -- like this report, they are all collections of design guidelines. None of these four general references provide supporting data for their design recommendations, and they need not be consulted for that purpose. The two early reports (EG and PR) have served as a fertile source of ideas for our current guidelines; where those reports are cited here, it means that their early recommendations are still judged to be correct. The two more recent reports (BB and MS) have drawn heavily from common sources, including previous editions of the guidelines proposed here; where those reports are cited, it means that their authors have made similar recommendations to those presented here.
The 1975 IBM report by Engel and Granda (EG) was the first widely recognized compilation of user interface design guidelines. That report has provided inspiration and has served as a seminal reference for others working in this field.
The 1975 BBN report by Pew and Rollins (PR) represents an admirable attempt to propose design guidelines for one particular system application. Its recommendations, however, can readily be generalized for broader application.
The 1983 report by Lin Brown and his colleagues at Lockheed (BB) is a good example of user interface guidelines developed for use as an in-house design standard, but which have also been made available for public reference.
None of these three reports are distributed by government sources such as the National Technical Information Service. However, these reports may be obtained by direct request from their authors.
MIL-STD-1472C (MS), in its current revision, is the US military standard for human engineering in system design. That standard has been cited here 237 times, for 209 guidelines. It is important to emphasize that guidelines do not carry the same weight as design standards. Guidelines are proposed here for optional application in system development, rather than to be imposed contractually. However, there is some considerable correspondence in content between these guidelines and the current military standard.
Not all ideas for guidelines come from published references. Some of the guidelines proposed here have resulted from discussion with professional colleagues. And the wording of all guidelines has been improved through critical review of earlier published versions. Over the past several years, a number of people have contributed suggestions for improving the guidelines material:
Some of these people have offered specific suggestions. Some have contributed more general comments about the wording or formatting of the guidelines material. But all have shown a serious concern with trying to improve the guidelines and make them more useful to designers of user interface software. Probably not one of these people would agree with all of the guidelines proposed here; in matters of judgment we can seldom achieve unanimity. But where the guidelines seem good, these are people who deserve our thanks.
Several people on this list deserve extra thanks. Our colleagues at MITRE have continued to serve as an in-house working group for guidelines review. Special thanks are due to Nancy Goodwin for her thorough revision of the guidelines on data transmission; to Jeanne Fleming and James Foley for their detailed comments on guidelines proposed for graphics entry and display; and to Dorothy Antetomaso for her review of the guidelines on data security. Special thanks for past contributions are due to Arlene Aucella who helped prepare the 1983 guidelines report; and to MITRE supervisor Marlene Hazle for her early encouragement and support of guidelines compilation.
Albert, A. E. (1982). The effect of graphic input devices on performance in a cursor positioning task. In Proceedings of the Human Factors Society 26th Annual Meeting (pp. 54-58). Santa Monica, CA: Human Factors Society.
Aretz, A. J., and Kopala, C. J. (1981). Automatic return in multifunction control logic. In Proceedings of the Human Factors Society 25th Annual Meeting (pp. 254-256). Santa Monica, CA: Human Factors Society.
Badre, A. N. (1984). Designing transitionality into the user-computer interface. In Salvendy, G. (Ed.), Human-Computer Interaction (pp. 27-34). Amsterdam: Elsevier Science Publishers.
Barnard, P. J., Hammond, N. V., MacLean, A., and Morton, J. (1982). Learning and remembering interactive commands in a text-editing task. Behaviour and Information Technology, 1, 347-358.
Barnard, P., and Marcel, T. (1984). Representation and understanding in the use of symbols and pictograms. In Easterby, R., and Zwaga, H. (Eds.), Information Design (pp. 37-75). Chichester: Wiley.
Bauer, D. W., and Eddy, J. K. (1986). The representation of command language syntax. Human Factors, 28, 1-10.
Bertelson, P., Boons, J.-P., and Renkin, A. (1965). Vitesse libre et vitesse imposee dans une tache simulant le tri mechanique de la correspondence (Self pacing and imposed pacing in a task simulating automated postal sorting). Ergonomics, 8, 3-22.
Bertoni, P. (1982, June 22). Of slipped disks . . . . Boston Globe.
Bewley, W. L., Roberts, T. L., Schroit, D., and Verplank, W. L. (1983). Human factors testing in the design of Xerox's 8010 "Star" office workstation. In Proceedings of CHI'83 Human Factors in Computing Systems (pp. 72-77). New York: Association for Computing Machinery.
Bigelow, C. (1985, July). Proceedings of the Typography Interest Group ACM CHI'85. SIGCHI Bulletin, 17(1), 10-11.
Billingsley, P. A. (1982). Navigation through hierarchical menu structures: Does it help to have a map? In Proceedings of the Human Factors Society 26th Annual Meeting (pp. 103-107). Santa Monica, CA: Human Factors Society.
BB = Brown, C. M., Brown, D. B., Burkleo, H. V., Mangelsdorf, J. E., Olsen, R. A., and Perkins, R. D. (1983, June 15). Human Factors Engineering Standards for Information Processing Systems (LMSC-D877141). Sunnyvale, CA: Lockheed Missiles and Space Company.
Bruder, J., Moy, M., Mueller, A., and Danielson, R. (1981). User experience and evolving design in a local electronic mail system. In Uhlig, R. P. (Ed.), Computer Message Systems (pp. 69-78). New York: North-Holland.
Bury, K. F., Boyle, J. M., Evey, R. J., and Neal, A. S. (1982). Windowing versus scrolling on a visual display terminal. Human Factors, 24, 385-394.
Butterbaugh, L. C., and Rockwell, T. H. (1982). Evaluation of alternative alphanumeric keying logics. Human Factors, 24, 521-533.
Campbell, A. J., Marchetti, F. M., and Mewhort, D. J. K. (1981). Reading speed and text production: A note on right-justification techniques. Ergonomics, 24, 633-640.
Carroll, J. M. (1982). Learning, using and designing filenames and command paradigms. Behaviour and Information Technology, 1, 327-346.
Chao, B. P. (1985). Evaluation of a video storage system for intrusion detections. In Proceedings of the Human Factors Society 29th Annual Meeting (pp. 417-421). Santa Monica, CA: Human Factors Society.
Cleveland, W. S. (1985). The Elements of Graphing Data. Monterey, CA: Wadsworth Advanced Books and Software.
Cohill, A. M., and Williges, R. C. (1985). Retrieval of HELP information for novice users of interactive computer systems. Human Factors, 27, 335-343.
CSC-STD-002-85 (1985, 12 April). Department of Defense Password Management Guideline. Fort George G. Meade, MD: Department of Defense Computer Security Center.
Dean, M. (1982). How a computer should talk to people. IBM Systems Journal, 21, 424-453.
Demers, R. A. (1981). System design for usability. Communications of the ACM, 24, 494-501.
Deutsch, D. (1981). Design of a message format standard. In Uhlig, R. P. (Ed.), Computer Message Systems (pp. 199-220). New York: North-Holland.
Deutsch, D. P. (1984). Implementing distribution lists in computer-based message systems. In Smith, H. T. (Ed.), Computer-Based Message Services (pp. 3-13). New York: North-Holland.
Dray, S. M., Ogden, W. G., and Vestewig, R. E. (1981). Measuring performance with a menu-selection human-computer interface. In Proceedings of the Human Factors Society 25th Annual Meeting (pp. 746-748). Santa Monica, CA: Human Factors Society.
Duchnicky, R. L., and Kolers, P. A. (1983). Readability of text scrolled on visual display terminals as a function of window size. Human Factors, 25, 683-692.
Dunn, C. (1973). The use of real-time simulation by means of animation film as an analytical design tool in certain spatio-temporal situations. Ergonomics, 16, 515-519.
Durding, B. M., Becker, C. A., and Gould, J. D. (1977). Data organization. Human Factors, 19, 1-14.
Dwyer, B. (1981). A user-friendly algorithm. Communications of the ACM, 24, 556-561.
Dzida, W. (1981). Computer mediated messaging for interactive purposes. In Uhlig, R. P. (Ed.), Computer Message Systems (pp. 79-87). New York: North-Holland.
Ehrenreich, S. L. (1981). Query languages: Design recommendations derived from the human factors literature. Human Factors, 23, 709-725.
Ehrenreich, S. L. (1985). Computer abbreviations: Evidence and synthesis. Human Factors, 27, 143-156.
Ehrenreich, S. L., and Porcu, T. (1982). Abbreviations for automated systems: Teaching operators the rules. In A. Badre and B. Shneiderman (Eds.), Directions in Human/Computer Interaction (pp. 111-135). Norwood, NJ: Ablex Publishing.
Elkerton, J., Williges, R. C., Pittman, J. A., and Roach, J. (1982). Strategies of interactive file search. In Proceedings of the Human Factors Society 26th Annual Meeting (pp. 83-86). Santa Monica, CA: Human Factors Society.
EG = Engel, S. E., and Granda, R. E. (1975, December). Guidelines for Man/Display Interfaces (Technical Report TR 00.2720). Poughkeepsie, NY: IBM.
Foley, J. D., and Van Dam, A. (1982). Fundamentals of Interactive Computer Graphics. Reading, MA: Addison-Wesley.
Foley, J. D., and Wallace, V. L. (1974). The art of natural graphic man-machine conversation. Proceedings of the IEEE, 62, 462-471.
Foley, J. D., Wallace, V. L., and Chan, P. (1984, November). The human factors of computer graphics interaction techniques. IEEE Computer Graphics and Applications, 4(11), 13-48.
Gade, P. A., Fields, A. F., Maisano, R. E., Marshall, C. F., and Alderman, I. N. (1981). Data entry performance as a function of method and instructional strategy. Human Factors, 23, 199-210.
Galitz, W. O. (1980). Human Factors in Office Automation. Atlanta, GA: Life Office Management Association.
Garcia-Luna, J. J., and Kuo, F. L. (1981). Addressing and directory systems for large computer mail systems. In Uhlig, R. P. (Ed.), Computer Message Systems (pp. 297-313). New York: North-Holland.
Gardan, Y., and Lucas, M. (1984). Interactive Graphics in CAD. London: Kogan Page.
Geer, C. W. (1981). Human Engineering Procedures Guide (Technical Report AFAMRL-TR-81-35). Wright-Patterson Air Force Base, OH: Air Force Aerospace Medical Research Laboratory. (NTIS No. AD A108 643)
Geiser, G., Schumacher, W., and Berger, L. (1982). Talking keyboard for user guidance in multifunction systems. In Proceedings of the Human Factors Society 26th Annual Meeting (pp. 436-439). Santa Monica, CA: Human Factors Society.
Gilfoil, D. M. (1982). Warming up to computers: A study of cognitive and affective interaction over time. In Proceedings of Conference on Human Factors in Computer Systems (pp. 245-250). Washington, DC: Association for Computing Machinery.
Good, M. D., Whiteside, J. A., Wixon, D. R., and Jones, S. J. (1984). Building a user-derived interface. Communications of the ACM, 27, 1032-1043.
Goodwin, N. C. (1974, March). INTRO -- In Which a Smart Terminal Teaches Its Own Use (Technical Report ESD-TR-74-374). Hanscom Air Force Base, MA: USAF Electronic Systems Division. (NTIS No. AD A126 205)
Goodwin, N. C. (1975). Cursor positioning on an electronic display using lightpen, lightgun, or keyboard for three basic tasks. Human Factors, 17, 289-295.
Goodwin, N. C. (1980). A user-oriented evaluation of computer-aided message handling. In Proceedings of the Human Factors Society 24th Annual Meeting (pp. 585-589). Santa Monica, CA: Human Factors Society.
Goodwin, N. C. (1982). Effect of interface design on usability of message handling systems. In Proceedings of the Human Factors Society 26th Annual Meeting (pp. 69-73). Santa Monica, CA: Human Factors Society.
Goodwin, N. C. (1983). Designing a multipurpose menu driven user interface to computer based tools. In Proceedings of the Human Factors Society 27th Annual Meeting (pp. 816-820). Santa Monica, CA: Human Factors Society.
Goodwin, N. C. (1984). Building a usable office support system from diverse components. In Shackel, B. (Ed.), Human-Computer Interaction INTERACT'84 (pp. 577-581). Amsterdam: Elsevier Science Publishers.
Gould, J. D. (1981). Composing letters with computer-based text editors. Human Factors, 23, 593-606.
Gould, J. D., and Grischkowsky, N. (1984). Doing the same work with hard copy and with cathode-ray tube (CRT) computer terminals. Human Factors, 26, 323-337.
Gould, J. D., and Lewis, C. (1983). Designing for usability -- Key principles and what designers think. In Proceedings of CHI'83 Human Factors in Computing Systems (pp. 50-53). New York: Association for Computing Machinery.
Granda, R. E., Teitelbaum, R. C., and Dunlap, G. L. (1982). The effect of VDT command line location on data entry behavior. In Proceedings of the Human Factors Society 26th Annual Meeting (pp. 621-624). Santa Monica, CA: Human Factors Society.
Gregory, M., and Poulton, E. C. (1970). Even versus uneven right-hand margins and the rate of comprehension in reading. Ergonomics, 13, 427-434.
Grudin, J., and Barnard, P. (1984). The cognitive demands of learning and representing command names for text editing. Human Factors, 26, 407-422.
Hakkinen, M. T., and Williges, B. H. (1984). Synthesized warning messages: Effects of an alerting cue in single- and multiple-function voice synthesis systems. Human Factors, 26, 185-195.
Hamill, B. W. (1980). Experimental document design: Guidebook organization and index formats. In Proceedings of the Human Factors Society 24th Annual Meeting (pp. 480-483). Santa Monica, CA: Human Factors Society.
Hannemyr, G., and Innocent, P. R. (1985). A network user interface: Incorporating human factors guidelines into the ISO standard for open systems interconnection. Behaviour and Information Technology, 4, 309-326.
Hanson, R. H., Payne, D. G., Shiveley, R. J., and Kantowitz, B. H. (1981). Process control simulation research in monitoring analog and digital displays. In Proceedings of the Human Factors Society 25th Annual Meeting (pp. 154-158). Santa Monica, CA: Human Factors Society.
Hartley, J., Young, M., and Burnhill, P. (1975). On the typing of tables. Applied Ergonomics, 6, 39-42.
Haskett, J. A. (1984). Pass-algorithms: A user validation scheme based on knowledge of secret algorithms. Communications of the ACM, 27, 777-781.
Hayes, P. (1985). A panel on the utility of natural languages. In Proceedings of CHI'85 Conference on Human Factors in Computing Systems (p. 19). New York: Association for Computing Machinery.
Hirsh-Pasek, K., Nudelman, S., and Schneider, M. L. (1982). An experimental evaluation of abbreviation schemes in limited lexicons. Behaviour and Information Technology, 1, 359-369.
Hollingsworth, S. R., and Dray, S. M. (1981). Implications of post-stimulus cueing of response options for the design of function keyboards. In Proceedings of the Human Factors Society 25th Annual Meeting (pp. 263-265). Santa Monica, CA: Human Factors Society.
Hopkin, V. D., and Taylor, R. M. (1979). Human Factors in the Design and Evaluation of Aviation Displays (Report AGARD-AG-225). Neuilly sur Seine: NATO Advisory Group for Aerospace Research and Development. (NTIS No. AD A076 631)
Human Factors Society. (1984). Author's Guide. Santa Monica, CA.
Keister, R. S., and Gallaway, G. R. (1983). Making software user friendly: An assessment of data entry performance. In Proceedings of the Human Factors Society 27th Annual Meeting (pp. 1031-1034). Santa Monica, CA: Human Factors Society.
Koved, L., and Shneiderman, B. (1986). Embedded menus: Selecting items in context. Communications of the ACM, 29, 312-318.
Krohn, G. S. (1983). Flowcharts used for procedural instructions. Human Factors, 25, 573-581.
Lee, A., and Lochovsky, F. H. (1983). Enhancing the usability of an office information system through direct manipulation. In Proceedings of CHI'83 Human Factors in Computing Systems (pp. 130-134). New York: Association for Computing Machinery.
Liebelt, L. S., McDonald, J. E., Stone, J. D., and Karat, J. (1982). The effect of organization on learning menu access. In Proceedings of the Human Factors Society 26th Annual Meeting (pp. 546-550). Santa Monica, CA: Human Factors Society.
Limanowski, J. J. (1983). On-line documentation systems: History and issues. In Proceedings of the Human Factors Society 27th Annual Meeting (pp. 1027-1030). Santa Monica, CA: Human Factors Society.
Magers, C. S. (1983). An experimental evaluation of on-line HELP for non-programmers. In Proceedings of CHI'83 Human Factors in Computing Systems (pp. 277-281). New York: Association for Computing Machinery.
Martin, J. (1973). Design of Man-Computer Dialogues. Englewood Cliffs, NJ: Prentice-Hall.
Martin, J. (1978). The Wired Society. Englewood Cliffs, NJ: Prentice-Hall.
McDonald, J. E., Stone, J. D., and Liebelt, L. S. (1983). Searching for items in menus: The effects of organization and type of target. In Proceedings of the Human Factors Society 27th Annual Meeting (834-837). Santa Monica, CA: Human Factors Society.
Michard, A. (1982). Graphical presentation of boolean expressions in a database query language: Design notes and an ergonomic evaluation. Behaviour and Information Technology, 1, 279-288.
MIL-H-48655B. (1979, 31 January). Military Specification: Human Engineering Requirements for Military Systems, Equipment and Facilities. Washington, DC: Department of Defense.
MIL-STD-12D. (1981, 29 May). Abbreviations for Use on Drawings, and in Specifications, Standards and Technical Documents. Washington, DC: Department of Defense.
MIL-STD-1472B. (1974, 31 December). Military Standard: Human Engineering Design Criteria for Military Systems, Equipment and Facilities. Washington, DC: Department of Defense.
MS = MIL-STD-1472C, Revised. (1983, 1 September). Military Standard: Human Engineering Design Criteria for Military Systems, Equipment and Facilities. Washington, DC: Department of Defense.
Miller, D. P. (1981). The depth/breadth tradeoff in hierarchical computer menus. In Proceedings of the Human Factors Society 25th Annual Meeting (pp. 296-300). Santa Monica, CA: Human Factors Society.
Miller, R. B. (1968). Response time in user-system conversational transactions. In Proceedings of the AFIPS Fall Joint Computer Conference, 33, 267-277.
Milroy, R., and Poulton, E. C. (1978). Labelling graphs for improved reading speed. Ergonomics, 21, 55-61.
Mooers, C. D. (1983). Changes that users demanded in the user interface to the Hermes message system. In Proceedings of CHI'83 Human Factors in Computing Systems (pp. 88-92). New York: Association for Computing Machinery.
Morrill, C. S. (1967). Computer-aided instruction as part of a management information system. Human Factors, 9, 251-256.
Morrill, C. S., and Davies, B. L. (1961). Target tracking and acquisition in three dimensions using a two-dimensional display surface. Journal of Applied Psychology, 45, 214-221.
Morrill, C. S., Goodwin, N. C., and Smith, S. L. (1968). User input mode and computer-aided instruction. Human Factors, 10, 225-232.
Moses, F. L., and Ehrenreich, S. L. (1981). Abbreviations for automated systems. In Proceedings of the Human Factors Society 25th Annual Meeting (pp. 132-135). Santa Monica, CA: Human Factors Society.
Mosier, J. N., and Smith, S. L. (1986). Application of guidelines for designing user interface software. Behaviour and Information Technology, 5, 39-46.
Muter, P., Latremouille, S. A., Treurniet, W. C., and Beam, P. (1982). Extended readings of continuous text on television screens. Human Factors, 24, 501-508.
Muter, P., and Mayson, C. (1986). The role of graphics in item selection from menus. Behaviour and Information Technology, 5, 89-95.
Myers, B. A. (1985). The importance of percent-done progress indicators for computer-human interfaces. In Proceedings of CHI'85 Human Factors in Computing Systems (pp. 11-17). New York: Association for Computing Machinery.
NASA (National Aeronautics and Space Administration). (1979, January). Spacelab Experiment Computer Application Software (ECAS) Display Design and Command Usage Guidelines (Report MSFC-PROC-711). George C. Marshall Space Flight Center, AL: Author.
Neal, A. S., and Darnell, M. J. (1984). Text-editing performance with partial-line, partial-page, and full-page displays. Human Factors, 26, 431-441.
Neal, A. S., and Emmons, W. H. (1984). Error correction during text entry with word-processing systems. Human Factors, 24, 443-447.
Nickerson, R. S., and Pew, R. W. (1971, June). Oblique steps toward the human-factors engineering of interactive computer systems. Published as an Appendix in M. C. Grignetti, D. C. Miller, R. S. Nickerson and R. W. Pew, Information Processing Models and Computer Aids for Human Performance (Report No. 2190). Cambridge, MA: Bolt, Beranek and Newman. (NTIS No. AD A732 913)
Noyes, L. (1980). The positioning of type on maps: The effect of surrounding material on word recognition. Human Factors, 22, 353-360.
Pakin, S. E., and Wray, P. (1982). Designing screens for people to use easily. Data Management, 20(7), 36-41.
Palme, J. (1979). A human-computer interface for non-computer specialists. Software -- Practice and Experience, 9, 741-747.
Parsons, H. M. (1970). The scope of human factors in computer-based data processing systems. Human Factors, 12, 165-175.
Penniman, W. D. (1979, May). Past chairman's message. SIG Newsletter No. UOI-10. Washington, DC: American Society for Information Science.
PR = Pew, R. W., and Rollins, A. M. (1975). Dialog Specification Procedures (Report 3129, revised). Cambridge, MA: Bolt Beranek and Newman.
Phillips R. J. (1982). An experimental investigation of layer tints for relief maps in school atlases. Ergonomics, 25, 1143-1154.
Poller, M. F., and Garter, S. F. (1984). The effects of modes on text editing by experienced editor users. Human Factors, 26, 449-462.
Price, W. L. (1981). Encryption in computer networks and message systems. In Uhlig, R. P. (Ed.), Computer Message Systems (pp. 413-423). New York: North-Holland.
Radin, D. I. (1984). Effects of command language punctuation on human performance. In Salvendy, G. (Ed.), Human-Computer Interaction (pp. 177-180). Amsterdam: Elsevier Science Publishers.
Ramsey, H. R., and Atwood, M. E. (1979, September). Human Factors in Computer Systems: A Review of the Literature (Technical Report SAI-79-111-DEN). Englewood, CO: Science Applications, Inc. (NTIS No. AD A075 679)
Ramsey, H. R., and Atwood, M. E. (1980). Man-computer interface design guidance: State of the art. In Proceedings of the Human Factors Society 24th Annual Meeting (pp. 85-89). Santa Monica, CA: Human Factors Society.
Ramsey, H. R., Atwood, M. E., and Kirshbaum, P. J. (1978, May). A Critically Annotated Bibliography of the Literature of Human Factors in Computer Systems (Technical Report SAI-78-070-DEN). Englewood, CO: Science Applications, Inc. (NTIS No. AD A058 081)
Reisner, P. (1977). Use of psychological experimentation as an aid to development of a query language. IEEE Transactions on Software Engineering, SE-3, 218-229.
Reisner, P. (1981). Formal grammar and human factors design of an interactive graphics system. IEEE Transactions on Software Engineering, SE-7, 229-240.
Roberts, T. L., and Moran, T. P. (1983). The evaluation of text editors: methodology and empirical results. Communications of the ACM, 26, 265-283.
Rogers, W. H., and Moeller, G. (1984). Comparison of abbreviation methods: Measures of preference and decoding performance. Human Factors, 26, 49-59.
Savage, R. E., Habinek, J. K., and Blackstad, N. J. (1982). An experimental evaluation of input field and cursor combinations. In Proceedings of the Human Factors Society 26th Annual Meeting (pp. 629-633). Santa Monica, CA: Human Factors Society.
Schutz (1961) An evaluation of formats for graphic trend displays - Experiment II. Human Factors, 3, 99-107.
Seibel, R. (1972). Data entry devices and procedures. In H. P. Van Cott and R. G. Kinkade (Eds.), Human Engineering Guide to Equipment Design (pp. 311-344). Washington, DC: U. S. Government Printing Office.
Shinar, D., Stern, H. I., Bubis, G., and Ingram, D. (1985). The relative effectiveness of alternative strategies in menu driven computer programs. In Proceedings of the Human Factors Society 29th Annual Meeting (pp. 645-649). Santa Monica, CA: Human Factors Society.
Shneiderman, B. (1980). Software Psychology: Human Factors in Computer and Information Systems. Cambridge, MA: Winthrop Publishers.
Shneiderman, B. (1981). A note on human factors issues of natural language interaction with database systems. Information Systems, 6, 125-129.
Shneiderman, B. (1982). The future of interactive systems and the emergence of direct manipulation. Behaviour and Information Technology, 1, 237-256.
Shneiderman, B. (1984). Response time and display rate in human performance with computers. Computing Surveys, 16, 265-285.
Sidorsky, R. C., Parrish, R. N., Gates, J. L., and Munger, S. J. (1984, May). Design guidelines for user transactions with battlefield automated systems: Prototype for a handbook (ARI Research Product 84-08). Alexandria, VA: US Army Research Institute. (NTIS No. AD A513 231)
Simpson, C. A., McCauley, M. E., Roland, E. F., Ruth, J. C., and Williges, B. H. (1985). System design for speech recognition and generation. Human Factors, 27, 115-142.
Simpson, C. A., and Williams, D. H. (1980). Response time effects of alerting tone and semantic context for synthesized voice cockpit warnings. Human Factors, 22, 319-330.
Smith, D. C., Irby, C., Kimball, R., and Verplank, B. (1982). Designing the Star user interface. BYTE, 7(4), 242-282.
Smith, H. T. (Ed.) (1984). Computer-Based Message Services. New York: North-Holland.
Smith, S. L. (1962a). Angular estimation. Journal of Applied Psychology, 46, 240-246.
Smith, S. L. (1962b). Color coding and visual search. Journal of Experimental Psychology, 64, 434-440.
Smith, S. L. (1963a). Color coding and visual separability in information displays. Journal of Applied Psychology, 47, 358-364.
Smith, S. L. (1963b). Man-computer information transfer. In J. H. Howard (Ed.), Electronic Information Display Systems (pp. 284-299). Washington, DC: Spartan Books.
Smith, S. L. (1980, June). Requirements definition and design guidelines for the man-machine interface in C3 system acquisition (Technical Report ESD-TR-80-122). Hanscom Air Force Base, MA: USAF Electronic Systems Division. (NTIS No. AD A087 258)
Smith, S. L. (1981a, February). Man-Machine Interface (MMI) Requirements Definition and Design Guidelines: A Progress Report (Technical Report ESD-TR-81-113). Hanscom Air Force Base, MA: USAF Electronic Systems Division. (NTIS No. AD A096 705)
Smith, S. L. (1981b). Exploring compatibility with words and pictures. Human Factors, 23, 305-315.
Smith, S. L. (1982a). "User-system interface". Human Factors Society Bulletin, 25(3), 1.
Smith, S. L. (1982b, April). User-System Interface Design for Computer-Based Information Systems (Technical Report ESD-TR-82-132). Hanscom Air Force Base, MA: USAF Electronic Systems Division. (NTIS No. AD A115 853)
Smith, S. L. (1986). Standards versus guidelines for designing user interface software. Behaviour and Information Technology, 5, 47-61.
Smith, S. L., and Aucella, A. F. (1983a, March). Design Guidelines for the User Interface to Computer-Based Information Systems (Technical Report ESD-TR-83-122). Hanscom Air Force Base, MA: USAF Electronic Systems Division. (NTIS No. AD A127 345)
Smith, S. L., and Aucella, A. F. (1983b). Numbering formats for hierarchic lists. Human Factors, 25, 343-348.
Smith, S. L., Farquhar, B. B., and Thomas, D. W. (1965). Color coding in formatted displays. Journal of Applied Psychology, 49, 393-398.
Smith, S. L., and Goodwin, N. C. (1970). Computer-generated speech and man-computer interaction. Human Factors, 12, 215-223.
Smith, S. L., and Goodwin, N. C. (1971a). Alphabetic data entry via the Touch-Tone pad: A comment. Human Factors, 13, 189-190.
Smith, S. L., and Goodwin, N. C. (1971b). Blink coding for information display. Human Factors, 13, 283-290.
Smith, S. L., and Goodwin, N. C. (1972). Another look at blinking displays. Human Factors, 14, 345-347.
Smith, S. L., and Mosier, J. N. (1984a). Design Guidelines for User-System Interface Software (Technical Report ESD-TR-84-190). Hanscom Air Force Base, MA: USAF Electronic Systems Division. (NTIS No. AD A154 907)
Smith, S. L., and Mosier, J. N. (1984b). The user interface to computer-based information systems: A survey of current software design practice. Behaviour and Information Technology, 3, 195-203.
Smith, S. L., and Thomas, D. W. (1964). Color versus shape coding in information displays. Journal of Applied Psychology, 48, 137-146.
Snowberry, K., Parkinson, S. R., and Sisson, N. (1983). Computer display menus. Ergonomics, 26, 699-712.
Stewart, T. (1980). Communicating with dialogues. Ergonomics, 23, 909-919.
Symons, C. R., and Schweitzer, J. A. (1984). A proposal for an automated access control standard. ACM/SIGCHI Bulletin, 16(1), 17-23.
Tammaro, S. G. (1983). An analysis of the use of computer-based office support tools: User characteristics and usage patterns. In Proceedings of the Human Factors Society 27th Annual Meeting (pp. 882-886). Santa Monica, CA: Human Factors Society.
Thimbleby, H. (1985). Failure in the technical user-interface design process. Computers and Graphics, 9, 187-193.
Thomas, J. C., and Rosson, M. B. (1984). Human factors and synthetic speech. In Shackel, B. (Ed.), Human-Computer Interaction INTERACT'84 (pp. 37-42). Amsterdam: Elsevier Science Publishers.
Thompson, D. A. (1971). Interface design for an interactive information retrieval system: A literature survey and a research system description. Journal of the American Society for Information Science, 22, 361-373.
Trollip, S. R., Sales, G. (1986). Readability of computer-generated fill-justified text. Human Factors, 28, 159-163.
Tucker, J. B. (1984, June). Computer graphics achieves new realism. High Technology, 40-53.
Tufte, E. R. (1983). The Visual Display of Quantitative Information. Cheshire, CT: Graphics Press.
Tullis, T. S. (1981). An evaluation of alphanumeric, graphic, and color information displays. Human Factors, 23, 541-550.
Tullis, T. S. (1983). The formatting of alphanumeric displays: A review and analysis. Human Factors, 25, 657-682.
Uhlig, R. P. (Ed.) (1981). Computer Message Systems. New York: North-Holland.
Weitzman, D. O. (1985). Color coding re-viewed. In Proceedings of the Human Factors Society 29th Annual Meeting (pp 1079-1083). Santa Monica, CA: Human Factors Society.
Whalley, P. C., and Fleming, R. W. (1975). An experiment with a simple recorder of reading behaviour. Programmed Learning and Educational Technology, 12, 120-124.
Whitfield, D., Ball R. G., and Bird, J. M. (1983). Some comparisons of on-display and off-display touch input devices for interaction with computer generated displays. Ergonomics, 26, 1033-1053.
Williamson, H., and Rohlfs, S. (1981). The user interface design process. In Uhlig, R. P. (Ed.), Computer Message Systems (pp. 427-445). New York: North-Holland.
Williges, R. C. (1984). Design of human-computer dialogues. In Salvendy, G. (Ed.), Human-Computer Interaction (pp. 35-42). Amsterdam: Elsevier Science Publishers.
Woodson, W. E. (1981). Human Factors Design Handbook. New York: McGraw-Hill.
Wright, P. (1977). Presenting technical information: A survey of research findings. Instructional Science, 6, 93-134.
Wright, P., and Reid, F. (1973). Written information: Some alternatives to prose for expressing the outcomes of complex contingencies. Journal of Applied Psychology, 57, 160-166.
Zoltan-Ford, E. (1984). Reducing variability in natural-language interactions with computers. In Proceedings of the Human Factors Society 28th Annual Meeting (pp 768-772). Santa Monica, CA: Human Factors Society.
A comprehensive glossary of words dealing with the user interface to computer systems could contain hundreds of terms. Such a glossary would be difficult to compile, because terms are often used inconsistently. The glossary presented here is not intended to be a comprehensive reference. Instead, it simply attempts to clarify the meanings of some of the terms used in this report. A term may be included in this glossary if it is used inconsistently in the general literature, or perhaps if its meaning in this report is more narrow than its commonly understood meaning.
Preparing header information to specify the destination for data to be transmitted.
A characteristic of a displayed element such as color, bolding, size, pattern or font, which can be specified by a user.
A capability that returns a user to the last previous display in a defined transaction sequence.
A graphic figure in which numeric quantities are represented by the linear extent of parallel lines (or bars). Bar graphs are useful for showing a comparative measure for separate entities or for a variable sampled at discrete intervals.
A capability that regenerates (or re-initializes) the current display without processing or retaining any changes made by the user.
A grouping of data values along a dimension defined for operational purposes. For example, an air traffic controller might wish to implement the same procedures for all aircraft with speeds in the category of 600 to 800 knots. See also "value".
A type of dialogue in which a user composes control entries, possibly with prompting by the computer.
Displaying an indication of previous user actions or computer processing that will affect the results of current actions, in order to help a user predict how the system will respond.
User input for sequence control, such as function key activation, menu selection, command entry, etc.
Ensuring that transmitted data are delivered, saved until they can be delivered, or returned to the sender. A computer will usually control transmission, but users may need information about that process.
A marker on the display screen that indicates the current position for attention, which may designate a displayed item. A cursor might be positioned under computer control or by the user.
A graphed line that shows the relation between sets of data defined by two continuous variables. On a curve, data points are sufficiently close to appear as a smooth line.
The raw materials from which a user extracts information. Data may include numbers, words, pictures, etc.
A collection of data that is stored in the computer.
Output of data from a computer to its users. Generally, this phrase denotes visual output, but it may be qualified to indicate a different modality, such as an "auditory display".
User input of data for computer processing, and computer responses to such inputs.
An area of the display screen reserved for user entry of a data item.
A displayed word or phrase that serves as a prompt for entering an item in a data field. Such a label usually cannot be changed by a user.
A set of characters of fixed or variable length that forms a single unit of data. Examples of a data item might be a person's last name, or a ZIP code. Sometimes a data item might contain only a single character. Data items may be entered by a user or may be supplied by the computer.
Functional capabilities that guard against unauthorized data access and tampering, and data loss due to user errors or computer failure.
Computer-mediated communication among system users, and also with other systems. Transmitted data may include numbers, words, pictures, etc.
Functional capabilities that check data entry items for correct content or format, as defined by software logic.
A predetermined, frequently used, value for a data or control entry, intended to reduce required user entry actions.
A special form of a picture in which details are only shown if they are necessary for the performance of a task. For example, an electrical wiring diagram for a building would show wiring but not necessarily furniture or plumbing.
A structured series of interchanges between a user and a computer. A dialogue can be initiated by a computer (e.g., question and answer) or by a user (e.g., command language).
A scale or categorization along which data may vary, taking different values at different times. For example, relevant dimensions for an aircraft might include its heading, speed and altitude. See also "variable".
User entry of directional data (azimuth, bearing, heading) on a display.
See "data display".
Procedures by which a user can specify what data are shown, and how.
The organization of different types of data in a display, including information about the data such as labels, and other user guidance such as prompts, error messages, etc.
User control of data coverage by display movement, including paging, scrolling, offset, expansion, etc.
Refers to the specification of data outputs, either by a user or automatically.
Designing displays to meet the specific task needs of a user, rather than providing a general display which can be used for many purposes.
Regeneration of changing data to show current status, by user request or automatically by the computer.
Using computer aids to specify lines and other graphic elements, in order to create a pictorial representation.
An explicit user action that effects computer processing of user entries. For example, after typing a series of numbers, a user might press an ENTER key that will add them to a data base, subject to data validation.
See "data entry" or "control entry".
Interface design to facilitate the detection and correction of user errors.
See "data field".
A collection of data, treated as a single unit, that is stored in the computer.
A diagram that illustrates sequential relations among elements or events. Flowcharts are often shown as boxes connected by arrows.
See "display format".
A type of dialogue in which the computer displays forms containing labeled fields for data entry by a user.
See "display framing".
A computer-supported capability provided to users as an aid for task performance. Examples of functions are position designation or direction designation.
A key whose activation will effect a control entry.
Data specially formatted to show spatial, temporal, or other relations among data sets.
A component part of a graphic display, such as a line, a circle, or a scale.
A kind of dialogue which permits a user to select displayed control elements by pointing and other direct manipulation.
A printed paper display output by the computer.
A capability that displays information upon user request for on-line guidance. HELP may inform a user generally about system capabilities, or may provide more specific guidance in information handling transactions.
Emphasizing displayed data or format features in some way, e.g., through the use of underlining, bolding, or inverse video.
Organized data that users need to successfully perform their tasks. Information serves as an answer to a user's question about data. It is used here to refer to the effective assimilation of data by a user.
A computer-supported, task-oriented tool designed to help users perform defined information handling tasks.
The process of actually sending a prepared message or data file. Transmission can either be initiated by the computer, or by a system user.
See "control entry" and "data entry".
See "transaction".
See "user-system interface".
Stopping an ongoing transaction in order to redirect the course of the processing. Examples of interrupt options are BACKUP, REVIEW, CANCEL, RESTART.
See "data item".
A set of responsibilities and activities that are defined for each system user.
A title or descriptor that helps a user identify displayed data. See "data field label".
A scaled figure that shows relations among sets of data defined by two continuous variables. On a line graph, data points are connected by straight line segments.
A type of dialogue in which a user selects one item out of a list of displayed alternatives, whether the selection is by pointing, by entry of an associated option code, or by activation of an adjacent function key.
Refers specifically to data that are transmitted as a discrete transaction from one computer user to another along with formal header information, and may sometimes refer loosely to other forms of data transmission. See "data transmission".
A type of dialogue in which a user composes control entries in natural language (e.g., English, Spanish, French) rather than by a more formally constrained command language.
See "user".
See "data Display".
The data appearing at one time on a single display screen.
An orientation for display framing in which a user conceives of the display frame as moving over a fixed array of data. The opposite of scrolling.
A detailed representation of a real or imaginary object or event.
A circle divided into sections (as pieces of a pie) in order to represent graphically the relative proportions of different parts of a whole.
Locating data points on a scaled graphic display by means of coordinates.
User selection and entry of a position on a display, or of a displayed item. See also "cursor".
Includes specification of contents, format and header information.
A type of dialogue in which a user composes control entries requesting specified data from a data base.
A type of dialogue in which a computer displays questions, one at a time, for a user to answer.
Includes provision of computer aids for queuing, reviewing, filing or otherwise disposing of data transmitted to a user from some other source.
A capability that cancels all user entries in a defined transaction sequence.
A capability that returns a user to the first display in a defined transaction sequence, while retaining any entries made by the user.
The positioning of displayed data elements with respect to a defined measurement standard.
A scaled graph which shows relations among individual data points in a two dimensional array.
See "page".
An orientation for display framing in which a user conceives of data as moving behind a fixed display frame. The opposite of panning.
A user's action of identifying display elements to the computer in order to manipulate those elements in some way, e.g., to move them, or change their attribute(s), or delete them.
See "display selection".
Logic and means by which user actions and computer responses are linked to become coherent transactions.
A type of diagram on which changing data are shown on a fixed background.
See "selection".
Information on current data processing status which is displayed to a user either automatically or by user request, perhaps indicating system load, keyboard lock, or processing delay.
User control of displayed data by temporary deletion of specified data categories.
A temporary collection of data saved by a computer for later use.
See "information system".
A series of transactions that comprises part of a user's defined job.
An input/output device used to enter and display data. Data are usually entered via a keyboard, and are usually displayed via a video screen ("soft copy") or a printer ("hard copy").
Initial entry and subsequent editing of textual data.
An action by a user followed by a response from the computer. Transaction is used here to represent the smallest functional unit of user-system interaction.
Controlling the sequence, content, format, routine, timing, etc., of data transmission.
See "display update".
Any person who uses an information system in performing his/her job.
Computer prompts and feedback that aid users in performing their tasks. Examples include data field labels, alarm or alert signals, error messages, and HELP displays.
Automatic recording of user performance, e.g., data access records, error records, requests for HELP.
All aspects of information system design that affect a user's participation in information handling transactions.
Specific data for a particular dimension or variable. For example, values for an aircraft's speed might be 800 knots during one observation and 500 knots during another. See also "category".
See "dimension".
A portion of a display screen showing a particular kind of information, e.g., a command entry window, or a window for displaying error messages. Windows may be stable features of a display format, i.e, defined by system designers, or may be temporary, i.e., window overlays requested by a user for temporary display of data, menus, etc.
A portion of a display that is temporarily used to show added features such as requested data, menus, user guidance, etc., which may obscure initially-displayed data.
The physical facilities with which a user works and the relevant environment, including such things as computer terminals, source documents, desks, chairs, and lighting.
|
|
Introduction | | | Data Entry | | | Data Display | | | Sequence Control | | | User Guidance | | | Data Transmission | | | Data Protection | | | Table of Contents | | | Top |