SKYHAWKE EX. 1015, page 2
`
`

`
`SKYHAWKE EX. 1015, page 3
`
`

`
`Designing the User Interface:
`Strategies for Effective
`Human-Computer Interaction
`
`BEN SHNEIDERMAN
`
`The University ofMaryland
`
`Illustrations by Carol Wald
`
`A V
`
`V
`
`ADDISON-WESLEY PUBLISHING COMPANY
`.
`I
`? ’
`/.
`_
`.-
`,
`READING, MASSACHUSETFS ' MENLO PARK, CALIFORNIA
`DON MILLS. ONTARIO ' WOKINGHAM, ENGLAND ' AMSTERDAM
`SYDNEY - SINGAPORE - TOKYO - MADRID ~ BOGOTA
`SANTIAGO - SAN JUAN
`
`

`
`Library of Congress Cataloging-in-Puhlication Data
`Shneiderman, Ben.
`'
`Designing the User Interface: Strategies for Effective Human-Computer
`Interaction
`'
`i
`‘
`
`Bibliography: p.
`Includes indexes.
`1._
`Interactive computer systems. 2. System design.
`1. Title.
`.
`‘
`QA76.9.I58S47 1987
`ISBN 0-201-16505-8
`
`004.5
`
`85-287_65
`
`Many of the designations used by manufacturers and sellers to distinguish their products are claimed
`as tmdemarks. Where those designations appear in this book, and Addison—Wesley was aware of a
`tradernark claim, the designations have been printed in initial caps or all caps.
`
`Reprinted with corrections May, 1987
`
`Text reproduced by Addision-Wesley from camera—ready materials provided by the author. Cover
`and chapter opening ililustrations ©Caro1 Wald".
`
`Copyright ©1987 Addison-Wesley Publishing Company, Inc. All rights
`reserved. No part of this publication may be reproduced, stored in a retrieval
`system, or transmitted, in any form or by any means, electronic, mechanical,
`photocopying, recording, or otherwise, without the prior written permission of
`the publisher. Printed in the United States of America. Published
`simultaneously in Canada.
`I
`'
`'
`
`FG.HIJ—HA—8_9
`
`

`
`CHAPTER 2
`
`THEORIES, PRINCIPLES, AND GUIDELINES
`
`We want principles,
`not only deVe1oped,~the work of the closet,‘
`
`Horace Mann, Thoughts, 1867
`
`

`
`Designing the User Interface
`
`2.1
`
`INTRODUCTION
`
`they can and
`Successful designers of interactive systems know that
`must go beyond intuitive judgments made hastily when a design problem
`emerges, Fortunately, guidance for designers is beginning to emerge in
`the form of:
`‘
`‘
`
`high—lcvel theories or models
`
`middle-level principles
`specific and practical guidelines and
`strategies for testing.
`
`The theories or models offer a way to organize the design process,
`whereas the middle-level principles are useful
`in weighing alternatives.
`The practical guidelines provide helpful reminders of rules, uncovered by
`previous designers. Early prototype evaluation encourages exploration
`and
`enables
`iterative
`design
`to
`correct
`inappropriate
`decisions.
`Acceptance testing is the trial—by-fire to determine whether a system is
`ready for distribution; its presence may be seen as a challenge, but it is
`also a gift to designers since it establishes clear measures of success.
`In many contemporary systems, there is a grand opportunity to improve
`the human interface. The cluttered and multiple‘ displays, complex and
`tedious
`"procedures,
`inadequate
`command
`languages,
`inconsistent
`sequences of actions, and insufficient informative feedback can generate
`debilitating stress and anxiety that
`lead to poor performance, frequent
`minor and occasional serious errors, and job dissatisfaction:
`
`This chapter begins with a review of theories, concentrating on the
`syntactic/semantic model. Section 2.3 then deals with frequency of use,
`task profiles, and interaction styles. Eight principles of interaction are
`offered in Section 2.4. Strategies for preventing errors are described in
`Section 2.5. Specific guidelines for data entry and display appear in
`Sections 2.6 and 2.7. Testing strategies are presented in Section.2.8 and
`covered in detail
`in Chapter 10. Section 2.9 attempts to deal with the
`difficult question of the balance between automation and human control.
`
`

`
`Ch. 2 Theories, Principles, and Guidelines
`
`43
`
`2.2 A HIGH-LEVEL THEORY: SYNTACTIC/
`
`SEMANTIC MODEL OF USER KNOWLEDGE
`
`Distinctions between syntax and semantics have long been made by
`compiler writers who sought to separate out the parsing of input text from
`the operations that were invoked by the text.
`Interactive system designers
`can benefit
`from a syntactic/semantic model of user knowledge.
`In
`outline,
`this
`explanatory model
`suggests
`that users have syntaetif
`knowledge about device-dependent details and semantic knowledge about
`concepts.
`The semantic knowledge is
`separated into task concepts
`(objects and actions) and computer concepts (objects and actions) (see
`Figure 2.1). A person can be an expert in the computer concepts, but a
`novice in the task, and vice versa.
`
`The syntactic/semantic model of user behavior was originated to
`describe programming (Shneiderman & Mayer,
`1979; Shneiderman,
`
`ACHON
`
`OBJECT ‘
`
`TASK
`
`ACTION
`
`OBJECT
`
`COMPUTER
`
`SEMANTlC
`
`SYNTACTIC
`
`Figure 2.1: A representation of the user’s knowledge in long—term memory. The
`Syntactic knowledge is varied, device dependent, acquired by rote memorization,
`and easily forgotten. The semantic knowledge is separated into the computer
`and task domains. Within these domains, knowledge is divided into actions and
`objects.
`Semantic knowledge is structured, device independent, acquired by
`meaningful learning, and stable in memory.
`
`

`
`Deswgning the User Interface
`
`SAVE Doc
`CANCL
`‘ILLEGAL ACTION’
`lCUR50R- CONTROL}
`,-E":
`(DELEYEI
`
`_r*' 1.”;
`'.
`(KEV-WAIT}
`
`mum
`
`cunson
`com um
`
`cc KEY
`MOVE cunson
`
`uxsv KEV
`@ nsuovs cmn
`
`‘\LLEaAL ACTION’
`
`-II-—.
`
`rm KEY
`FIND wnnr
`
`INP\n=cAncL
`
`mvuv :5 NULL
`now: 10 OLD PA11Enu
`Nowuuu mvuv
`PAYYERN o—INPu'l’
`MOVE ro FAYTEHN
`
`DEL KEY
`
`.
`
`TARGET IS NULL
`
`I
`
`|'/(:ELECY-
`IKTARGET)
`
`T‘
`NON~NULL TARGET
`DELETE TARGET
`
`MOVE KEV
`
`(SEL_ECT—I
`TARGET?
`/’
`
`TARGET IS NULL
`
`NON-NULL
`TARGET
`'TO WHERE7'
`
`CANCL
`TARGET9— NULL
`ENTER
`MOVE TAFIDET
`Move-cunson
`
`INITIAUZE
`""55?
`
`TAFlGET4— NULL
`ENTER
`
`uovE—cuasoa
`EXTEND TARGET
`
`CURSOR-CONTROL’
`
`I
`
`MOVE TO CHARACTER
`
`

`
`Ch. 2 Theories, Principles, and Guidelines
`
`@!
`
`I
`
`/‘N,
`err]
`-
`‘vi
`n’
`II}
`_
`..
`4-.‘ v
`"\
`n‘
`
`ca
`.
`
`--
`—— l
`ll/fa—-I1--<lI'lVEI'I{Ol'Y>
`J
`'1
`_.
`‘{’."2.,_.-..-9- <lendinz>
`¢.#_ '3’
`_
`:_ E
`'l
`PI\‘4"-—..g_-<bcrruwer> _-v"’)j/
`0'
`,-
`,
`,
`‘,3’
`
`_
`
`_
`
`_
`/' '-\
`0 finmenfi .
`__
`fail
`
`6 E +
`
`Ii
`
`II
`
`Figure 2.2b: A second example of a transition diagram indicates user actions on
`the arrows and ‘computer responses or states in the boxes and circles.
`(Source:
`Transition
`diagram editor
`from Interactive Development)
`
`facilities
`database manipulation
`to
`applied
`been
`has
`and
`1980)
`(Shneiderman, 1981) as well as to direct manipulation (Shneiderman,
`1983).
`
`involve
`system usage
`interactive
`for modeling
`strategies
`Other
`These
`(Figure 2.2).
`(Kieras & Polson.
`1985)
`transition diagrams
`diagrams are helpful during design, for instruction, and as a predictor of
`learning time, performance time. and errors.
`
`Figure 2.2a: This generalized transition network for the Displaywritcr shows the
`sequence of permissible actions.
`If the users begin at the EDIT state and issue a
`FIND command,
`they follow the paths in the FIND subdiagram.
`(Kieras and
`Polson, “An approach to the formal analysis of user complexity,” International
`Journal of Man—Machine Studies 22 [1985], 365-394. Used by permission of
`Academic Press Inc. [London] Limited.)
`
`

`
`Designing the User lnteriace
`
`Other theories include the four—level approach of Foley and Van Dam
`(1982):
`
`is the conceptual model or the user’s
`level
`The highest
`mental model of the interactive system. Two conceptual
`models for text editing are line editors and screen editors.
`
`The semantic level describes the meanings conveyed by the
`user's command input
`and by the
`computer’s output
`display.
`
`The syntax level defines how the units (words) that convey
`semantics are assembled into a complete sentence that
`instructs the computer to perform a certain task.
`
`The lexical
`
`level deals with device dependencies and the
`
`precise mechanism by which a user specifies the syntax.
`
`Card, Moran, and Newell (1980, 1983) proposed the GOMS (goals,
`operators, methods, and selection rules) model and the keystroke-level
`model. They postulated that users formulate goals and subgoals that are
`achieved by methods or procedures for accomplishing each goal. The
`operators are “elementary perceptual, motor, or cognitive acts, whose
`execution is necessary to change any aspect of the user’s mental state or
`to affect the task environment’; (Card, Moran & Newell, 1983: 144).
`The selection rules are the control structure for choosing among the
`several methods available for accomplishing a goal.
`
`The keystroke—leve1 model is an attempt to predict perfomiance times
`for error—free expe11 performance of tasks by summing up the time for
`keystroking, pointing, homing, drawing,
`thinking, and waiting for the
`system to respond. These models concentrate on expert users and
`error—free performance, with less emphasis on learning, problem-solving,
`error handling, subjective satisfaction, and retention.
`
`to describe the
`Kieras and Polson (1985) used production rules
`conditions and actions in an interactive text editor. The number and
`complexity of production rules gave accurate predictions of learning and
`performance times for five text editing operations:
`insert, delete, copy,
`move, and transpose.
`
`

`
`Ch. 2 Theories, Principles, and Guidelines
`
`47
`
`Norman (1984) offers a stages and levels model of human-computer
`interaction. The four stages of an interaction are:
`
`1.
`
`internal mental characterization of a
`
`Forming an intention:
`goal.
`Selecting an action: review possible actions and select most
`appropriate.
`T
`
`Executing the action:
`computer.
`
`carry out
`
`the
`
`action using the
`
`Evaluating the outcome: check the results of executing the
`action.
`
`Norman’s levels correspond roughly to Foley and Van Dam’s separation
`of concerns, that is, the user forms a conceptual intention,'refo11nulat_es it
`into the semantics of several commands, and eventually produces the
`action of moving the mouse to select a point on the screen. Norman
`describes how errors often occur as intentions are reformulated to lower
`levels.
`V
`'
`
`detailed models will
`and more
`theories
`these
`to
`Refinements
`undoubtedly emerge. There is a need for many theories about
`the
`multiple aspects of interactive systems. The next section expands on the
`syntactic/semantic model of user" behavior.
`
`2.2.1 Syntactic knowledge
`
`When using a computer system, users must maintain a profusion of
`device—dependent details in their human memory.
`These low~level
`syntactic details include the knowledge of which key erases a character
`(delete, backspace, CTRL-H, rightmost mouse button, or ESCAPE), what
`command inserts _a new line after the third line of a text file (CTRL—I,
`INSERT key,
`I3’, I .3, or 3I), which icon to click on to scroll
`text
`forward, which abbreviations are permissible, and which of the numbered
`function keys produces the previous screen.
`The learning, use, and retention of this knowledge is hampered by two
`problems. First,
`these’ details vary across systems in an unpredictable
`
`

`
`48
`
`Designing the User Interface
`
`Second, acquiring syntactic knowledge is often a struggle
`manner.
`because the arbitrariness of these minor design features greatly reduces
`the
`effectiveness of paired-associate
`learning.
`Rote memorization
`requires repeated rehearsals to reach competence, and retention over time
`is poor unless the knowledge is frequently applied. Syntactic knowledge
`is usually conveyed by example and repeated usage. Formal notations,
`such as Backus-Naur Form, are useful
`for knowledgeable computer
`scientists but confusing to most users.
`A
`'
`
`is the
`in some cases,
`A further problem with syntactic knowledge,
`difficulty of providing a hierarchical structure or even a modular structure
`to cope with the complexity. For example. how is a user to remember
`these details of using an "electronic mail system: Press RETURN to
`terminate a paragraph. CTRL—D to terminate a letter. Q to quit
`the
`electronic mail subsystem, and logout to terminate the session. The
`knowledgeable computer user understands these four forms of termination
`as commands in the context of the full system. but
`the novice may be
`confused by four seemingly similar situations that have radically different
`syntactic forms.
`A final difficulty is that syntactic knowledge is system dependent. A
`user who switches from one machine to another may face different
`keyboard layouts,
`‘commands.
`function key usage. and sequences of
`actions.
`To be
`sure.
`there may be
`some overlap.
`For example,
`arithmetic
`expressions might be
`the
`same
`in
`two languages; but
`unfortunately. small differences can be the most annoying. One system
`uses K to keep a file and another uses K to kill
`the file. or S to save
`versus S to send.
`
`Expert frequent users can overcome these difficulties and they are less
`troubled by syntactic knowledge problems. Novices and intermittent
`users, however. are especially troubled by syntactic irregularities. Their
`burden can be lightened by using menus (see Chapter 3). a reduction in
`the
`arbitrariness of
`the keypresses.
`use of consistent patterns of
`commands. meaningful command names and labels on keys, and fewer
`details that must be memorized (see Chapter 4).
`
`In summary. syntactic knowledge is arbitrary, system dependent, and
`ill-structured.
`It must be acquired by rotememorizalion and repetition.
`Unless it is regularly used. it fades from memory.
`
`

`
`Ch. 2_ Theories, Principles, and Guidelines
`
`49
`
`2.2.2 Semantic knowledge—c0mpu_ter concepts
`
`Semantic knowledge in human long-term memory has two components:
`computer concepts and task concepts (Figure 2.1). Semantic knowledge
`has a hierarchical structure ranging from 1ow—level actions to middle-level
`strategies to high—level goals (Shneiderman _& Mayer, 1979; Soloway et
`al., 1982; Card et al.,
`I983). This presentation enhances the earlier
`syntactic/semantic model and other models by decoupling computer
`concepts from task concepts. This enhancement accommodates the two
`most common forms of expertness:
`task experts who may be novice
`computer users and computer user experts who may be new to a task.
`Different
`training materials are suggested for task or computer experts.
`Novices in both domains need yet a third form of training.
`
`Semantic knowledge is conveyed by showing examples of use, offering
`a general theory or pattern, relating the concepts to previous knowledge
`by analogy, describing a concrete or abstract model, and by indicating
`examples of incorrect use. There is an attraction to-showing incorrect use
`to indicate clearly the bounds of a concept, but there is also a danger
`since the learner. may confuse correct and incorrect use. Pictures are
`often helpful
`in showing the relationships among semantic knowledge
`concepts.
`
`Computer concepts include objects and actions at high and low levels.
`For example, a central
`set of computer object concepts deals with
`storage. Users come to understand the high—level concept that computers
`store information. The concept of stored information can be refined into
`the Object concepts of the directory and the files of information.
`In turn,
`the directory object is refined into a set of directory entries that each have
`a name, length, date of creation, owner, access control, and so on. Each
`file is an object that has a lower level structure consisting of lines, fields,
`characters, pointers, binary numbers, and so on.
`
`The computer actions are also decomposable into lower level actions.
`The high-level actions or goals, such as creating a text data file, may
`require load,
`insertion, and save actions. The _rni_d—level action of saving
`a file is refined into the actions of storing a file and backup file on one of
`many disks, of applying accessicontrol rights, of overwriting previous
`versions, of assigning a name to the file, and so on. Then,
`there are
`
`

`
`Designing the User Interface
`
`sizes, error
`many low—level details about permissible file types or
`conditions such as shortage of storage space, or responses to hardware or
`software errors. Finally, there is the low—level action of issuing a specific
`command, carried out by the syntactic detail of pressing the RETURN
`key.
`
`These computer concepts were designed by highly trained experts in
`the hope that they were logical, or at least “made sense” to the designers.
`Unfortunately,
`the logic may be a very complex product of underlying
`hardware, software, or performance constraints, or it might be just poorly
`chosen. Users are often confronted with computer concepts that
`they
`have great difficulty absorbing; but hopefully. designers are improving
`and computer literacy training is raising knowledge levels. For example,
`the action ‘of terminating a command by pressing RETURN is more and
`more widely known, even by nonprogramniers.
`Users can learn computer concepts by seeing a demonstration of
`commands, hearing an explanation of features, or by trial and error. A
`common practice is
`to create a model of concepts, either abstract,
`concrete, or analogical,
`to convey the computer action. For example,
`with the file—saving concept, an instructor might draw a picture of a disk
`drive and a directory to show where the file goes and how the directory
`references thefile. Alternatively,
`the instructor might make a library
`analogy and describe how the card catalog acts as a directory for books
`saved in the library.
`V
`
`Since semantic knowledge about computer concepts has a logical
`structure and since it can be
`anchored to familiar concepts,
`this
`knowledge is expected to be relatively stable in memory.
`If you
`remember the high-level concept about saving _a file, you will be able to
`conclude that thefile must have a name, a size, and a storage location.
`The linkage to other objects and the potential for a visual presentation
`support the memorability of this knowledge.
`
`These computer concepts were once novel and known to only a small
`number of scientists, engineers, and data processing professionals. Now,
`these concepts are taught at
`the elementary school
`level,’ argued over
`during coffee breaks
`in the office,‘ and exchanged in the aisles of
`corporate jets. When educators talk of computer literacy, part of their
`plans cover these computer concepts.
`
`

`
`Ch. 2 Theories, Principles, and Guidelines
`
`In summary, the user tnust acquire semantic knowledge about computer
`concepts.
`These concepts are hierarchically organized, acquired by
`meaningful
`learning or analogy,
`independent of the syntactic details,
`hopefully transferable across different computer systems, and relatively
`stable in memory. Computer concepts can be usefully sorted out
`into
`objects and actions.
`
`2.2.3 Semantic knowledge—task concepts
`
`The primary way for people to deal with large and complex problems
`is to decompose them into several smaller problems in a hierarchical
`manner until
`each subproblem is manageable.
`Thus,
`a book is
`decomposed into the task objects of chapters,
`the chapters into sections,
`the sections into paragraphs, and the paragraphs into sentences. Each
`sentence is approximately one unit of thought for both the author and the
`reader. Most designed objects have similar decompositions: computer
`programs, buildings,
`television sets, cities, paintings, and plays,
`for
`example. Some objects are more neatly and easily decomposed than
`others; some objects are easier to understand than others.
`Similarly,
`task actions can be decomposed into smaller actions. A
`construction plan can be reduced to a series of steps; a baseball game has
`innings, outs, and pitches; and creating a business letter involves creating
`an address, date, addressee, body, signature, and so on.
`
`the user has to integrate
`In writing a business letter with a computer,
`smoothly the three forms of knowledge. The user must have the
`high—level concept of writing (task action) a letter (task object), recognize
`that the letter will be stored as a file (computer object), and know the
`details
`of
`the
`save command
`(computer
`action
`and
`syntactic
`knowledge). The user must be fluent with the middle—leve1 concept of
`composing a sentence and must recognize the mechanism for beginning,
`writing, and ending a sentence. Finally,
`the user must know the proper
`low—1evel details of spelling each word (task), comprehend the motion of
`the cursor on the screen (computer concept), and know which keys to
`press for each letter (syntactic knowledge).
`
`Integrating the three forms of knowledge, the objects and actions, and
`the multiple levels of semantic knowledge is a substantial challenge that
`
`

`
`Designing the User Interface
`
`that
`Learning materials
`concentration.
`takes great motivation and
`this knowledge are difficult
`to design,
`facilitate the acquisition of
`especially because of
`the diversity of background knowledge and
`motivation levels of typical
`learners. The syntactic/semantic model of
`user knowledge
`can provide
`a guide
`to educational designers by
`highlighting the different kinds of knowledge that users need to acquire
`(see Chapter 9).
`
`Designers of interactive systems can apply the syntactic/semantic model
`to systematize their efforts. Where possible,
`the semantics of the task
`objects should be made explicit and the user’s task actions should be laid
`out clearly. Then the computer objects and actions can be identified,
`leaving the syntactic details for the end.
`In this way, designs appear to
`be more comprehensible to users and more independent of specific
`hardware.
`
`2.3 PRINCIPLES: RECOGNIZE THE DIVERSITY
`
`The remarkable diversity of human abilities, backgrounds, cognitive
`styles,
`and personalities challenges
`the
`interactive system designer.
`When multiplied by the wide range of situations,
`tasks, and frequencies
`of use,
`the set of possibilities becomes enormous. The designer can
`respond by choosing from a spectrum of interaction styles.
`
`A preschooler playing a graphic computer game is a long way from a
`reference librarian doing bibliographic searches for anxious and hurried
`patrons. Similarly,\‘a professional programmer using a new operating
`system is a long way from a highly trained and experienced air traffic
`controller.
`Finally,
`a
`student
`learning
`from a
`computer—assisted
`instruction lesson is a long way from a hotel reservations clerk serving
`customers for many hours a day.
`
`in background
`the differences
`These sketches of users highlight
`knowledge, training in the use of the system. frequency of use, goals of
`the user, and the impact of a user error. No single design could satisfy
`all
`these users
`and situations.
`so before beginning a design.
`the
`characterization of the users and the situation must be precise and
`complete.
`
`

`
`Ch. 2 Theories, Principles, and Guidelines
`
`53
`
`2.3.1 Usage profiles
`
`“Know the user” was the first principle in Hansen’s (1971) list of user
`engineering principles.
`It's a simple idea, but a difficult goal and,
`unfortunately, an often undervalued goal. No one would argue against
`this principle, but many designers assume that they understand the users
`and their tasks. Successful designers are aware that other people learn,
`think, and solve problems in very different ways (see Section 1.5). Some
`users really do have an easier time with tables than graphs. with words
`instead of numbers, with slower rather than faster display rates, or with a
`rigid structure rather than an open—ended form.
`'
`
`It is difficult for most designers to know whether boolean expressions
`are too difficult a concept for library patrons at a junior college, fourth
`graders
`learning programming, or professional electric power utility
`controllers.
`
`All design should begin with an understanding of the intended users,
`including profiles of their age, sex, physical abilities, education, cultural
`or ethnic background, training, =motivation, goals, and personality. There
`are often several communities of users for a system, so the design effort
`is multiplied.
`In addition to these profiles, users might be tested for such
`skills as comprehension of boolean expressions, knowledge of set theory,
`fluency in a foreign language, or skills in human relationships. Other
`tests might cover such task—specific abilities as knowledge of airport city
`codes, stockbrokerage terminology,
`insurance claims concepts, or map
`1COI1S.
`
`The process of knowing the user is never ending, because there is so
`much to know and because the users keep changing. Every step in
`understanding the users and in recognizing them as individuals whose
`outlook is different from the designer’s own is likely to be a step closer
`to a successful design.
`
`knowledgeable
`into novice,
`separation
`a generic
`example,
`For
`intermittent, and frequent users might lead to these differing design goals:
`
`Novice users: This community is assumed to have no syntactic
`knowledge about using the system and probably little semantic knowledge
`of computer issues. They may even have shallow knowledge of the task
`and, worse still, they may arrive with anxiety about using computers that
`
`

`
`54
`
`Designing the User Interface
`
`inhibits learning. Overcoming these limitations is a serious challenge to
`the designer. Restricting vocabulary to a small number of familiar,
`consistently used terms is essential
`to begin developing the user’s
`knowledge of the system. The number of possibilities should be kept
`small and the novice user should be able to carry out a few simple tasks
`to build confidence, reduce anxiety, and gain positive reinforcement from
`success.
`Informative feedback about the accomplishment of each task is
`helpful, and constructive, specific error messages should be provided
`when errors do occur. Carefully designed paper manuals and step-by—step
`
`online tutorials may be effective.
`
`'
`
`be
`people will
`users: Many
`intermittent
`Knowledgeable
`knowledgeable but intermittent users of a variety of systems. They will
`be able to maintain the semantic knowledge of the task and the computer
`concepts, but
`they will have difficulty maintaining the
`syntactic
`knowledge. The burden of memory will be lightened by simple and
`consistent structure in the command language, menus,
`terminology, and
`so on, and by the use of recognition rather
`than recall. Consistent
`sequences of actions, meaningful messages, and frequent prompts will all
`help to assure knowledgeable intermittent users that they are performing
`their tasks properly. Protection from danger
`is necessary to support
`relaxed exploration of features or attempts to invoke a partially forgotten
`command. These users will benefit from online help screens to fill
`in
`missing
`pieces
`of
`syntactic
`or
`computer
`semantic
`knowledge.
`Well-organized reference manuals will also be useful.
`
`Frequent users: The knowledgeable “power” users are thoroughly
`familiar with the syntactic and semantic aspects of the system and seek to
`get their work done rapidly. They demand rapid response times, brief
`and less distracting feedback, and the capacity to carry out actions with
`just a few keystrokes or selections. When a sequence of three or four
`commands is performed regularly,
`the frequent user is eager to create a
`macro or other abbreviated form to reduce the number {of steps. Strings
`
`through menus,
`shortcuts
`of commands,
`accelerators are requirements.
`
`abbreviations,
`
`and other
`
`These characteristics of these three classes of usage must be refined for
`each environment. Designing for one class is easy; designing for several
`is much more difficult.
`
`

`
`Ch. 2 Theories, Principles. and Guidelines
`
`55
`
`When multiple usage classes must be accommodated in one system, the
`basic strategy is to permi_t a level-structured (some times called layered or
`spiral approach) to learning. Novices can be taught a minimalsubset of
`objects and actions with which to get started, After gaining confidence
`from hands—on experience, the users can progress to ever greater levels of
`semantic concepts and the accompanying syntax.’ The learning plan
`shouldlbe governed by the progress through the task semantics. For users
`with ‘strong knowledge of the task and computer semantics,
`rapid
`presentation of syntactic details is possible.
`For example, novice users of a bibliographic search system might be
`taught author or title searches first, followed by subject searches that
`require boolean combinations of queries.
`‘The progress is governed by
`the task domain, notby commands.
`,
`The level—structured approach must be carried out not only in the
`design of the software, but also in the user manuals, help screens, error
`messages, and tutorials.
`M
`V
`to
`is
`Another approach ‘ to accommodating different usage classes
`permit user control of the density of informative feedback that the system
`provides. Novices want more informative feedback to confirm their
`actions, whereas frequent users ‘want less distracting feedback. Similarly,
`it seems that frequent users prefer more densely packed displaysvthan do
`novices. Finally,
`the pace of interaction may be varied from slow for
`novices to fast for frequent users,
`‘
`-
`'
`
`2.3.2 Task profiles
`
`the tasks must be identified.
`After carefully drawing the user profile,
`Task analysis ‘has a long,
`‘but mixed history (Bailey, 1982). Every
`designer would agree that
`the set of-tasks must'be decided on before
`design can proceed, but too often the task analysis is done informally or
`implicitly.
`If implementers find that another command can be added, the
`designer is often tempteduto include the command in the hope that some
`users will find it helpful. Design or implementation convenience should
`not dictate system functionality or command features.
`
`task actions can be decomposed into multiple middle—level
`High—level
`task actions that can be further refined into atomic actions that the user
`
`

`
`56
`
`Designing the User Interface
`
`executes with a single command. menu selection, and so on. Choosing
`the most appropriate set of atomic actions is a difficult
`task.
`lf the
`atomic actions are too small, the users will become frustrated by the large
`number of actions necessary to accomplish a higher level
`task.
`If the
`atomic actions are too large and elaborate, the users will need many such
`actions with special options, or they will not be able to get exactly what
`they want from the system.
`in shaping a set of
`The relative task frequencies will be important
`commands,
`a menu tree. etc.
`Frequently performed tasks should be
`simple and quick to carry out. even at the expense of lengthening some
`infrequent tasks.
`V
`"L
`Relative frequency of use is one of the bases for making architectural
`design decisions. For example, in a text editor:
`
`Frequent actions might be performed by special keys, such
`as the four cursor arrows,
`the INSERT, and the DELETE
`key.
`lntermediate frequency actionslmight be performed by a
`single letter plus the CTRL key. or by a selection from a
`pull—down 'menu.
`Examples
`include underscore. Center.
`indent, subscript, or superscript.
`
`Less frequent actions might require going to a command
`mode and typing the command name; for example, MOVE
`BLOCK or SPELLING CHECK.
`
`Still less frequent actions or complex actions might require
`going through a
`sequence of menu selections or
`form
`fill—ins; for example,
`to change the printing format or to
`revise network protocol parameters.
`
`A matrix of users and tasks can help sort out these issues (Figure 2.3).
`In each box, the designer can put a check mark to indicate that this user
`carries out this task. A more precise analysis would lead to inclusion of
`frequencies instead of simple check marks.
`'
`
`

`
`Ch. 2
`
`lheories, Principles, and Guidelines
`
`57
`
`FREQUENCY OF TASK BY JOB TITLE
`
`Query by Update
`Patient
`Data
`
`Task
`
`Query
`across
`Patients
`
`Evaluate
`Add
`Relations System
`
`Job title
`
`Nurses
`
`Physicians
`Supervisors
`Appointments personnel
`Medical record
`
`maintainers
`Clinical researchers
`Database programmers
`
`_
`
`.
`
`.
`
`.04
`.08
`.02
`
`.01
`
`.02
`
`.05
`
`Figure 2.3: Hypothetical frequency of use data for a medical clinic information
`system. Queries by patient
`from appointments personnel are the highest
`frequency task.
`
`2.3.3 Interaction styles
`
`When the task analysis is complete and the semantics of the task
`objects and actions can be identified, the designer can choose from these
`primary interaction styles (Table 2.1):
`
`-
`
`°
`
`*
`
`°
`
`-
`
`menu selection
`
`form fill—in
`
`command language
`
`natural language
`
`direct manipulation.
`
`through 5 explore these styles
`3
`Chapters
`comparative overview sets the stage.
`
`in detail, but
`
`first a
`
`

`
`Designing the User Interface
`
`INTERACTION STYLE
`Aiai/ANT'A'c;Es
`
`Menu selection
`shortens learnin‘g‘
`reduces lreystrokes ‘
`Structures decision-making
`permits use of dialdg management
`tools
`
`easy to support error handling
`
`Form nli,-in_
`sirnplifies data entry
`requires modest training
`assistance is convenient
`
`permits use of form
`management tools
`
`Command language
`flexibilty
`appeals to “power” users
`supports user initiative
`convenient for creating user
`defined macros
`
`Natural language
`relieves burden of learning syntax
`
`DISADVANTACES
`
`danger of many menus
`may slow frequent users
`consumes screen space
`requires rapid display rate
`
`con