5
`
`UTE!’
`
`
`
`3av.I.!J\«.1!
`
`..rbutE
`
`
`
`;H.:J.T...lCrbr.m.,I,34...,3.me...«.f:mV.u»
`
`k,mm..9;a\$,,u;_n.u,¢€.m3nmaja
`
`
`
`
`
`..:.>.Cn)....KUfl_V\.C.»:L/,u..J.\II:_“Br...1(xx!:9.WluvawhflkwngrbEfilrfifiktnm«sL{vmLE
`3_..
`_____E.___________
`
`$.14.
`
`
`
`AwKS
`
`7,MX.EW;
`
`e9aD.
`
`SKYHAWKE Ex. 1017, page 1
`
`

`
`
`ENGINEERING THE
`
`HUMAN—COMPUTER
`
`INTERFACE
`
`Edited by
`Andy Dovvnton
`Department of E/ecfron/c Systems Engineering
`U/7/‘I/ers/fy of Essex
`
`MCGRAW—I-1ILL BOOK COMPANY
`
`London - New York ~ St Louis - San Francisco < Auckland
`
`Bogota - Caracas - Hamburg ~ Lisbon ’ Madrid - Mexico ‘ Milan
`Montreal - New Delhi - Panama - Paris - San Juan - Sao Paulo
`
`Singapore - Sydney - Tokyo ~ ToronEi9HE UMVERSITY UBRARY
`WASHINGTON & LEE UNIVERSITY
`LEXINGTON VA. 24450
`
`SKYHAWKE EX. 1017, page 2
`
`SKYHAWKE Ex. 1017, page 2
`
`

`
` I
`
`Published by
`MCGRAW-HILL Book Company (UK) Limited
`SHOPPENHANGERS ROAD - MAIDENHEAD - BERKSHIRE - ENGLAND
`TEL: 0628 23432
`FAX: 0628 770224
`
`
`
`British Library Cataloguing in Publication Data
`Engineering the human—computer interface. — (Essex series in
`telecommunication and information systems).
`1. Man. Interactions with computer systems
`I. Downton, Andy
`II. Series
`004.019
`
`ISBN 0-07-707321-5
`
`Library of Congress Cataloging-in-Publication Data
`Engineering the human—computer interface/editor, Andy Downton.
`p.
`cm.—(Essex series in telecommunication and information systems)
`Includes bibliographical references and index.
`ISBN 0-07-70732]-5
`
`l. Human—computer interaction.
`I. Downton, A. C.
`II. Series.
`QA76.9.H85E53
`005.1—<lc20
`
`1991
`90-24975 CIP
`
`2. User interfaces (Computer systems)
`
`Copyright © 1991 McGraw-Hill Book Company (UK) Limited. 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 permission of McGraw-Hill Book Company (UK) Limited.
`
`1234 CUP 94321 '
`
`Typeset by Computape (Pickering) Ltd, Pickering, North Yorkshire
`and printed and bound in Great Britain at the University Press, Cambridge
`
`JUL 281992
`
`SKYHAWKE EX. 1017, page 3
`
`SKYHAWKE Ex. 1017, page 3
`
`

`
` .
`
`4 Dialogue styles:
`basic techniques and
`guidelines
`
`ANDY DOWNTON
`
`
`
`4.1 Introduction
`
`4.1.1 History
`
`Computer dialogue styles have been transformed over the last
`twenty-five years by the introduction of first minicomputers and then
`microprocessors. The introduction of the first minicomputer (the DEC
`PDP8), though primarily viewed as a breakthrough in dedicated
`real-time computing, also represented a landmark in human—computer
`interaction. Whereas mainframes had typically been run in a batch
`mode, minicomputers were used interactively, introducing for the first
`time the need to provide a programmed interface between the user and
`the computer.
`Since the early 1970s the microprocessor has become a ubiquitous
`part of most electronic systems. The widespread availability of
`‘ microcomputers based upon microprocessor technology has accelerated
`the trends first begun by minicomputers, by putting significant raw
`computing power in the hands of inexperienced users for the first time.
`System performance in this case is clearly dependent upon maximizing
`the usability of the computer rather than using its processing power
`efficiently, and thus much of the processing power of personal
`computers is now expended not in processing data but in facilitating
`communication with the user. Even where the basic level of
`communication (via the operating system) is rather traditional
`(typically, a terse command line dialogue where the user is expected to
`know the names of commands acceptable to the machine), applications
`such as word processors, database managers, spreadsheets, etc., overlay
`this with simpler menu-selection command mechanisms.
`Increasingly, machines like the Apple Macintosh model their user
`interface upon familiar metaphors such as the office desk, and use a
`pointer device (the mouse) to select and manipulate objects. This
`example -illustrates the close interrelationship between the capabilities of
`
`SKYHAWKE Ex. 1017, page 4
`
`SKYHAWKE Ex. 1017, page 4
`
`

`
`66
`
`ENGINEERING THE HUMAN—COMPUTER INTERFACE
`
`the technology and the style of the user interface, because the WIMP
`(variously an acronym for windows, icons, mouse, pull-down menus, or
`windows, icons, menus, pointers) style of user interaction was fully
`explored and evaluated in the early 1970s at the Xerox Palo Alto
`Research Center using dedicated minicomputer workstations. In spite of
`their apparent visual appeal and friendliness, however, the software
`complexity of such graphics-oriented interfaces is high, and thus it was
`not until 16- and 32-bit microprocessors were introduced that sufficient
`processing power was available to enable such systems to become
`practicable at low cost.
`
`4.1.2 Application areas
`
`Although the archetypal concept of a humanwomputer dialogue
`conjures up images of the user sitting in front of a terminal interacting
`with a keyboard and video display, the expression admits a much wider
`range of interpretations than this. Many familiar home, office and
`entertainment systems now contain embedded microcontrollers with
`which dialogues of a sort are conducted.
`A minimal example of such a system is the familiar digital watch
`(Figure 4.1). Typically, this incorporates, in addition to clock, day and
`date functions, a stopwatch with lap timer, a presettable countdown
`timer, and one or more alarms. It may seem natural and obvious with
`hindsight that all these functions can be readily controlled and initialized
`with only four pushbuttons, but in the absence of a known solution the
`problem would be much more taxing. Furthermore, given only the
`specification of the required functionality, and the availability of a single
`four-bit input, it is clear that many possible solutions could be generated,
`varying widely in simplicity, consistency, flexibility and ease of use.
`Other examples of domestic equipment containing a microcontroller
`are now commonplace: video cassette recorders, teletext TV sets,
`microwave and conventional ovens, and automatic washing machines
`
`Alarm Stopl
`Lap/Reset
`
`v Start/Stop
`
`‘
`
`J 12/24 Hourl
`
`Figure 4.1 The digital watch—a minimal example of
`human—computer dialogue
`
`SKYHAWKE Ex. 1017, page 5
`
`SKYHAWKE Ex. 1017, page 5
`
`

`
`
`
`DIALOGUE STYLES: BASIC TECHNIQUES AND GUIDELINES
`
`
`
`all enable the mode of operation to be programmed using a rudimentary
`pushbutton dialogue, typically augmented by feedback from a display
`panel. Such dialogues can generally be categorized as simple forms of
`menu selection, and are readily formalized using state transition
`diagram techniques (see Sections 6.5 and 7.5.1).
`In the office, business and industrial environment, too, examples of
`embedded systems abound: photocopiers, intelligent VDU terminals,
`telephones, PABXS, machine tools and industrial process controllers are
`all controlled using dialogues of greater or lesser sophistication. Word
`processors, video games and personal computers running databases,
`spreadsheets, graphics and communication packages represent the
`conventional concept of computers and provide a more versatile and
`flexible potential for human—computer interaction. The availability of
`video displays, keyboards and graphic input devices opens up
`opportunities for much richer, more powerful and more extensive
`dialogues using menus, form-filling, command languages and /or direct
`manipulation to specify commands.
`
`4.1.3 Dialogue design objectives
`
`In all these application areas, the concept of developing the engineering
`design using top-down techniques starting from systems analysis and
`specification is well understood: what is often overlooked is that exactly
`the same process of step-wise refinement should and can be applied to
`the process of interface and dialogue design. Instead, the user—interface
`design is often based upon unsupported implicit assumptions made by
`the design engineer about the nature of the task, the user’s model of the
`task, and the characteristics of the users.
`As part of the design process, the designer needs to be armed with a
`comprehensive understanding of the types of interfaces and dialogue
`styles available, their appropriateness for different categories of users,
`and their system implications in terms of display, input device and
`processing power requirements. The objective of this chapter is to
`provide an overview and taxonomy of different dialogue styles;
`Chapters 6 and 7 then discuss some of the techniques and tools
`available to support different human—computer dialogue models and
`illustrate the models and dialogue styles using some example research
`systems. Chapter 5, on knowledge analysis of tasks, is concerned with
`ways of eliciting knowledge of user models and methods which can
`provide a specification for the required dialogue.
`
`4.2 Dialogue properties
`Before reviewing specific styles of dialogue in detail, it is worth while
`considering some desirable generic characteristics of these dialogues.
`Alison Kidd (1982) cites five important properties:
`
`SKYHAWKE EX. 1017, page 6
`
`SKYHAWKE Ex. 1017, page 6
`
`

`
`68
`
`ENGINEERING THE HUMAN—COMPUTER INTERFACE
`
`O initiative;
`0 flexibility;
`O complexity;
`0 power;
`0 information load;
`
`to which can also be added:
`
`0 consistency;
`0 feedback;
`0 observabilityz
`O controllability;
`O efficiency;
`0 balance.
`
`These properties are considered in more detail below.
`
`4.2.1 Initiative
`
`Initiative is the most fundamental property of any dialogue, since it
`defines the overall style of communication and thus. to a large extent,
`the type of user for whom the system is intended. The two most
`common styles are computer-initiated and user-initiated. In
`computer-initiated dialogues, the user responds to explicit prompts from
`the computer to input commands or command parameters: typically,
`(s)he will be presented with a series of options from which a selection
`must be made (menu selection). or a number of boxes into which
`parameters must be inserted (form-filling), or questions to which
`answers must be specified in a more or less restricted way (for example
`yes/no vs. natural language). The key characteristic is that the dialogue
`consists of a closed set of options defined by the computer.
`By contrast, user-initiated dialogues are open-ended in nature: the
`user is expected to know a valid set of command words and their
`allowable syntax, and possibly a semantic structure for the system if
`operation in several different modes is possible. A typical example of a
`user-initiated dialogue would be the command language of a computer
`operating system; superimposed upon this could be the semantic
`structure of a variety of other command language-driven programs such
`as editors and debuggers, each with their own distinct style of dialogue.
`Dialogues need not be purely computer-initiated or user-initiated.
`Variable-initiative dialogues are becoming more common, particularly in
`systems intended for wide ranges of users. In many current systems, the
`level of user initiative required is chosen by the users themselves (for
`example by selecting between user-initiated and computer-initiated
`modes), but adaptive dialogue styles are also becoming more common.
`At their simplest, adaptive dialogue systems adjust the level of
`assistance by monitoring, for example, the delay in the user inputting a
`
`SKYHAWKE EX. 1017, page 7
`
`SKYHAWKE Ex. 1017, page 7
`
`

`
`‘
`
`h
`
`II
`
`|
`
`|
`
`i
`I
`|
`
`69
`
`DIALOGUE STYLES: BASIC TECHNIQUES AND GUIDELINES
`
`command or parameter: when a prespecified limit is exceeded,
`additional assistance on options available is displayed. Alternatively,
`when parameters are omitted from a command line, they can be
`prompted for by the system. In either case, a user-initiated dialogue is
`partially transformed to a computer-initiated style. Conversely, a
`computer-initiated menu selection system can be adapted to a
`user-initiated mode by allowing selections from subsequent menus to be
`given without waiting for the intervening menu(s) to be displayed (see
`Section 4.12 for an example of this). More complex techniques, for
`example the use of know1edge—based systems to predict users’
`capabilities by monitoring the content of their interactions (adaptive
`intelligent dialogues—see Chapter 7) remain a research problem at
`present.
`Finally, we can distinguish mixed-initiative dialogues as being
`common in natural-language communication with computers: here, the
`free format of both input and output to the system allows the possibility
`of either the computer or the user leading the dialogue at different
`times.
`
`4.2.2 Flexibility
`
`A flexible system is one in which a particular objective can be achieved
`in a variety of different ways. This is not simply a matter of providing
`a very large command repertoire in the hope of covering every
`possibility, but should follow from an analysis of users’ models of the
`activity. The objective is then to map the system onto representative
`users’ models, rather than to force the users to work within a
`framework defined by the designer.
`One of the less frequently recognized reasons for the success of the
`Apple Macintosh personal computer is that a great deal of attention has
`been paid in the design of its interface to this concept. Most functions
`can be accomplished in several different ways, corresponding to
`different models which the user may have of his or her activity (e.g., see
`Figure 4.2). Generally, users are unaware of this characteristic, since
`there is little incentive to investigate alternative methods of
`accomplishing a function once success has been achieved, but they may
`notice a higher success rate in trying out new functions than is common
`with other machines (which itself will tend to generate a positive
`response to the system).
`Flexibility can also be conferred by providing opportunities for the
`user to customize and extend the interface to meet their own personal
`requirements. This capability is most commonly observed in the
`provision of programmable function keys on microcomputers, or
`programmable control code alternatives (power keys) to pull-down or
`pop-up menu selection options on WIMP interfaces.
`The price paid for flexibility is in the complexity and efficiency of the
`
`SKYHAWKE EX. 1017, page 8
`
`SKYHAWKE Ex. 1017, page 8
`
`

`
`
`
`70
`
`ENGINEERING THE HUMAN—COMPUTER INTERFACE
`
`L “SC.” .
`positioning
`
`Wlord.
`5° ‘“’‘‘°"
`
`Word
`deletion
`
`Mouse
`
`
`
`Cursor keys
`
`I
`
`_
`
`- _ l
`(none)
`
`l L _l_
`_
`
`Jgouble click
`Click and
`shift-click
`_
`t.. T T
`.3"-
`
`Mouse/menu
`select CUT
`
`i —|
`
`?r_'l'_.
`Backspace
`
`Figure 4.2 Word deletion strategies under Apple”‘’' Macintosh
`Macwrite
`
`interface software: clearly there is an overhead in providing additional
`functionality over and above the minimum required to perform the task.
`This overhead can however by minimized by careful organization of the
`command structure to eliminate duplication (see Section 4.2.6 below).
`
`4.2.3 Complexity
`
`In general, there is no benefit in making an interface more complex than
`necessary. Often, an apparently complex interface is in fact a symptom
`of a failure to analyse the structure of the interaction and organize the
`commands accordingly. Logical grouping is important in reinforcing the
`user’s model of the system, and is commonly achieved by the use of
`hierarchy or orthogonality or both.
`
`Hierarchy
`
`This is the structuring of commands according to related characteristics
`and their relative importance. Rather than having a flat command
`structure requiring memorization of a large number of individual
`unrelated commands, the commands are grouped into a hierarchical
`tree, where related commands are associated in different branches of the
`
`SKYHAWKE Ex. 1017, page 9
`
`SKYHAWKE Ex. 1017, page 9
`
`

`
`
`DIALOGUE STYLES: BASIC TECHNIQUES AND GUIDELINES
`
`71
`
`lil
`i: ._
`
`Slit
`
`I:
`
`_
`
`$_
`
`1
`
`:
`
`fi
`
`Figure 4.3 Tree structure of commands
`
`tree (Figure 4.3). This maximizes the chance of memorizing the
`commands by recoding groups of commands as individual ‘chunks’,
`while at the same time simplifying decision making by offering a
`restricted set of options according to the current position in the tree.
`
`Orthogonality
`
`This is the structuring of commands according to independent
`characteristics (Figure 4.4). For example, specifying three independent
`command characteristics A, B and C, each of which is chosen from a set
`of 10 options, provides the capability to represent up to 1000 distinct
`commands, while requiring only 30 independent items (Al
`A10, Bl
`B10, Cl
`C10) to be memorized. This technique is most commonly
`exploited in specifying command parameters.
`
`0
`
`A
`
`Figure 4.4 Orthogonallty in command structures
`
`SKYHAWKE EX. 1017, page 10
`
`SKYHAWKE Ex. 1017, page 10
`
`

`
`72
`
`ENGINEERING THE HUMAN—COMPUTER INTERFACE
`
`4.2.4 Power
`
`Power is defined as the amount of work accomplished by the system per
`user command. Users (particularly expert and experienced users)
`generally react positively to the availability of powerful commands, and
`conversely can be irritated by the pedantry of a system that requires
`excessive user input to achieve a specific function. Note that a
`requirement for powerful commands may conflict with the need for
`flexibility, and may affect the complexity of the system.
`
`4.2.5 Information load
`
`The information load which the dialogue imposes on the user in terms
`of both memory_and decision making should be appropriate to the level
`of user. If too high a load is incurred, this leads to anxiety on the part
`of the user, which has a negative effect both on cognitive processing
`capability and attitude towards the system. If there is too low a load,
`this leads to resentment since the user sees the system as inhibiting his
`or her performance. Matching the information load to the user presents
`particular difficulties, since different loads are optimal for different
`categories of users, but any user who uses a system regularly will
`become more proficient and hence change categories over a period of
`time. Variable initiative dialogues provide one possible way of coping
`with this problem.
`
`4.2.6 Consistency
`
`Consistency is an important attribute in helping the user to develop his
`mental model of any computer system. A consistent system will
`encourage this by helping the user to extrapolate successfully from his
`or her current knowledge to explore new commands and command
`options. Once the user has used a particular command in one context, it
`is reasonable for him or her to expect that it will also work in any other
`context which he or she perceives as similar.
`Consistency should apply to all aspects of user interface design.
`Commands should have a standardized syntax and parameter ordering;
`displays should have a consistent layout; the data entry format should
`be compatible and consistent with the data display format.
`
`4.2.7 Feedback
`
`Immediate feedback is needed for any user input. The feedback should
`unambiguously indicate the type of activity taking place, for example
`text input, mode selection, command input, pointing. It is amazing how
`many widely used systems fail to observe this fundamental requirement!
`
`SKYHAWKE Ex. 1017, page 11
`
`SKYHAWKE Ex. 1017, page 11
`
`

`
`DIALOGUE STYLES: BASIC TECHNIQUES AND GUIDELINES
`
`73
`
`4.2.8 Observability
`
`An observable system is one in which the system function is apparent
`and clear at a surface level, even if the underlying processing is complex.
`This can sometimes be difficult to achieve, particularly where a simple
`model of a complex underlying activity is presented to the user.
`Difficulties arise where the user exceeds the bounds of the model (for
`example due to errors) and the system is no longer able to present
`responses which the user can understand in terms of the model.
`
`4.2.9 Controllability
`
`Controllability is the converse of observability, and implies that the user
`is always in control of the system. For this to be true, the interface must
`provide means by which the user can determine:
`
`0 where he has been;
`0 where he is now;
`0 where he can go from here.
`
`4.2.10 Efficiency
`
`Efficiency in a closely coupled human—computer system is defined in
`terms of the throughput achieved by the person and the computer
`working together. Thus, although the efficiency of the engineering and
`software aspects of the system may be important if they affect the
`response time or display rate of the system, often the designer can
`afford to buy his way out of trouble (by specifying a more powerful
`computer if necessary), knowing that developments in technology will
`minimize the cost of this decision in due course. In contrast, the cost of
`skilled staff is increasing all the time, emphasizing the importance of
`using their time as effectively as possible, even at the expense of
`devoting a large proportion of the total available processing power to
`the user interface. The development and exploitation of workstations
`and computer-aided engineering vividly illustrate this point.
`
`4.2.11 Balance
`
`A basic design strategy for any humanmomputer system should be to
`subdivide the tasks in an optimum way between the person and the
`computer. Table 4.1 illustrates some of the relative capabilities of each.
`Essentially these differences reflect the complementary strengths and
`weaknesses of humans and computers: humans cope best with changing
`circumstances, uncertainty and incomplete knowledge, while computers
`are better suited to dealing with repetitive and routine activity, reliable
`
`SKYHAWKE EX. 1017, page 12
`
`SKYHAWKE Ex. 1017, page 12
`
`

`
` — je-
`
`74
`
`ENGINEERING THE HUMAN—COMPUTER INTERFACE
`
`Table 4.1 Relative aptitudes of humans and computers (adapted from
`Shneiderman, 1987)
`
`
`
` Human aptitudes Computer aptitudes
`
`Accurate calculation
`Estimation
`Logical deduction
`Intuition
`Repetitive activity
`Creativity
`Consistency
`Adaptation
`Multitasking
`Subconscious concurrency
`Routine processing
`Abnormal/exceptional processing
`Data storage and retrieval
`Associative memory
`Deterministic decision making
`Non-deterministic decision making
`Data processing
`Pattern recognition
`Domain knowledge
`World knowledge
`
`Error proneness Freedom from error
`
`storage and retrieval of data, and accurate computation of both
`numerical and logical functions.
`At the interface between the human and the computer, the
`complementary aptitudes must be brought together in an appropriate
`way, otherwise the overall efficiency of the human—c0mputer system will
`be degraded. Interface design therefore involves choices which affect not
`only the hardware configuration, but also the way in which the tasks are
`divided, and the structure of the dialogue between the person and the
`machine.
`
`4.3 Human characteristics
`
`Human characteristics, as they affect the design of systems and their
`user interfaces, can in some senses be viewed as an onion-like structure.
`At the centre is the system itself, and around this in concentric layers
`are the various human characteristics (Figure 4.5). Human cognition
`should be taken into account in designing the dialogue organization,
`whereas perception and motor control should respectively influence the
`graphical structure of the interface and the design of input devices. The
`dialogue style should be chosen with reference to the experience and
`expertise of the user. The influence on interface design of each of these
`characteristics is briefly reviewed below.
`
`4.3.1 Ergonomics
`
`The basic physical characteristics of humans provide initial criteria for
`judging the efficacy of human—computer interfaces, and indeed for
`
`SKYHAWKE Ex. 1017, page 13
`
`SKYHAWKE Ex. 1017, page 13
`
`

`
`|—ni—r—un-uu—u—n7z\-nu—\.ir~.|
`
`\v4._.o-nu»;
`
`nu
`
`DIALOGUE STYLES: BASIC TECHNIQUES AND GUIDELINES
`
`75
`
`Ergonomics
`
`Experience/expertise
`
`Figure 4.5 Onion—skin structure of human-—computer interaction
`
`specifying the surrounding environment (lighting, seating, table height.
`keyboard and screen angles, etc.). Anthropometric data concerning
`human dimensions and their statistical ranges and distribution are
`widely available (e.g., see Bailey, 1982, Chapter 5 for a review and
`sample tables). Although statistical averages can be calculated for any
`parameter, Bailey illustrates the fallacy of designing for the ‘average’
`person by demonstrating that among a sample of 4063 men measured in
`a survey (Daniels and Churchill, 1952), no two were average in all 10
`dimensions commonly used in clothing design. (‘Average’ was
`considered to be the middle 30 per cent of the measured range for each
`dimension.) A more satisfactory strategy is therefore to design for a
`particular percentile range, for example 5-95 per cent. In many cases
`(e.g., keyboards) a single design can meet this requirement, but where
`the range of human variation is large (e.g., seat height) then user control
`can be provided to allow optimization.
`
`SKYHAWKE EX. 1017, page 14
`
`SKYHAWKE Ex. 1017, page 14
`
`

`
`
`
`76 ENGINEERING THE HUMAN—COMPUTER INTERFACE
`
`4.3.2 Perception, cognition and motor skills
`
`In human—computer interface design, dynamic as well as static physical
`characteristics are important. Since these depend not only on human
`physical dimensions but also on muscular control, they are often
`categorized under the heading of motor control parameters (see Chapter
`2). Parameters concerned with arm, hand and finger movement speeds
`are generally of most concern to interface designers, though voice
`control is also of fundamental importance to those in the
`speech-processing field, and has led to the development of complex and
`detailed models of the vocal tract (e.g., see Holmes, 1988).
`If motor control represents the output of the human information
`processor, then perception provides the inputs. Vision and hearing are
`by far the most important perceptual faculties from the point of view of
`interface design, and the more important characteristics of each are
`briefly reviewed in Chapter 2. Further detail can be found in Card,
`Moran and Newell (1983), Chapter 2; in Bailey (1982), Chapters 4 and
`7; and in Monk (1984), Chapter 1.
`Cognitive models of the type developed in Chapter 2 provide the most
`specifically useful information and insight into user interface design.
`Short-term memory, long-term memory and the communication channel
`between them are used extensively in interactions with a computer; in
`closely-coupled activity between the human and computer, decision
`making and problem solving form the major human contribution to the
`dialogue.
`
`4.3.3 Personality factors
`
`Though less readily measured than more basic physical, perceptual,
`cognitive and motor characteristics, personality and motivation should
`also be considered in human—computer dialogue design. Characteristics
`such as extroversion and introversion, not to mention different
`behaviour patterns between sexes, can have a major impact on
`dialogues. Similarly, tolerance, harassment, mood and fatigue can all
`make the difference between ready acceptance and total rejection of a
`computer system. Unfortunately, these factors tend to introduce an
`element of instability in human—computer dialogues: for example,
`anxiety increases the difficulty in learning about a new computer system,
`which in turn reduces performance, which increases anxiety, and so on.
`
`4.3.4 Experience and expertise
`
`Background knowledge concerning the experience and expertise of the
`expected user population is important in designing the interface.
`Experience relates to the general understanding which the user has of
`the problem, and of computer technology in general; expertise implies
`
`SKYHAWKE EX. 1017, page 15
`
`SKYHAWKE Ex. 1017, page 15
`
`

`
`77
`
`, DIALOGUE STYLES: BASIC TECHNIQUES AND GUIDELINES
`
`the more specific detailed knowledge which the designer may expect the
`user to have in carrying out the task using the system. Clearly, neither
`of these factors is likely to remain static unless the system is used very
`infrequently; nevertheless, this situation can arise in the case of, for
`example, computer-based public information systems.
`However, the concept of an ‘expert’ as someone with extensive
`knowledge of the system has been shown to be simplistic, at least in
`large systems with open learning (Draper, 1984). In a survey of use of
`the\UNIX operating system and its screen editor, vi, by 94 users over 8
`months, it was shown that there were no ‘experts’ using the system in
`the sense of people who used all the commands. Only 69 per cent of the
`total available UNIX commands were used at all over the period of the
`survey, and the highest individual vocabulary was 60 per cent of these.
`Users’ expertise was idiosyncratic: 18 individuals used one or more
`commands not used by any other users. Thus schemes for classifying
`users, such as that proposed in the next section, should ideally take
`account of the context in which the user is working—an argument in
`favour of adaptive interface styles.
`The same survey also showed that ‘experts’ were by far the heaviest
`users of the UNIX manuals, whereas the reverse might be expected to
`be the case. A possible inference from this is that expertise is not so
`much based on innate knowledge about the system, but is more a case
`of understanding how to use the system and its documentation to tackle
`and solve new problems. This is analogous to the skill of a librarian,
`whose expertise in navigating through the library’s cross-referencing
`systems is often called upon by library users to help solve their own
`specialized problems. Thus expertise may be more associated with the
`acquisition of techniques and strategies for problem solving rather than
`any defined static body of knowledge.
`
`4.3.5 Common user classifications
`
`The characteristics described in the previous section can be represented
`as three orthogonal axes on a graph (Figure 4.6). Although any
`combination of characteristics can occur in principle (the axes are
`continuous), there are nevertheless a few frequently encountered user
`types which characterize many human—computer interface scenarios.
`
`Casual users
`
`These are not very knowledgeable about the task or knowledge domain
`which they wish to interact with, and are also unfamiliar with the
`system they will be using. Frequency of access may be low, and hence
`there is little motivation to study manuals or other training aids. Use of
`the system and its logical structure must be self-evident. Examples of
`systems intended for casual users include databases such as Prestel and
`
`SKYHAWKE EX. 1017, page 16
`
`SKYHAWKE Ex. 1017, page 16
`
`

`
`78
`
`ENGINEERING THE HUMAN~COMPUTER INTERFACE
`
`4 System
`
`1' Frcquermy of use
`
`s.‘
`
`“‘~>
`Task
`
`Figure 4.6 Dimensions of human capability in hurnan—computer
`interaction
`
`Teletext, computerized library search facilities, and computer-based
`banking facilities accessible to the general public. Most computer
`messaging systems ought to be designed for casual users, but are not!
`
`Novice users
`
`Although these may start out with the same characteristics as casual
`users, they are distinguished by being much more frequent users. There
`is therefore much more motivation for them to read manuals and other
`
`off-line training aids, and thus less need for on-line support. As
`experience and use increase. they may eventually become expert users.
`This category covers many white-collar workers who use office and
`data-processing systems regularly.
`
`Knowledgeable intermittent users
`
`Typically. these are professional staff who use a wide range of different
`types of computer support equipment. They generally have a clear idea
`of the task they wish to accomplish, and a good general understanding
`of the capabilities of computer technology. but only a limited amount of
`familiarity with the specific systems they need to use. Motivation to use
`the system is high in the general sense that they are aware of the 'power‘
`
`SKYHAWKE EX. 1017, page 17
`
`SKYHAWKE Ex. 1017, page 17
`
`

`
`
`
`DIALOGUE STYLES: BASIC TECHNIQUES AND GUIDELINES 79
`
`improvements which the use of computers can bring, but tolerance is
`limited since they cannot afford to expend too much time learning the
`syntax of a system which will be used infrequently.
`
`Expert users
`
`Sometimes known as power users, these are fully conversant with both
`the task and the system they are using. Their main objective is to exploit
`to the maximum the capabilities the system provides for improving their
`performance. Excessive feedback and support is generally an irritant for
`these users, who are more interested in exploring ways of increasing the
`power of their interaction.
`
`4.4 Task characteristics
`
`Task characteristics are the complementary component of background
`knowledge which is required alongside knowledge of the characteristics
`of the human users before dialogue design can begin. Determination of
`task characteristics is accomplished using task analysis, which is