ADA087 258 MITRE CORP BEDFORD MA F/6 17/2REQUIREMENTS DEFINITION AND DESIGN GUIDELINES FOR AN-MACHINE I--TC(U)JUN 80 S L SMITH F19628-60-C-0001

UNCLASSIFIED MSO-10 ESD-TR-80-122 NLII'12lllllllEIIEEEIIEEIIIEEIIIIIEIIIIII

E IIIIIEEIIIIEEEEEIIIIIIEIIIIE

MICROCOPY RESOLUTION TEST CHART

ESD-TR-80-122 LW8YE1Vo LEVEM8DESIGN

REQUIREMENTS DEFINITION AND DESIGNGUIDE LINES FOR MAN-MACHINE INTERFACE

IN C3 SYSTEM ACQUISITION

BY SIDNEY L. SMITH --

JUNE 1980 90SCt

d4C .Prepared for

DEPUTY FOR TECHNICAL OPERATIONSELECTRONIC SYSTEMS DIVISIONAIR FORCE SYSTEMS COMMAND

UNITED STATES AIR FORCEHanscom Air Force Base, Massachusetts

Project No. 572RPrepared by

THE MITRE CORPORATION, ) Approved for public releae; Bedford, Massachusetts

distribution unfimited. Contract No. F19628-80-C-0001

80 8 0

When U.S. Government drawings, specifications,

or other data are used for any purpose other

than a definitely related government procurement

operation, the government thereby incurs no

responsibility nor any obligation whatsoever; and

the fact that the government may have formu-

lated, furnished, or in any way supplied the saiddrawings, specifications, or other data is not to be

regarded by implication or otherwise. as in any

manner licensing the holder or any other person

or corporation, or conveying any rights or per-

mission to manufacture, use, or sell any patented

invention that may in any way be related thereto.

Do not return this copy. Retain or destroy.

REVIEW AND APPROVAL

This technical report has been reviewed and is approved for publication.

51-C J.. ) .t, Jr., L /U t C, USAFJOHN C. KOTELLY JComputer Scientist Chief, Technology ApplicationsTechnology Applications Division Division

FOR THE COMIANDER

NORMAND MICHAUD, Colonel, USAFDirector, Computer Systems

EngineeringDeputy for Technical Operations

UNCLASSIFIEDSECURITY CLASSOFICATION OF TNIr 01E (Whesi Datl Entered)

REPOT DCUMNTATON AGEREAD INSTRUCTIONS,BEFORE CO1PLETING FORM

ESD ' R8 122N No. 3. PECIOFI.T"; CATALOG NUMBER

. . T-- 3F EPORT PERIOD COVERED

QUREMENTS DEFINITION ANDDESIGN \IC _UIDELINES FOR.MAN- IVACINE INTERFACE IN/

S R oPOT UMBERQUSYSTEM_4 UISITIONov 8___ _____N

/0 Sidney L/Smhith jf /7/ I F19628-8 -C-90601-

9. PRR~INGGANIZATION NAME AND ADDRESS fA sr~ ~ .r. WC.RK 'JNIT NUMBERS

* The MITRE Corporation'/P.O. Box 208, Bedford, MA 01730 , - Project No. 572R

11. CONTROLLING OFFICE NAME AND ADDRESS 12. REP>ORT DATE.

Deputy for Technical Operations JUNE 1980Electronic Systems Division, AFSC 13. NUMBER nr PAGES

Hanscorm AFB, MA 01731 11914. MONITORING AGENCY NAME & ADDRESS(it different from Controlling Office) 15. SECURITY CLASS. (of this report)

. . .. UNCLASSIFIED

15. DECLASSIFICATION DOWNGRADiiGSCHEDULE

16. DISTRIBUTION STATEMENT (of this Report)

Approved for public release; distribution unlimited.

17. DISTRIBUTION STATEMENT (of the abstract entered in Block 20, if different from Report)

18. SUPPLEMENTARY NOTES

IS. KEY WORDS (Conlinue on reverse side If necessary and identify by block number)

DESIGN GUIDE LINESMAN-MACHINE INTERFACEMMIREQUIREMENTS DEFINITION

24 ABSTRACT (Continue an reverse side if neceesary and Identify by block number)

The man-machine interface (MMI) represents a significant proportion of the hard'A areand software investment in Air Force C3 system acquisition. Early definition of 1]fMIrequirements and provision of design guidance in functional specification may becritical to successful system development. Tentative design guidelines are prop)sedin this report for further elaboration, trial application and subsequent evaluation :ncollaboration with selected ESD/MITRE program engineering efforts. F

DO ' 1473 EoITION OF I NOV6 S OBSOLETE U S ," 'SECUIT UNCLASSIFIED Tl PAGE (ln , t gSECURITY CLASSIFICATIoN, OF THIS PAGE (9l%en 1 4 to En---tered)

SUMMARY

The *an-machiue interface (MII) is a critical element of C3systems. There are, however, no presently available guidelines fordefining MIII functional requirements and specifying MIII softwaredesign. In this report, it is recommnended that ESD/MITRE shouldundertake a collaborative effort to explore the potentialdevelopment and application of MIII design guidelines in Air Force C3system acquisition.

The first step in MMI design is to decide what is needed. MIIrequirements definition must include consideration of user/operatorcharacteristics, the information handling requirements of people'sjobs, and the functional capabilities that can be provided in theMIII. A requirements matrix is proposed, to illustrate how MIIfunctional capabilities can be systematically related to the dem~andsof operator tasks.

The second step in MIII design is to develop specifications thatwill communicate functional requirements to the system designers.In addition to the requirements matrix, guidelines for softwaredesign should be provided with respect to dialogue type, dataentry/input, data display/output, sequence control, user guidance,and other interface functions. A sample set of design guidelinesfor data entry functions is proposed to illustrate what might bederived on the basis of current knowledge.

Given effective requirements definition and guidelines for MIIdesign, an important further step in system acquisition is to ensuredesign review and verification before software implementation. Forthis purpose, specific documentation of MIII design will be needed.Such documentation will help coordinate MIII design during systemdevelopment and will provide a continuing standard for anysubsequent design modification. Possible approaches to MIII designdocumentation are proposed here for consideration.

These proposed tools for improved MIII requirements definitionand design need further development and evaluation in practicalapplication. It is recommended that a continuing effort toward thatend be undertaken in cooperation with system acquisition programoffices.

.02

1 a r(4

ACKNOWLEDGMENTS

This report has been prepared by The MITRE Corporation underProject No. 572R. The contract is sponsored by the Electronic SystemsDivision, Air Force Systems Command, Hanscom Air Force Base,Massachusetts.

2

TABLE OF CONTENTS

Page

LIST OF ILLUSTRATIONS 5

SECTION 1 INTRODUCTION 7

THE MII IN SYSTEM ACQUISITION 7

NEED FOR GUIDELINES 8

CURRENT STATUS 10

PROPOSED EFFORT 13

SECTION 2 MII REQUIREMENTS DEFINITION 15

USER/OPERATOR CHARACTERISTICS 15

TASK ANALYSIS 18

FUNCTIONAL CAPABILITIES 20

SECTION 3 MII DESIGN GUIDELINES 25

WORK ENVIRONMENT 25

INTERFACE HARDWARE 26

DIALOGUE TYPE 27

DATA ENTRY/INPUT 29

DATA DISPLAY/OUTPUT 31

SEQUENCE CONTROL 34

USER GUIDANCE 37

SECTION 4 DESIGN REVIEW AND VERIFICATION 41

DESIGN DOCUMENTATION 41

3

TABLE OF CONTENTS (cont.)

Page

DESIGN REVIEW 42

DESIGN COORDINATION 43

SECTION 5 CONCLUSIONS AND RECOMMENDATIONS 46

REFERENCES 48

APPENDIX A SUMARY INFORMATION RELATING TO MMI DESIGN 53

APPENDIX B KNI REQUIREMENTS MATRIX 79

MMI FUNCTIONS 79

CHARACTERISTIC TASKS 80

REQUIREMENT ESTIMATES 82

APPLICATION AND EXTENSION 84

APPENDIX C DESIGN GUIDELINES FOR DATA ENTRY 96

APPENDIX D DOCUMENTING MIll DESIGN 110

4

LIST OF ILLUSTRATIONS

Table Page

3-1 Estimated Requirements of Different Dialogue Types 28

A-1 Properties of Some Major Classes of InteractiveSystem User 54

A-2 User Responses to Inadequate System 55

A-3 Representative Examples of Statistical Studies ofUser Behavior in Time-Sharing Systems 56

A-4 Requirements Analysis: Questionnaire and SurveyMethods 57

A-5 Requirements Analysis: Interviews and FieldObservation 58

A-6 Requirements Analysis: Simulation and Gaming 59

A-7 Major Approaches to the Modeling of InteractiveSystems 60

A-8 Basic Subtasks or Phases Involved in ProblemSolving 62

A-9 Types of Problem-Solving Aids 64

A-10 Some Major Properties of Interactive Dialogues 66

A-li Sumary of System Response Time Effects 68

A-12 Basic Interactive Dialogue Types 69

A-13 Some Known Problem Areas in the Use of QueryLanguages 70

A-14 Basic Display Device Types 71

A-15 Basic Visual Properties of Displays 73

A-16 Display Properties of Alphanumeric Characters 74

5

LIST OF ILLUSTRATIONS (cont.)

Table Page

A-li Major Display Coding Techniques 75

A-18 Input Device Types 76

B-1 Sample 1111 Requirements Matrix 86

C-1 Design Guidelines for Data Entry Functions 99

Figure

D-1 Sample Task Flow Chart 113

D-2 Sample Transaction Flow Chart 114

D-3 Sample Form for Display Format Specification 115

D-4 Sample Form for Input Data Definition 116

D-5 Sample Form for Documenting User Guidance Messages 117

6

SECTION 1

INTRODUCTION

The man-machine interface (1111) is a critical element ofmilitary command, control and communication (C3) systems. Thereare, however, no presently available guidelines for defining MMIfunctional requirements and specifying MIII software design. Stepsto meet this deficiency are currently being initiated by the othermilitary services. It is proposed that MITRE should undertake acollaborative effort with the Air Force Electronic Systems Division(ESD) to explore the potential development and application of MIIdesign guidelines in Air Force C3 system acquisition.

TILE MIII IN SYSTEM ACQUISITION

The phrase "man-machine interface", abbreviated MIII, isfrequently used by system designers, sometimes with differentmeanings. In the broadest sense, "man" refers to the people whowill use and maintain a system. Some of these people are women.Because the operational jobs in C3 systems generally require neitherexceptional strength nor dexterity, neither men nor women have anyspecial advantage in performing those jobs.

"Machine" can refer to the tools provided people to accomplishtheir jobs. The tools used for C3 information processing usuallyinclude a computer with its associated terminal equipment --

displays, keyboards, printers, etc. Also important, however, arethe software programs that govern the logic of computer use, thetask allocation and operating procedures that give purpose andstructure to a person's interaction with a computer, the paper formswhich may contain data for entry into the computer, the operatormanuals and other paper files which may have to be used inconjunction with computer processing, and other conditions of thework enviroment which influence job performance.

To acknowledge the multiplicity of factors which influence aperson's use of information processing tools, the man-machineinterface should be characterized in the broadest terms as person-system interaction. This is the meaning intended here: any aspectof system design that influences user performance is part of theman-machine interface.

Given this broad definition, to say that the MIII critical to C3system design is to state the obvious. The purpose of most C3

7

systems is to facilitate the collection, processing anddissemination of data for human use. Thus poor design of the MMI

must inevitably work against the fundamental objectives of system

design. Task analysis, review of operating procedures, equipment

selection, workspace configuration, and especially MMI software

design -- all must be done with care to ensure effective system

operation.

Not only is MMI software design critical to system operation,

it can also represent a significant investment of effort in C3

system development, ranging from perhaps 10 to 50 percent of the

operational software production during initial acquisition, plus

software maintenance to accommodate changing operational

requirements thereafter.

Given the importance and the extent of MM! software, some way

must be found to determine MMI software requirements in system

functional specification, to provide guidelines for MMI design, and

to verify the design before implemei.tation of MMI software. This

desired sequence of requirements analysis, function specification

and design verification is essentially that called for in MilitarySpecification MIL-H-48655B (1979). What steps can system developerstake to achieve this sequence in MMI software design?

NEED FOR GUIDELINES

The actual sequence of MMI software design in C3 systemacquisition will sometimes depart from the principles specified inMIL-H-58655B. There may be no explicit attempt to determine MMIrequirements. Specifications may include only rudimentaryreferences to MMI design, with general statements that the systemmust be "easy to use". In the absence of more effective guidance,both the design and implementation of MMI software may become theresponsibility of programmers unfamiliar with operationalrequirements. MMI software may be produced slowly, while detectionand correction of design flaws occur only after system prototyping,when software changes are difficult to make.

It seems fair to characterize present methods of MMI softwaredesign as art rather than science, depending more upon judgment thansystematic application of knowledge. As an art, MI design is bestpracticed by experts, by specialists experienced in the humanengineering of man-computer systems. But such experts are notalways available to help guide system acquisition generally, andcertainly cannot guide every step of MII design at first hand. Whatseems needed is some way to embody expert judgment in the form ofexplicit procedures and guidelines for MII design.

8

.1

Present human engineering standards and design guide books areof little use to the software designer. Military standards areoriented toward hardware design ("knobs and dials") and physicalsafety ("avoid sharp corners"). We need similar standards for 1111software design.

MIL-STD-483 refers only briefly to MIII software design,indicating that human performance/human engineering requirementsshould be specified for "minimum times for human decision making,maximum time for program responses, maximum display densities ofinformation, clarity requirements for displays, etc." (1970, page43, paragraph 60.4.3.2.2.1)

MIIL-STD-454F offers just one paragraph on the general subjectof human engineering:

Human engineering design criteria and principles shallbe applied in the design of electronic equipment so as toachieve safe, reliable, and effective performance byoperator, maintenance and control personnel, and tominimize personnel skill requirements and training time.MIL-H-46855 shall be utilized as a guideline in programplanning and MIL-STD-1472 as a guideline in applying humanengineering design criteria. Quantitative humanengineering requirements shall be as specified in thecontract.

(1978, page 62-1)

MIL-STD-1472B (1974), the iajor human engineering designstandard for system procurement, is concerned almost exclusivelywith hardware design.

Some guides to MIII software design might be reasoned byanalogy. Just as we should not design sharp corners on hardware, weshould not include hazardous features in user software. Just as aphysical step may be marked with a painted line to keep us fromtripping on it, so we may seek some way to signal abrupt shifts inthe logical steps of an interactive sequence. A pushbutton reservedonly for emergencies may be shielded to prevent accidentalactivation. So too it is possible to provikde software protection inthe MIII to prevent accidental initiation of critical actions. Butsuch analogies do not take us very far.

Current efforts at re-wording human engineering standards doinclude token references to software, but still provide no explicitguidance, no advice on how to avoid "sharp corners" in man-computerinteraction. So there is a dilemma: guidelines for MIII design seem

9

needed, but none are available. The question is, can neededguidelines for MMI design be developed?

CURRENT STATUS

In the past decade, as increasing experience has been gained inthe use of on-line computer systems, a number of experts haveattempted to set forth principles ("guidelines", "ground rules","rules of thumb") for design of the man-computer interface. None ofthese sets of guidelines looks to be entirely satisfactory for MIIdesign.

Some guidelines have been proposed in quite general terms:"know the user" (Hansen, 1971). Some emphasize specific aspects ofinterface design: response time (Miller, 1968); error protection(Wasserman, 1973); command languages (Kennedy, 1974); multifunctionswitches (Calhoun, 1978); lightpen selection (IUber, Williams andHisey, 1968); graphic interaction (Foley and Wallace, 1974); displayformatting (Stewart, 1976; Green, 1976); color coding (Krebs, 1978).

Some guidelines have been proposed for specific operator tasks,such as document retrieval (Thompson, 1971), or process control(Williams, 1975). Some have been oriented toward the general use ofon-line systems, with little task specificity (Nickerson and Pew,1971; Palme, 1975; Chariton, 1976; Dzida, Herda and Itzfeldt, 1978).Some guidelines are based on explicit assumptions of systemarchitecture and equipment capability (Pew and Rollins, 1975; seealso Pew, Rollins and Williams, 1976). Some guidelines may assumeimplicit constraints, such as printed outputs rather than electronicdisplays (Chamberlain, 1975).

Some guidelines may be well stated generally, but are notelaborated in necessary detail (Smith, 1974). Only a few sets ofguidelines have been expressed at the level of detail needed bydesigners. Perhaps the most detailed MIII guidelines are thoseproposed by Engel and Granda (1975). Here is a sample: "If a fixedlength word or collection of characters is to be entered via thekeyboard, limit the field on the screen by special characters, forexample, underscores." More guidelines of this sort are ne'±ded.

Although this evident concern for design principles isencouraging, we still have much to learn. Most published reportsdealing with the man-computer interface describe applications ratherthan design principles. A recent bibliography of the literature onhuman factors in computer systems includes 564 items, but identifiesonly 17 as offering design guidelines (Ramsey, Atwood and Kirshbaum,1978). A popular current book on the design of man-computer

10

dialogues offers much in the way of stimulating examples, covering arange of on-line applications, but is disappointing in its failureto emphasize design principles (Martin, 1973).

Until this year, there has been no thorough-going attempt tointegrate the scattered papers, articles and technical reports whichhave constituted the literature of man-computer interaction. Afirst step was made, under sponsorship of the Office of NavalResearch, in compilation of the bibliography cited above. Asignificant follow-on effort has just culminated in publication byRamsey and Atwood of a comprehensive summary of this literature,with particular emphasis on determining the feasibility of designguidelines.

In that compendium the authors characterize the currentunsatisfactory situation:

In some well established research areas, such as keyboarddesign and certain physical properties of displays,guidelines exist which are reasonably good and fairlydetailed. Such guidelines may be quite helpful in thedesign of a console or other interface device for asystem, or even in the selection of an appropriate off-the-shelf input/output device. As we progress toward themore central issues in interactive systems, such as theirbasic informational properties, user aids, and dialoguemethods, available guidelines become sketchy andeventually nonexistent. The interactive system designeris given little human factors guidance with respect to themost basic design decisions. In fact, the areas in whichexisting guidelines concentrate are often not even underthe control of the designer, who may have more freedomwith respect to dialogue and problem-solving aids thanwith respect to terminal design or selection.

(Ramsey and Atwood, 1979, p.2)

Summarizing their report, the authors express some reservationsconcerning the feasibility of general MMI design guidelines:

Based on an extensive literature survey, this documentpresents a description and critical analysis of the stateof the art in the area of human factors in computersystems. This review is concerned both with the status ofhuman factors research in the area of user computerinteraction and with the current state of user-computerinteraction technology and practices. The primary purposeof the review is to determine whether research and

practice in this area have evolved sufficiently to supportthe development of a human factors guide to computersystem design. It is concluded that insufficient dataexist for the development of a "quantitative referencehandbook" in this area, but that a "human factors designguide" -- which discusses issues, alternatives, andmethods in the context of the design process -- is both

feasbleandneeed. (Ramsey and Atwood, 1979, abstract)

The authors do concede that useful MMI design guidelines mightbe developed for specific application areas, but indicate thedifficulty of generalization:

The greatest difficulty involved in making our knowledgeof problem-solving aids useful to the designer is therelatively abstract level of that knowledge. If designguidelines were to be written for a very limited class ofsystems, it might be possible to suggest very specificaids. For more general guidelines, it would be necessaryto greatly simplify the language in which problem solvinghas just been discussed, and provide guidance to help thedesigner recognize the kinds of problem-solving behaviorinvolved in the particular tasks at hand. Furthermore, itwould probably be necessary to provide very explicitexamples of the various types of aids which are known.This all appears feasible, but is by no means easy, and weare unaware of any such guidelines which have beendeveloped in the past. If designers operate primarily bysynthesizing designs from already known elements, such apresentation might greatly enhance the designer'sutilization of aiding techniques which happen to lieoutside the designer's past experience.

(Ramsey and Atwood, 1979, p.59)

Whether or not their limited optimism concerning thefeasibility of design guidelines is realistic, Ramsey and Atwoodhave performed a considerable service by providing tabular summariesof current knowledge relating to many aspects of lINI design. Aselection of their tables has been reproduced by permission asAppendix A to this present report.

A newly funded effort to develop MKI design guidelines hasrecently begun, under sponsorship of the U.S. Army ResearchInstitute for the Behavioral and Social Sciences, as described in anRFP (request for proposal) titled "Development of Design Guidelinesand Criteria for User/Operator Transactions with Battlefield

12

Automated Systems" (ARl, 1979). This study contract was awarded inNovember to Synectics Corporation. The Army sponsors of this effortbelieve that the defined restrictions on user population andinformation processing tasks will permit effective development ofMMI design guidelines.

This current interest in MIII design on the part of Army andNavy research organizations raises the question of what isappropriate Air Force involvement. There is, of course, an elementof concern. Design standards developed in one organization mayeventually be imposed on others, through DoD encouragement ofuniform military application. There is also an element ofopportunity. In view of the Air Force' s considerable experience,gained in 20 years of responsibility for the design of computer-based command systems, it seems appropriate that the Air Forceshould have a voice, and perhaps even play a lead role, in thedevelopment of any MIII design standards that may be established forC3 system acquisition. It is recommended that ESD/MITRE shouldundertake such a development effort.

PROPOSED EFFORT

There are at least three ways in which MIII design guidelinescould be used. First, guidelines might help in the early definitionof MIII functional requiremenzs. This possibility is discussed inSection 2 of this report, where it is proposed to develop a matrixstructure indicating the MIII requirements of various characteristicC3 information processing tasks. That approach is illustratedfurther in Appendix B.

Second, M111 guidelines should prove useful in the designprocess itself, as discussed in Section 3. The task vs interfacematrix could be abstracted ("tailored") to reflect the anticipatedjob requirements of a particular system, and a functionaldescription of the resulting MMI1 requirements embodied as guidelinesin the system specification. A tentative sample of such guidelinesis included in Appendix C to this report.

Third, MIII guidelines could provide criteria for the review andevaluation of a proposed interface design prior to its softwareimplementation, as discussed in Section 4. Some means must be foundfor effective documentation of 1111 design to permit such review.Sample formats for MIII design documentation are included inAppendix D.

To assess the potential value of MIII design guidelines, it willbe necessary to try them out in actual C3 system acquisition

13

programs. During FY80, ESD Program Offices and MITRE engineeringsupport groups will be invited to participate in a collaborativeeffort to develop and apply MMI guidelines in practice. It is hopedthat several programs will volunteer to participate: programs in anearly stage of system development, and anticipating a strongemphasis on the MMI in system design. Ideally, programs will beselected which include a wide variety of different operator jobs, inorder to encourage a broad consideration of applicable MMIlguidelines.

Whatever MMI guidelines are developed at this stage can only beregarded as tentative, to be used on an interim basis untilexperience is gained in their trial application. The initialdevelopment process may have to extend over a period of severalyears, since it is necessarily linked to the pace of systemacquisition. Such an extended effort may well be justified,however, in view of the potential long-term benefits. In the longrun, standards for MMI design established at ESD/MITRE couldcontribute significantly to improved C3 system acquisition.it

David Penniman, writing for the User On-Line Interaction Groupof the American Society for Information Sciences, cites the sameneed for "An interim set of guidelines for user interface designbased on available literature and pending the development of betterguidelines as our knowledge increases" (1979, page 2). Pennimangoes on to remind us that interim guidelines are better than noguidelines at all.

There is one important factor to consider in this regard, whichis the relative stability of human engineering guidelines.Standards for hardware design may change as each new generation ofequipment becomes available. But people change hardly at all fromone generation to the next, in terms of their basic informationprocessing capabilities and limitations. This relative invarianceof people with respect to technology poses both problems andadvantages.

The most significant advantage is this: if MMI guidelines canbe expressed in terms of basic human capabilities rather thantransient technology, a design standard of enduring value will beestablished. It may be true that such guidelines can be establishedonly slowly, but that is all the more reason to make a start now.

14

SECTION 2

NNI REQUIREMENTS DEFINITION

The first step in MIII design is to decide what is needed. OnceMIII requirements are determined, then design guidelines can betailored to anticipated needs. MIII requirements definition mustinclude consideration of user/operator characteristics, theinformation handling requirements of people's jobs, and thefunctional capabilities of the MIII that are needed for those peopleperforming those jobs.

USER/OPERATOR CHARACTERI STICS

A challenging aspect of C3 system design is the broad range ofuser characteristics that must be accommodated. The users whooperate C3 systems include a wide variety of people with differentdegrees of training and experience. The skill mix may includeconmmand managers as well as clerical personnel, hardware andsoftware technicians performing maintenance functions, even "boxkickers" at a truck dock in the automation of air cargo datahandling (Smith, 1976b).

There are various ways to categorize the different kinds ofusers. One categorization distinguishes 'operators" and "analysts"from "service"~ personnel (Goodwin, 1978; see also Rouse, 1975). Inthis view, an operator is a person performing a structured task,usually at a forced pace, monitoring and controlling through systemoutputs and inputs, making decisions and initiating actions throughthe system within limited time constraints: e.g., radar trackmonitoring; air traffic control; process control. An analystperforms an unstructured task, usually self-paced, manipulatessystem data to establish relationships, perhaps using on-line tools,may rely also on data from other sources including past experienceto recognize problems and make decisions, which may not be madeimmnediately and may not be entered into the data processing systemfor action: e.g., intelligence analysis; mission planning; messagehandling. Service personnel perform more routine clerical tasks,where the user is not the source of data being entered, retrieval isin response to specific query, using highly structured transactionsequences, sometimes at a forced pace under pressure: e.g., makingairline reservations; providing telephone directory assistance; word

* processing jobs.

15

Although such categorization offers helpful descriptiveinformation of the user's role, it is clear that thecharacterization is largely one of differences among jobs ratherthan differences among people. Job differences can be definedbetter in the more specific context of task analysis. For purposesof the present discussion, no attempt will be made to label userdifferences in terms of job description. The terms "uer and"loperator" will be used interchangeably throughout this report.

For any one category of user, individual differences in skillmay be considerable. Because of systematic rotation of jobassignments for military personnel, today' s naive user becomes nextyear's expert, then to be replaced by another beginner. Thisregular reassignment policy implies the need for flexible job aidsin MMIl design, which can provide optional help to the novice userbut can be bypassed by the expert.

Where there is high personnel turnover, low skill levels andminimal operator training, MMI design must take that into account.Interactive sequences should be configured as a routine series ofsimple steps, with adequate guidance and on-line error correctionprocedures to ensure effective operator performance. For most C3applications, however, both operator characteristics and job demandswill require an MMIl design offering more extensive capabilities andpermitting more flexible use.

An important distinction can be made between dedicated andcasual users (Martin, 1973). C3 systems include both kinds. Anoperator in a surveillance job may spend virtually full timemonitoring computer-generated displays. Such a person willgenerally receive extensive training, and the MMI design can betailored to his presumed skills. Another operator may be anintelligence analyst who interacts with a computer system onlyperiodically, and whose requirements for information retrieval aremuch more wide ranging. Although this person may have beeninstructed in MI procedures, perhaps being given an operator'smanual, his use of computer aids may remain uncertain for anextended period unless on-line guidance is incorporated in MKIldesign.

Although these examples are cited to illustrate usercharacteristics, they actually reflect important differences in jobrequirements. It is obvious that user characteristics are closelyrelated to job requirements, and that necessary user skills can bespecified more exactly after job requirements have been determined.

This is discussed further below.

l6

As a general objective, it can be argued that the MMI design inautomated systems should not require higher skills and greateroperator effort than the manual procetL res which are being replaced.In practice, of course, this design objective is not alwaysattained. Some automated systems are found to be harder to userather than easier, and increased demands are made upon theoperators.

In the Army RFP cited earlier, the increasing demand forskilled operators caused by command automation is advanced as anargument in favor of developing MII design guidelines:

The skill/demand mismatch is due in part to the fact thatthe equipment/procedural configurations of existing andprojected systems have been devised without coordinationamong proponents of different systems. As a result, verylittle of the skill and know-how accrued from experiencewith one system can be transferred to other systems.Therefore, one of the long range goals of this project isto promote functional standardization and modularizationof user/operator tasks and procedures in order to reducethe amount of training and the skill levels required ofusers/operators of fielded automated data processsingsystems. Many of the procedures employed in the operationof various automated systems are basically similar. Yetfrom the user/operator's perspective each system is a newsituation with little carryover or transfer from previousexposures to other systems. While it may be too early toestablish absolute "standards" for many system parameters,a measure of consistency would go a long way towardincreasing effectiveness, reducing personnel costs andmaking battlefield automated systems more approachable toArmy users/operators.

(ARI, 1979)

This call for consistency in MII design is common to allrecommendations on the subject, but is particularly important inmilitary settings because of the frequent rotation of personnel. Tothe extent that jobs may be similar in different C3 systemapplications, the operator transferred from one system to anotherought to be able to use similar means to accomplish similar ends.Even for quite different system applications, it may prove possibleto introduce a coherent general approach to MIII design, so that theinterface logic will seem familiar to a person transferring to a newjob.

17

For the developers and designers of C3 systems, it may help topostulate some basic characteristics of the prospective users. Theoperators of C3 systems will generally be intelligent men and women,with professional military skills. These people will notnecessarily be knowledgeable about computer technology, may havelittle time to learn specialized interface procedures, and will havevarious degrees of familiarity- with the system. Being human, theseoperators will sometimes make mistakes, especially when workingunder pressure, and good 1111 design must take this into account.

These operators are motivated toward effective job performancein the face of operational demands. They will generally regardautomated data processing as a tool to aid job performance, withlittle curiosity about the internal mechanisms of computingmachines. Operators will tend to judge the entire system on thebasis of their personal experience with the MMIl. If the MII isefficient and easy to use, operators will like the system. Butusers will be impatient and critical when handicapped by a clumsyinterface design.

For further information on user characteristics, see Tables A-ithrough A-3 in Appendix A.

TASK ANALYSIS

Fundamental to NMI design is the analysis of operator jobs.The process must begin with the mission requirements of a proposedC3 system, which state the basic objectives to be accomplished.These mission requirements are then elaborated and translated,taking into account the proposed operational employment concept,environmental, technological and fiscal constraints, to define thesystem operational requirements.

Operational requirements imply the performance of variousidentifiable functions -- data sensing, data transmission, dataprocessing, etc. Analysis of those functions, in turn, establishesmore specific data processing requirements -- what data must enterthe system, what data must be stored, what combinations andtransformations of data are required, what kinds of informationshould result from that processing.

These data processing functions imply the specification oftasks to accomplish particular ends. Some tasks may be performedentirely by machine and thus affect MIII design only indirectly if atall. Because of the critical role of human judgment, however, manytasks in C3 systems involve joint performance by man and machine.

18

Most tasks can be partitioned into identifiable subtasks.Those subtasks in turn are often designed as a series of simple,discrete transactions, such as operat'.: entry of a single item ofdata. (As defined here, note that a transaction is the smallestfunctional "molecule" of man-machine interaction, and does notdenote an extended task seqtience.) It is at these levels of task,subtask and transaction tha.. MIII design guidelines might be applied.

What about jobs, where do they fit in? To define a job, whichis a set of responsibilities and activities for a person, we mustallocate tasks to operators. Task allocation, however, will notprove easy. F.,r C3 systems it will seldom be desirable to allocatethis task to man and that task to machine, as textbooks suggest.Instead, more effective performance may result when man and machineparticipate jointly. This view has already been stated above, andis emphasized also by Ramsey and Atwood (1979).

If this is the case, then a more accurate description of jobdefinition involves specification of operator participation intasks. From this viewpoint, one possible contribution of MIguidelines would be to suggest the most effective ways in whichoperators can participate in various identified C3 informationhandling tasks, as well as to specify the functional MIIcapabilities needed to facilitate such participation.

It should be noted that jobs as defined here are generally notthe same as information processing functions. Jobs can be bothsmaller and larger than functions. A surveillance function, forexample, might involve a monitoring task performed by severaldifferent operators, perhaps each responsible for a differentsurveillance sector. And each of those operators, as part of hisjob, might also participate in other tasks related to differentfunctions, for example, weapons control.

Thus job definition, the combining of tasks performed bypeople, involves something more than functional analysis, an extraapplication of judgment in the design process. The purpose of jobdefinition is twofold. On the one hand, the definition of jobsdetermines what capabilities will be required of the operators. Onthe other, the definition of jobs indicates what tasks may have tobe performed in combination, by a particular operator at aparticular work station, and so implies what functional capabilities

will be required of the MIII.

19

FUNCTIONAL CAPABILITIES

If an operator must interact with a graphic display, as in acomputer-aided design task, he will need a functional capability forpointing at different parts of the display. Without a pointer todesignate displayed objects and positions, the task would bedifficult or even impossible to perform. Various means might bechosen to provide a pointer -- a lightpen, perhaps, or joystick-controlled cursor, or trackball, or whatever -- each choice offeringits own advantages and disadvantages. But it is the functionalrequirement for pointing that is essential.

For an on-line editing task, where an operator must designatearbitrary portions of displayed text for correction, a pointer wouldclearly be useful. For a task involving sequential selections amongcomputer-displayed options, a pointer would probably be useful,although other design alternatives such as multifunction keys mightdo nearly as well. Far many other tasks a pointer may not be neededat all.

One could imagine making a long list of typical C3 datahandling tasks and noting for each one whether a pointing capabilityis an essential or probably useful feature of the MIII, or whether itis not needed. To do this would be to make a modest beginning inthe definition of MIII requirements. But, of course, many other MIIcapabilities have to be considered also.

How about color? Color coding could be very helpful to anoperator monitoring a complex display, trying to detect criticalconditions in rapidly changing data, but for many other tasks theexpense of colored displays might not be justified. Perhaps blinkcoding, special symbols or auxiliary alarms could be used instead.

Many functional capabilities of the MIII have little to do withhardware selection, and depend primarily on the logic of softwareimplementation. Consider two examples. For a particular data entrytask, an operator may need a capability to defer entry ofunavailable items, even when they may be essential for subsequentdata processing calculations. For many data entry tasks operatorsmay need a flexible capability to back up and change previouslyentered items.

The software designs chosen to implement these two functionalcapabilities -- deferred data entry and optional backup -- mightshare some common features, e.g., some sort of suspense file.Software implementations would also differ in some respects, e.g.,in terms of the validation checks applied during data entry, those

20

t

applied at later stages of data processing, and the particularmessages displayed to the operator when data deficiencies aredetected.

It is safe to say that the operator will not care what goes onbehind the scenes, but will simply use the operational capabilitiesavailable to him, however they are provided. And it is thesecapabilities that should be described in functional MIspecification, rather than their means of implementation.

As more and more MIII capabilities are considered, our initiallist of which tasks require a pointer will expand into a sizabletable, or "matrix" as it will be called here. Across the top,labeling each column, will be the names of tasks. Down the side,labeling each row, will be listed the various different functionalcapabilities we have considered. In the body of the matrix, at theintersection of each column and row, there could be a cell entryindicating whether that row/function is essential, useful or notneeded for the performance of that column/task.

There are several problems with such an MMI requirementsmatrix. The chief problem is that it does not yet exist. No onehas yet undertaken the systematic effort needed to create it.Laboratory researchers have been too removed from operationalapplications to see the need for such a matrix. System developers,on the other hand, have enough trouble defining the 1.!MI featuresrequired by a particular application, let alone trying to assess thebroader range of capabilities which might be required by othertasks.

What may be needed here is a broad survey across systems, ofthe kind proposed in the Army REP cited earlier. Pending such acomprehensive effort, a beginning might be made by tabulatingseveral characteristic tasks and interface features, perhapsstarting with one C3 system and then moving on to another, with theintention of expanding the MIII requirements matrix with increasingexperience in its use. Such a beginning with a rudimentary matrixis illustrated in Appendix B to this report. See also Tables A-4through A-9 in Appendix A.

Other problems associated with the MIII requirements matrix,aside from its present unavailability, have to do with the labelingof rows, columns and cell entries. As suggested above, rows shouldbe labeled as functional capabilities. This ideal may be difficultto attain when our thinking turns so easily to implementation.Current lists of desirable MIII features tend to include means (e.g.,lightpen) more often than ends (pointing). As a practical matter,

21

we shall have to begin with whatever comprehensive lists we canfind, and try to abstract the implied functional capabilities.

Column/task labeling poses similar problems. If a columnrepresents a task defined specifically for a particular system,perhaps monitoring a track display for air traffic control, then theresulting pattern of MIII requirements may not provide usefulguidance in specifying a somewhat different but related task inanother system, perhaps monitoring a track display for air defensepurposes. To prevent the MIII requirements matrix from growingindefinitely, as each new system acquisition adds its own new set ofspecific column/tasks, it will be necessary to generalize taskdescriptions to some degree, to list characteristic rather thanspecific C3 tasks.

With further investigation, it is possible that we shall findthe key to successful generalization at the level of subtasks ratherthan tasks. Consider the obvious subtask of keyed data entry, whichis a common component in many larger tasks. (The expressedcommitment to hardware implementation in the word "keyed" might beforgiven in view of currently accepted limitations in interfacetechnology.) MIII requirements determined for that subtask shouldprove applicable in a variety of C3 system applications, withperhaps some occasional modifications appropriate to special workingconditions.

Or it may be that to derive generic MMI requirements one mustdistinguish several categories of a subtask, such as keyed dataAentry with prompting or without. Whatever the level of taskspecification that eventually proves useful, there seems thepotential here for using some form of abstracted or generic taskanalysis to predict the MIII requirements of actual tasks. Infuture, when our understanding of generic task analysis hasincreased, we might look at a proposed operator task, estimate it as"60 percent monitoring a high-density multivariate display, 15percent controlled option selection, 25 percent prompted keyed dataentry", and derive from that description a specification of MIfunctional requirements.

Today we do not know how to do that. But as we addcolumn/tasks to the MIII rtquirements matrix we should stay alert tothe possibilities for generalization, trying to abstract taskdescriptions wherever possible and to identify the subtasks andtheir variations which may comprise the generic components of futurerequirements definition.

22

..... ....

Aside from the problems of selecting suitable row and columnlabels, we also have to depend largely on judgment in designatingcell entries for the MMI requirements matrix. At present, probablythe best we can do is make an approximate categorical judgment thatHMI capabilities are essential, useful, or not needed. In future wemay be able to replace those approximate estimates with morequantitative weighted values. It might be possible to derivequantitative values from system performance measures, although thatseems unlikely at present. More probably, we could developquantitative values directly from structured testing of generic taskcomponents, as those can be identified.g

Still another problem with the KNI requirements matrix is thatrather different versions of the matrix might conceivably be neededfor different categories of users. This problem, however, may bemore conceptual than real. As a practical matter, several argumentscan be advanced in favor of a single matrix. As noted earlier, usercharacteristics are implicit in task descriptions: simple clericaltasks are often assigned to untrained personnel, complicatedclerical tasks to experienced, well-trained people, monitoring andcontrol tasks to young officers, planning and resource allocationtasks to older officers, etc. Moreover, because of the skill mix ofoperators in most C3 jobs, MIII functional specifications for anyparticular job must generally accommodate a fairly broad range ofuser characteristics.

In the future, when the MIII requirements matrix may beexpressed in terms of generic task components, the results offunctional analysis may be expressed in terms of required operatorskills, as well as specification of MIII requirements. Thus again asingle requirements matrix may be referenced for more than onecategory of system user.

Nonetheless, it will prove a wise precaution to consider usercharacteristics explicitly when applying the IIMI requirementsmatrix. A prospective user group may be "speLial" in somesignificant way, as might be the case in a C3 system designed foroperators in another country with different linguistic backgroundand cultural expectations. A user group may include color-blindpeople, or people with some other special characteristic. If so,then those special user characteristics should be taken into accountand MIII requirements interpreted accordingly.

In the face of these various problems, why should we attempt todevelop an MII requirements matrix? What advantages will it offer?First, it seems clear that such a matrix should help to providegeneral perspective and serve as a framework to structure judgment

23

in determining MMI requirements. This would be true even in theearly, rudimentary stages of MMI requirements matrix development.

With further development, as the MMI requirements matrixexpands to include more functional capabilities and a manifold rangeof C3 tasks, it will embody the experience accumulated in a varietyof system acquisition programs. It may then be possible to draw onthis cumulative judgment instead of having to re-invent an MMI fromscratch for each new system. If nothing more, the row labels in thematrix would constitute a checklist to remind system developers ofMMI capabilities that should be considered.

In the long run, of course, the MMI requirements matrix couldbecome an even more powerful tool. As in the hypothetical exampledescribed earlier, it may eventually be possible to analyzeprospective operator tasks into familiar subtasks and their genericcomponents, for which MMI functional requirements have already beendetermined. If so, then requirements definition for a new systemcould be accomplished both rapidly and comprehensively.

An important use of functional requirements definition in earlystages of system acquisition will be to limit the choice of MMIdesign guidelines to be employed during system development. Asdiscussed later in this report, the total "catalog" of designguidelines might grow quite large, perhaps including hundreds ofitews. But many of these guidelines will be specifically related toparticular functional capabilities. Thus when the subset ofcapabilities required by a new system has been determined, then arelated subset of guidelines could be selected, tailored to systemrequirements.

One could imagine providing computer aids to facilitate thistailoring process. If both the MilI requirements matrix and thedesign guidelines were presented in computer storage, withappropriate cross inde. g, then specification of desired functionalcapabilities coul - 1.ogrammed to produce automatic printout ofthe corresponding beL of guidelines for MMI design.

By its nature, the MMI requirements matrix cannot be createdall at once, but will grow gradually through accretion, as newcapabilities and tasks are added and old ones are further analyzedand subdivided. After several years of experience using the matrix,some estimate might be made of the eventual success of this approachto MMI requirements definition. To gain that experience, abeginning must be made in current C3 system acquisition programs, asa collaborative effort with program personnel. Such an effort isrecommended.

24

SECTION 3

MMI DESIGN GUIDFLINES

The second step in MMI design is to develop specifications thatwill communicate functional requirements to the system designers.Specifications may include descriptions of the operational workenvironment and interface hardware, if those are expected toconstrain MMI design, but will provide critical guidance for thedesign of MMI software with respect to the selection of dialoguetype, and the requirements for data entry/input, datadisplay/output, sequence control and user guidance.

WORK ENVIRONMENT

In itself, the design of a work environment seldom fulfillsfunctional requirements directly. (Exceptions might be noted forthe special requirements of merchandising, stagecraft, etc.)Instead, the general objective of workspace design is to minimizeconstraints on functional performance.

In many C3 system applications, the immediate work environmentis relatively benign, and does not constrain MMI design. But thereare exceptions. For example, the noise, dirt and confusion ofmovement at a truck dock may limit MMI options available for aircargo data entry (Smith 1976a; 1976b).

Even in clean, quiet office locations, poor workspace layoutcan handicap operator performance. Inaccessibility of paper files,inadequate workspace at an operator's station, badly positioneddisplays and keyboards, glare sources in unbalanced ambientillumination, all take their toll. It can be argued thatenvironmental deficiencies such as these contribute in large measureto complaints of operator fatigue after long hours at a constrainedwork station.

Although an optimal work environment can sometimes be specifiedin C3 systems, when that is not possible some limits on MMI designmay have to be imposed in order to accommodate sub-optimal workingconditions. As an example, mechanical vibration in airborne commandposts might hinder fine manipulations required for lightpen use. Anoisy environment can obscure voice output displays and otherauditory signals. A high ambient illumination, such as experiencedin an open control tower on a sunny day, can reduce the

25

effectiveness of light signals and other visual displays, which mayhave to be taken into account for some system applications.

Where a normal working environment can be assumed, it may bepossible to rely on standard procurement specifications andengineering practice to produce a good design. Where unusualworking conditions must be accommodated, however, it will benecessary to include a description of environmental constraints inthe MMI design specification.

INTERFACE HARDWARE

Although it is usually the logic and software implementation ofMIII design which prove most critical, hardware choices can affectimplementation and eventual system performance. Hardware here ismeant to include input devices, output display and signalingdevices, and also printouts, paper forms and other equipment whichmay be used in conjunction with the MIII. If the MIII is used tomediate person-to-person communication, which is becoming mcrecommon, then communication facilities should probably also beincluded under this heading.

Functional specifications for hardware, such as those fordisplay capacity, legibility, etc., are reasonably well understoodin C3 system acquisition and will not be considered further in thisreport. Such device capabilities should be included in an MMIlfunctional specification, however, if the physical requirements canbe determined in advance of MIII design. Ideally, of course,hardware specification should follow and derive from functionaldesign. In practice, it may happen that C3 system acquisition maybuild upon and hence be constrained by existing equipment.

The effect of hardware constraints on MIII design may be moresubtle than suggested by physical equipment specifications. As anexample, the technique and format of data input may have toaccommodate the nature of the data source, paper forms beingtranscribed, etc. For data output, display formats may have to beadaptable to document printing and other constraints. For sequencecontrol, hardware choices can have a pervasive influence. As anobvious example, the availability of a lightpen or other pointingdevice for selection of control options will permit more flexibledisplay formatting than the use of multi-function keys labeled indisplay margins.

Where anticipated hardware limitations will constrain MIIfunctional capabilities, these must be indicated clearly in thedesign specification, so that they can be taken into account and the

26

functional design compromised as necessary. Where MMI hardware canbe chosen freely, as in acquisition of a new system, it may bedesirable not to impose any special constraints, except thoseimplied in equipment design standards. The inclusion of detailedequipment "requirements" in system specification may be thought tosubstitute adequately for the lack of detailed functionalspecifications. For HMI design, however, with its heavy dependenceon software for effective implementation, detailed hardwarespecification may make good design harder to achieve rather thaneasier.

DIALOGUE TYPE

A fundamental decision in MIII design is selection of dialoguetype(s). Here dialogue refers to the sequence of transactions whichmediate man-machine interaction. Ramsey and Atwood (1979, pp. 76-95) identify eight general dialogues:

question-and-answerform-fillingmenu selectionfunction keys with command languageuser-initiated command languagequery languagesnatural-language dialogueinteractive graphics

Various sub-categories can, of course, be identified, asillustrated by the ma-ny examples in Martin's book on the subject(1973).

In C3 systems, MIII design will often involve a mixture of twoor more dialogue types, since different dialogues are appropriate todifferent jobs and different kinds of users. Recognition ofappropriate dialogue types at the outset of system development willfacilitate HMIl design and help ensure the effectiveness of eventualsystem operation.

The selection of dialogue type based on anticipated taskrequirements and personnel skills seems straightforward, at leastfor simple cases. Computer-initiated question-and-answer dialoguesare suited to routine data entry tasks where data items are knownand their ordering can be constrained, and provides explicitprompting for unskilled, occasional operators. Form-fillingdialogues permit somewhat greater flexibility in data entry, but mayrequire operator training. When data entries must be made inarbitrary order, perhaps mixed with queries as in making airline

27

reservations, for example, then some mixture of function keys andcoded commnand language will be required for effective operation,implying a moderate to high level of operator training.

From these examples, it would seem possible to judge for anyinformation handling task the type(s) of dialogue that should provemost suitable, and to include this judgment in the MMI requirementsmatrix and possibly in the functional specification as well.

One important aspect of dialogue selection is that differenttypes of dialogue imply differences in system response time foreffective operation. In a repetitive form-filling dialogue, forexample, the operator may accept relatively slow computer processingof a completed form. If the computer should take several seconds torespond, the operator probably can use that interval to set one datasheet aside and ready another. But several seconds delay in a menuselection dialogue may prove intolerable, especially where theoperator must make an extended sequence of selections in order toaccomplish a desired end.

Table 3-1

Estimated Requirements of Different Dialogue Types

Required Required System

Dialogue Type User Training Response Time

Question and Answer Little/None Moderate

Form Filling Moderate/Little Slow

Menu Selection Little/None Very Fast

Function Keys with High/Moderate FastCommand Language

User-Initiated Command High FastLanguage

Query Languages High/Moderate ModerateI

Natural-Language Dialogues Moderate Fast(potentially Little)

Interactive Graphics High Very Fast

28

To categorize these differences, Table 3-1 presents for each ofthe eight general dialogue types identified above an estimate of theimplied requirement for operator training and for system responsetime. Cumulative experience and specific requirements of aparticular task may lead us to modify such estimates. But thegeneral principle illustrated here, that one design choice impliesothers, must be taken into account in MIII specification.

Specification of dialogue type will also determine otheraspects of MIII design. Guidelines specifically appropriate toform-filling dialogues may be irrelevant for the design of otherkinds of dialogue. Eventually it may be desirable to codeguidelines in some way, to designate those pertinent for each typeof dialogue. Such coding would facilitate the tailoring ofguidelines to meet the MIII requirements of particular tasks.

For further comment on dialogues and system response time, seeTables A-10 through A-13 in Appendix A.

DATA ENTRY/INPUT

* Another way to categorize design guidelines is in terms oftheir relation to general MIII functions. A fourfold distinction isadopted here, to permit discussion of guidelines relat4ing to dataentry, data display, sequence control and user guidance. Data entryrefers to input by the operator of data items to be processed;command inputs or option selections intended to control dataprocessing are considered later in the discussion of sequencecontrol.

Data entry is heavily emphasized in tasks related to clericaljobs, and many other C3 tasks involve data entry to some degree.Because data entry is so common, because the requirements of dataentry seem to be readily understood, and because inefficienciescaused by poorly designed data entry are so apparent, many of thepublished recommendations for good MIII design deal with this topic.

Rather than trying to present here a long list of specificguidelines for data entry, they are included in Appendix C to thisreport. Certain important design principles, however, do deserve tobe emphasized in this general discussion, if only because some ofthese principles are so basic that they are seldom explicitlyexpressed.

Here is an example: an operator should not have to enter thesame data twice. Now that is something every designer alreadyknows, even if he does not often think about it. A corollary is

29

this: an operator should not have to enter a data item alreadyentered by another operator. That seems to be just common sense,although one could imagine occasional exceptions to the rule whencross validation of data inputs may be required.

How can we avoid duplicative data entry in practice? The keylies in designing the NIl (i.e., programming the computer) tomaintain context. Thus when an operator identifies a particularsquadron of interest, the computer should be able to access allpreviously entered data relevant to that squadron and not requirethe operator to enter such data again. If an operator enters oneitem of data about a particular squadron, it should be possible toenter a second item immediately thereafter without having to re-identify that squadron. In repetitive data entry transactions theoperator should have some means of defining default entries forselected data items, in effect telling the computer those items willstay the same until the default value is changed or removed.

Context should also be preserved to help speed correction ofinput errors. One significant advantage of on-line data entry isthe opportunity for immediate computer validation of operatorinputs, timely feedback so that an operator can correct detectederrors while that set of entries is still fresh in his mind and/orwhile documented source data are still at hand. Here the computershould preserve the context of the data entry transaction,remembering correct items so that the operator does not have toenter those again while changing ~incorrect items.

The preservation of context is, of course, important in allaspects of man-machine interaction, with implications for dataoutput, sequence control and operator guidance. The importance ofcontext will be emphasized again in the further discussion of thoseother general functions.

Another important design concept is that of flexibility. Theidea that the NIl should adapt flexibly to operator needs is oftenexpressed. The means of achieving such flexibility should bepelled out in MIII guidelines. For data entry functions it isimportant that the pacing of inputs be controlled flexibly by theoperator. Tasks where the pacing of operator inputs is set by themachine (for example, ZIP code keying at "automated" post offices)are stressful and error-prone.

Aside from flexibility in pacing, the operator will generallybenefit from having some choice in the ordering of inputs. Althoughthis kind of flexibility is related to the topic of sequencecontrol, it merits discussion here as well. What is needed in MI

30

design is some sort of suspense file(s) to permit flexible orderingof operator inputs, including temporary omission of unknown items,backup to correct mistaken entries, cancellation of incompletetransactions, etc.

As suggested earlier, the data input operator may also benefitfrom flexibility in defining his own default options to simplifyentry during a sequence of transactions. Some systems include onlythose defaults anticipated by the designers, which may not provehelpful to the operator in a particular instance.

It is obvious that design of data input transactions isnecessarily dependent on. hardware selection. For that reason,design guidelines for input devices receive considerable attention.A notable example is standardization of keyboard layouts. Forfurther comment see Table A-18 in Appendix A.

Future technological advances in input hardware may wellinfluence the design of data entry tasks, presaged perhaps by thecurrent advocacy of voice input. But the major need in C3 systemsis for consistently good software design. It is in improving thelogic of data entry that the chief gains can be made, and it is herethat design guidelines should prove most helpful.

DATA DISPLAY/OUTPUT

Data display, i.e., some kind of output from the machine to theoperator, is needed for all C3 tasks. Data display is emphasizedparticularly in monitoring and control tasks. Included under thisheading may be hardcopy printouts as well as more mutable electronicdisplays. Also included are any auxiliary displays or signalingdevices, including voice output, used to alert the operator ofunusual conditions. Displays specifically intended to guide theoperator in his interaction with the system are discussed laterunder the topics of sequence control and operator guidance.

In general, it may be said that rather less is known about datadisplay and information assimilation by the operator than about dataentry. In present C3 system design, display formatting is an art.Guidelines are surely needed.

Here again some general concepts deserve emphasis, includingthe importance of context and flexibility. Data displays mustalways be interpreted in the context of the operator's taskrequirements and expectations. An early statement of the need forrelevance in data display seems valid still:

31

When we examine the process of man-computercommunication from the human point of view, it is usefulto make explicit a distinction which might be described ascontrasting "information" with "data." Used in thissense, information can be regarded as the answer to aquestion, whereas data are the raw materials from whichinformation is extracted. A man's questions may be vague,such as, "What's going on here?" or "What should I donow?" Or they may be much more specific. But if the datapresented to him are not relevant to some explicit orimplicit question, they will be meaningless. This is alsotrue, in some degree, for the computer, which isprogrammed to accept and process certain kinds of data andnot others. However, the limitation in the case of theman is somewhat different, being more in the nature of agenerally low processing rate or attention span.

What the computer can actually provide the man aredisplays of data. What information he is able to extractfrom those displays is indicated by his responses. Howeffectively the data are processed, organized, andarranged prior to presentation will determine howeffectively he can and will extract the information herequires from his display. Too frequently these two termsdata and information are confused, and the statement, "Inieed more-information," is assumed to mean, "I want moresymbols." The reason for the statement, usually, is thatthe required information is not being extracted from thedata. Unless the confusion between data and informationis removed, attempts to increase information in a displayare directed at obtaining more data, and the trouble isexaggerated rather than relieved.

(Smith, 1963, pp. 296-297)

This distinction between data and information is still notfamiliar to display designers, although the issue itself is raisedrepeated'ly. Consider the following description of our current"information explosion", and notice how using the terms data andinformation interchangeably tends to confound an otherwise incisive(and lively) analysis:

The sum total of human knowledge changed very slowlyprior to the relatively recent beginnings of scientificthought. But it has been estimated that by 1800 it wasdoubling every 50 years; by 1950, doubling every 10 years;and by 1970, doubling every 5 years . . . . This is a muchgreater growth rate than an exponential increase. In many

32

fields, even one as old as medicine, more reports havebeen written in the last 20 years than in all prior humanhistory. And now the use of the )mputer vastlymultiplies the rate at which information can be generated.The weight of the drawings of a jet plane is greater thanthe weight of the plane. The computer files of currentIBM customer orders coiw:ain more than 100 billion bits ofinformation -- more than the information in a library of50,000 books.

For man, this is a hostile environment. His mindcould no nr're cope with this deluge of data, than his bodycould cope with outer space. He needs protection. Thecomputer -- in part the cause of the problem -- is alsothe solution to the problem. The computer will insulateman from the raging torrents of information that aredescending upon him.

The information of the computerized society will begathered, indexed, and stored in vast data banks by thecomputers. When man needs a small item of information hewill request it from the computers. The machines, tosatisfy his need, will sometimes carry on a simpledialogue with him until he obtains the data he wants.With the early computers, a manager would often havedumped on his desk an indigestible printout -- sometimesseveral hundred pages long. Now the manager is morelikely to request information when he needs it, andreceive data about a single item or situation on a screenor small printer.

It is as though man were surviving in the depths ofthis sea of information in a bathyscaphe. Life in thebathyscaphe is simple, protected as it is from thepressure of the vast quantities of data. Every now andthen man peers through the windows of the bathyscaphe toobtain facts that are necessary for some purpose or other.The facts that he obtains at any one time are no more thanhis animal brain can handle. The information windows mustbe designed so that man, with his limited capabilities,can locate the data he wants and obtain simple answers toquestions that may need complex processing.

(Martin, 1973, p.6)

Somehow we must find the means to provide and maintain contextin data displays so that the operator can find the information heneeds for his job. Task analysis may point the way here, indicating

33

what data are relevant to each stage of task performance. Designguidelines must emphasize the value of displaying no more data thanthe operator needs, maintaining consistent display formats so thatthe operator always knows where to look for different kinds ofinformation, and using consistent labeling to help the operatorrelate different data items, on any one display and from one displayto another.

Detailed operator information requirements will vary from timeto time, however, and may not be completely predictable in advance,even from a careful task analysis. Here is where flexibility isneeded, so that data displays can be tailored on-line to operatorneeds. Such flexibility is often provided in C3 systems throughcategory selection, optional display offset and expansion features.If such options for display coverage are available, the operator maybe able to adjust his information processing of data outputs in away analogous to self pacing of data inputs.

In tasks where an operator must both enter and retrieve data,which is often the case, the formatting of data displays should becompatible with the methods used for data entry. As an example, if

'I data entry is accomplished via a form-filling dialogue with ait particular format for data fields, subsequent retrieval of that data

set should produce an output display with the same format,especially if the operator is expected to make changes (and/oradditional entries) to displayed data. Where compaction of dataoutput is required for greater efficiency, to review multiple datasets in a single display frame, the displayed items should retain atleast an ordering and labeling compatible with those fields usedpreviously for data entry.

Display design should also be compatible with dialogue type(s)and hardware capabilities, as noted earlier. Where operator inputsare made via menu selection, using a pointing device like alightpen, then display formats should give prominence (and adequateseparation) to the labeled, lightpennable options. Location ofmulti-function keys at the display margin, to be labeled on theadjacent portion of the display itself, may provide flexibility forboth data entry and sequence control, but will necessarily constrainthe formatting of displays for data output.

For further comment on data display see Tables A-14 throughA-17 in Appendix A.

SEQUENCE CONTROL

Sequence control refers to the logic and means by which inputs

and outputs are linked to become coherent transactions, and which

34

govern the transitions from one transaction to the next. Techniquesof sequence control require explicit attention in MMIl design, and anumber of published guidelines bear on this topic. The generalideas of flexibility and context are i ?ortant in sequence control

as in other aspects of KNI design.

Idea] flexibility woulM permit the operator to undertake iwhatever task or transaction he wishes, at any time. Although thismay not always prove feasible, the MIII designer should try toprovide the maximum possible user control of the on-line transactionsequence. As a simple example, suppose the operator is scanning a imulti-page data display. He should be able to go either forward orback at will. If the Mill design only permits him to step forward,so that he must cycle through the entire display to reach a previouspage, that design is deficient. The operator should also be able tointerrupt display scanning at any point to initiate some othertransaction. Such simple flexibility is relatively easy for thedesigner to achieve, and indeed is commonily provided.

More difficult are transactions that involve potential changeto stored data. Here again the operator will need some flexibilityin sequence control, perhaps wishing to back up in a data entrysequence to change previous items, or to cancel and restart thesequence, or to abort the sequence altogether and escape to someother task. The MIII designer can provide such flexibility throughuse of suspense files, as suggested in the earlier discussion ofdata entry, and other special programmed features. This flexibilityrequires extra effort from the designer and programmer. But thatextra effort is made only once, and is a worthwhile investment onbehalf of the eventual operators who may interact with theircomputer system for months or years.

In one sense, flexibility of sequence control has pitfalls.Just as an operator may make a mistake in data entry, so also can hemake a mistake in sequence control. The MMIl designer must try toanticipate operator errors in sequence control and ensure thatpotentially irreversible actions are difficult to take. In dataentry tasks, for example, when an operator is satisfied with a setof keyed data he should be obliged to take some explicit action toENTER it for computer processing. The MMI should be designed toprotect the operator from the consequences of inadvertentlydestructive actions. Any large-scale erasure or deletion of data,for example, should require some sort of explicit operatorconfirmation, being accomplished as a two-step process rather than asingle transaction. This provides a software analogy to thephysical barriers sometimes used to protect critical hardwarecontrols from accidental activation.

35

One form of flexibility frequently recommended is the provisionof alternate modes of sequence control for experienced andinexperienced operators. In a command-language type of dialogue,optional guidance might be provided to prompt a beginner step bystep in his composition of commands for sequence control, whereas anexperienced operator might enter a complete command as a singlecomplex input. Some such flexibility is surely desirable -- Lointerpret halting, stepwise commands as well as fluent, coherentinputs.

More generally, however, it may be desirable to includeredundant modes of sequence control in MMI1 design, perhaps involvingcombinations of different dialogue types. As an example, menuselection might be incorporated to provide easy sequence control forbeginners, but every display frame might also be formatted toinclude a standard entry field where an experienced operator couldkey in complete sequence control commands more efficiently.Examples of this approach have been provided by Palme (1979).

Another way to provide flexibility in sequence control isthrough specific tailoring of display formats. Consider, forexample, a dialogue type in which sequence control is exercisedthrough lightpen selection among displayed command options. For anyparticular display frame it might be possible to display those threeor four options most likely to be selected by the operator at thatpoint in the task sequence, with perhaps a general purpose OPTIONSselection that could be used to call out a display of any other(less likely) sequence control commands. Thus, on the first page ofa two-page display, one of the likely sequence control commandswould be NEXT PAGE; but on the second page that command would bereplaced by its now more likely complement, PREV PAGE.

This approach illustrates two design ideas. The first is asclose as we will probably come to a general rule for sequencecontrol: make the operator's most frequent transactions the easiestto accomplish. The second idea is the reliance on context toimprove flexibility in NM1I design.

The importance of context in sequence control extends beyondthe example above, where likely control options are givenpreferential display. Context can be used to shorten command inputsduring sequence control and still permit unambiguous interpretation.In general, it will prove desirable to have the operator rather thanthe computer define the task context in which control inputs are tobe interpreted.

36

As an example, suppose that an operator wishes to assignseveral sorties of aircraft from a particular squadron to preplannedmissions. He should be able to specir; the squadron and then expectall subsequent commands to be applied to that squadron. Further, heshould be able to specify that he is making assignments and expectthat subsequent selections 7,f aircraft/crews and missions will beinterpreted accordingly. Ii context can be used in this way, theoperator will not have to take repetitious control actions, which isjust as desirable as avoiding repetitious data entries.

A potential pitfall here is that the results of a particularcontrol action, if contingent on context, may vary from one time tothe next. Thus aircraft selection in the context described abovewould result in mission assignment, whereas aircraft selection in adifferent context might result in unassignment, or allocation toready reserve, or perhaps commitment to maintenance status. Suchvariability may prove confusing to an operator. If the consequencesof control actions are made contingent on context, then the MIdesigner should ensure that the current context and its impliedcontingencies are always displayed to the operator. That will helpmaintain operator orientation as discussed next.

USER GUIDANCE

Many MIII design features contribute directly or indirectly toguide the user in his interaction with an on-line computer system.A general discussion here may serve to illustrate the range offactors that should be considered.

The primary principle governing this aspect of MMI design is tomaintain consistency. Design consistency is emphasized in allpublished guidelines. With consistent MMI design, the operator willlearn to use his computer tool more quickly and with moreconfidence. Consistency in the small details of MMI operation willhelp serve as an antidote, or stable counterbalance, to thefunctional flexibility advocated above. Without such consistency ofdetail, flexibility in MMI design may make a system easy to use byan expert but hard to learn for a beginner.

Design consistency implies predictability of system response tooperator inputs. A fundamental rule is that some response bereceived: for every action (input) by the operator there should besome noticeable reaction (output) from the machine processor. It isthis feedback linking action to reaction that defines each discretetransaction and maintains operator orientation in his interactionwith the system. In the absence of response, the operator willbecome frustrated and uncertain of proper machine functioning.

37

RON -"P-----

A rule such as this is so general in its application to MIIdesign that it is seldom stated explicitly. Because it would applyto any on-line information handling task, it might not be called outin a task-specific requirements matrix. There may be some otherdesign guidelines that also have this kind of general applicability.Such general guidelines could be referenced in the functional MIspecification for any C3 system acquisition, in addition to the morespecific design guidelines derived from task analysis.

Predictability of machine response also relates ,to systemresponse time. Timely response can be critical in'maintainingoperator orientation to his task. If a respoIs-,. is. received onlyafter a long delay, the operator's attention T~ have wandered.Indeed, he may forget just which of his actions the machine isresponding to. Frequent operator actions, generally those involving

simple inputs such as sequence control selections, should beacknowledged immediately. In transactions where output must bedeferred pending the results of computer search and/or calculation,the expected delay should he indicated to the operator in a quickinterim message.

Some experts have argued that consistency of system responsetime may be more important in preserving operator orientation thanthe absolute value of the delay, even suggesting that designersshould delay fast responses deliberately in order to make them moreconsistent with necessarily slow responses. To some extent such areduction in response time variability may be desirable. If systemresponse time is always slow, an operator may adapt to the situationand find something else useful to do while waiting. But surely thebetter solution is to make all responses uniformly fast, or wherethat is not possible to signal quickly the occasional slow responseas suggested above. In this way, an unusually slow response can bemade predictable although inconsistent.

As it happens, variability in response time is probably agreater problem in the design of general-purpose, multiple-user,time-shared commercial systems than for most C3 applications. WhereC3 systems are designed to accomplish defined tasks in a predictablemanner, data processing loads can usually be anticipatedsufficiently well in MIII design to provide adequately quick responsetime.

Consistency is also important in other aspects of MIII design.Display formats should be consistent from one frame to another,including always a title at the top to tell the operator where heis, labels to indicate page number in related displays, standardlabeling of control options, standard positioning of guidance

38

messages, etc. Messages indicating operator error should becarefully worded to be both concise and informative, consistentlyworded from one message to the next, and consistently located in thedisplay format.

Even such a subtle feature as cursor positioning at displaygeneration should receive consistent treatment in MMI design.Consistent positioning is particularly helpful to the operator ifthe cursor does not have a prominent appearance and/or the means ofmanual cursor positioning are inconvenient. At display generationthe cursor should be placed in its most probably useful position,such as a data entry field. If input errors are detected, thecursor should be placed in the first data entry field requiringcorrection in the regenerated error display.

Data entry is also facilitated by consistent treatment of dataentry fields on the display, including consistent wording of labels,consistent placement of labels with respect to entry fields, andconsistent demarcation of the fields themselves. Underlining isfrequently recommended for field delineation, displaying clearly tothe operator where each field is located and also its definedextent. Even more guidance could be provided by consistent use ofdifferent underlines to indicate different types of data entry,perhaps dots where optional entries can be made, and dashes whererequired entries are expected.

For sequence control, consistent guidance will- also provehelpful to the operator. As a general principle, the MMI designershould not rely on the operator to remember what he has just done,or even what he is currently doing. Operators are often distractedby competing job demands. For extended transaction sequences thedesigner should arrange to display a cumulative record of controlactions for operator review. For control actions whose consequencesare contingent on context, an indication of that context shouldalways be displayed even if context was defined by the operator, asrecommended in the earlier discussion of sequence control.

Another design feature that can help guide the operator isconsistent provision of an OPTIONS display, a "home base" to whichthe operator can return from any point in the control sequence inorder to select a different transaction.

Although consistent MIII design will provide much inherentguidance to the operator, it is often also desirable to include incomputer-generated display outputs some explicit instructions orreminders to the operator. Such instructions should be consistentlylocated in display formatting, perhaps always at the bottom where

39

they can be ignored by experienced operators. For inexperiencedoperators it may be desirable to provide supplementary guidance orjob instruction, optionally available in response to operatorrequest, perhaps through selection of a HELP or EXPLAIN option.Such optional guidance will help adapt the 1111 to different operatorcapabilities, supporting the novice user without hindering theexpert.

It should be clear that a general discussion of the kindprovided here offers some perspective to the MIII designer, butlittle direct guidance. General principles must be elaborated inspecific guidelines, as illustrated by the sample set for data entryfunctions proposed in Appendix C. Further, there must be some meansof comparing proposed designs with those guidelines, as discussed inthe next section of this report.

40

SECTION 4

DESIGN REVIEW AND VERIFICATION

Having decided what is needed in MMI requirements definition,and having specified what is needed in design guidelines, the thirdstep is to ensure that what is specified will actually be includedin the MMI design. Some review process should be established topermit early verification of a proposed MII design before itssoftware implementation, and continuing design coordinationthereafter.

DESIGN DOCUMENTATION

The key to effective design review lies in documentation. Insystem acquisition it has become customary to require documentationin advance of design, at least for critical design elements. Insystems where MII design is considered critical, which probablyincludes most C3 systems, documentation should describe interfacecharacteristics influencing software design as well as hardwareselection, including for each on-line transaction the expectedinputs, required data processing, format of displayed outputs, andthe associated sequence control logic.

There are several ways in which documentation of MII designcould be specified. First, a standard Data Item Description (DID)might be interpreted to require system development contractors toprovide MMII design data. The most obvious candidates would be thecurrent (1979) DIDs for human engineering design, DI-H-7056 forsystem operation and DI-H-7057 for maintenance. Although these DIDsare primarily oriented toward equipment design and workspace layout,there is some implied acknowledgment of software design: "Displaysymbology, display formats and control/display operation logic shallbe described with regard to intended use by the operator(s)" (DID-H-7056, 1979, page 2). Further, there is a stated requirement toinclude "narrative which provides rationale for any need to deviatefrom, or take exception to, MIL-STD-1472 or other contractual humanengineering documents" (DI-H-7056, 1979, page 3). Presumably anycontractually-imposed MMI design guidelines might be considered asfalling in this "other" category.

A second approach might be to modify an existing DID to dealmore specifically with 11I design. It is evident from the meagerquotations cited above that DI-H-7056 provides little specificguidance to a contractor as to just what should be included in the

41

description of MIII design. But that DID could be expanded for aparticular system acquisition to indicate more clearly what isneeded.

A third approach might be to draft a new contractualrequirement dealing specifically with MMIi design, thus creating aso-called Unique Data Item (UDI). This approach might serve forinitial exploration of the usefulness of MIII design guidelines, butin the long run a more standardized approach will be desirable sothat a new UDI does not have to be created for each new program.Standardized documentation requirements in the long run shouldaccommodate the needs of all military services, since there is astrong emphasis within DoD toward eventual adoption of unifiedprocurement standards.

Whatever its eventual designation, the contractual requirementfor contractor documentation of MIII design should probably specifyboth the content and the format for description of the MMIi. Withlittle precedent for such documentation, one example is the approachproposed by Pew and Rollins (1975) to document display formats, datainputs, operator actions and their consequences. This approach toHMIl design documentation is discussed further in Appendix D.

DESIGN REVIEW

The purpose of MMIi design documo'ntation is review andcoordination. Design review offers several potential advantages.Early review would allow critique of inadequate design featuresbefore actual implementation. At this stage, suggestions forimprovement of MMIi design would not entail the costs and delays ofsoftware modification. To permit effective review, the contractorshould document the proposed MIII design so that it is clearlyexplained to both system developers and intended users.

In some system acquisitions the contractor may be encouraged topropose additional MIII design standards beyond those included in thesystem specification. Standards proposed by the contractor shouldbe included in MMIi design documentation, so that design review candetermine whether MIII functional requirements will be met.

In an acquisition program involving modifications to improve anexisting system, rather than development of a completely new system,the contractor may be asked to define MMIi guidelines consonant withcurrent procedures, which represent de facto design standards.Again, MIII design documentation will demonstrate contractorunderstanding of functional requirements. With increased emphasison incremental procurement in system acquisition, modification and

42

expansion of existing system capabilities may become the typicalmode of future ESD system development programs.

One aspect of MIII design review deserves particular attention.In many C3 systems the MIII represents such a significant andpervasive element of the total effort that review of MIII design canbe a large first step in reviewing overall system design. Ifoperators are to be intimately involved in critical systemfunctions, then a detailed review of proposed operator functionswill go a long way toward understanding system functions. Thus adocument describing MIII design could, with some amplification toinclude internal data processing and interfaces plus relevantexternal constraints, become a description of the larger informationsystem in which the operators will work.

Such reference to MIII design in order to clarify understandingof more general system operation can prove helpful in systemacquisition. In ESD programs there is evidence that MIII designdocuments have sometimes been generated informally, outside ofcontractual requirements, as a spontaneous aid to overall designreview and coordination in system development.

DESIGN COORDINA'TION

Documentation of MIII design could serve a variety of purposesin design coordination. During initial software implementation, anMI "design handbook" could provide a single reference to helpcoordinate the contributions of different people in hardware andsoftware engineering groups. Such a handbook could also provide thebasis for configuration management of MIII design, as subsequentchanges are proposed to initial implementation.

For the purpose of coordination, MIII design documentationshould include a sunmmary of the guidelines actually used, i.e., asadapted from initial design proposals to take into accountsubsequently imposed software tradeoffs, hardware constraints, etc.In effect, the MIII designer should document his work as if he weretelling someone else how to do it.

Such explicit documentation of system-specific MIII guidelinesis presently rare, but is nonetheless needed. A recent example isprovided in a NASA report of MIII guidelines providing a sort ofdesign handbook for Spacelab experiments:

The purpose of this document is to present CRT displaydesign and conmmand usage guidelines applicable toexperiments utilizing the Experiment Computer Application

43

Software (ECAS) for use by Spacelab scientificinvestigators and experiment designers. It is expectedthat most Spacelab experiments will have need of suchdisplays.

The guidelines, while not given as strictrequirements, explain recommended methods and techniquesfor presenting data from the ECAS program via the DDSdata display system to the payload crew. The user isencouraged to apply and follow them, although otherconsiderations (memory conservation, etc.) may force atrade-off in specific instances. Used as a reference, thedocument will be an important aid in standardizing thecrew/experiment interface among the different payloods andshould result in lower crew training time and increasedefficiency of the payload crew in onboard experimentoperations.

(NASA, 1979, page 1-1)

An MMI design handbook could also provide timely information tocoordinate the preparation of operator manuals and trainingmaterials in parallel with design implementation, in the course ofsystem development.

MMI design documentation could also continue to provide helpfulguidance after system implementation, for users who may wish to addor modify displays, operator inputs, sequence control logic, etc.,in order to meet changing operational requirements. That may becomemore common in the future as existing C3 systems are upgraded ratherthan new systems built. In such situations, it could be importantto maintain consistency in MMI design between "old" and "new"

portions of a system.

It may seem redundant to keep a written desciption of MIdesign once a system is operating. Why not just look at the actualon-line interface to see what it is like? Certainly it is true thatoperational use can provide valuable insight into the advantages anddrawbacks of any particular MII design. And it is operationalperformance that provides final design verification. Butoperational use is a slow and inefficient way to review some designfeatures, for example, to discover system response to inputs seldom

made and transaction sequence paths seldom taken.

Moreover, the principles underlying MMI design, the functional

requirements and the chosen guidelines for meeting them, willprobably not all be evident in operational use. It may well be

easier for future designers and users if those principles can be set

44

down explicitly for each system, as well as more generally for allsystems. Which brings this report full circle in itsrecommendations: system analysts should define and documentfunctional MMI reouirements as guidelines for the designer, and MMI

designers should in turn document for the system user what they havedone.

45

SECTION 5

CONCLUSIONS AND RECOMMIENDATIONS

This report proposes that a significant program of work beundertaken. It marks a beginning, not an end. Thus only tentative,interim conclus 4ons are offered, and the chief recommendation isthat the work be carried forward. To follow the approach outlinedhere, the next steps involve further development of tools for lMfIrequirements definition and design, and evaluation of theapplication of those tools in C3 system acquisition.

Three kinds of tools have been proposed:

1. An MII requirements matrix, a systematic tabulation ofthe functional capabilities required by differentoperator tasks, to permit requirements definition inadvance of MIII design. The concept of a requirementsmatrix is described in Section 2 of this report andillustrated in Appendix B. A tentative conclusion isthat this requirements matrix could prove a usefultool, at the least providing a check list forsystematic consideration of MIII requirements, withsome potential promise as an effective means ofcoordinating analysis with design. Furtherdevelopment of this requirements matrix is recommendedin conjunction with evaluation in system acquisition.

2. MIII design guidelines, a compilation of availablewisdom, to be tailored to the requirements ofdifferent system applications. Design guidelines arediscussed in Section 3 of this report and illustratedin Appendix C. A tentative conclusion is thatguidelines can be found for the design of certaincommon MIII functional capabilities, and that these canbe related at least approximately to the requirementsmatrix, with potential for tailoring. It isrecommended that the sample set of guidelinespresented here be expanded to provide broaderfunctional coverage, and then evaluated in systemacquisition.

3. Design documentation, some means of specifyingdetailed MIII design for coordination and review inadvance of software implementation. Design

46

documentation is discussed in Section 4 of thisreport, and one possible approach is illustrated inVAppendix D. A tentative conclusion is that suchdocumentation could prove useful for both initialdesign and subsequent design modification, but that itis not clear just what are the proper means forimposition of this special documentation requirementin system acquisition. This question should beexplored further, until a formal documentationrequirement can be developed.

All of these proposed tools must be applied to assess theirvalue. Discussion of the possible utility of these tools for MIdesign is an interesting exercise in armchair philosophy, but willhave no practical effect unless carried forward and tested in actualsystem development. Certainly no Air Force or DoD design standardcan be justified on the basis of this discussion alone, withoutpractical evaluation.

In Section 1 of this report, a long introduction of backgroundmaterial concluded with a call for a collaborative effort, askingpeople responsible for system acquisition to join in the developmentand evaluation of tools for MIII design. A call for jointparticipation is appropriate again here at the conclusion of thisreport.

Are you involved in a system acquisition program where MIIdesign will be critical to effective system operation? Could an MMIlrequirements matrix help define needed functional capabilities?Would guidelines help MIII design and software implementation? Willformal documentation of MIII design help system development,evaluation and future operation? If so, consider using the toolsproposed here.

*1 47

REFERENCES

ARI (Army Research Institute for Behavioral and SocialSciences). Development of Design Guidelines and Criteriafor User/Operator Transactions with Battlefield AutomatedSystems, RFP No. MDA903-79-R-0218, 1979.

Calhoun, G. L. Control logic design criteria for multifunctionswitching devices. In Proceedings of the 22nd AnnualMeeting. Santa Monica, California: Human Factors Society,1978, 383-387.

Chamberlain, R. G. Conventions for interactive computerprograms. Interfaces, November 1975, 6(1), 77-82.

Chariton, D. R. Man-machine interface design for timesharingsystems. In Proceedings of the Annual Conference. NewYork: Association for Computing Machinery, 1976, 362-366.

Clap: , J. A. and Hazle, M. Building Blocks for C3 Systems,ESD-TR-77-360, Electronic Systems Division, AFSC, HanscomAFB, MA, March 1978, ADA052568.

DI-H-7056. Data Item Description: Human Engineering DesignApproach Document - Operator. Washington: U.S. GovernmentPrinting Office, 1 June 1979.

DI-H-7057. Data Item Description: Human Engineering Design

Approach Document - Maintainer. Washington: U.S.Government Printing Office, 1 June 1979.

Dzida, W., Herda, S. and Itzfeldt, W. D. User-perceivedquality of interactive systems. In Proceedings of the 3rdInternational Conference on Software Engineering, IEEECatalog No. 78CH1317-7C, 1978, 188-195.

Engel, S. E. and Granda, R. E. Guidelines for Man/Display

Interfaces, Technical Report TR 00.2720. Poughkeepsie, New

York: IBM, December 1975.

Foley, J. D. and Wallace, V. L. The art of natural graphicman-machine conversation. In Proceedings of the IEEE, April1974, 62(4), 462-471.

48

Goodwin, N. C. Man-machine interface characteristics.Published as an Appendix in J. A. Clapp and M. Hazle,Building Blocks for C3 Systems, ESD-TR-77-360,Electronic Systems Division, AFSC, Hanscom AFB,MA, March 1978, ADA052568.

Green, E. E. Message design -- graphic display strategies forinstruction. In Proceedings of the Annual Conference, NewYork: Association for Computing Machinery, 1976, 144-148.

Hansen, W. J. User engineering principles for interactivesystems. In AFIPS Conference Proceedings, 1971, 39, 523-532.

Kennedy, T. C. S. The design of interactive procedures forman-machine communication. International Journal of Man-Machine Studies, 1974, 6, 309-334.

Krebs, M. J. Design principles for the use of color indisplays. In SID International Symposium Digest of Papers.Los Angeles: Society for Information Display, 1978, 28-29.

Martin, J. Design of Man-Computer Dialogues. EnglewoodCliffs, New Jersey: Prentice-Hall, 1973.

MIL-H-48655B. Military Specification: Human EngineeringRequirements for Military Systems, Equipment and Facilities.Washington: Department of Defense, 31 January 1979.

MIL-STD-454F. Military Standard: Standard GeneralRequirements for Electronic Equipment. Washington:Department of Defense, 15 March 1978.

MIL-STD-483. Military Standard: Configuration ManagementPractices for Systems, Equipment, Munitions, and ComputerPrograms. Washington: Department of Defense, 31 December1970.

MIL-STD-1472B. Military Standard: Human Engineering DesignCriteria for Military Systems, Equipment and Facilities.Washington: Department of Defense, 31 December 1974.

Miller, R. B. Response time in man-computer conversationaltransactions. In AFIPS Conference Proceedings, 1968, 33,267-277.

49

NASA (National Aeronautics and Space Administration). SpacelabExperiment Computer Application Software (ECAS) DisplayDesign and Command Usage Guidelines, Report MSFC-PROC-711.George C. Marshall Space Flight Center, Alabama, January1979.

Nickerson, R. S. and Pew, R. W. Oblique steps toward thehuman-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 Modelsand Computer Aids for Human Performance, Report No. 2190.Cambridge, Massachusetts: Bolt, Beranek and Newman, Inc.,June 1971. (NTIS No. AD732913)

Palme, J. Interactive Software for Humans, Report FOA-C10029-M3(ES). Stockholm: Swedish National Defense ResearchInstitute, July 1975.

Palme, J. A human-computer interface for non-computerspecialists. Software - Practice and Experience, 1979, 9,741-747.

Penniman, W. D. Past chairman's message. SIG NewsletterNo. UOI-1O. Washington: American Society for InformationScience, May 1979.

Pew, R. W. and Rollins, A. M. Dialog Specificatirn Procedures,Report 3129 (revised). Cambridge, Massachusetts: BoltBeranek and Newman, 1975.

Pew, R. W., Rollins, A. M. and Williams, G. A. Generic man-computer dialogue specification: an alternative to dialoguespecialists. In Proceedings - 6th Congress of theInternational Ergonomics Association. Santa Monica,California: Human Factors Society, 1976, 251-254.

Ramsey, H. R. and Atwood, M. E. Human Factors in ComputerSystems: A Review of the Literature, Technical Report SAI-79-111-DEN. Englewood, Colorado: Science Applications,Inc., September 1979. (NTIS No. ADA075679)

Ramsey, H. R., Atwood, M. E. and Kirshbaum, P. J. A CriticallyAnnotated Bibliography of the Literature of Human Factors inComputer Systems, Technical Report SAI-78-070-DEN.Englewood, Colorado: Science Applications, Inc., May 1978.(NTIS No. ADA058081)

50

Rouse, W. B. Design of man-computer interfaces for on-lineinteractive systems. In Proceedings of the IEEE, June 1975,63(6), 847-857.

Smith, S. L. Angular estimation. Journal of AppliedPsychology, 1962, 46, 240-246.

Smith, S. L. Man-computer information transfer. In Howard, J.H. (Ed.) Electronic Information Display Systems, 284-299.Washington: Spartan Books, 1963.

Smith, S. L. An On-Line Model of Traffic Control in aCommunications Network, Technical Report MTR-2813. Bedford,Massachusetts: The MITRE Corporation, March 1974.

Smith, S. L. MAC Air Cargo Data Entry: 1 . PreliminaryAnalysis of Alternative Modes, ESD-TR-76-162, Vol. I, ElectronicSystems Division, AFSC, Hanscom AFB, MA, August 1976a, ADA029013.

Smith, S. L. MAC Air Cargo Data Entry: 5. Field Testing anOn-Line Terminal at the Dover Aerial Port, Technical ReportMTR-3066-5. Bedford, Massachusetts: The MITRE Corporation,30 June 1976b.

Smith, S. L. and Goodwin, N. C. Computer-generated speech andman-computer interaction. Human Factors, 1970, 12(2), 215-223.

Smith, S. L. and Goodwin, N. C. Alphabetic data entry via theTouch-Tone pad: A comment. Human Factors, 1971, 13(2),189-190.

Stewart, T. F. M. Displays and the software interface.Applied Ergonomics, 1976, 7(3), 137-146.

Thompson, D. A. Interface design for an interactiveinformation retrieval system: a literature survey and aresearch system description. Journal of the AmericanSociety for Information Science, 1971, 22, 361-373.

Uber, G. T., Williams, P. E. and Hisey, B. L. The organizationand formatting of hierarchical displays for the on-lineinput of data. In AFIPS Conference Proceeding , 1968, 33,219-226.

51

Wasserman, A. I. The design of 'idiot-proof' interactiveprograms. In AFIPS Conference Proceedings, 1973, 42, M34-M38.

Williams, T. J. (Ed.) Guidelines for the Design of Man/MachineInterfaces for Process Control. West Lafayette, Indiana:Purdue University, January 1977. (NTIS No. ADA036457)

52

APPEND~IX A

SUMMARY INFORMATION RELATING TO MIII DESIGN

This appendix presents tables taken from the report on humanfactors in computer systems by Ramsey and Atwood (1979). They arereprinted here by permission. These tables summarize informationrelating to various aspects of MIII design, and thus provide a usefulsupplement to various topical discussions in the text of thisreport.

The tables have been cited in the text, but are presented hereseparately to emphasize their independent provenance. These tablespreserve the titles provided by their authors, and are in the samegeneral order, but their original "Figure" numbers are changedsomewhat here. The Ramsey and Atwood report, of course, containsmuch more detailed information than can be included in these tables,and should prove an important source document for MIII designers.

An explanation is needed of the reference notation used in thetables. The listed references are cited more completely at the endof their source report (Ramsey and Atwood, 1979), and can also befound in a separately published annotated bibliography (Ramsey,Atwood and Kirshbaum, 1978). References marked with a singleasterisk indicate reports of survey, questionnaire, or summarizeddata. A double asterisk indicates a report of performance data ordetailed results of experimental studies.

53

Table A-1

Properties of Some Major Classes of Interactive System User

*0 I.Co

41 -- u41

* ~~~ w ~ C ~ aOSVw 0C

U 4L VL~ C7, .1

a) 00C w 04 L C

1. i4 - 10 94 C -LI .ZZ 4

L. . 0 410 10412. 9lu C4 C C .1010 ac, w0w4 U, 0 414141 41 L- L

V ~ 2 -- ,O aiwa )

4100- 4141 4 c- 3: 41 C-41~~~*E~~41~ 414,. 0 .. 0 C4

C0 C~1 0 V

C01. C09.c 3,0 " ;41.0414. CL 41 L.- rC 04 4 C

a4 L > , . 4 1 9

4 1 0L1,- -4 0, a- -,

As1~ 4uC L.41 C0 ~ 9 C

Go 4010 0 :P- LE 2 U41 MC7. ~ .4 O - 441 LoC V 0CL o0~ ~ Z0. 4 - C L L2 41 91 C-L 41L CL- 2 AO.C7 a 4.

ao 1 Q M.Cq M 41 0 3 .A ,0 Is

4J 110 L A 0. z VC 0 CuA. uC a

W~~0 0

41 04140 .0C4

41~. 2.94 0 1 -

-~6, 411C9C'A * 0 . .~ C41 4# 1 4 1 0 I C O .1 4

L~~~ 41 41 , C 0 01

CL

5-4

Table A-2

User Responses to Inadequate System

I. 0

I 0= Z 0 . w

0U IO-c-

U. =.. m ~ z-

W : g~o, - L.-

L.. - 4,

w, 6o Q- C C4

L. .L- w ~

c o LI I v

L..e1 11

B 5

Table A-3SttsiaSude

RepresentativeExmlso Sttsia Sudeof User Behavior in Time-Sharing Systems

.0-1 C

C2 0.

0I C- CCr_ ~ 61 L.~ OC V1-f L

-0 L0 .' V

61w

C 40 C. G

4-0 a* - -

0. 61 V, Cc4P- -11 - 3 ~4P 6 :C :1

..W e .0 -CLw

610 C. 61 400 .

V ~ L C1 ~ I6~.IC C U

C ~ ~ 0.61L 61~'A

0. V61 C. * 10.0C - ' t~~~~~~~~ CM0 1 ~ 6a'1 C'a 64) 61C *EI E I C1VI .. .. - .6

0-61 C CCC~ 613 '-50

~61 t1

V -C . N C

Table A-4

Requirements Analysis: Questionnaire and Survey Methods

10 ED

41w & 4.

.4~L 00 C .0.6 U 41 g

C

41

*si456sLAaAo puje saseLq ewuautunLf jt 'UIDLJpUbLS ULPIuO31 XOW pUwpISuosj.Aedwo3 aounL.01.Aad ahA43afqo 01 puodsa.jo0D ol I~v ual~a s5upe.i

aA 33OqnS OS0B4J j; Butqj.asap jou *qop 9 6ULO itjjdxa S .asn01 *33 'Sqe4 4.Lom 's~uaajnbaj uoLPW.o;U ;qoC eal ;o uodp.ts

sl safibLt4:,aj XaAafls PUR aJLVuuoLjsarib jo UOLIVIWLL 6ULPJ.AJOAO UV

41 41 4& ow S.

0.g'l a 40w 452 L.4"410

Z.I.j =C CO. 4,-.C ' 4,4c v1 c J. 2 10 IOM - O. " U

V...! 0 - 0 0.1- cw

L. =SW 0 - CC%

0.O0~ ~. L..- u 4 4 J-~V 1 . .5

~~.6 .0~ wR 41. 41 0L4 V

4. V L c-C w~ wO 4,1C 41

64 CC 5. 4jC Mc0w0U. aU. 0 40 w a c 5 0.21 k -1

'A 'a IU 2 1 C 4 21 .C. C s z .

cz 9"i St 10- 0W.0 C 0C a

CL 41aU UV. L 41Sa~ 55

4w Cw 4141c4Or-

6~C 0 c L w CL 116 41V.

w.4 V.0 U4 4 062- Q

1. V.

41 S* ,t.L4 0,4 0lV

5'2

Table A-5

Requirements Analysis: Interviews and Field Observation

a W~

.01

Vo 10-t - . C 14-9-.0j 0 L4)c

- !!4

Ce 0- 0,00

CW Z IV, 81 0. oo

C. OU 15 0-M

WC *... W L 81% C '0 C8

1= 910 "1 c0 8- U0h U813C L(C. ~ ~ 0 r5CC-M' . MM

0 cU' I 100 ~ 0

0 c C- f- 00 1 ..- 8

41 Cc1 cL -W I * M IMO0- W 0*

M= -ISU Z~. a, C- U( C CL .0W Z,41 c1 0. C ~ 1C 0

L~'1 1C. -~(1 . . U -2.00 41 8

- 0 0-.'8183 0

.5 L . 0 Z 0.!e 40 LC LC 1

81000 000~ ~ Z 88 .0. . =-.0

001L.,0 "0 . c 2-.. 0 ~ IN

-~ ~~~~~~~ 1~.L V WE8 1 08 80 £ , 0 0

.AC8-~810 0.~81- 0 C08 L 1C0 0.1

C C8 40

V 1 " e 81 C810 c Vj'a,'a -

00 U .

0 VO C 0£~ Is

Table A-6

Requirements Analysis: Simulation and Gaming

~0%

0

w C. 05 L~

0iJ ale Z" W =2C

405 I - .4L.. w5W L - 0 6

Lwe 1. CIL3. w- 4 CL= M 4.

L. .. 0.8 c t

, U w 1 ~

w-. ...c. - 0 -~ -a1-.x

x tj . U W ~ 0O -

w 0 0 V IS - .0 ZL . Q.c . . )- -wC

6-aC E0 1 "W0 w0z C

-j- 00 CLI 2:2-- M6 .- L -

V I It5i

C CL~ L .

IS L f C 30'O 49 C

-00 C GE .vI

41 202~.~

c - u a w-

59

Table A-7

Major Approaches to the Modeling of Interactive Systems

06~

44' 4

2 'A~.

1w' .C 3JV0.- J

OG w 0 a -

1-0 4 a . c =4GJ 4Jj-~

4) Il v' 0 '01 70o. -. 5Z oJ

o t- . Z 4,-8 - w'~ Q41I.O.L4J4~ o-3 a ' 0J jL

!4 ~ . S > C " . 0 -3- cV. 60'- -0-L~ 'U~4~-~

W 2 0 ~ ~ ~ ' CV w IQ 2 4 0 4 0 4 '

.62'flu v4J A~p~L A -

t' A . -~.

D.".'L0. ~ .. " 06*

Table A-7 (Concluded)

Major Approaches to the Modeling of Interactive Systems

i t

," 'C

W C. rt -2"

---.0 ,.ac: C C .. + - +

I,- - .- -.. .... ...

:. V ' +.. .. -+ . + C- --. :.... ..4 -. . . 0 -0%:

~~L.C2J4D: LI ) J

_0 A++ - = + -C .0 8 -- = =_• . -LC C- L k . 3=--0 C+n

I)- - _ .- ) ..... C I - 3. I

0CO . C' . .0'..

j . 1 --- J : o -C I) C I)=+ + -.. 0 I° =.' I . . . . . . . .

G -0.-4-,, '-0 %- ....00

.0%a. w V 0 0 AV t W

A3. CL~ 0,4CQ 0~,0CII)C 0 c'm0~Ii.:CJ 'C L~ C -3C6OA

Table A-8

Basic Subtasks or Phases Involved in Problem Solving

4Z -0~ ~

*~ ~ ~~' K1. 4 0 ) 4I % % C' &

CCL~~~~~~~~~~ &00E Q 0-O 03 p4.d-44 -L. LC...L4

- t~ C O U -E A %

tZ L4 SC C

46! 0 0 3 3 CL.,-

430 0-'' 0C CC La 'C C C

itC4nf C! V4114 0 .2 4 a

43L~4 43 V3.z T-.2

4) E'0 1 0' z ~'

U C 43 C C - V'C 11 4

C10. 4)4 W4 CNM 0t C

t0 3 C ;3)4 . 3 CC

.-. CC LICC C'CC 0 C*.

LLC 6a 4644 C 2430 C E

4, -1 31U 14 3. C''

144 C )41 I -LO 434 0~ ".4624

Table A-8 (Concluded)

Basic Subtasks or Phases Involved in Problem Solving

UIC

c4 6 c

.o 0 .w'

co _~ 0~' o- o ~1.

-~ ~ -1aL' 014. - 4 >50Q r- w1 0 0 w "I-

4.1 09- 42 -1 C-r1U .- - a - =

m W 4) u- m -:

oU o3'1 r-1 4) m MM c V >.C

m~ 40'5'C >059 411. a0

*c > a'.CO- 41U C0 .2 GJ.>..- 41. z .4 9-0 a, U

o i. 0 9. . -lo .C o-9 c4 4) 0 -. 540~ O.C 11 WC10 w-.4 -.. o 14 0. wU >

0.a0.xj4' 41 c '5 3 4> > .9 W1

o. c1 o10 14 - M ~ w4 3-. a M z co L C -) 0.O cm- 414 *-.' v~. w. OW

0 .!: ,Qo .E 'D 00() - .o c.'4 M441 . .4'- 9

9-41 0 4109- 95 4 o '. 3W 0C ~ U 4 4M~4 ~ 9~'~' M1 QU M1~ 1 .- ~ 0M.' C4 03 4 9 ,4 -44 M101C 'D -- m ~ 6

41 .4D v4

409-41 a CI.- a- m. 21 0.09 a1' ol 95 a

w 15 o 1 >1-4C3'-t40ol 1. M w aa ' or- .-

M I.,- w10.=4 -=41o

o 'a W--5_95 = r 0-

4)0 4111- L0.- 4) -. rC1,~ .

G-3.- -w

- -115 41 41 I 5 41 a 41-)z wL 9541' C _;4s1m 2.5.6L - .4;

41C41~~ 0.- r~ I4U-1O40

lo9 -0. -L410-0.a V-1 O 0. 9-D o1.-1.94 .4.9

o o 2 5 -'.9-0 w

41 4. 4.Q.4 aC M14 w 41

-0 -C C

495c 'a ~

63

Table A-9

Types of Problem-Solving Aids

i -'a

1!! 2 . ~ K

I =, _W ' Z. .- 214 1044

1- ~ ~~~~ C44= 1c.1

411- 33.0 41~0 01,1 4 0 1 40140I.044

411 40 0441. , FwC 1~ 1 1 .4 >

CL 4 41 <4,1111 Z 11 14 0 >

I 0.64

Table A-9 (Concluded)

Types of Problem-Solving Acids

*=01 I; -0c

E 0I

- C - zS .~ , ,

* ~ ~ JC0.~

a~~ ~ 0 0 ,1 ---

02 'S E -8 S

21 I I" w .. c I I C IW,~ v -o

SaCZ 0CC Q.S !.0C S' -

a CA

~* ~*.-~CcK=_5U X OCS - -

It 0 CC

*-Lr.x SC S-S C

Table A-10

Some Major Properties of Interactive Dialogues

3- w.w a- ,o

3U, 00 a0,0 0

C Z rz

6~~ t, .T = z 7 W

7 .

7.* - 4'L,- ~ -I 0 '

4' 33 3s-- 0~4 4)O0, - .-- ~5a4'9 -3

t0~ 0 %

w0 3L. V . 06 ' 6 300 3.

00~ ~~~~~ c~~.00 -~ -'

46 41

Table A-10 (Concluded)

Some Major Properties of Interactive Dialogues

Z t 7;101-

aa -

2 7.0. -0~

I. IV L

00 . 0C 0 - -Z.. c -

UL Mc-. .0 '

v=,,e . ,0.ca V

12 , - CC 4

'.3 4o 109 11 8C4

Vt. £0454 0.c 4 0 0 674

2Table A-I

Summary of System Response Time Effects

'n *nO0c

o CO 0 -

0.. ;- C E'n4.,-" 0)0 Ov -

I.. N. "

4-- -

a!

C 4..)4aa.. U400) JE . 4- * ES." -u

in 0- )0 0)L- u fl..- ON .0 *1 4-

D0 o o w

0. 4-'4-flM

W - "- .00 * )

o 0 4.j

ana .. -

o A U ) CCOtoV

>4-'C4) DJ

o w XS.-- 0

4J. 4J +-) S.. o-1M M t

, n L-. - ,. C. 0-

Cl - CA U0 -):

68

4JJ

Table A-12

Basic Interactive Dialogue Types

I *' : - '

I K. :1p , 4. .

f, t - 3 1-

"h* " S ""C. C,5

696

E.1

. i. Z

21 -- -.--e

1' 6

7 ~ *t:1= 6 1 -

69

Table A-13

Some Known Problem Areas in the Use of Query Languages

I :I! :~ : :

I I

2' VC

--. 4

I= ,- C

T 2Uo tAC

- -I

*0"-- 0 C, 04'

20

4~ c'

~7()

• ? I ' '~~~ L C... .. . .. . . . . in ..... . .. . . .

Table A-14

Basic Display Device Types

L.,49 394.-I0 N 0

L.~ 41

V);

L-0.nnL C u 0, 3 4-'O

4j Cm 4- - I

U5C. 0 "t OJ- CmO QCCC r- 0. G

B- aJ 4A w--~ 0-.4-l~. . w> u~.4 .- .,4j ' A S 4j 0 .

L. .0 %m-i G 4. - aC US-L x=LO . 4A 4JU:% W-.VI- 0. CnS u-C - aS

V.)V .-- u 'j C. LJ 4 Qj>5f06(-'f 1J C.V 5 G 4 - AOJ > .GJ.US *

64- 1 39' 0 1R 4.D4 0.GJ =V 0S WS Am) U41- USC GJ0 Q CL 41 :C

t'0 .9. m rC0. : 0M- L z; X LUSu QU >5'0 9 >USZ

-o~~~~~~~ u >, .J4- i )n4.U - L-.U#UmC0.w 054-.-5 I4- A 0 u

0 ~ ~ 4 C 0. .:2' t 4)( - 39 0 0u 'om s

AA >1 06 N T04,

4j L. (u u .41

0 ) . - I.- - 04- -IM 05 (Mu L 0

0 CUS_ O 1 . CL ) I--; 1-- CU inC

WJ E V 4CA 06 0, o a 4) 4

0 V 4- 0 km 71

Teble A-14 (Concluded)

Basic Display Device Types

'4- 0-

-0 U

0.

U 0 4-'=IC

w. Cs- G O GE-+~- a, 0 EE'- d0. 0i - 4- U 4-0 ->1

L. w 0 G 4 C O C.I>- UU IV 0 +US

w CLEU In C In

m- 4. - A ;UI :

w=U~ .G U w 1 4j 0E -Z

01 w

m 39 0EE mE wS.. - 0~ - a. >a > 0.0.

GE~~ =u, j,'i- E

>J 4

IOU ~ ~ M : 1

Table A-15

Basic Visual Properties of Displays

U' 0,%

-41 - E

L. L r. 4,.r-'

0 N4 04:) 1- 1 -

U ~ ~ ~ 4 4110 1 o

4141.41 A ivn 4~~~U.0 ~ ~ % 0 44 1 . 0 ACf L CU >N .- 04

C'4j G -Q 41;. m1 LC~ 0 O.0-'5-14.0 0 = =. -4 0 CL U.ONUI S. 0 0,410"n OSC.. V) 01 .~Cu L.0 fac C 0'i~ 0.CU4 = "G

4j .4 .. C -C4 C41 z 0 j 0 .

- .0 41 0 4 m . L_ L.

VC C8. 00 Mm. C LA 4) -4jL C 4 4C CL (U.

U'4.- ~ m CL U-. C . .0a Z~'.-LCUCI U 0U .L. L3 U 4

0 .041)G .

4J0 6 O. C C . L )0 C

C U.IV 004 a. 4) w~v *-e 41.L t o

4.' -~~4 4-J *0 -> 0i .C ~ ~ ~ ~ ~ ~ ~ 4 41 U4 U. XV v.4 4'- O . ) .0

10C'4-k5 7V m0j4C 10JU0U JO4 U0 C.U C UV LU-. W0

UO. U4 C L.I0 O 84 . . ,T

CC A-UU J '4 - 0 W .... 0 CLO L.- C 4. 1 4-4'4' - .. C1 Ia. 4

w C4 .0 :;.0 wC1O.O L0S.. 06 P. 10 :G10 0 . 39 L C'.41 0141-W

41~~ C CS" L- "o 0 COU~EC~14L

L..41, *U.z1mM10V f VCL=VI CC0 41 0 0 C 0 %-%04)

0 4A Q . J IA 2 4.) 0 0. US L ". ~0 .

(M0 404 410a 04 - CU 40V 0 S-)4.1L-4 >, L W0. CU -4 CL... 401-

. 4J' CAO '4- .- : U I 1--L 0v CU1.0 >1, 4J IA mm-U - .C £4'

r - "G E." WVX .U -4 4 ) 6.% C US

SIC W' 'A 0.4 =:: 41''L j5 = 0 0506 ~ __U M 0' .0 39 I

Z~O~ 01 USV IA m1~44.C 1LV. C 30 0>'- L4CI4. 5 L44 ~ 0S

at- 15- . C40 CA 6 0 1 .C -04

4'W 4'A

w UU m

or C.

or..) L

Table A-16

Display Properties of Alphanumeric Characters

U, -,

U1 - 0-

W S -D $.- M 3 3 r-

GD 0r-.4 CA W0 qu 4 0 C a, C E 00CQ (

EU~ U .1 L O% .4

0. ui0 .0 41. 41 E 00%. CM

0. -E -EU W- C . L.JE - ) v s-EvC * UV. W L U v *- R jai U w oL _r

.0 EU' 'AU CU. M 0CU E

x 0. WW 02U4 0 t :

414. UCAI 0. *2 z04-1 S-7 M IIT U 1 4.10 4 0 1 -C4M V

0.- (v1 M1,-1- a,0- U4- 0.0 U 4S1 CL 4) .- U $ 0EU0I-4V A~ 4UZE 41u MUU 4A w% C 41 1

WA. 0 OX; ,C I U 1 L0.! s UCE EU -I UA UUU 4-- >U4- L. M 41 ( C EU V, L--D- U 0 MU L ,,a N

41 ,C0 W1 S.)L-E L. W-. U.4 4 O MU euC0 -j r-W - C 4'a a1 r- 0' 0 %a0 4-W $- WL.4 * 0 0 L LA-C

U . CE L4 MJ aJ .CA0 > C41-0 E4-'I% CC91M .- -.4 +4 0. .- M4~. CLO LU s- .02 4-..L L V .C 0 .04-lt; V) 41 w . l 4 ~ 1 3 - 1 4 -0 ~ 4 l U U >

41 *-~ 1 C - CI O E 4 .4 o. OC E UEU1 .EUVC ~ ~ ~ ~ ~ ~ ~ 4 0. E0 00 44C - 40 1-.l . .41

S-. S.4- 4- 00 VEU W ~ WEL0 . - UW(\ s-E.LC- - U C- mL41A ~ 111 0 C . 0 41 L-W 4-W

4-U4L 41 Ir- M> AL 4' CU4 0,.. 0 0 E04l-

(U4- LU EEU M~1

>U.L U0. ~M -,, L0. 510 0,I A1 - 41- 0-' EU4 .j1

M UL. CU X -- 1 L - 0MO E~4 4).C 3CU. 3: 0 041EU.0 CA 04 C411 4,01 M - 0. L. IA C E

-M01 1. UE M. 41 aU 1- 'a 410 V ~ U L-- %E

*L 14 I T - L4 L -,IA 4.- u 0 41 0 41 IA C. U .0V4E -0. 3 .- 4 a)0 LC .0 d)4 A4 'a .1~ 0)4 0

E.U W U 0) 3.1D.V V03 Im E 4) 0 4- 4 - - U 41-0 40 -410_C 0 1* 41 . 4-1)1 I V 0A1 U L- CL .-

IAA - %U4IA L.LC- L.U 0 r-14 U 0. LA EU 4"Z 1a). L.1> 04, i 0 .EUU4 1 >L4 0.EU 0W 4-' U a) M

C4) 0 4-2 ( 4-.1 4U LI 410 4.1 EU x cm>% U L- :2 I41.1 M -0 L- LMC 4- ) 10 1 0 EU-E EU 0 - , 1

0I- W. U L' WU F 0414C 4-U. -U0S-CL' r L L .-)0 'V C - "A0

.0I UE 4-I U4- N0% UEU 10 U0 r.4' L 1V WU- ~U 1 IAEUA -aC-. 010EU CC-. M4E IA 100.

41CU 0I44 M 41E0I 0I tUoU= 4-1 a4 IA 0A

W01IA 0 C1-U4 -

-- 4L- CW m 0. U. V (U ULIWA0 0.C-W AL 04- EUI LL - 4 - >41 4-4-A4E C~I (GL Ut

CA .1 4 1-

00 4- 414. 41 0- E 'A 'A AL3 %, U E I L0L UUE 4 > M;MUU 6 41 4) *CU4 L.0 41o 5..0 IC U - -0

W0..E M W4E U00%. 4.IQ C-4 CE LI x 1 OEU U4T

M1IL 41 10I EU - M 4- >1~ 'A 4)L. M10 MCv'a ,4).. 4IA u- L.O L4U44 IA a 104- .L 4) EL7 (S% %0 VEMwUZ 41

EU-0 M10 C. 0440 MEC O I- 5111 4L-- 0 14W.W0 U) t10. EUV)U1. 11, 0OUI C1 -4 C

IAIAC 4'EC C -. .0 -14.174 L L 41I 4.0 E IAAA

Table A-17

Major display coding techniques

L..%- 4 w 41 ON 0

L. E

C; 0 0'4J 0 .

-L E CL 6- (SJ G-mC -

.- 4-~U. 41410' r_1% 10%L 0 0lC UC. U .A.0a) . .

UC .CW 1 S - >: U 4

C 0 -5 r-U 4.1. 41' C .-. C J ~ ;*- SO) C... s-, 1~ '- 00 S-Q 4- 0- -U

.0 C C 4.11-C>, C 1'

Z4~. U,1 C * , U 0 -. vC " 4J m

.C - J 041 C1- U- I, m'V 2 0'=Vm

0-- C -. 1 0 (D4 L 0 C 'UOU.:n .0 0UVUUS~~~ -~'.- C CLJ.,L.U A4E ,U(dO4 '0iO IVU*Q'U'UC4CL

'UU,.A 0 0 0 C .Z'C r 41U41' 0.CU,U U4 r- 41 41V =1.-. m~' A . 'U U CU ,,

to- vs- U ,U 4- U 4..-C . L '

.4- S0 ' U414U L > 0 UC U4U, L4-C.0U'0 4- 0 .0 ' 44 V0- Ur .GI. -

4J 0 00UO OC L, 40 . lL I. 0 ,0C 4- *.UC 0-' O' 41 - U +4 1 w 1 V1 -O 0-

4-CU w s0-., 0-L 0(a 4C 0. ,.- U

4.15V.4t4 4-l m)1 C IV U C 1 U0 0 U. U . C M. J.C-v0 ::~ CU CUwiU2'w 0S.E 0.>&:, 0, :1- 40-.U 41'414 S-1.

C '- ,~ W0O 1 -CC O4 4- 41 4-4 31.'0 0,4 4J,1 U, ' , 0.0'U.U 0.

UC LLUU. w41 CLU'...0L~C0 > : O O e0( O CR 01r-C 41 S- >,S-M

4.14. X U ' 41 r..4 S.4

W-044- 4--4

:2 0A " C 0 %-

U == '0 '0 1I

z 0 m0 .

40 'a 4, U (Ua ,

CC

'U

75

Table A- 18

Input Device Types

2ItI11W~ w,

0 UW m

-. V. C7,0 -W

LL

-x- - U ~ - C. 0''05

w**~U W--4,U.CU0 AO

04 C Q)r - 0 ,r . =wO' 0 LV C C - J 0 0.4 C, C .a ca

104 C. CL L'0 " ~I- 00 , 0-.- 0 i. -- M a Ve

VO.a, 0 C4'.- C O 'e 0

41 L..-~ Z woo mc - ~ ,

C .4 wv ~ , ,

>*4.. 0 .3->- ~ ->- -U- .4, U 01 3 .C -,1

- 0, ~~.-- ,. o V"

0.. 10 LL W. w,

w 4,1 'C wV4 wL 4UZ L 0M mC .IL LW ~~ CL a,4- 0., C La >00

0. :2-.. c 0 - 10 w40 w L

CL --4,~.-.- ~ , CL Q.Q CL.c~*~ 0 -. o LQ-~~~~o. -0W 2 00=I1

*0 44.1 0.0. C - 4E . .0 .- 4 -

o . a ,~*~. 1 ~ . -W -~£ 0.- >6 W -V00. m f

Q. U3 %-o .. V W .0 0

0 C 06-.~

1CL 0.0 M

'a. 4, m

7(10

Table A-18 (Continued)

input Device Types

0.U L" w~ U- x I .no

0 4 '0w. _

~02- ) C0 ' 01. C~ 0

w L 0 - - 0

Vw~ 4)0

Qj 2 .0 4 0

wC CU L. Z 01 L Q

- 41 0 .-

Cu 00 CL 0 0 L0C 00-.l -. L- 0

1C '- -C 0 E

xo 0 40 4)

CuC 0 " 0

410 -0 m 0 C. CILr 0w)1 I I- O 0mmC

4.1~UC 0. _ O 1J- WIC

.0. .2 0 4, WV 41 C

a, 0 00

- . -V . V ,a"0

0 ~~~ 0 - V .c 0. 1VC.C '010~ a 4.' 4V 'L 0-' 40u

4,0~~~' mC . 4,~ w-.O CO C .- Zr1l 1 ~ .0' 4 . L . . 44

V0'.- 0. 0

06' ~ 0 4 COO C) 0U IC C

3l~, 0 OCQ 1 u 4~- 41 C 77

Table A-18 (Concluded)

Input Device Types4

C 4

I- * C* -

L- C =a .m

4; 0~ - -

II 4

.0 V, C

Q.Q 3C COL3. Vol w3

024)L 4)3 CLV- C CL CL 3 0~ m --

43 =3 .) w 0C .C. 02 m ~ C C.0.Vlowt~ -w o

C - I- C' X ~ M-34

-7-V04 ~ '3,C -r- C 'Co 1j oL C L -

C C > .3 " .04 >, 43 -- >334

0243 >1* 01- 1-C -4 - 3-M

-~ ~ ~ 4=3.3..- '. C ~- U. W . 0-~ 3 4

C C

-o >3.C . '0 >, WC 3

*-0 W33 -

433- - 4333V4,C4U 0.. 3 0 4C, ''

CI43.~- *. .. 3.0 .

3-0 00 r- M3 M3 VQ.% 02 w03

0 4 > 3 3

M. C. C . '3CCI 0 m Q- w

21 ~40 O~43, 0 w 00

78

APPENDIX B

MIII REQUIREMENTS MATRIX

In Section 2 of this report, there is a discussion of thepossibility of developing a structured approach to the definition ofman-machine interface requirements. More specifically, it isproposed to develop a matrix in which MIII functional capabilitiesare listed as row labels, identified operator tasks are representedas columns, and cell entries estimate the degree to which eachcapability is required for each task. A first pass at such arequirements matrix is presented here in Table B-i. Some furtherdiscussion is needed concerning the listing of MIII functions, thecharacteristic tasks chosen for illustration here, the estimation ofrequirements, and the potential application and extension of thisrequirements matrix.

MIII FUNCTIONS

A first pass at listing MIII functional capabilities isrepresented by the several hundred row labels in the requirementsmatrix. This tabulation has been drawn from several sources, butparticularly from the listing of MIII features by Goodwin (1978).Capabilities are exprcssed in functional terms, for the most part,without reference to specific means of implementation, e-g.,"position designation" rather than "lightpen".

11111 functions are grouped here under six major headings,generally following their discussion in the text of this report.First, and most fundamental, is Dialogue Type. Specification ofdialogue type will influence the definition of all other MIIfunctional requirements.

Other functional areas listed here include Data Entry, DataDisplay, Sequence Control (strongly related to Dialogue Type) andUser Guidance. An additional area, Data Transmission, is listed toindicate that this requirements matrix can be extended to cover abroader scope of MIII functions than Lhose that have been discussedia this report. Data Transmission includes consideration ofautomatic data inputs from external systems, which may affect MIIfunctional design, as well as data transfers resulting from explicitoperator actions.

This listing of MI functions needs further extension toinclude capabilities not considered here, e.g., those relating more

79

specifically to maintenance tasks, system performance evaluation andtesting.

This listing of MIII functions also needs amplification in someareas, based on cumulative experience in using the requirementsmatrix. Certainly the specification of various dialogue types(codes 1.x) could be amplified to include sub-headings, perhapsincluding response time requirements (as suggested in Table 3-1)among other things.

Rows now labeled "other" (codes 2.1.2.2, 2.1.3.3.4, 2.2.2,

etc.) could be amplified to cite more specific alternatives. Rows4labeled "automatic" (codes 2.6.1.1, 2.6.3.1, etc.) could beamplified to distinguish functions driven by "external" events from[those resulting implicitly from operator inputs and control actions.

Some of the functions listed here, although seemingly specific,may on closer examination be defined more effectively in terms ofcomponent sub-functions. For example, text editing (code 2.3.1.2.2)could be elaborated in terms of subfunctions to type, insert ordelete characters, to mark character strings, to move, copy ordelete marked strings, and to save text in named files, or named orunnamed buffer stores (Goodwin, 1978, p. 55).

Aside from the need for extension and amplification, thislisting of MMI functional capabilities should be examined criticallyas to the proper placement or grouping of functions. In practice,the close association of Sequence Control with Dialogue Type, notedabove, may make it unfeasible to distinguish these as separatetopics in requirements definition. A less significant example hasto do with the questionable placement of alarm functions, which arelisted here under Sequence Control (code 4.5) to emphasize potentialuser participation in determining alarm logic, but must also beacknowledged under User Guidance (codes 5.1.5, 5.3.3) which is thegeneral purpose of alarms, and considered ;n connection with othermore specific functions (see code 6.3.4.1 i

CHARACTERISTIC TASKS

To illustrate the potential application of this requirementsmatrix, fiur characteristic data processing tasks are shown in,able B-I as columns in the matrix. These are not "generic" tasks,.#s that word is used in the text of this report (see page 16), butthrv should serve to illustrate characteristic patterns off~inriauI requirements. These four are, of course, only a small.*lng of the broad variety of tasks that must be performed in C3

SIn the subject index to a recent bibliography on man-

80

computer systems (Ramsey, Atwood and Kirshbaum, 1978), 34 generalapplication areas are cited, from air traffic control to wargaming.The variety of different possible operator tasks is probably atleast as large, although that could only be verified by comparativeexamination and categorization of task analysis descriptions.

The four tasks tabulated here, although a small sample, dorepresent a rather broad range of operational jobs. Two represent"loperator" tasks, the third is a poorly-defined "analyst" task, andthe fourth a narrowly-defined "data entry/service' task, as thoseterms have been applied to characterize user roles (Goodwin, 1978,

pages 43-44; see also text, pages 15-16).

The first task is labeled Mission Scheduling. This is the kindof data handling task that must be accomplished, for example, at aTactical Unit Operations Center (TUOC), assigning sorties fromseveral squadrons of aircraft to a list of preplanned missions,trying to optimize aircraft, armament and crew capabilities inrelation to target characteristics, trying to minimize flightdistances and on route refueling requirements, trying to scheduletakeoffs to meet required time over target and schedule returns toprovide time for necessary turn around. TUOC mission scheduling, asconceived here, requires rather little data entry: mission and[target data are filed automatically with receipt of orders from the

Tactical Air Control Center, and current squadron status data areassumed already available. The task itself is well defined. Theoperator makes iterative matchings of aircraft and crews againstmissions, sometimes changing those that do not fit well in thedeveloping schedule. Computational aids are needed fortime/distance calculation and would be helpful in assessing proposedalternative plans. The final schedule must be reported to highercommand and to squadron operations officers, and also filed forsubsequent operations monitoring. Scheduling of preplanned missionscan be done under relatively little time pressure. The operator canprobably accomplish most of the required transactions simply bypointing at categorized displays, so that an extended form of menuselection is the preferred dialogue type.

The second task is labeled Operations Monitoring and Control.This is the kind of task that might be required, for example, in theCommnunication System Control Element (CSCE) proposed for TRI-TACacquisition of tactical communication control facilities (see Smith,1974). In this task the operator is expected to monitor on acontinuous basis the flow of message traffic through the nodes andchannels of a communications network, to spot overloads and outages,and to institute control actions as necessary to maintain networkfunctioning. The operator may have to work under time pressure,

assimilating information from rapidly changing network displays, sothat some form of auxiliary display coding will probably provevaluable. Computational aids could help the operator predict theresult of proposed network reconfiguration. Communication functionsare needed to transmit control messages to node elements in thenetwork. Rather little data entry is required in the performance ofthis task, and menu selection combined with the direct designationof nodes and links on a graphic display is probably the bestdialogue type to use.

The third task is labeled Intelligence Analysis. This task isgenerally conceived to be like those proposed for the Department ofDefense Intelligence Information System (DODJIS), where an analystmust access an extensi--e data base in a variety of ways in order toanswer a broad range of questions. Some form of query language isthe dialogue type required here. Other functional capabilitiesinclude flexible formatting of display output, and computationalaids to permit categorization, statistical summary and inferencefrom stored data. The analyst would probably be a periodic ratherthan a continuous user of the computer facility, will draw on othersources of information, will need capabilities for entry andmanipulation of a variety of data types, including some textprocessing and graphics.

The fourth task involves routine Data Entry of the sortrequired when loading or unloading air cargo (see Smith, 1976b). Thetask must be performed under time pressure by relatively unskilledpersonnel. Data formats and the sequence of entries are rigidlycontrolled. A variety of data validation checks are applied toensure correct entry and pioper cargo handling. This task isprobably best designed as keyed data entry with prompting, in aquestion-and-answer type of dialogue.

More tasks should be added as the requirements matrix gainsacceptance and practical use. The eventual list should includemaintenance tasks, with their emphasis on diagnostic routines andperformance evaluation, as well as the kinds of operational tasksillustrated here.

REQUIREMENT ESTIMATES

MIII requirements are represented by the cell entries in thematrix. Here only rough estimates are given. For each task everyfunctional capability has been judged as Essential, Useful or NotNeeded, a three-way categorization suggested in the text of thisreport (see page 23).

* 82

Where a function is marked Not Needed, any sub-functions underthat heading have simply been marked with a dash to indicate that no

separate judgments had to be made.

The logical constraints relating ratings for functions and sub-functions also work in reverse. In this requirements matrix, eachfunction has been assigned a rating corresponding to the highestrating given any of its related sub-functions.

If requirement estimates for some functions are redundant,i.e., directly inferrable from ratings of sub-functions, then whyinclude them in the matrix? Experience in applying the requirementsmatrix may in fact confirm that redundant ratings can be omitted.They should be retained, however, if they facilitate scanning theImatrix, or the association of design guidelines with requiredfunctions, or the possible specification of MIII requirements on thebasis of higher-level functions rather than detailed sub-functions.

In the text of this report it is suggested that futureexperience may permit replacing qualitative requirement estimates inthe matrix with quantitative indices. This has not been done here,and some awkward expedients have been adopted to deal with certainnecessarily qaantitative capabilities. An example is the estimationof required display capacity (see entries under code 3.2). Ratherthan simply indicating anticipated capacity requirements as cellentries in the matrix, a categorization of high-moderate-low hasbeen incorporated in the list of functional capabilities. Such a"1solution" enlarges the requirements matrix to little purpose and sodoes not seem satisfactory.

In actual application of the requirements matrix to MIIfunctional specification, it may prove helpful to annotate theratings of different capabilities, to indicate just how thosejudgments were reached. Supplementary annotation would certainly beneeded to explain ambiguous entries, as when any capability called"other" has been rated Essential. Such annotation would also helpto delineate the conceptual design of the more general informationsystem of which the MIII will be a critical part.

Even in its present rough form, however, with qualitativeentries and no annotation, the matrix does seen' to provide a usefulstructure for MIII requirements definition. The sample tasksincluded here do seem to show different "profiles" of requiredcapabilities which serve to highlight their characteristicfunctional differences. Future experience can confirm whether suchprofiled requirements can help guide MIII design.

83

APPLICATION AND EXTENSION

Design should follow function. To state function is to implyIdesign. To define functional requirements will necessarilyconstrain the designer. That is the whole point. Thus requirementsmust be specified with care, so that arbitrary constraints will notexclude desirable design alternatives. This is particularly true inhardware specification. Constraints in software specification,however, serve generally to make subsequent software design moreefficient and ultimately better related to needs. The question is,can use of an MIl requirements matrix constrain design to goodeffect?

In its present rough form the requirements matrix is littlemore than a check list. Indeed, if the requirement estimates weresimplified to become just a binary categorization of needed versusnot needed, then check list would be an apt designation. Even asimple check list, of course, can find useful application, servingto remind system developers of the range of functional capabilitiesthat should be considered, and providing a structure for theimposition of design guidelines.

Use of a check list or simple matrix will not necessarily makerequirements definition a simple process. MMIl requirementestimation will still involve a good deal of judgment, and if donecarefully may imply prior design, at least at a conceptual level, ofthe overall information system in which the MNI will be implemented.

A further complexity is that most C3 systems involve multiplejobs, each with multiple data handling tasks. Thus ratings anddescriptive annotation of the requirements for one task must becombined with those for another task to produce a total HIlfunctional specification.

As the requirements matrix is extended and amplified from thisinitial version, its application may become more difficult. The useof quantitative indices in the matrix, as suggested above, couldpermit a relative weighting and trade-off of requirements, withpotential use in evaluating MMIl design proposals as well as in earlyrequirements definition. But such elaboration of requirementestimates would probably need computational aids for its effectiveuse. Thus some sort of computer-based version of the requirementsmatrix would have to be developed.

A further extension of this tool might be to expand the listingof functional capabilities to include other factors influencing 1111design. The present matrix, for example, does not refer directly to

84

means of implementation. For examiple, it is never specified whetherdata displays should be implemented as electronic displays (cathoderay tube or other), on a printer, as an audio output, or by another particular means. Where a commitment has already been made toparticular means of implementation, as in upgrading aix existingsystem retaining operator work station facilities in place, thensome way mutit be found to include such constraints in MIIIrequirements specification.

Perhaps the best way to handle constraints of this kind --those relating indirectly to software design, such as committedfacilities, unusual work environments, special user characteristics

-is to create a separate check list of expected conditions, ratherthan to expand the requirements matrix.

A more difficult decision is how to handle constraints thatcould directly affect software design. In system upgrade, retentionof existing software may severely limit options for extending andimproving MHI design. Considered more positively, future systemacquisition may come to rely on "building blocks" of the kindadvocated by Clapp and llazle (1978), in which successful softwareimplementations of selected MIII functions are preserved as standardmodular packages, and translated as necessary for re-use in newsystem applications.

Once such standard MMI modules have been developed, they shouldprobably be included in any expanded version of the requirementsmatrix, to remind system planners of their availability and topermit their formal inclusion in system specifications asappropriate. In the long run, increased reliance on such standardcomponents should simplify MIII specification by reducing the numberof specific features that are considered in the requirements matrix.But design standardization to that degree still lies many yearsaway.

Meanwhile, it is clear that this initial version of the MIIrequirements matrix represents only a partial, tentative listing,based on best judgment rather than proven value. This matrix needsextension and amplification, and its potential usefulness must beevaluated through cumula'ive experienrn in trial applications.Suggestions for its improvement are nt Jed and will be welcome.

Table B-i

Sample MMI Requirements Matrix

Characteristic Tasks*

MMI Capability MS OM IA DE

1.0 DIALOGUE TYPE

1.1 Question and Answer N N N E

1.2 Form Filling U N U N

1.3 Menu Selection E E N N

1.4 Function Keys U U N N

1.5 Command Language N U U N

1.6 Query Language N N E N

1.7 Natural Language N N U N

1.8 Graphic Interaction U U U N

2.0 DATA ENTRY/INPUT

2.1 Position Designation (Cursor E E F NControl)

2.1.1 arbitrary positions E N U -

2.1.1.1 discrete E - U -

2.1.1.2 continuous U - N -

*MS = Mission Scheduling Requirements Ratings:

O = Operations Monitoring & Control E = essentialIA = Intelligence Analysis U = usefulDE = Air Cargo Data Entry N = not needed

86

Table B-i (continued)

Characteristic Tasks

MMI Capability MS OM IA DE

2.1.2 predefined positions E E E -2.1.2.1 "HOME" N N E -2.1.2.2 other E E N -2.1.3 incremental positions N N U -

2.1.3.1 by character - - U -

2.1.3.1.1 right - - U -2.1.3.1.2 left - - U -2.1.3.1.3 up - - N -

2.1.3.1.4 down - - N -2.1.3.2 by interval ("TAB") - - N -2.1.3.2.1 horizontal - -

2.1.3.2.2 vertical - -

2.1.3.3 by other features - - U -

2.1.3.3.1 "word" - - U -2.1.3.3.2 "line" - - U -2.1.3.3.3 "paragraph" - - U -

2.1.3.3.4 other - - U -

2.2 Direction Designation N N N N2.2.1 vector rotation ....2.2.2 other

2.3 Data Type E E E E2.3.1 text N N E N2.3.1.1 formatted (messages/lists) - - U -

2.3.1.1.1 entry - - U -

2.3.1.1.2 change - - U -

2.3.1.2 unformatted (free text) - - E -

2.3.1.2.1 entry (composition) - - E -

2.3.1.2.2 change (editing) - - E -

2.3.2 tabular E E E E2.3.2.1 entry E N E E2.3.2.2 change E E E E2.3.3 graphic U E E N2.3.3.1 entry U N E -

2.3.3.1.1 selection N - E -

2.3.3.1.2 creation U - U -2.3.3.2 change U E E -

87

Table B-i (continued)

Characteristic Tasks

MMI Capability MS OH IA DE

2.4 Entry Formats E E E E2.4.1 predefined E E U E2.4.2 user defined N N E N

2.5 Data Validation E E U E2.5.1 required entry E E U E2.5.1.1 immediate E E N E2.5.1.2 deferrable U N U N2.5.2 length of entry E E N E2.5.2.1 fixed E N - E2.5.2.2 maximum E E - E2.5.2.3 minimum E N - E2.5.3 content of entry E E U E2.5.3.1 numeric E E N E2.5.3.2 alphabetic E E N N2.5.3.3 alphanumeric E E N N2.5.3.4 defined codes E E U E2.5.3.5 other N E U N2.5.4 comparative checks E E U E2.5.4.1 equal to E N U E2.5.4.2 greater than E E U E2.5.4.3 less than E E U N2.5.4.4 "IF.. .THEN" E U U U2.5.4.5 other N U U N2.5.5 default entry E E N U2.5.5.1 predefined N N - N2.5.5.2 user defined E E - U

2.6 Data Processing E E E E2.6.1 cross-file update E E U N2.6.1.1 automatic E E N -2.6.1.2 by request N N U2.6.2 derived data (summary U E E E

statistics, etc.)2.6.2.1 automatic U E U E2.6.2.2 by request N U E N2.6.3 other computational aids E U E N2.6.3.1 automatic N N N2.6.3.2 by request E U E

Table B-1 (continued)

Characteristic Tasks

MNI Capability MS OM IA DE

3.0 DATA DISPLAY/OUTPUT

3.1 Data Type E E E E3.1.1 text N N E N3.1.1.1 formatted - - U3.1.1.2 unformatted - - E3.1.2 tabular E E U E3.1.3 graphic U E E N3.1.4 combination N E U N

3.2 Data Density3.2.1 high U E E N3.2.1.1 (text > 1000 char./frame) N N E3.2.1.2 (tabular > 600 char./frame) U N U3.2.1.3 (graphic > 300 char./frame) N E U -

3.2.2 moderate E E E N3.2.2.1 (text 600-1000 char.) N N E3.2.2.2 (tabular 300-600 char.) E U U -

3.2.2.3 (graphic 100-300 char.) U E E3.2.3 low E E E E3.2.3.1 (text < 600 char.) N N E N3.2.3.2 (tabular < 300 char.) E E E E3.2.3.3 (graphic < 100 char.) U E E N

3.3 Data Aggregation E E U E3.3.1 high (summary display) E E U N3.3.2 moderate (grouped items) E E U U3.3.3 low (individual items) E E U E

3.4 Data Coding U E U N3.4.1 dimensionality U E U -

3.4.1.1 many relevant variables N N U -

3.4.1.2 few relevant variables U E U -

3.4.2 categories ("alphabet") U E U -

3.4.2.1 many > 20) (alphanumeric) N N U -

3.4.2.2 moderate (8-20) (symbol) N N U -

3.4.2.3 few (3-7) (color) U E U -

89

Table B-1 (continued)

Characteristic Tasks

MM Capability _6 OH IA DE

3.4.2.4 just two (size, brightness, U E U -

etc.)3.4.3 criticality N E N -3.4.3.1 high (redundant coding) - E - -3.4.3.2 moderate (separate coding) - E - -

3.5 Display Partitioning E E U N3.5.1 fixed windows E E U -3.5.2 variable windows N N U -3.5.2.1 automatic - - N -3.5.2.2 by request - - U -3.5.3 multiple displays N U N -

3.6 Display Selection E E E E3.6.1 by display name E E U N3.6.2 by data subset name E U U N

("category", "page", etc.)3.6.3 by data item E E E N3.6.4 by data characteristics U N E E

("selective retrieval")3.6.4.1 automatic U - N E3.6.4.2 by request U - E N

3.7 Data Coverage E U E N3.7.1 displacement E N E -3.7.1.1 page (text or tabular) E - E -

3.7.1.1.1 forward E - E -

3.7.1.1.2 back E - E -3.7.1.2 scroll (text) N - N -

3.7.1.2.1 up3.7.1.2.2 down3.7.1.3 offset (graphic) U - U -

3.7.1.4 return/recenter U U -3.7.2 expansion U U U -3.7.2.1 incremental U U U -3.7.2.2 continuous N N U -3.7.2.2.1 zoom in - U -3.7.2.2.2 zoom out - U -3.7.2.3 return/normalize U U U -

90

Table B-1 (continued)

Characteristic Tasks

MII Capability MS OM IA DE

3.7.3 other reformatting N U U

3.8 Display Update N E U N

3.8.1 autcmatic - E N -

3.8.2 by request - N U -

3.8.3 rate - E U -

3.8.3.1 normal (event driven) - E N -

3.8.3.2 fast (time compression) - U U -

3.8.3.3 slow - U N -

3.8.3.4 freeze ("stop action") - U N -

3.9 Data Deletion N U U E

3.9.1 automatic - N N N

3.9.2 by request - U U E

3.9.2.1 all ("CLEAR") - N N N

3.9.2.2 data category (selective - U U E

erasure)3.9.2.3 data item - N U E

4.0 SEQUENCE CONTROL

4.1 Transaction Selection E E E N

4.1.1 general "OPTIONS" E E U -

4.1.2 contingent (step-specific) E E U -

options

4.1.2.1 automatic E E N -

4.1.2.2 by request E E U -

4.1.3 linked commands ("macros") N U E -

4.2 Interrupt E E E E

4.2.1 "BACKUP" N U N E

4.2.2 "CANCEL" E U N E

4.2.3 "RESTART" U N N E4.2.4 abort E E U N

4.2.5 "END" U N E E

4.3 Context Definition E E U E

4.3.1 automatic N N N E

91

r

Table B-1 (continued)

Characteristic Tasks

MMI Capability MS OM IA DE

4.3.2 by request E E U N4.3.2.1 user command E E U4.3.2.2 data category E U U4.3.2.3 data item E E U

4.4 Error Management E E E E4.4.1 command validation N U E N4.4.2 explicit "ENTER" N N E E4.4.3 "CONFIRM" protection U E E E4.4.4 direct error correction N N E E

4.5 Alarms N E U N4.5.1 alarm definition - E U -4.5.1.1 predefined - E N -4.5.1.2 user defined - E U -4.5.1.2.1 categories - E U -4.5.1.2.2 parameters - E U -4.5.2 alarm acknowledgment - E U -4.5.2.1 automatic - U U -4.5.2.1.1 routine ("timeout") - U N -4.5.2.1.2 implicit action ("seen") - U U -4.5.2.1.3 other - N N -4.5.2.2 user action - E U -4.5.2.2.1 predefined response - E N -4.5.2.2.2 user defined response - U U -4.5.2.2.3 override - N N -

5.0 USER GUIDANCE

5.1 Status Information U E E U5.1.1 operability U E E U5.1.1.1 local work station U U E U5.1.1.1.1 equipment U U U U5.1.1.1.2 data files U U E U5.1.1.1.3 functions U U U N5.1.1.2 system N E N U5.1.1.3 external N E N N5.1.2 current users N N U N

92

Table B-1 (continued)

Characteristic Tasks

MMI Capability MS OM IA DE

5.1.3 current load (response time) N N U N5.1.4 timeliness U E U U5.1.4.1 continuous N E N N5.1.4.2 periodic N N N N5.1.4.3 by request U N U U5.1.4.4 date/time U E U N5.1.5 alarm signals N E U N5.1.5.1 categories - E U5.1.5.2 parameters - E U

5.2 Routine Feedback E E E E5.2.1 input E E E E5.2.1.1 data entry E N E E5.2.1.2 data change E N E E5.2.1.3 data deletion N E E E5.2.2 output E E E N

5.2.2.1 requested data displayed E E E -

5.2.2.2 exceeds display capacity E N E

5.2.2.2.1 partial display E N E -

5.2.2.2.2 not displayed N N N -

5.2.2.3 data not available E N E

5.2.3 sequence control E E E N

5.2.3.1 requested transaction E E E -

5.2.3.2 changed context E E E5.2.3.3 other N U E

5.3 Error Feedback E E E E

5.3.1 error type E E E E5.3.2 correction procedure E E U N

5.3.3 alert signals E E U E

5.3.4 cursor position E E U N

5.4 Instructional Aids E E E E5.4.1 automatic E E U E5.4.1.1 fixed guidance messages E E U E5.4.1.2 contingent on input E E U E

5.4.1.2.1 command selection E E U N

5.4.1.2.2 context change N U U N

5.4.1.2.3 data entry U N U E

93

L . .. . . . , .... _... . ... ..

REQUIREMENTS DEFINITION AND DESIGN GUIDELINES FOR MAN-MACHNE I--ETC(U)UNJUN 80 S L SMITH F19626-8@C-0OO1

UNCLASSIFIED MSG-IO ESD-TR-80-122 MLflffffffffff

~jfl .2.5 B 1.8

M N 1 I.6

MR NW 01 10

Table B-i (continued)

Characteristic Tasks

NMI Capability MS OM IA DE

5.4.1.3 command aiding N U U N5.4.1.3.1 branching options - U U5.4.1.3.2 disambiguation - N U5.4.1.3.3 other - N U

5.4.1.4 cursor position U E U N5.4.2 by request E E E N5.4.2.1 command index E E E -

5.4.2.2 data index N E E -

5.4.2.3 "HELP", "EXPLAIN" U U E5.4.2.4 on-job training U N U5.4.2.5 other (simulation, etc.) N U U5.4.3 instructional modes E E E E5.4.3.1 novice users U N E E5.4.3.2 transitional users N N U N5.4.3.2.1 by time of use - - N -

5.4.3.2.2 by demonstrated skill - - U -

5.4.3.2.3 other - - U -

5.4.3.3 expert users U U U N5.4.3.4 mixed user skills E E E N

6.0 DATA TRANSMISSION/COMMUNICATION

6.1 Data Transfer E E E E6.1.1 to files E E E E6.1.1.1 own E E E E6.1.1.2 other users U N U N6.1.2 to other terminals N N U N6.1.3 to printer U U E E6.1.4 external E E N U

6.2 Data Type E E E E6.2.1 text E E E N6.2.1.1 formatted E E E -

6.2.1.1.1 messages E E E -

6.2.1.1.2 documents N N E6.2.1.2 unformatted N N E6.2.2 tabular E E E E

6.2.3 graphic N N U N

94

Table B-I (concluded)

Characteristic Tasks

IMI Capability MS 011 IA DE

6.2.4 alarm/alert signals N E N N

6.3 Transmission Control E E E E6.3.1 data source E E E E6.3.1.1 from display U N E N6.3.1.2 from files E E E E6.3.2 data specification E E E N6.3.2.1 by display- name N N E -6.3.2.1.1 all - - E -

6.3.2.1.2 designated part - - U -6.3.2.2 by data name E E N -6.3.2.2.1 category E E - -

6.3.2.2.2 item U E - -

6.3.3 initiation E E E E6.3.3.1 automatic N E N E6.3.3.1.1 continuous - N - N6.3.3.1.2 periodic N - N6.3.3.1.3 contingent on transaction - E - E6.3.3.2 by request E E E N6.3.4 feedback E E U N6.3.4.1 transmission E E U -6.3.4.1.1 initiated N E N -6.3.4.1.2 confirmed E E U6.3.4.1.3 failed E E U -

6.3.4.2 message received N E U -

6.3.4.2.1 priority - E U -

6.3.4.2.2 routine - E U -

95

APPENDIX C

SAMPLE DESIGN GUIDELINES FOR DATA ENTRY

In Section 3 of this report, it is recommended that guidelinesbe prepared pertinent to the design of the man-machine interface forC3 systems. In this appendix, in Table C-i, a sample set of 72guidelines is provided for design of functional capabilitiesrelating to data entry. These MMI functions are those that havebeen given codes 2.x in the requirements matrix presented inAppendix B.

These design guidelines for data entry are not invented herefor the first time. Most of them have been taken,'albeit reorderedand sometimes reworded, from more comprehensive sets of guidelinesproposed by Engel and Granda (1975), and by Pew and Rollins (1915).Those prior authors deserve credit for setting down first what manypeople imagined they knew already but had not explicitly formulated.

These guidelines represent just a partial, tentative sample ofwhat might be derived from published recommendations. Similarguidelines could be listed for other functional areas of 1111 design.Even the data entry functions chosen for illustration here are notcompletely represented by these sample guidelines. There are, forexample, no guidelines here that are specifically pertinent tographical data entry. Presumably those could be derived from otherreference sources.

Like the requirements matrix, the list of design guidelineswill grow larger through cumulative experience with its use in trialapplications. In this present listing, however, something of thevariety of possible "rules" is evident. Some rules are simple,almost too simple to need stating. Others are complex. Some rulesseem to apply generally to data entry functions, whereas others aredirected toward specific sub-functions. The guidelines listed hereare grouped in relation to the primary sub-functions of data entry,as coded in the requirements matrix.

What is missing from this sample list? Aside from graphics,many other specific sub-functions are poorly represented. There areundoubtedly many special-purpose rules still to be stated, whichpertain to particular data entry applications.

Conversely, there may be some rules so elementary, so generallyaccepted, that no one thinks of them and they are never explicitly

96

stated. That is a mistake. Even the simplest rules deserve somesort of acknowledgment, as a reminder to the designer.

An example is the recommendation that a displayed cursor shouldnot obscure another symbol whose position it may mark (see rule2.1-2 in Table C-1). This rule seems self-evident, yet it ismissing from published guidelines. Once in a while, however, adisplay will be designed in such a way that when its cursor marksanother character that character is temporarily erased. Anyone whohas to work with such a display will be reminded of the need forthis "missing" rule.

One obvious deficiency in the guidelines listed here is theinfrequent inclusion of examples. For the MIII designer, examplesmight help to clarify the intent and significance of the rules. Iflists such as this are to be published as design standards, theyshould be written to include more examples.

Some guidelines relating to the provision of routine feedbackfor data entry are included here, although they relate also tofunctional capabilities for User Guidance (code 5.2 in therequirements matrix). Not included here are guidelines for otherUser Guidance functions relating to data entry, such as feedback forerror correction (code 5.3) and instructional aids for data entry(subfunctions under code 5.4). Also not included here are SequenceControl functions associated with data entry, including interruptfunctions (code 4.2) and error management (code 4.4).

Another deficiency of this sample list is its almost exclusiveconcern with electronic visual displays as the input/output mediumfor man-machine interaction. A few references to auditory displaysare included, but more are needed. Additional guidelines would alsobe needed for MIII designs employing a teletype (or reactivetypewriter) rather than electronic displays.

The dependence of design on its means of implementation isacknowledged in the contingent wording of some of the guidelineslisted here. For the most part, however, the list includesfunctional rules rather than hardware specification. Suchfunctional guidelines could be amplified to include a more explicitrecognition of hardware features if that were appropriate in systemacquisition.

Certainly there are hardware features implied in theseguidelines, including function keys for ENTER, CONFIRM, BACKUP,CANCEL, DITTO, PRINT, possibly DEFAULT and RESTART, as well asvarious tab keys for controlling cursor position, for 1111 designs

97

involving form-filling dialogues. It is not clear whether it wouldprove desirable in system acquisition to state the hiardwareimplications of these guidelines more specifically. It may bebetter to leave that to the designer.

One significant weakness in current design guidelines is thatthey are based on opinion, judgment, accumulated wisdom, rather thanon quantitative performance measures. Thus the designer is givengood advice but not told the consequences of ignoring it. Untilresearch on man-machine interaction catches up with application,which may take a long time, this weakness cannot be remedied. Forthe present, it can be argued that good advice, even if ignored, isprobably better than no advice at all.

If design guidelines are based on judgment, then they arepotentially controversial. Thus any proposed guidelines should beexamined through extended debate and in broad-ranging applicationbefore they can be adopted as a general design standard. Some rulesthat sound good for the general case may fail in a specificapplication. Such exceptions should be noted as they arediscovered. Meanwhile, readers of this report are invited topropose improvements and additions to the sample guidelinespresented here.

As any initial list of guidelines is gradually amended andextended, the eventual result may become quite a large designhandbook. For any particular system application the large total setof guidelines would need tailoring to the particular dialoguetype(s) selected for use and in accord with the M111 requirementsmatrix for that system. Procedures for tailoring design guidelinesmust be worked out in practice. As suggested in the text (see page18), computer-based aids could be helpful in this regard. Theresult of such tailoring, in combination with a detailedrequirements definition, should provide an effective functionalspecification for the man-machine interface.

98

Table C-1

Design Guidelines for Data Entry Functions

Code*

2.0 DATA ENTRY/INPUT

- 1 Where data entry is a significant-task function, itshould be accomplished via the operator's primarydisplay. (For example, entry via typewriter isacceptable only if the typewriter itself, undercomputer control, is the primary display medium.)

- 2 Data entry transactions, and associated displays,should be designed so that the operator can use onemode of entry as long as possible before having toswitch to another (e.g., switching from lightpen tokeyboard input).

- 3 Except for passwords and other secure entries, keyedinputs should always appear in the display.

- 4 Keyed data entry and change on an electronic displayshould generally be accomplished by direct characterreplacement, in which keyed inputs replace underscoresor previous entries (including default values) indefined data fields.

- 5 Wherever possible, data entry should be self-paced,depending upon the operator's needs, attention spanand time available, rather than computer processing orexternal events. (Where self-pacing does not seemfeasible, the general approach to task allocation and1111 design should be reconsidered.)

- 6 Using a form-filling dialogue, entry of logicallygrouped items should be accomplished by a single,explicit action at the end, rather than requiringseparate entry of each item.

*Refers to coding scheme of functional capabilities adopted for theM1M1 requirements matrix in Appendix B (see Table B-1).

99

Table C-1 (continued)

-7 Where multiple items are entered as a singletransaction, the operator should be allowed to "backup" and change any item before taking the final entryaction.

2.1 Position Designation (Cursor Control)

- I Position designation on an electronic display shouldbe accomplished by means of a movable cursor withdistinctive visual features (shape, blink, etc.).(However, where position designation involves onlyselection among displayed alternatives, then some formof highlighting selected items might be used insteadof a separately displayed cursor.)

- 2 The cursor should be designed so that it does notobscure any other character which may be displayed inthe position designated by the cursor.

- 3 Where fine accuracy of positioning is required (as insome forms of graphic interaction) the displayedcursor should include a point designation feature.

- 4 Actual entry ("activation") of a designated positionshould be accomplished by an explicit operator actiondistinct from cursor placement.

- 5 For arbitrary position designation, the cursor controlshould permit both fast movement and accurateplacement. Rough positioning should take no more than0.5 seconds for a displacement of 20-30 cm on thedisplay. Fine positioning may require incrementalstepping of the cursor, or a control deviceincorporating a large control/display ratio for smalldisplacements, or a selectable vernier mode of controluse.

- 6 In position designation, the displayed cursor shouldbe stable, i.e., should remain where it is placeduntil moved by the operator (or computer) to anotherposition.

100

Table C-1 (continued)

-7 Continuous position designation, such as used forinput of track data, should be accomplished bycontinuously operable controls (e.g., thumb wheel forone dimension, joystick for two dimensions) ratherthan incremental, discrete key actions.

-8 When position designation is the sole or prime meansof data entry, as in selection of displayedalternatives, cursor placement should be accomplishedby a direct-pointing device (e.g., lightpen) ratherthan by incremental stepping or slewing controls(keys, joystick, etc.).

-9 In selection of displayed alternatives, the acceptablearea for cursor placement should be made as large aspossible, including at least the area of the displayedlabel plus a half-character distance around the label.

-10 Where position designation is combined with keyed dataentry, cursor movement should be controlled at thekeyboard (by function keys, joystick, "cat", etc.)rather than by a separately manipulated device(lightpen, "mouse", etc.).

-11 On initial appearance of a data entry display thecursor should be placed automatically at the firstcharacter position of the first input field.

-12 Display formats for data input should be designed soas to minimize operator actions required for cursormovement from one entry field to the next.

-13 Sequential cursor positioning in predefined areas,such as displayed data entry fields, shouid beaccomplished by programmable tab keys.

-14 Areas of a display not needed for data entry (such aslabels and blank spaces) should be made inaccessibleto the operator, under computer control, so that thecursor does not have to be stepped through blank areasnor are they sensitive to pointing actions.(Mechanical overlays on the display should not be usedfor this purpose.)

101

Table C-1 (continued)

-15 Operator action confirming entry of multiple dataitems should result in input of all items, regardlessof where the cursor is placed on the display.

2.2 Direction Designation

I Where accurate designation of direction is required,some "analog" means of entry should be provided, suchas vector rotation on the display, and/or a suitablydesigned rotary switch (see Smith, 1962). Where onlyapproximate direction designation is required, forjust eight cardinal points, keyed entry can be used.

2.3 Data Type

-I Ideally, the length of individual data entries shouldnot exceed 5-7 characters, except for textualmaterial. Longer items (such as the 17-charactertransportation control number for air cargo) exceedthe operator's memory span, inducing errors in bothdata entry and reviewv.

-2 Where longer items must be entered, the item should bepartitioned into shorter symbol groups for both entryand display (e.g., a 10-digit telephone number enteredas three groups:__

-3 Where portions of a long item are highly familiar orrendundant, ideally those should be entered last, inorder to reduce the load on the operator's short-termmemory (but not if this sequence would violate afunctional requirement, such as initial keying of areacode in telephone numbers).

-4 Minimize keying in data entry by abbreviation oflengthy inputs where that can be done without

ambiguity, providing data validation routines andIoperator interrogation as necessary to resolve anyambiguity which may arise.

-5 Where abbreviated codes are used to shorten dataentry, code values should be designed to be asdistinctive as possible in order to avoid potentially

102

Table C-1 (continued)

confusing similarity (e.g., BOS vs. LAX is good; LASvs. LAX is bad).

-6 Where alphabetic data entry is required, restrictedalphabetic sets should not be used. Software might beprovided to interrogate the operator to resolve anyinput ambiguities resulting from hardware limitations(see Smith and Goodwin. 1971).

-7 Special characters used in data entry (,* /etc.),particularly if used frequently, should be choseninsofar as possible so that the keyboard operator willnot have to shift from one case to another.(Conversely, keyboard designers should put frequentlyused special characters where they can be most easilykeyed.)

-8 Entry of leading zeros should be optional for generalnumeric input, though it may be required occasionallyfor special cases (e.g., entry of serial numbers orsimilar identifiers.)

-9 For input of tabular data, where vertical repetitionof entries is frequent the operator should be provideda "ditto" key to speed entry of duplicative data.

2.4 Entry Formats

I Wherever possible, multiple data items should beentered without the need for special separators ordelimiters, either by keying into predefined entryfields or by including simple spaces betweensequentially keyed items. Where a delimiter must beused, adopt a standard character; slash (/) ispreferred.

-2 For all dialogue tynes involving prompting, dataentries should be prompted explicitly by means ofdisplayed labels for data entry fields, and/orassociated user guidance messages.

103

Table C-1 (continued)

- 3 For operator-initiated (command language) dialogues, ameans of entry stacking should be available so that anexperienced operator can shortcut prompting sequences.

- 4 For data entries involving selection among displayedalternatives, implicit prompting can be provided bymarking (brightening, inverse video, etc.) theselected alternative(s).

- 5 Implicit cues should be provided in form-fillingdialogues to supplement explicit labels. Specialcharacters (e.g., underscores) should be used todelineate each entry field.

- 6 Field delineation cues should distinguish required(dashed underscore) from optional (dotted underscore)entries, and should indicate the maximum acceptablelength of the entry. (Similar implicit cues can beprovided when data entry is prompted by auditorydisplays. See Smith and Goodwin, 1970.)

-7 Where item length is variable, the operator should nothave to justify an entry either right or left, andshould not have to remove any unused underscores.

- 8 Where multiple items (especially those of variablelength) will be entered by a skilled touch typist,each entry field should end with an extra (blank)character space. This will permit consistent use oftab keying to move from one field to the next. Anauditory signal should be provided to alert theoperator if an entry is keyed into a blank space.

-9 Where entry fields are distributed across a display, aconsistent format should be adopted for relatinglabels to delineated entry areas. For example, thelabel might always be to the left of the field; or thelabel might always be immediately above and left-justified with the beginning of the field. Suchconsistent practice will help the operator distinguishlabels from data in distributed displays.

104

Table C-1 (continued)

-10 Where tabular formats are used for data entry, columnlabels should be left-justified with the leftmostposition beginning column entries, especially whencolumns vary in width.

-11 Numeric entries (e.g., dollars and cents), althoughentered as left-justified, should be automaticallyjustified with respect to a fixed decimal point if adisplay of these data is regenerated for review by theoperator.

-12 Labels for data entry fields should be distinctivelyworded, so that they will not be readily confused withdata entries, labeled control options, guidancemessages, or other displayed material.

-13 In labeling data entry fields, only approved terms,codes and/or abbreviations should be used. Do notcreate new jargon. If in doubt, pretest all proposedwording with a sample of qualified users.

-14 Labels for entry fields may incorporate additionalcueing of data formats where that seems helpful, forexample, DATE (t1/D/Y):

-15 Where a dimensional unit (,mph, kin, etc.) isconsistently associated with a particular data field,it should be displayed as part of the fixed labelrather than entered by the operator. Wherealternative dim~ensional descriptors are acceptable,then space sho. td be provided in the data field foroperator entry of a unit designator.

-16 Where data entry displays are crowded, auxiliarycoding should be adopted to distinguish labels fromdata. The recommended standard is to display fixed,familiar labels in dim characters, with data entriesbright.

-17 Display formats for data entry should be identical orcompatible with formats used for display output,scanning and review of the same data items. Where adisplay format optimized for data entry seems unsuited

105

Table C-i (continued)

for data review, or vice versa, some compromise formatshould be designed taking into account the relativefunctional importance of data entry and review in theoperator's task.

-18 Where data entry involves transcription from sourcedocuments, in a form-filling dialogue displayed formsshould match (or be compatible with) paper forms. Ina question-and-answer dialogue, the sequence of entryshould match the data sequence in source documents.(Where paper forms are not optimal for data entry,consider revising the layout of the paper form.)

-19 Where data entries must follow an arbitrary sequenceof external inputs (e.g., keying telephonedreservation data), some form of command languagedialogue should be used to identify each item as it isentered, so that the operator does not have toremember and re-order items.

-20 If no source documents or external inputs areinvolved, the ordering of multiple-item data entriesshould follow the logical sequence in which theoperator can be expected to think of them.Alternatively, data entry can sometimes be made moreefficient by placing all required fields before anyoptional fields.

2.5 Data Validation

- 1 Automatic data validation software should beincorporated to check any entry whose input and/orcorrect format or content is required for subsequentdata processing. Do not rely on the operator alwaysto make correct inputs.

- 2 Where critical data entries have not been input, butcan be deferred, data validation software shouldsignal that to the operator, permitting eitherimmediate or delayed input of missing items.

- 3 Where deferred entry of a required data item isnecessary, the operator should have to enter a special

106

Table C-1 (continued)

symbol in the data field to indicate this item hasbeen temporarily omitted rather than ignored.

-4 In a repetitive data entry task, data validation forone transaction should be completed, and the operatorallowed to correct errors, before another transactioncan begin. (This is particularly important when theoperator is transcribing data from source documents,so that any detected input errors can be correctedwhile the relevant document is still at hand.)

- 5 Item by item data validation within a multiple-entrytransaction may be helpful to a novice user, but ifthis capability is provided it should be only as aselectable option. It will tend to interrupt and slowa skilled operator.

- 6 Where useful default values for data entry cannot bepredicted by system designers, which is often thecase, the operator (or perhaps some authorizedsupervisor) should be provided a special transactionto define, change or remove default values for eachdata entry field.

- 7 Currently defined default values should be displayedautomatically in their appropriate data fields withinitiation of a data entry transaction. The operatorshould not be expected to remember them.

- 8 Operator acceptance of a default value should beaccomplished by simple means, such as by a singleconfirming key input or by tabbing past the defaultfield. (Similar techniques should be used in tasksinvolving operator review of stored data.)

- 9 In any particular data input transaction the operatorshould be able to replace any default value with adifferent entry, without changing current defaultdefinition.

10 7

Table C-1 (continued)

2.6 Data Processing

-I The user should not be required to enter redundantdata, already known to the computer, except as neededfor resolving ambiguous entries, security (useridentification), verification of stored data (betterhandled by review rather than re-entry) or Gperatortraining. (For example, the operator should not haveto enter both an item name and identification codewhen either one defines the other.)

-2 Data entries made in one transaction skhould beremembered by the system when relevant to anothertransaction, and displayed for review if appropriate.The operator should not have to enter those dataagain.

- 3 Wherever needed, automatic computation of derived datashould be provided, so that the operator does not haveto calculate and enter any number that can be derivedfrom data already entered in the system.

- 4 Wherever needed, automatic cross-file update should beprovided, so that the operator does not have to enterthe same data twice (e.g., assignment of aircraft to amission should automatically indicate that commitmentin squadron status files as well as in a missionassignment file).

5.2 Routine Feedback

- I In tasks where data input is usually a single,occasional transaction, successful entry should besignaled by a confirmation message without removingany visual display of the entered data. (This followsa general principle of sequence control that theoperator should leave one transaction and choose thenext by explicit command.)

- 2 In tasks where data input is usually repetitive, in acontinuing sequence of transactions, successful entry

s hould be signaled by regeneration of the data entrydisplay, automatically removing the just entered data

108

Table C-1 (concluded)

in preparation for the next entry. (This representsan exception to the general principle of sequencecontrol by explicit operator choice, in the interestof efficiency.)

- 3 Where an entry will cause any extensive change instored data, procedures and/or system operation, andparticularly if that change cannot be easily reversed,the operator should be notified and required to4confirm the entry action before it is implemented.

- 4 In an extended data entry transaction, whereverpossible a cumulative record of operator inputs shouldbe displayed if relevant to the current input. (In amulti-page data entry display, for example, do notrely on the operator to remember data accurately fromone page to the next.)

- 5 Keys and other input devices not needed for dataentry, particularly those with disruptiveconsequences, should be temporarily disabled undercomputer control, during data entry transactions.(Mechanical overlays manipulated by the operatorshould be used only as a last resort.)

- 6 Where computer processing of just-entered data willresult in a noticeable delay, an acknowledging messageshould appear, and the keyboard should beautomatically locked until the operator can begin anew transaction. Keyboard lock should be accompaniedby disappearance of the cursor from the display and

* (especially if infrequent) by some more specific

* T indicator such as an auditory signal.

-7 Where the operator requires a printed record of dataentries, a print request should not change thecontents of the display, except for the addition of aconfirmation message if printing is accomplished

remotely.

109

APPENDIX D

DOCUMENTING IIMI DESIGN

In Section 4 of this report it is argued that definition offunctional requirements and establishment of guidelines, althoughworthy activities, are not sufficient to ensure effective IIMIdesign. It will be necessary to document a proposed design forreview and coordination by the various groups of people responsiblefor system development and operation.

Design documentation should certainly provide an account ofrequirements met and guidelines followed, but should include othermaterial as well. Pew and Rollins (1975) recomend five componentsfor design documentation. With some changes of terminology, thesefive components can be summarized as follows.

1. Task Flow Chart. This breaks down a generally statedoperator task into a logical series of decisions to bemade and information handling activities to beperformed. Some of these activities will involveinteraction with a computer subsystem, and some maynot. Task analysis at this level may be provided in asystem functional specification, but more often mustbe developed in the first stage of system design.

2. Transaction Flow Chart. This breaks down thoseactivities involving computer use into a series ofdiscrete transactions. The proposed man-machinedialogue is outlined step by step, or as is sometimessaid for dialogues involving visual displays, frame byframe. The transaction flow chart indicates choicesthe operator can make in sequence control, contingentbranching as a result of operator input, data entriesrequired, outputs generated, etc.

3. Display (Frame) Format. Working from the transaction'Flow chart, each step or display frame must bespecified in detail. The most effective way to dothis is to design a facsimile display showing theexact wording, spacing, etc., that will be used. Here

to the designer.

110

4. Inpu Data Definition. For transactions involvingdata entry, it will be necessary to provide adefinition for each item (or "variable") to be input.This definition will involve specifying the range ofacceptable values for each entry where data validationis required, the consequences of data entry in termsof required computer processing, and the implications(if any) for subsequent sequence control and for userguidance.

5. User Guidance. For any transaction, but particularlyfor transactions involving data entry, the designershould specify the feedback that will result from anypossible operator action, e.g., alarm or alertsignals, guidance messages, other display changes.Often this aspect of MI11 design is conceived morenarrowly, in terms only of the specification of errormessages. It will help MMIl design, however, if thedesigner can adopt a broader perspective. Perhaps theoperator should be given a message requestingconfirmation of a doubtful entry, i.e., an entry thatis so unlikely that it is probably though notcertainly an error. Perhaps the operator should berequested to enter additional data to amplify an entryjust made. Or perhaps the operator should simply begiven a message suggesting the next step in atransaction sequence. There are many possible aspectsof user guidance that cannot fairly be termed errormessages.

In their report, Pew and Rollins suggest that special forms beadopted for documentation of these various aspects of MMIl design.Examples of their forms are reproduced here, with permission, in theremaining pages of this appendix, to give an idea of what may beneeded for documentation purposes. The task chosen for illustrationhas to do with commodity loan repayment, for an information systembeing considered at that time (1975) by the U.S. Department ofAgriculture. Of interest here, however, is the general approachused rather than the particular task being documented. Other formsof documentation might work as well, or better, as long as a similardegree of detail is achieved.

Pew and Rollins make the additional recommendation that onceHMi design has been documented it should be subject to configura tionmanagement control. That is to say, during software implementationchanges to a documented NI design should be made only after reviewand authorization. Such control will help ensure design

consistency, so that different people can implement different partsof the HlI with reasonable confidence that the parts will fittogether as a coherent whole. That seems a good idea.

1

' 112

MENU SELECTIONUP TO

REPAY COMMODITYLOAN

DECIDE: SELL S REPAY

-REPAY DIRECTLY

PRODUCER IDENTIFY LOANI DEN T IF Y LOANOR I. PRODUCER ID INQUIRYI. PRODUCER ID I NOU IRY2. PRODUCER OR Co FIk'ESCO. FILES 2. PRODUCER OR CO. FIJeES

CONDUCTPRODUCER) LOAN

FILE INQUIRY

TL7 &A LOAN

j E COLLECTINrO 1COLLECTINFO F1 LEFOR RELEASE 6 COMPUTE

(681-1 REPAYMENT1PRODUCER1, (CCC-500) PRODUCER

TYPE UP TYPE UPCOLLATERAL REPAYMENTRELEASE ICONTRACT IAGREEMENT

TIME DELAY TIME DELAY

RECEIVE

P OC SSLOAN CHIECKFILE PROCESSYM NTIAYMENTE

Figure D-1. Sample Task Flow Chart

113

LOAN APPLICATIONS SUBSYSTEM

I

an "". , P4 NOW -5

6 Reclivelplea

69 iorrect

L pocialicis and information CAALO)

REPAYMENTSI Commodity

1 2 FS & DIE AAL02 iz)

a it I ic-

I SON and RepayCOMMODITY REPAMMENTS112 Repay Directly

CAAL03

Sell/Known CAALOMI I COMMODITY LREPAYMENTSCAAL05 I in-drA 04(3)Ghit CAALOS I Loon No KnownSoil/ CAA 4 2 2 Loon No Unknown

suspense LOOM * 3 SU""H FIk CAANQ4I unknown

Me IC.AdAL03(2) Repay/Marketing

R CAALOXZ)Memories 0 Ion Summit*

Aullhorlialion A~ ,sat*n ldCA CAAL04(i) CAALO4113)CCC-60-1 CCC-661-1 0Loon III Suspense F-10 L inquiry Repaym RepaymentLOT Loon Life fkxardC; _SDO RQCordCCC-5OOCAALIT_ CAA Loon (d sulps"se, File No

Enter jDGfo.ljCA LO (1 03is

CAAL 18 CAALII

Illsopsy at Record Bypooate

M&kotwq Avithoratfion Far LOOM Dot IsEnter, E ICollateral CCC-661-1 It

11 riput I CAALOB ANI" nt Rec d cc-

Ent * i Nast (input)

Marketing Authorization Far Enter illIMATION

;tWeIL4L it Collateral MWWR" Illocord I I Start Now Repayment

A0* 1COC-50OS"nW 2 Exit CAAL11

Soal selection CAAL20 CX-500

fe, CAAW

-'flAuthorilatilmFor LoonCollateral CCC-681-1 No.t j Defoull

1"a"', n(oirip.9 CAAL09 wapay"M solectlionNOV j i Dof . Suspense Fjo

Sole 1 Compalef Repayment

File ""a" 2 Start New Repsyment3 E..l

SuI Complete lipay-sint CAA-E2%,..',' 14"PRopolmiml i

S fort ld (3)

3) 1(1 C AALIO CM (2)

(2)

*indicates a point at which access to central computer data baseis required

Figure D-2. Sample Transaction Flow Chart

I.L4

IA

-0 - -I

ILI

- - -

440 44

w~ $4c' -4 1

-- - - - - - - - - --1

a E-4

44

[0- -

E-. 0.Itn

a Oca

11

a>4L'-4 0

0. to

C4 u

00

z 0-~E - ua.L

E-.04wi 10 ---

z 49 - - -4it a1- - i -- >

41 1 0

0 OD 04

-1 0LL (A - A hix z

V z0

C4

E- 0

41

in0 N 0

t 04V) N N

w0 -4 N- z4 .

444to

4 -- - -1-

o to

Ulf

Ir w 0

Im U U 1U- 0 22

w u UU

A 14 -4 4

N~ z1

0 0

SM M > >1

0 M 0 0E- 0

hJ~~ ZC. 0

4 I--~ ..-1 4

Ic. td 2 i

1174