Successful industrial design gracefully unites esthetics and functionat minimum cost. However, designers face specialproblems when

they apply their skills to interactive computer systems.

Human FactorsExperiments inDesigningInteractive SystemsBen ShneidermanUniversity of Maryland

Providing useful tools for computer users with awide range of experience, problems, skills, and expec-tations is a challenge to scientific competence,engineering ingenuity, and artistic elegance. Systemdevelopers are increasingly aware that ad hoc designprocesses, based on intuition and limited experience,may have been adequate for early programminglanguages and applications but are insufficient for in-teractive systems which will be used by millions ofdiverse people. Regular users quickly pass throughthe gadget fascination stage and become demandingusers who expect the system to help them in perfor-mance of their work. Clearly, therefore, interactivecomputer-based consumer products for home, per-sonal, or office applications require increasing levelsof design effort.Unfortunately, it is not possible to offer an algo-

rithm for optimal or even satisfactory design. In-teractive system designers, like architects or in-dustrial designers, seek a workable compromise be-tween conflicting design goals. Systems should besimple but powerful, easy to learn but appealing toexperienced users, and facilitate error handling butallow freedom of expression. All of this should be ac-complished in the shortest possible developmenttime, costs should be kept low, and future modifica-tion should be simple. Finding a smooth paththrough these conflicting goals is a challenge.Henry Dreyfuss,' a leading industrial designer

responsible for plane, train, and boat interiors as wellas dozens of familiar consumer items, provides usefulguidance. He devotes a full chapter to the experienceof designing the 500-Type Telephone, the standardrotary dial desk model. Measurements of 2000human faces were used to determine the spacing be-tween the mouth and ear pieces. After consultationwith Bell System engineers about the layout of elec-tronic components, 2500 sketches for possibledesigns were made. Numerous variations ofthe hand-

grip were considered until the familiar rounded-offrectangular cross section was adopted. Variations ondial and faceplate were tested until a 4¼/4-inchdiameter faceplate was selected to replace the older3-inch version. Placement of the letters and numberswas studied, the angle of the dial was adjusted toreduce glare, and the cradle was modified to minimizethe receiver-off-the-hook problem. Accurate layoutdrawings were made for all the variations, and finallyclay and plaster models were built to compare theleading designs. Then testing began.This process contrasts sharply with most interac-

tive system development experiences where designsare hastily proposed and evaluated informally. Alter-native command structures, error handling pro-cedures, or screen formats rarely getimplemented forpilot testing purposes. Dreyfuss spends another en-tire chapter emphasizing the importance of testing.Tests and pilot studies should be more than the infor-mal, biased opinion of a colleague. A pilot test shouldinvolve actual users for sufficient time periods to getpast initial learning problems and novelty. Conflict-ing designs should be evaluated in carefully con-trolled experimental conditions. Though ex-periments provide no guarantee of quality, they arefar better than informal guesswork. The process ofdeveloping an experimental comparison can itself beproductive, often providing worthwhile insights.Statistical performance data and informal subjectivecommentary from participants can be valuable infine-tuning proposed procedures. Experimentalresearch can lead to fundamental insights whichtranscend specific systems. Nickerson,2 Bennett,3Martin,4 and Miller and Thomas5 provide broad-ranging reviews of issues and references fordesigners and researchers of interactive systems.Shneiderman6 covers related work in data-basefacilities, and other articles in this issue focus on pro-gramming language usage.

0018-9162/79/1200-0009$00.75 © 1979 JEEE 9December 1979

Goals for interactive system designers

The diversity of situations in which interactivesystems may be used makes it difficult to prescribe auniversal set of goals. The attempts of several systemdesigners to define goals are shown in Figures 1through 8.Foley and Wallace15 make their recommendations

by enumerating five problem areas: boredom (im-proper pacing), panic (unexpectedly long delays),frustration (inability to convey intentions or inflexi-ble and unforgiving system), confusion (excessivedetail or lack of structure), and discomfort (inap-propriate physical environment).The best detailed guide for design of interactive

display systems was developed by Engel and Gran-da.16 They make specific suggestions about displayformats, frame contents, command language, recov-ery procedures, user entry techniques, general prin-ciples, and response time requirements.Unfortunately, these lists are only crude gnides to

the designer. The entries are not independent andsometimes are in conflict. The lists contain contradic-tory recommendations and are certainly incomplete.Finally, these design goals are largely unmeasurable.Can we assign a numerical value to the simplicity,

stability, responsiveness, variety, etc., of a system?Howcanwe compare the simplicity oftwo designpro-posals? How do we'know what has been left out of thesystem design?Experimental research can help to resolve some of

these issues and refine our capacity to measuresystem quality. Stin, some aspects of designing willremain an art or intuitive science where esthetics andcontemporary style determine success.The remainder of this paper presents several

human factors issues in designing interactivesystems. The discussion is independent of hardware-related concerns such as the design of keyboards,displays, cursor controls, audio output, speechrecognition, graphics systems, and customizeddevices, and software-related topics such as naturallanguage front-ends, menu selection, commandlanguages, data-base query facilities, and editors.The emphasis is on general problems and basic ex-perimental results.

Attitude and anxiety

Several studies have demonstrated that user at-titudes can dramatically affect learning and perfor-mance with interactive systems. Walther andO'Neil,17 for example, showed that novices withnegative attitudes towards computers learnedediting tasks more slowly and made more errors.Anxiety, generated by fear of failure, may reduceshort-term memory capacity and inhibit perfor-mance. If users are insecure about their ability to use

COMPUTER

First principle: Know the userMinimize memorization

Selection not entryNames not numbersPredictable behaviorAccess to system information

Optimized operationsRapid execution of common operationsDisplay inertiaMuscle memoryReorganize command parameters

Engineer for errorsGood error messagesEngineer out the common errorsReversible actionsRedundancyData structure integrity

Figure 1. User engineering principles for interac-tive systems (W. J. Hansen, 1971).' Hansen's FirstPrinciple should be the motto of every designer:Know the User. No qualifier or explanation isnecessary. Hansen's sensitivity to human short-term memory limitations leads to his secondcategory: minimizing memorization. Under "op-timization of operations," Hansen includes"display inertia," suggesting that when operationsare applied, as little of the display'should bechanged as possible. This approach reducesdisruptive movement and highlights the impact ofthe last operation. "Muscle memory" refers to theidea that users develop the feel for frequently usedkeypresses. Hansen recognizes the importance ofengineering for errors by providing good errormessages, reversible actions, and revisions toengineer out common errors.

1. Provide a program action for every possible type ofuser input.

2. Minimize the need for the user to learn about thecomputer system.

3. Provide a large number of explicit diagnostics,along with extensive on-line user assistance.

4. Provide program shortcuts for knowledgeableusers.

5. Allow the user to express the same message inmore than one way.

Figure 2. The design of idiot-proof interactive pro-grams (A. I. Wasserman, 1973).8 Wasserman's fivedesign principles are reasonable, but the secondand fifth ones may need qualification. Although itis usually good to minimize the user's need to learnabout the computer system, restricting access tothose who have acquired a certain knowledge levelmay sometimes be agood idea. The qualifying test,which works well for driver's licensing and collegeentrance, may be useful for complex and powerfulsystems. Naive users should be prevented from us-ing a system which is too hard for them and wouldproduce an unpleasant experience. Wasserman'sfifth principle may not always be good advice.Novices will prefer and do better with a systemwhich has few choices and permits only limitedforms of expression.

10

the system, worried about destroying files or thecomputer itself, overwhelmed by volumes of detailsor pressured to work rapidly, their anxiety will lowerperformance. Programmers who must meet a dead-line tend to make more errors as they franticallypatch programs in a manic attempt to finish. Ofcourse, mild pressure can act as a motivator, but ifthe pressure becomes too strong the resultant highlevels of anxiety interfere with competent work.In designing a system for novices, every attempt

should be made to make the user at ease, without be-ing patronizing or too obvious. A message tellingusers not to be nervous is a bad idea. Users will feelbest if the instructions are lucid, in familiar terms,and easy to follow. They should be given simple tasksand gain the confidence that comes with successfuluse of any tool or machine. Diagnostic messagesshould be understandable, nonthreatening, and low-key. If the imput is incorrect, avoid blaring phrasessuch as "ERROR 435-NUMBERS ARE ILLE-GAL" and merely state what is necessary to makethings right-e.g., "MONTHS ARE ENTERED BYNAME." Try to avoid meaningless,~condemning

December 1979

Simple: project a "natural,'' uncomplicated "virtual'' image of thesystem.Responsive: respond quickly and meaningfully to user commands.User-controlled: all actions are initiated and controlled by the user.Flexible: flexibility in command structures and tolerance of errors.Stable: able to detect user difficulties and assist him in returning tocorrect dialogue; never ''dead ending'' the user (i.e., offering norecourse).Protective: protect the user from costly mistakes or accidents (e.g.,overwriting a file).Self-documenting: the commands and system responses are self-explanatory and documentation, explanations, or tutorial material arepart of the environment.Reliable: not conducive to undetected errors in man-computer com-munication.User-modifiable: sophisticated users are able to personalize their en-vironment.

Figure 5. Interface design for time-sharing systems (D. R.Cheriton, 1976).11 Cheriton's thorough list provides good guide-lines for interactive system designers.

1. Know the user population.2. Respond consistently and clearly.3. Carry forward a representation of the user's

knowledge basis.4. Adapt wordiness to user needs.5. Provide the users 'with every opportunity to correct

their own errors.

6. Promote the personal worth of the individual user.

Figure 3. Design guidelines for interactive systems(R. W. Pew and A. M. Rollins, 1975).9 Pew andRollins echo Hansen's motto and add some of theirown besides. Guideline No. 4, above, was probablyintended to mean "adapt the messages to theuser's level of syntactic and semantic knowledge."

SimplicityFew keywordsSimplicity of inputShort commandsSimple commands

ClarityHierarchical structure (commands and subcommands)Functional separation of commandsHomogeneity (same structure for all commands)Problem orientation

UniquenessDeterminism-every command is fully determined by its

operands and preset optionsNo undefined states

Comfortable languagePowerful commandsFlexibilityShort dialogueData structures can be displayed and utilized for searching and

browsingOther comfort

Input comfort: rereading or previous input or output after correc-tions have been made; menu technique

Dialogue can be interrupted at any timeClear, short, understandable system messages

Evidence and reusabilityEvidence of the system stateAcknowledgment of executed commandsHelp functionsFormer commands and output reusable for inputSaving commands for later execution

StabilityClear messages on severe input errorsError correction on slight errorsUniform error handlingNo compulsion to continue the dialogue in a fixed way

Data security

Figure 6. Design criteria for documentation retrieval languages(F. Gebhardt and 1. Stellmacher, 1978).12

Introduce through experienceImmediate feedbackUse the user's modelConsistency and uniformityAvoid acausalityQuery-in-depth (tutorial aids)Sequential-parallel tradeoff

(allow choice of entry patterns)Observability and controllability

Figure 4. Guidelines for designing interactive sys-tems (Brian R. Gaines and Peter V. Facey, 1975).10Gaines and Facey emphasize the importance of theuser being in control of the terminal, the pace of theinteraction, the tutorial aids, and the execution pro-cess.

1 1

messages such as "SYNTAX ERROR" and givehelpful, informative statements such as "UN-MATCHED RIGHT PARENTHESIS." Construc-tive messages and positive reinforcement producefaster learning and increase user acceptance.

Control

A driving force in human behavior is the desire tocontrol. Some individuals have powerful needs to at-tain and maintain control of their total environment;others are less strongly motivated in this directionand are more accepting of their fate. With respect tousing computers, the desire for control apparently in-creases with experience. Novice terminal users andchildren are perfectly willing to foliow the computer'sinstructions and accept the computer as the control-ling agent in the interaction. With experience andmaturity, users resent the computer's dominance

and prefer to use the computer as a tool. These usersperceive the computer as merely an aid in ac-complishing their own job or personal objectives andresent messages which suggest that the computer isin charge.The Library of Congress recognized this distinc-

tion in changing the prompting message from theauthoritarian "ENTER NEXT COMMAND" to theservile "READYFORNEXTCOMMAND." A largebank offers a banking terminal which displays themessage "HOWCAN I HELPYOU?" This is appeal-ing at first glance, but after some use, this come-onbecomes annoying. The illusion that the machine isjust like a human teller is perceived as a deceptionand the user begins to wonder about other ways inwhich the bank has been deceptive. The attempt todominate the interaction, by implying that the ter-minal will help the user by emphasizing the "I,"violates common rules of courtesy. If a startingmessage is used at all, it probably should focus on thecustomer-for example, "WHATDO YOU NEED?"followed by a list of available operations. In any casethe user should initiate the operation by hitting a but-ton labeled "START," thus reinforcing the idea thatthe user is in control of the machine.Early computer-assisted instruction systems

heaped praise on the student and "wisely" guided thestudent through the material at a computer-selectedpace,; more recent systems merely display perfor-mance scores and provide an environment where thestudent chooses the path and pace. Only children ap-preciate praise from a computer; most people achieveinternal satisfaction if their performance is satisfac-tory. Instead of the lengthy "VERY GOOD, YOUGOTTHE RIGHTANSWER," the simple display of"+ +" signals a correct answer to a problem.Reinforcement for these ideas comes from Jerome

Ginsburg of the Equitable Life Assurance Society,who prepared an in-house set of guidelines fordeveloping interactive applications systems. Hemakes the powerful claim that

Nothing can contribute more to satisfactory system per-formance than the conviction on the part of the terminaloperators that they are in control of the system and notthe system in control of them. Equally, nothing can bemore damaging to satisfactory system operation,regardless of how well all other aspects of the implemen-tation have been handled, than the operator's convictionthat the terminal and thus the system are in control, have"a mind of their own," or are tugging against rather thanobserving the operator's wishes.

Being in control is one of the satisfying com-ponents of time-sharing and of programming ingeneral. Systems which are designed to enhance usercontrol are preferred. One explanation of why wordprocessing systems have come into widespread use inonly the last few years is that mini and microcom-puters give users a powerful feeling of being in con-trol compared to the time-shared usage of a largemachine. Files kept on floppy disks are tangible whencompared to disk files on an unseen remote machine.Although failures, loss of files, and faulty disks prob-ably occur more often on the stand-alone minis and

COMPUTER

Forgiveness-ease in repairing errorsSegmentation-layered approachVariety-choice of styleEscape-break out of dangerGuidance-direction and learningLeverage-flexible, powerful features

Figure 7. Humanimachine interface design criteriain a computerized conferencing environment (M.W.- Turoff, J. L. Whitescarver, and S. R. Hiltz,1978)-13

Use terse ''natural'" language, avoid codes, allow ab-breviations.Use short entries to facilitate error correction and main-tain tempo.Allow user choice of single or multiple entries.Maintain "social element" to the communication.Permit user to control length of cues or error messages.Error messages should be polite, meaningful, and infor-mative.Give help when requested or when users are in difficulty.Simple, logically consistent command language.Control over all aspects of the system must appear tobelong to the user.Avoid redundancy in dialogue.Adapt to the user's ability.Keep exchange rate in user's stress-free range; usercan control rate.

Figure 8. Ground rules fora "well-behaved" system(T. C. S. Kennedy, 1974).14 This list is based on ex-perimental studies with data entry.

12

micros than on larger systems, the users of minis andmicros have the satisfaction of controlling their owndestiny.

Closure

One of the byproducts of the limitation on humanshort-term memory is that there is great relief wheninformation no longer needs to be retained. This pro-duces a powerful desire to complete a task, reduce ourmemory load, and gain relief. Closure is the comple-tion of a task leading to relief. Since terminal usersstrive for closure in their work, interactions should bedefined in sections so completion can be attained andinformation released. Every time a user completesediting a line or ends an editing session with an EXITor SAVE command, there is relief associated withcompletion and attaining closure.The pressure for closure means that users, especial-

ly novices, may prefer multiple small operations to asingle large operation. Not only can they monitorprogress and.ensure that all is going well, but theycan release the details of coping with early portions ofthe task. One informal study shQwed that userspreferred three separate menu lists. rather than threemenus on the screen at once. Although more typingand more interactions were required for the threeseparate menus, the users preferred doing one smallthing at a time. With three menus at a time, the infor-mation about the first menu decision must be main-tained until the system acknowledges or theRETURN key is hit. Similarly, word processor usersmay make three separate changes on adjacent words,when one large change command could have ac-complished the same results with fewer keystrokes.

Response time

Most designers recognize that a simple limit onresponse time, the time it takes for the system to re-spond to a command (e.g., two seconds), is anunreasonably crude specification. Some systemshave design specifications of two-second responsetime for 90 percent of the commands and 10-secondresponse time for the remaining 10 percent. A moreinformed view is that the acceptable response time isa function of the command type. Users are notdisturbed to wait several seconds for the loading of afile or large program, but expect immediate responseto editing commands or emergency requests. R. B.Miller'8 provides a list of 17 command types andreasonable response times (Table 1).Wemay disagreewith specific entries or suggest new entries, but theidea of having different response times seems accep-table. In fact, one possible approach is to guaranteethat more complex and expensive commands requirelonger waits. This will tend to make users favorfaster, cheaper commands.A contrasting design goal is to minimize the

variance of response time. It has been confirmed byexperiment'9 that increasing the variability of

response time generates poorer performance (Figure9) and lower user satisfaction (Figure 10). Users mayprefer a system which always responds in 4.0 secondsto one which varies from 1.0 to 6.0 seconds, eventhrough the average in the second case is 3.5. Ap-parently users can devote 3.9 seconds to planning ifthey are sure that the time is available. If attentionhas to be maintained on the screen, users will not usethe response time for planning work. Some users evenreport surprise and disruption if thb response is tooprompt. Holding responses to minimize responsetime variance may actually improve user perfor-mance and satisfaction. For extremely long responsetimes-i.e., more than 15 seconds-the user should beinformed of the time required. One graphics systemshows a clock hand ticking backwards counting offthe seconds until the system will respond. Even if theresponse is ready earlier, the system continues itscountdown to zero.

Table 1.System response times as function of user activity (R. B. Miller, 1968).18

USER ACTIVITY

CONTROL ACTIVATION (FOR EXAMPLE,KEYBOARD ENTRY)

SYSTEM ACTIVATION (SYSTEMINITIALIZATION)

REQUEST FOR GIVEN SERVICE:SIMPLECOM PLEXLOADING AND RESTART

ERROR FEEDBACK (FOLLOWINGCOMPLETION OF INPUT)

RESPONSE TO ID

INFORMATION ON NEXT PROCEDURE

RESPONSE TO SIMPLE INQUIRY FROM LIST

RESPONSE TO SIMPLE STATUS INQUIRY

RESPONSE TO COMPLEX INQUIRY INTABLE FORM

REQUEST FOR NEXT PAGE

RESPONSE TO "EXECUTE PROBLEM"

LIGHT PEN ENTRIES

DRAWINGS WITH LIGHT PENS

RESPONSE TO COMPLEX INQUIRY INGRAPHIC FORM

RESPONSE TO DYNAMIC MODELING

RESPONSE TO GRAPHIC MANIPULATION

RESPONSE TO USER INTERVENTION INAUTOMATIC PROCESS

"'MAXIMUM" RESPONSE TIME(SECONDS)

0.1

3.0

2.05.0

15.0-60.0

2.0-4.0

-2.0

< 5.0

2.0

2.0

2.0-4.0

0.5-1.0

<15.0

1.0

0.1

2.0-10.0

2.0

4.0

December 1979 13

Installers of time-sharing systems report userdissatisfaction in two situations where response timevariance is a factor. In the first case, when anew time-sharing system is installed and the workload is light,response times are low and users are pleased. As theload increases, the response time will deteriorate tonormal levels and produce dissatisfaction. By slow-

Figure 9. Graph of time to complete tasks vs. outputvariability for low volume and high volume. (L. H. Miller,1 977)-'9

Figure 10. Graph of average response to post-test ques-tionnaire vs. output variability for 1200 and 2400 baud(L. H. Miller, 1977).'9

ing down the system when it is first installed, thechange is eliminated and users seem content. A sec-ond case occurs when the load on a time-sharingsystem varies substantially during the day. Usersbecome aware of the fast and slow periods and try tocram their work into the fast periods. Although thisapproach does help to balance the load, users tend tomake errors while working quickly to beat the crowd.Anxiety is increased, complaints increase, and pro-grammers or terminal users may even be unwilling towork during the slow periods. By eliminating thevariance in response time, service is perceived to bemore reliable and one source of anxiety can be re-duced.In summary, response time is an intriguing issue

whose complexities have not yet been unraveled. Weare left with several conflicting design goals:

* Response time should be reduced under all condi-tions.

* Response time should match the complexity andcost of the command.

* Variance of response time should be reducedeven at the expense of some increase in meanresponse time.

* System performance should not vary over time.

In an experiment studying the effect of systemresponse time on performance in a multi-parameteroptimization task, solution time increased signifi-cantly with system response time.20 Subjectsmodified five parameters with light pen touches till acurve matched requirements. Each of the 30 subjectsperformed the task with fixed system response timesof 0.16, 0.72, and 1.49 seconds. Figure 11 shows thatdecreasing the response time from 1.49 to 0.72seconds reduces the solution time for this task.

Figure 11. Solution time (T) versus System ResponseTime 2SRT) for 30 subjects (Goodman and Spence,1 978).2

COMPUTER14

Grossberg, Wiesen, and Yntema2l studied foursubjects performing 36 interactive tasks involvingcalculations on numeric arrays. Response times werevaried from 1 to 4 to 16 to 64 seconds. As the responsetime increased subjects became more cautious, usedfewer commands, and took longer time between com-

mands, but the total time consumed showed surpris-ing invariance with respect to the response time in-crease. The subjects changed their working style asthe response time increased by becoming more

cautious and by making heavier use of hard copyprintouts. The difference in results between this ex-

periment and the previous one may be a product ofthe available commands, required tasks, or subjectexperience.A related aspect of response time is the thought

time of the terminal user. For complex decision-making, there is some evidence that locking the ter-minal for a short period, say 25 seconds in one pilotstudy, may improve user performance on the decisionand increase user satisfaction. An open keyboard andpartial attention to the display can distract the usersand interfere with problem-solving while increasinganxiety. The illusion of "dialog" may compel users tokeep their end of the "conversation" going. Adecision-making study22 with longer lockout times (5and 8 minutes) revealed that subjects with no lockoutused twice as much computer time and, as might beexpected, the lockout groups expressed dissatisfac-tion with restricted access. The high variance in per-formance of the -20 subjects made it impossible toassess the impact of lockout, although the highestperformance mean was achieved by the 5-minutelockout group. Possibly if users perceive the com-

puter as a tool, they may be more willing to take theirtime and reflect on decisions. If users feel they are in-

volved in a "dialog" in which they must respondpromptly, anxiety and poorer performance may

result. Maybe we should replace the term "dialog"with "utilog" conveying the impression that the useris utilizing the system as a tool.

Time-sharing vs. batch processing

As technological developments allowed program-mers to use interactive terminals for preparing andexecuting their programs, a controversy arose overthe relative merits of interactive usage and tradi-tional batch submittal. Adherents of time-sharingargued that waiting for processing by batch-orientedcomputer systems was annoying, disruptive, andtime-consuming. Others felt that time-sharing en-

couraged sloppy and hasty programming, which inturn led to more errors and poorer quality work.Two of the earliest studies comparing on-line and

off-line processing were by Schatzoff, Tsao, andWiig29 and Gold.23 The former study showed a 50 per-cent higher total cost for time-sharing, and a

50-percent greater elapsed time for batch, withno dif-ference in computer time. More compilations weremade on-line, suggesting less time is spent in deskchecking. According to Gold,24 the "user's attitude

appears to be one of the variables which may in-fluence the user's immediate behavior and usage ofcomputer systems." Both studies agreed that someperformance variations may be attributable to pro-grammer and problem differences.Smith25 examined the effects ofconventional batch

versus instant batch (less than 5 minutes). Withrespect to elapsed time (time from the start of a prob-lem to its completion) and student reaction, instantsurpassed conventional.Summarizing five studies comparing on-line to off-

line problem solving (including the two mentionedabove), Sackman26'27 stated that time-sharing had a20-percent advantage over batch in hours used,whereas batch surpassed time-sharing with a40-percent advantage in CPU time. In regard to cost,neither mode outperformed the other. Sackman sug-gested that "the comparison ... is becoming academicas the contest converges toward interactive time-sharing and fast or even instant batch." Thesestudies need to be reevaluated and redone since hard-ware speeds and software capabilities have changedsubstantially in the last decade.As a result of experimentation with junior college

students, the use of time-sharing was recommendedto alleviate the high drop-out rate from the introduc-tory computer science courses.28 The immediate feed-back of time-sharing was seen as positively reinforc-ing.The decrease in literature comparing the two

modes of program development and the increase inarticles on time-sharing systems give the illusionthat the controversy has ended and the superiority ofon-line processing is accepted. But some managersand researchers suggest that time-sharing mode en-courages hasty program development and increasesthe number of errors. They feel that the slower turn-around of batch processing produces more carefulprogram design and thorough desk debugging.In a related application of interactive systems, J.

V. Hansen29 investigated performance differencesfor two management decision-making tasks. usingtime-sharing and batch approaches. Both problems,stochastic capital budgeting and product demandforecasting, were not solvable by a mathematicalalgorithm. Instead, they required heuristic ap-proaches where feedback from each interactionwould suggest new decision rules. The results (Table2) demonstrate that in this environment time-sharing

Table 2.Decision-making performance averages using time-sharing

and batch modes (J. V. Hansen, 1976).29

GROUP A GROUP B(BATCH/ON-LINE) (ON-LINE/BATCH)

(5 SUBJECTS) (5 SUBJECTS)

PROBLEM 1 82.0 88.4(CAPITAL BUDGETING) (BATCH) (ON-LINE)

PROBLEM 2(PRODUCT DEMAND 90.6 84.6

FORECAST) (ON-LINE) (BATCH)

15December 1979

access significantly improved the quality of the deci-sions.In short, the experimental results suggest that a

good time-sharing system is better than a bad batchsystem. Correcting minor errors quickly in time-sharing mode speeds productivity and reduces irrita-tion. For more fundamental work, some program-mers may abuse the rapid access of time-sharing,make hasty patches, and produce poor code.In all the experimental results, the influence of in-

dividual differences apparently played a major role.The high variance in performance and conflictinganecdotal evidence suggests that unmeasured factorssuch as personalitymay influence preference and per-formance. Whether or not a programmer wants to useinteractive equipment may be an important con-sideration. Merely because many programmers,perhaps even a majority, prefer interactive modedoes not mean that all programmers should utilizethat mode. Those individuals who feel more securewith a deck ofkeypunch cards arejust as necessary toan organization.Many variables enter into a programmer's

preference for a particular computer communicationalternative. In an effort to identify specific personali-ty traits influencing preference, Lee and Shneider-man30 studied locus of control and assertiveness.Locus of control focuses on the perception in-

dividuals have of their influence over events. Inter-nally controlled individuals perceive an event as con-tingent upon their own action, whereas externallycontrolled people perceive a reinforcement for an ac-tion as being more a result of luck, chance, or fate;under the control of other powerful people; or un-predictable.Assertive behavior "allows an individual expres-

sion in a manner that fully communicates his per-sonal desires without infringing upon the right ofothers."31 Assertive individuals can state their feel-ings; nonassertive people have difficulty doing so.

Table 3.Preference scores and personality factors (Lee and

Shneiderman, 1978).3

TIMEBATCH SHARING TOTAL

0 1 2 3 4 MEAN OBSERVATIONS

LOCUSDIMENSION:

INTERNAL 0 0 2 2 2 3.0 6

EXTERNAL 0 0 8 4 0 2.3 1218

ASSERTIVENESSDIMENSION:

LOW 0 0 5 3 0 2.4 8

HIGH 0 0 5 3 2 2.7 1018

Manyprogrammers learneduse ofkeypunch equip-ment before being introduced to time-sharing. Itwould be less anxiety provoking for them to remainwith a mode of program entry which is familiar-i.e.,keypunch-than to attempt on-line communicationwith its many problems-e.g., signing on or possibleloss of an editing session. It seems that individualswho view themselves as more effective and powerful,or internally controlled, would master on-line interac-tion with the computer, while those who see them-selves as less powerful and not very independent or

effective, or externally controlled, would continue toprocess by batch.

Likewise, more assertive programmers would notlet the intimidating terminal inhibit them from learn-ing and using interactive equipment. They would beable to ask for help when needed, thus promotingtheir learning process. The nonassertive individualmight look for a means ofprogram entry which allowsleast contact with others, including avoidance ofequipment which could require a great deal of helpand guidance during the familiarization stage.Weinberg32 conjectures that "humble programmersperform better in batch environments and assertiveones will be more likely to shine on-line."Subjects for our exploratory study were program-

mers from a Control Data Corporation installation,which allows the choice of either card or terminal en-

try. Three questionnaires, one to measure locus ofcontrol, one to ascertain assertiveness, and anotherto determine on-line or off-line preference were

distributed via interoffice mail.When the 18 responses were groupedby preference

scores (Table 3), the batch group did not differsignificantly from the interactive group on either per-sonality dimension: locus of control or assertlveness.However, when the sample was grouped by internallocus/high assertive and external locus/low assertive(Table 4), there was a significant difference in meanpreference scores. Confirming studies need to be car-ried out with more subjects in a wide variety of pro-

gramming environments.Although our findings in this exploratory study

showed mixed results, the import lies in the attemptto identify variables entering into a programmer'spreference for either batch or time-sharing. If pro-grammers are allowed to use the mode they prefer,their performance and job attitude could improve. If

Table 4.Average preference scores for personality groups (Lee

and Shnelderman, 1978).30

INTERNAL LOCUS/ EXTERNAL LOCUS/HIGH ASSERTIVE LOW ASSERTIVE

M EANPREFERENCE 3.34 2.54SCORE

VARIANCE 0.399 .0.108

NUMBER OFSUBJECTS (TOTAL 4 6NUMBER WAS 18)

16 COMPUTER

preference is affected by the type of task, theavailability of different modes may again improveperformance. When recruiting programmers for atime-sharing environment, managers may find thatthose who desire to work on-line will produce betterproducts in that environment than those who preferworking in a batch environment.

Text editor usage

A rapidly growing mode of computer use is by wayof text editors, document preparation systems, andword-processing equipment. These tools allow usersto construct files containing programs, alphanumericdata, correspondence, or general textual information.The diversity ofuser experience and the range ofuserpatterns is enormous. Sophisticated frequent usersdiffer from infrequent users, who are all very dif-ferent from novice users. The variety ofhardware andsoftware environments further increases the choicesfor text editor designers and users.Experimental comparisons of text editors are pro-

viding information about usage patterns, suggestingdirections for development projects, and aidingdevelopment of a cognitive model. Walther andO'Neil17 report on an experiment with 69 undergrad-uate computer science students: 41 percent hadneverused an on-line system, 38 percent had some ex-perience, and 22 percent had much experience. Thethree experimental factors were flexibility (one ver-sion of the editor was inflexible; the second versionpermitted abbreviations, default values, userdeclaration of synonyms, a variety of delimiters, andother features), display device (cathode ray tube andimpact teletype, both at 10 cps), and attitude (threesubjective tests indicating attitude towards com-puters and anxiety). The subjects performed 18 cor-rections to a text file while errors were tabulated andtiming data was collected. Experienced users workedfaster with the flexible version, but inexperiencedusers were overwhelmed by the flexible version. Theinexpenenced users made fewer errors and workedfaster with the inflexible version. The impactteletype users worked faster and made fewer errors,suggesting that the feedback from the impact mayfacilitate performance. Those with negative at-titudes made more errors. Walther and O'Neil offerinteraction effects, conjectures, potential designrules, and research directions.Sondheimer33 describes an experiment with more

than 60 professional programmer users of a texteditor. With active participation of the subjects, fivefeatures were chosen for addition to the text editor.Announcements, documentation, and training wereprovided, but after some initial testing, usage of thefeatures dropped off substantially. Sondheimer con-cludes that "the results of the experiment seem to in-dicate the persistence of individual usage habits."This experiment has implications which go beyondtheuse of text editors, but it does emphasize that textediting is a skill which is deeply ingrained in theuser's mind and difficult to change. Sondheimer con-

jectures that novice users of the text editor wouldmore frequently employ the newly added features.Card34 and Card, Moran, and Newell3536 provide

detailed reports on text editor experiments and offercognitive models of human performance. Their ex-periments emphasize in-depth study of a limitednumber of highly trained subjects. Subjects per-formed manuscript editing tasks with a variety ofline and display editors while precise timingmeasurements were made automatically. Textediting is characterized as a "routine cognitive skill"which "occurs in situations that are familiar andrepetitive, and which people master with practice andtraining, but where the va,riability in the task, plusthe induced variability arising from error, keeps thetask from becoming completely routine and requirescognitive involvement. '35 A cognitive model basedon goals, operators, methods, and selection rules(GOMS model) is proposed and is claimed to repre-sent the performance of expert users. User style inlocating a line (by jumping ahead a given number oflines or by locating a character string) and correctingtext (by substitution or by subcommands for modify-ing characters in a line) was compared among sub-jects with the goal of predicting behavior in futuresituations.Card, Moran, and Newell35 use data from 28 sub-

jects, on 10 systems, and over 14 task types to sup-port the keystroke model of editor usage, suggestingthat task performance time can be predicted from aunit task analysis and the number of keystrokes re-quired. This model has strict requirements: "Theuser must be an expert; the task must be a routineunit task; the method must be specified in detail; andthe performance must be error-free. " The timing datafrom a variety of users and systems reveals impor-tant differences, such as the speed advantage ofdisplay editors over line editors (about twice as fast).The timing data from Card33 demonstrates the clearspeed and accuracy advantages of a mouse for selec-ting text, when compared with a joystick, step keys,or text keys.

Error handling

The error-checking and handling components of anon-line system may occupy the majority of the pro-gramming effort. Well-designed diagnostic facilitiesand error messages can make a system appealing.When user entries do not conform to expectations,diagnostic messages should guide the user in enter-ing correct commands. Messages should be brief,without negative tones, and should be constructive.Avoid ringing bells and bold messages which mayembarrass the user. Instead of meaninglessmessages like "ILLEGAL SYNTAX," try to in-dicate where the error occurred andwhatmay be doneto set it right. If possible, allow users to modify the in-correct command rather than forcing complete reen-try. Command and programming languages shouldbe designed so that a common error will not be inter-preted as a valid command.

December 1979 17

Error messages should be included in the systemdocumentation, so that users know what to expectand so that designers cannot hide sloppy work in thesystem code.The system should permit easy monitoring of error

patterns so that system design can be modified inresponse to frequent errors. Simple tallies of error oc-currences may suggest modifications of errormessages, changes to command languages, or im-proved training procedures.An intriguing issue in error handling is whether the

error message should be issued immediately or whenthe end-of-line code (usually ENTER or RETURNkey) is hit. A nicely designed study37 suggests thathuman performance improves if errors are issued im-mediately and that the disruption of user, thoughtprocesses by immediate interruption is not a seriousimpediment. Seventy undergraduate subjects in thisexperiment had to list 25 of'the 50 states in the USAand list 20 permutations of "abcde" such that "c" oc-curs somewhere before the "d. " The results of the per-mutation task strongly favor immediate interrup-tion, but the results of the states task were mixed(Table 5). A powerful advantage of immediate inter-ruption is that changes can be made simply by replac-ing the incorrect character.A central problem in handling errors is providing

the user with the right kind of information. Ex-perienced frequent users need only an indication thatan error has occurred, such as a locked keyboard, alight, or a special character. As soon as the error hasbeen brought to their attention, they will probablyrecognize it and be prepared to make an immediatecorrection. Typical users familiar with the operationsor semantics of the domain merely require a brief noteto remind them of proper syntax or list of availableoptions. Novice users whose semantic knowledge isshallow need more than prompting on syntax; theyneed explanations of possible commands and the re-quired syntax. Since even experts may forget or benovices with respect to some portions of a system, asimple scheme based on recording user experiencelevels is unworkable. Probably the best approach is togive control to the user and provide options-maybe"?"for a brief prompt about syntax, a second"?" for

Table 5.Average performance results to error correction styles (Segal, 1975).37

STATES TASK PERMUTATION TASK

ERROR CORRECTION METHODIMMEDIATE END IMMEDIATE END

PERCENT ERRORKEYPRESSES 2.55 1.99 4.54 4.48

TOTAL TIME(SECONDS) 234.0 300.0 408.8 546.4

TWO CONSECUTIVERESPONSES IN 1.17 1.17 1.00 2.77ERROR

NUMBER OFRESPONSES IN 4.29 3.77 4.46 4.83ERROR

a brief prompt about semantics, and a third"?" for amore detailed explanation. Users could strike "??" or"???" initially to get complete information right away.This question mark scheme is a simple approach to

what are generally referred to as "HELP" systems.Typing "HELP" or merely "H" the user can getsome information; "HELP FILES," "HELPEDIT," "HELP FORTRAN," etc., may invoke moreextensive topic-oriented HELP facilities. "HELPHELP" should provide information about availablefacilities. The PLATO instructional system offers aspecial HELP key which offers appropriate guidancefor the material currently on the screen.

Practitioner's summary

Do not violate the bounds of human performanceimposed by limited short-term memory capacity.Design interactions in a modular fashion so thatclosure can be obtained providing satisfaction andrelief for users. Be sensitive to user anxiety anddesire for control. Provide novice users with thesatisfaction of accomplishment and a sense ofmastery, but avoid patronizing comments. Considerresponse time'requirements as part of the design, notas an uncontrollable aspect of system performance.Respect user preferences in choice of batch or in-

teractive program development. Accept the per-sonality and cognitive style differences among in-dividuals and do not attempt to make everyonebehave as you do.Devote substantial energy to error design. Make

messages constructive and give guidance for usingthe system in a courteous nonthreatening way.Prepare all messages as part of the system design andmake them available in user manuals. Give users con-trol over what kind of and how much informationthey wish at every point in the interaction. Do not re-quire them to identify themselves at the start asnovices. HELP facilities should be available for everycommand.Respect and nurture the user community. Listen to

their gripes with sympathy and be willing to modifyyour system to accommodate their requests. Remem-ber, the goal is not to create a computerized system,but to serve the user.

Acknowledgments

This article was adapted from portions of the forth-coming book, Software Psychology: Human Factorsin Computer and Information Systems (WinthropPublishers). The support for computer resources wasprovided by the University of Maryland ComputerScience Center. Helpfulcomments on earlier drafts ofthis paper were provided byJim Foley, John Gannon,Tom Love, G. Michael Schneider, John C. Thomas,Jr., and Jerry Weinberg.

References

1. Henry Dreyfuss, Designing for People, Simon andSchuster, New York, 1955.

COMPUTER18

2. R. S. Nickerson, "Man-Computer Interaction: AChallenge for Human Factors Research," IEEETrans. Man-Machine Studies, MMS-10, 1969, p. 164.

3. J. L. Bennett, "The User Interface in InteractiveSystems," in C. Cuadra(ed.), Annual Review ofInfor-mation Science and Technology, Vol. 7, AmericanSociety for Information Science, Washington, D.C.,1972, pp. 159-196.

4. J. Martin, Design of Man-Computer Dialogues,Prentice-Hall, Englewood Cliffs, N. J., 1973.

5. L. A. Miller and J. C. Thomas, Jr., "Behavioral Issuesin the Use of Interactive Systems," Int'l J. Man-Machine Studies, Vol.9, 1977, pp. 509-536.

6. B. Shneiderman, "Improving the Human FactorAspect of Database Interactions," ACM Trans. onDatabase Systems, Vol. 3, No. 4, Dec. 1978, pp.417-439.

7. W. J. Hansen, "User Engineering Principles for In-teractive Systems," AFIPS Conf. Proc., Vol. 39,1971FJCC, AFIPS Press, Montvale, N. J., 1971, pp.523-532.

8. A. I. Wasserman, "The Design of Idiot-Proof Interac-tive Systems," AFIPS Conf. Proc., Vol. 42,1973 NCC,AFIPS Press, Montvale, N. J., 1973, pp. M34-M38.

9. R. W. Pew and A. M. Rollins, "Dialog SpecificationProcedure," Bolt Beranek and Newman, Report No.3129, Revised Ed., Cambridge, Mass., 1975.

10. Brian R. Gaines and Peter V. Facey, "Some Ex-perience in Interactive System Development and Ap-plication," Proc. IEEE, Vol. 63, No. 6, June 1975, pp.894-911.

11. D. R. Cheriton, "Man-Machine Interface Design forTime-Sharing Systems," Proc. ACMNat'l Conf., 1976,pp. 362-380.

12. F. Gebhardt and I. Stellmacher, "Design Criteria forDocumentation Retrieval Languages,"J. Am. Soc. In-formation Science, Vol. 29, No. 4, July 1978, pp.191-199.

13. M. W. Turoff, J. L. Whitescarver, and S. R. Hiltz, "TheHuman Machine Interface in a Computerized Con-ferencing Environment," Proc. IEEE Conf on In-teractive Systems, Man, and Cybernetics, 1978, pp.145-157.

14. T. C. S. Kennedy, "The Design of Interactive Pro-cedures for Man-Machine Communication," Int'l J.Man-Machine Studies, Vol. 6, 1974, pp. 309-334.

15. J. D. Foley and V. L. Wallace, "The Art of GraphicMan-Machine Conversation," Proc. IEEE, Vol. 62,No. 4, Apr. 1974, pp. 462-471.

16. StephenE. Engel and RichardE. Granda, "Guidelinesfor Man/Display Interfaces," IBM PoughkeepsieLaboratory Technical Report TR 00.2720, Dec. 19,1975.

17. G. H. Walther and H. F. O'Neil, Jr., "On-line User-Computer Interface-the Effect of Interface Flexibili-ty, Terminal Type, and Experience on Performance,"AFIPS Conf Proc., Vol. 43, 1974 NCC, pp. 379-384.

18. Robert B. Miller, "Response Time in Man-ComputerConversational Transactions," AFIPS Conf. Proc.,Vol. 33, 1968 SJCC, pp. 267-277.

19. L. H. Miller, "A Study in Man-Machine Interaction,"AFIPS Conf. Proc., Vol. 46, 1977 NCC, pp. 409-421.

20. T. Goodman and R. Spence, "The Effect of SystemResponse Time on Interactive Computer-Aided Prob-lem Solving," Proc. ACM SIGGRAPH '78 pp.100-104.

21. Mitchell Grossberg, Raymond A. Wiesen, and DouweB. Yntema, "An Experiment on Problem SolvingwithDelayed Computer Responses," IEEE Trans.Systems, Man, and Cybernetics, Vol. SMC-6, No. 3,Mar. 1976, pp. 219-222.

22. B. W. Boehm, M. J. Seven, and R. A. Watson, "In-teractive Problem-Solving-An Experimental Studyof 'Lockout' Effects," "AFIPS Conf Proc., Vol. 36,1971 SJCC, pp. 205-210.

23. M. Schatzoff, R. Tsao, and R. Wiig, "An ExperimentalComparison of Time-Sharing and Batch Processing,"Comm. ACM, Vol. 10, No. 5, May 1967, pp. 261-265.

24. M. M. Gold, "Time-Sharing and Batch Processing: AnExperimental Comparison of their Value in a Problem-Solving Situation," Comm. ACM, Vol. 12, No. 5, May1969, pp. 249-259.

25. L. B. Smith, "A Comparison of Batch Processing andInstant Turnaround," Comm. ACM, Vol. 10, No. 8,Aug. 1967, pp. 495-500.

26. H. Sackman, "Experimental Analysis of Man-Computer Problem-Solving,"Human Factors, Vol.12,1970, pp. 187-201.

27. H. Sackman, Man-Computer Problem Solving, Auer-bach Publishers Inc., Princeton, N. J., 1970.

28. Michel Boillot, "Computer Communication Modesand their Effect on Student Attitudes Towards Pro-gramming," Nova University thesis, availablethrough ERIC ED 098 957, Apr. 1974.

29. J. V. Hansen, "Man-Machine Communication: AnEx-perimental Analysis of Heuristic Problem-Solvingunder On-Line and Batch-Processing Conditions,"IEEE Trans. Systems, Man and Cybernetics, Vol. 6,No. 11, Nov. 1976, pp. 746-752.

30. Jeanne M. Lee and B. Shneiderman, "Personality andProgramming: Time-Sharing vs. Batch Processing,"Proc. ACMNat'l Conf., 1978, pp. 561-569.

31. B. J. Winship and J. D. Kelly, "A Verbal ResponseModel of Assertiveness," Counseling Psychology,Vol. 23, No. 3, 1976, pp. 215-220.

32. G. M. Weinberg, The Psychology of Computer Pro-gramming, Van Nostrand Reinhold, N. Y., 1971.

33. Norman Sondheimer, "On the Fate of SoftwareEnhancements, AFIPS Conf Proc., Vol. 48, 1979NCC, pp. 1043-1048.

34. Stuart K. Card, "Studies in the Psychology of Com-puter Text Editing," Xerox Palo Alto ResearchCenter, SSL-78-1, San Jose, Calif., Aug. 1978.

35. Stuart K. Card, Thomas P. Moran, and Allen Newell,"The Keystroke-Level Model of User PerformanceTime with Interactive Systems" (submitted forpublication).

36. Stuart K. Card, Thomas P. Moran, and Alan Newell,"Computer Text-Editing: An Information-ProcessingAnalysis of a Routine Cognitive Skill," CognitivePsychology (to appear).

37. Barr Zion Segal, "Effects of Method of Error Inter-ruption on Student Performance at Interactive Ter-minals," University of Illinois Department of Com-puter Science Technical Report UIUCDCS-R-75-727,May 1975.

Ben Shneiderman, an associate pro-fessor at the University of Maryland,has produced five books (including theforthcoming Software Psychology)plus 50 articles on data-base manage-ment, programming, and human fac-tors. After receiving his PhD in com-puter science-from the State Universityof New York at Stony Brook, he spentthree years teaching in the Department

of Computer Science at Indiana University, before comingto the University of Maryland in 1976.

December 1979 19