`
`" DESIGNING
`
`COGNITIVE CONTROL
`
`INTERFACE
`
`AT THE
`
`HUMAN/COM PUTE R
`
`SKYHAWKE EX. 1025, page 1
`
`
`
`SKYHAWKE Ex. 1025, page 1
`
`

`

`“0—25er
`
`
`
`
`
`
`
`lCS
`
`
`
`Dmm_mZ_ZDfiOQZ..—._<mnOZjNOP>4.._.ImIC_<_>Z\nO_<=u—
`
`$238on-mE:S8::NE
`
`SKYHAWKE EX. 1025, page 2
`
`SKYHAWKE Ex. 1025, page 2
`
`

`

`—_
`
`
`
`I” Hi iillllilli______ii HI lillll I III
`
`Where ouse - BK12716326
`The Psychology at Menu Selecti...e (Human/Computer lnti.raction)
`Used, Good
`(uG)
`‘H_ W
`
`
`
`
`
`SKYHAWKE Ex. 1025, page 3
`
`SKYHAWKE Ex. 1025, page 3
`
`

`

`
`
`The Psychology of Menu Selection:
`
`Designing Cognitive Control
`of the Human/Computer Interface
`
`Kent L. Norman
`
`Department of Psychology
`University of Maryland
`
`
`
`fl ABLEX PUBLISHING CORPORATION
`
`NORWOOD, NEW jERSEY
`
`SKYHAWKE EX. 1025, page 4
`
`
`
`SKYHAWKE Ex. 1025, page 4
`
`

`

`Cover designed by Thomas Phon Graphics
`
`Copyright © 1991 by Ablex Publishing Corporation
`
`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, microfilming, recording, or otherwise, without per—
`mission of the publisher.
`
`Printed in the United States of America
`
`Library of Congress Cataloging-in-Publication Data
`
`Norman, Kent L.
`
`The psychology of menu selection : designing cognitive control at
`the human/computer interface / Kent L. Norman.
`p.
`cm.—(Human/computer interaction)
`Includes bibliographical references (p.
`ISBN 0-89391—553-X
`
`) and index.
`
`2. System design—Psychological
`1. Human~computer interaction.
`aspects.
`I. Title.
`II. Series: Human/computer interaction
`(Norwood, NJ.)
`QA76.9.H85N67 1990
`005. 1—dc20
`
`90- 1 198
`CIP
`
`Ablex Publishing Corporation
`355 Chestnut Street
`
`Norwood, New Jersey 07648
`
`SKYHAWKE Ex. 1025, page 5
`
`
`
`SKYHAWKE Ex. 1025, page 5
`
`

`

`
`
`
`
`Tasks and Flow of Control
`
`Menu selection systems are used to perform a variety of types of work
`from word processing to information retrieval, from computer-aided
`instruction to computer-aided design, and from teleconferencing to file
`management. In each case, a task analysis would indicate that work is
`performed by executing a number of component tasks and subtasks.
`Furthermore, such analyses would reveal a plan of attack that specifies
`the order in which the tasks and subtasks must be executed. Experi-
`enced workers have a fairly clear idea about what the component tasks
`are and have learned a number of protocols, rules, and strategies for
`applying the component tasks. When computers are used to automate
`part of the task, there should be a close match between user-defined
`component tasks and system-defined functions. Few things can be more
`frustrating than wanting to perform some function that seems necessary
`and logical to the user but that is not available on the system. Further-
`more, there must be an agreement between the order in which the user
`would like to perform the tasks and the order allowed by the system.
`Users should be allowed to perform tasks in an order that makes sense
`to them, even though it may not be optimal in terms of computer
`processing. The overriding principle is that computers should be de-
`signed to increase human control rather than optimizing computer pro-
`cessing at the expense of human control.
`This chapter extends the theory of cognitive control and discusses
`general types of tasks accomplished by menu selection. These tasks
`include the specific functions of selecting items frame by frame and the
`global task of traversing a menu structure for specific applications. The
`theory developed and the distinctions drawn in this chapter serve to set
`the foundation for understanding the empirical research conducted on
`menu selection.
`
`3.1 TAXONOMIES OF TASKS AND INFORMATION
`STRUCTURES
`
`it is necessary to develop a
`In designing a menu selection system,
`taxonomy of the tasks and subtasks that the user desires in performing
`the work. Tasks need to be considered at the cognitive level; that is, they
`41
`
`SKYHAWKE Ex. 1025, page 6
`
`
`
`
`
`SKYHAWKE Ex. 1025, page 6
`
`

`

`
`
`.__-._
`
`‘8
`
`The Psychology of Menu Selection
`
`need to be defined in terms of the components that the user thinks about
`when he or she is formulating a plan of action. They must not be too
`elemental nor too global in nature. Instead, they must be gauged to the
`level of action as defined by the user. If actions are too elemental, the
`menu structure will be more complex than it needs to be. If actions are
`too global, the menu structure will be simple but it will overshoot the
`user’s goal.
`For any task, the designer must create a list of all the actions imple-
`mented by the system. In formal programming languages,
`this list
`constitutes the set of allowable program statements and functions. In
`menu selection systems, this list becomes the set of menu items that
`evoke actions or changes. An analysis of the task is necessary for the
`designer to determine what functions need to be implemented. In devel-
`oping a taxonomy, one may take either a top~down or a bottom-up ap-
`proach (Chin, 1986). In a top-down approach, the designer lists major
`top—level functions which are then refined in greater and greater detail.
`In a bottom-up approach, the whole list of specific functions is analyzed
`and organized into groups. Which approach is used depends on the
`particular task and functions. For example, in text editing one may start
`with a top-down approach as shown in Figure 3.1. The major task
`components are (a) file functions, (b) printing, (c) text modification, (d)
`formatting, and (e) browsing. Each of these may then be refined to more
`specific functions. The top-down approach has the advantage in that as
`functions are added they are incorporated in a hierarchical structure.
`On the other hand, when a list of specific functions already exists, the
`bottom-up approach may be used. Tasks that have been manually per-
`formed in the past may be analyzed into subtasks. The subtasks are then
`clustered into groups. Figure 3.2 gives an illustration of a task analysis of
`a message handling system.
`
`3.2 HUMAN VS. COMPUTER CONTROL OF FLOW
`
`Once the list of tasks has been determined, designers must consider the
`order in which tasks are performed. The order may be either user-
`directed or computer-directed. In user—directed tasks, the user starts
`from a plan of action and directs the computer to perform those tasks in
`that order. Although command language has traditionally been the
`mode of interaction for user-directed tasks, menu selection is playing an
`increasingly important role. The two major problems with command
`language are that the user must remember the command (both its
`semantic function and syntactic structure) and correctly enter the com—
`mand via the keyboard. Menu selection can often be used more effec-
`
`SKYHAWKE Ex. 1025, page 7
`
`
`
`SKYHAWKE Ex. 1025, page 7
`
`

`

`Tasks and Flow of Control
`
`49
`
`Top Level Functlons:
`
`Secondarg functlons:
`
`Tertlarg Functlons:
`
`Prlntlng
`
`Open New FlIe fl Speclfg Deulce Name
`Open Old Flle
`Enter Flle Name
`Rename Old Flle
`Delete Old FIIe
`
`Page Setup
`Print Options
`Prlnt Document
`
`Speclfg Paper Slze
`Specllg Marglns
`Specllg Columns
`
`
`
`
`
`Modlfglng Tent
`
`Insert Text ——j———:
`flppend Tent
`Delete Text
`
`Speclfg Insert Polnt
`Input Text
`
`m Page Numbers
`Set Tabs
`Set Header
`Set Footer
`
`Specltg start
`E; Odd/Even
`Tltle Page
`
`Scroll ——_T: Up One Llne
`Search
`Down One Llne
`Page Forward
`Page Back
`
`Figure 3.|. Example of a top-down analysis of functions in a text editor.
`
`tively without burdening the user with the added memory and time
`required to type commands.
`In computer-directed tasks, the designer formulates the plan of action
`and software elicits input
`from the user in a prescribed order.
`Computer-directed tasks lead the user through a series of queries in
`structured tasks that must be carried out in a specific order. Prompts and
`form fill-in screens are often used to guide users in computer—directed
`tasks; however, structured menus which follow a prescribed order are
`also becoming popular.
`The distinction between user-directed and computer-directed tasks is
`partly one of program branching, but also one of user attitude. Just who
`or what is directing the course of events may be a matter of opinion.
`Users may feel that they are in command, or they may get the impres-
`sion of being passively led down the garden path. Whichever impres-
`sion dominates will be a function of the user’s level of experience and
`the complexity of the system. Menu systems may increase the complex-
`
`
`
`SKYHAWKE Ex. 1025, page 8
`
`
`
`SKYHAWKE Ex. 1025, page 8
`
`

`

`
`
`5.
`
`The Psychology of Menu Selection
`
`Bottom Leuel Functlons:
`
`Groups of Functlons:
`
`Beulew mall
`
`Review mall
`
`Select mall message
`
`Bead message
`
`Forward mail
`
`Saue message In file
`
`Prlnt message
`
`Reply to mall
`
`flnnotate message
`
`Select mall message
`
`Bead message
`Forward mall
`Saue In flle
`Prlnt message
`flnnotate
`Reply to mail
`
`Create mall
`
`nsslgn handllng category
`
`mm m" fl
`
`Name mall flle
`Select draft mall form
`
`Name mall file
`Select draft mall form
`Edlt draft mail
`
`[all draft. mail
`
`flsslgn handllng category m
`
`address mall
`
`send m°"
`
`address mall
`
`Figure 3.2. Example of a bottom-up analysis of functions in an electronic mail
`system.
`
`ity of the system by providing breadth of choice at any particular level
`and by providing successive levels of options. The user’s impression
`may be one of great choice latitude, flexibility, and power. On the other
`hand, a limited number of menu items may result in a feeling of con-
`straint, inflexibility, and powerlessness. The user’s impression, how-
`ever,
`is relative and depends on the match between the degree of
`latitude desired and that provided. It will be argued in the next section
`that systems may err in providing too little or too much flexibility. A
`system with scores of superficial options may appear very powerful on
`the surface but lack true usability. Alternatively, a system that appears
`
`
`
`SKYHAWKE Ex. 1025, page 9
`
`SKYHAWKE Ex. 1025, page 9
`
`

`

`P"
`
`'
`
`Tasks and Flow of Control
`
`5 I
`
`very simple may prove to be efficient. But a system that is too limited
`may require added work on the part of users.
`Another issue related to user- versus computer-directed tasks is that
`of switching control between the user and the computer. Typically,
`human/computer interaction is a dialog in which control is passed back
`and forth between the user and the computer. The user issues a com—
`mand, the computer executes a procedure and informs the user, who in
`turn evaluates the result and responds with another command. For
`users to interact effectively in such an environment, they must know
`three things: (a) who’s turn it is; (b) given that it is the user’s turn, what
`the currently valid set of commands or appropriate input is; and (c)
`given that it is the computer’s turn, what the computer is currently
`doing or what the result will be. Techniques used in menu selection help
`to provide some of this information. Menu prompts indicate when the
`user has control to select options. Menus display the currently available
`set of options, reducing the probability of selecting an invalid command.
`Additional feedback is required to inform the user of computer opera-
`tions and results once a menu selection has been made. To the extent
`that this information is available and meaningful, the user will be able to
`operate efficiently. When it is lacking, users will experience confusion
`and loss of control while performance will be slow and error prone.
`
`3.3 A THEORY OF COGNITIVE CONTROL
`
`The primary function of the human/computer interface is to provide
`users with an efficient means of controlling a complex process. In the
`same way that one would exercise control of an automobile, the user
`controls a computer. The operator of an automobile monitors displays
`(from instruments on the dashboard to the scene outside the wind-
`shield) and manually adjusts controls (from the steering wheel, accelera-
`tor, and brake to the light switches, turn signals, and radio). Control of
`computer processes, of course, differ in a number of ways. Computer
`processes are generally more autonomous in the sense that they are
`started and left to run on their own; whereas, automobiles require
`continuous close control (Wickens, 1984). Control of computer processes
`is primarily digital rather than analog although increasingly analog
`input devices are being used. Finally, computer processes vary exten-
`sively in their level of complexity (Card, Moran, 8r Newell, 1983). Con-
`trol of the process may be as simple as turning on or off a switch or as
`complex as controlling a simulation of the universe.
`Control theory deals with the interrelationships among ongoing pro-
`cesses, informative feedback, and control mechanisms. In general, one
`
`SKYHAWKE Ex. 1025, page 10
`
`
`
`
`
`SKYHAWKE Ex. 1025, page 10
`
`

`

`51
`
`The Psychology of Menu Selection
`
`is interested in using control theory to optimize efficiency, productivity,
`and/or quality. Similarly, in human/computer interaction, the designer
`is interested in optimizing some aspect of performance. The challenge is
`considerably greater than optimization of a purely mechanical process
`since the human is a prime source of control in the process. The user is
`not only a part of the control loop, but he or she typically maintains a
`higher strategic level of control. This metacontrol may be thought of as
`control of the control process and may involve such functions as (a)
`initialization, (b) parameter specification, and (c) programming of the
`control process itself.
`Menu selection is an attractive mode of human/computer interaction
`in that it explicates interrelationships of the control process in terms of a
`menu structure. The list of menu items and succession of menu frames
`help to reveal the underlying states and transitions of a program to the
`user. Menu selection is a particularly attractive mode of control when it
`allows users to exercise metacontrol over computer processes. Such
`systems may allow users to design their own menus, program macro-
`menu actions via direct manipulation, and organize files into menus
`using hierarchical file servers. These types of metacontrol will be dis-
`cussed in a later chapter.
`In Chapter 1, a model of human/computer interaction was presented
`in Figure 1.5. The central part of the figure is the overlap of the circle
`(cognitive processes) and the square (computer processes). Control in—
`volves information output from the computer (top left-going line) and
`commands from the user (bottom right-going line). A theory of cognitive
`control, however, must entail more than directions of information flow.
`In this section the issue of a system function will be addressed. Listed
`below are the main tenets of a theory of cognitive control dealing with
`system functionality.
`The Apparent System Complexity/Functionality Should Match User/
`Task Need. To maximize user efficiency, the complexity of the system
`functionality should match user need. Dehning, Essig, and Maass (1981)
`assert that for optimal performance and the human/computer interface,
`the system must provide maximal flexibility while at the same time
`minimize subjective operating complexity. In addition to the considera-
`tion of complexity, the present theory emphasizes a match in func-
`tionality between the system and user needs.
`To express this more formally, let F5 be the set of active system
`functions, and let Pu be the set of functions required by the user to
`perform a set of tasks—T. In general, system functions do not directly
`perform all the possible tasks. If they did, one would need as many
`functions as there are tasks. A statistical package, for example, would
`not have a function to calculate the mean of 2 numbers and another to
`calculate the mean of 3 numbers, 4 numbers, and so on. Rather, the
`
`
`
`SKYHAWKE EX. 1025, page 11
`
`
`
`SKYHAWKE Ex. 1025, page 11
`
`

`

`
`
`Tasks and Flow of Control
`
`53
`
`
`
`package would include another function to let the user set the sample
`size. At the other extreme, a system may be developed with a minimum
`number of functions capable of performing all of the desired tasks. A six-
`function calculator could be used to perform all of the statistical calcula-
`tions needed. However, to do so would require a lengthy application of
`functions on the part of the user. Cognitive control is facilitated when
`the user’s conceptualization of functions required to perform a set of
`tasks matches the set of system functions—F5 = F”.
`To the extent that F5 < Pu, performance will decrease because the
`user will have to work around the system’s lack of functionality by
`repeated application of existing functions. To the extent that F5 > Pu,
`performance will also decrease because the user will have to sort
`through a number of superfluous functions to locate needed functions.
`With experience, users may learn to overcome these problems. How-
`ever, the learning time and ongoing cognitive overhead may be too
`much of a burden to bear.
`
`A second problem in matching functionality has to do with the
`structure of the menu. The menu which implements system functions
`may be overly complex or impoverished. Menus are overly complex
`when scores of infrequently used items are constantly displayed. Well-
`designed hierarchical menus may direct the user to frequently required
`items, while at the same time allowing access to highly specialized
`items. Menus may be impoverished even though they contain all of the
`necessary items if they allow only a limited set of paths to those items.
`Impoverished menus require the user to spend an inordinate amount of
`time traversing the menu to get to the needed items.
`Functional complexity and menu complexity may be thought of as
`two somewhat related dimensions of a system. As shown in Figure 3.3,
`the ideal system exists when the complexity along both dimensions
`matches that of user need and proficiency. To the extent that the system
`is off center, performance will decrease. When menus are inadequate,
`users must contend with inefficient paths; whereas, when they are
`overly complex, users must contend with more menu items per frame.
`Moreover, when functional complexity is inadequate, users must select
`more functions to accomplish a task; whereas, when it is overly com-
`plex, users must search through more functions to find the appropriate
`one. Proper positioning on these two dimensions is the key to matching
`software to tasks.
`
`The System State Transition Diagram Should Optimize the User Sub-
`tusk Transition Matrix. A state transition diagram specifies a set of
`states (indicated by circles), the possible transitions from one state to
`another (indicated by arrows), and the conditions under which a transi-
`tion occurs. In menu selection systems, the allowable transitions are
`determined by the menu structure and the conditions for transitions are
`
`SKYHAWKE EX. 1025, page 12
`
`
`
`
`
`SKYHAWKE Ex. 1025, page 12
`
`

`

`
`
`6...:.35E3:
`
`9.88£385
`
`.5:—322532ES2855:
`
`
`
`5.58.33E25
`
`.585Emgzug
`
`:5:PBS5::
`
`FEE3:25
`
`
`
`:mEEou2:25
`
`3252.:
`
`
`
`3.5.3533:235...—
`
`fiuualdwoa nuaw
`
`32:5qu
`
`E28.36£25
`
`2.23.83.:Ea
`
`28:32936
`
`2:2”—:55:
`
`3.53:2:
`
`35:52..
`
`26:
`
`3:2.35225
`
` 82:5::2:8553265:$85
`
`:mEEou33::
`
`
`
`SKYHAWKE EX. 1025, page 13
`
`SKYHAWKE Ex. 1025, page 13
`
`

`

`
`
`Tasks and Flow of Control
`
`55
`
`determined by user selection. To perform a task, users call upon a
`number of subtasks. Given the set of subtasks, a transition matrix
`specifies the probability that one subtask follows another.
`The upper panel of Figure 3.4 gives an example of a probability
`transition matrix for a set of subtasks for playing a computer game. For
`each subtask implemented at state n (shown in the rows), there is a set
`of probabilities that the user needs to go to for particular subtasks at
`state n +1 (shown in the columns). For example, if the user is at subtask
`A, there is a .5 probability of going to subtask B and a .5 probability of
`
`state n + I
`
`Staten
`
`D-Replug
`
`E-Plug white
`
`F-Plug Black
`
`Inadequate
`
`adequate
`
`0
`
`
`
`0 >6)
`G) 2/
`
`\
`
`\ @\
`
`\9
`
`OueraIIg Rich
`
`/®\
`
`
`
`C)
`
`@
`
`Figure 3.4. User subtask transition matrix and system state transition dia-
`grams representing inadequate, adequate, and overly complex menu struc-
`tures.
`
`SKYHAWKE Ex. 1025, page 14
`
`
`
`'
`
`
`
`SKYHAWKE Ex. 1025, page 14
`
`

`

`r
`
`—-—-———fi
`
`56
`
`The Psychology of Menu Selection
`
`going to subtask C. Given this probability matrix, one may evaluate the
`graph structure of a menu system which implements these states. A
`good menu should allow direct paths for high—probability transitions.
`On the other hand, low—probability transitions need not be direct, but
`may require successive selections.
`Menus that control such state transitions may be either impoverished
`in the paths that they provide, or they may be too rich by including a
`number of seldom used paths. Impoverished menus are inefficient be-
`cause they require the user to make longer traversals of the menu
`system. In doing so, the user must make more decisions, selections, and
`planning. The graph in the bottom left of Figure 3.4 illustrates a hier-
`archical menu from the root node A to terminal nodes D, E, and F with
`transitions back to the root node. Although it contains 13 transitions,
`including transitions to previous nodes indicated by double arrows, it
`does not implement several important high-probability transitions as
`seen in the matrix: B -—> C, D —> C, E —> D, and F —> D. Lateral transitions
`are not implemented; hence, the user must return to the root node and
`proceed down to the next node in the sequence. The menu graph at the
`bottom middle of Figure 3.4 provides a better match with the same
`number of transitions. A number of unnecessary paths up the tree are
`eliminated and the high-probability lateral transitions are incorporated
`in the structure.
`
`The degree to which a menu structure is impoverished can be esti-
`mated from the probability transition matrix. For a given number of
`subtasks that have to be performed, one can estimate the percent of the
`expected number of transitions required by an impoverished menu
`relative to a menu that implements a path for all non-zero transitions.
`For example, the percent of extra traversals for the “inadequate” menu
`in Figure 3.4 is 60% over that of the ”adequate” menu.
`On the other hand, menus may be overly rich when they include a
`number of superfluous or underutilized paths in the structure. An
`overly rich menu is shown at the bottom right of Figure 3.4 which allows
`a transition from any node to any other node. Although a rich menu
`minimizes the number of frames traversed, the increased number of
`alternatives may retard choice and response times of the user. Impov-
`erished menus will evidence faster response times per frame, but the
`overall time to perform a task may be longer since more responses are
`required. Designers must tradeoff the costs between rich and lean
`menus to optimize performance.
`The efficiency of menus can be compared by estimating expected user
`response time across the menu. Response times are a function of the
`number of alternatives in each frame. For the present, assume that the
`response time is given by a power law—R = n” + 1—where n is the
`number of items per frame and let p = .7. Table 3.1. gives the response
`
`
`
`SKYHAWKE Ex. 1025, page 15
`
`SKYHAWKE Ex. 1025, page 15
`
`

`

`
`
` Tasks and Flow of Control
`
`51
`
`times at each node of the three menu graphs shown in Figure 3.4. Using
`the transition probabilities also in Figure 3.4 and the graphs, the ex-
`pected response times were calculated and are shown at the bottom of
`Table 3.1. The expected response time for the ”inadequate” menu is
`much longer, due to the fact that 60% more responses are required for
`the desired state transition. The “overly rich” menu also shows a higher
`response time due to slower responses at each frame. It can be seen that
`changes in the menu structure can result in rather large changes in
`performance. Similarly, designers should compare alternative imple-
`mentations of menus or iteratively vary menu structures to find one that
`optimizes performance.
`
`3.4 FUNCTIONS OF MENU SELECTION
`
`In this section the specific functions of a menu selection will be dis-
`cussed. Each selection made by the user in a menu performs one or
`more functions. The function may be merely to branch to another menu
`or it may be to do something else. This section will define the four
`functions of (a) pointing, (b) command control, (c) output, and (d) input.
`Other taxonomies of menu function could be specified based on pro—
`gram operation; however, the present one will prove useful from the
`perspective of understanding cognitive control by the user.
`
`3.4.1 Pointing: Moving to a New Node
`
`Each selection by the user branches to a successive node in the menu
`tree. Although this is an inherent function of all menus, the importance
`of this function varies among systems. In some cases,
`it is the sole
`purpose of the selection to traverse the menu tree. Selections serve in a
`stepwise specification of an object or command. The overriding purpose
`
`Table 3.|. Expected User Response Times
`for Three Menu Types.
`AdequateInadequate Overly Rich
`
`
`A
`2.62
`2.62
`4.09
`B
`2.62
`3. [6
`4.09
`C
`3. I6
`2.62
`4.09
`D
`2.62
`2.62
`4.09
`E
`2.62
`2.62
`4.09
`
`F
`2.62
`2.62
`4.09
`
`Expected
`Response Time
`
`4.24
`
`2.64
`
`4.09
`
`
`
`SKYHAWKE Ex. 1025, page 16
`
`SKYHAWKE Ex. 1025, page 16
`
`

`

`
`
`58
`
`The Psychology of Menu Selection
`
`is one of pointing to something. From the perspective of the user, menu
`selection is like navigation. The sole purpose of each selection is to steer
`the system toward a destination.
`In this way the process is goal—
`oriented. Although selection errors take the user off track and lead to a
`loss of time, they are not destructive and are in general undoable.
`The pointing function is essential in hierarchical menu systems. An
`example would be a menu system for a timesharing utility. A number of
`services are available to the user; but in order to access one, the user
`must specify its name. Rather than having to type in the name of the
`service, the user is given a series of choices. The services are typically
`clustered by type into a hierarchy. Each selection by the user does
`nothing except move to the next level of specification. Once the user
`comes to a particular service on the system, the function of the menu
`changes from traversal to implementation.
`
`3.4.2 Command Control: Executing a Procedure
`
`The second function of selection is to direct the computer to execute a
`procedure or to implement some action. In this case, the choice evokes a
`procedure that performs some function. It may open or close a file, write
`or read to a file, transform data, and so forth. As noted, this may only
`occur after the user has traversed the menu tree and is at some terminal
`node. On the other hand, every selection made by users may initiate a
`program procedure as they traverse a menu network. In this case,
`successive selections evoke a sequence of procedures. The users deter-
`mine the selection and order of procedures. From the user’s perspective,
`selections are “go-ahead” commands for the system to execute a func-
`tion. It should be clear to users that selections are not merely pointing to
`items, but that they are activating changes. Errors in command control
`may not be so inconsequential as in pointing to the wrong node. Conse-
`quently, the user needs to be informed if selections are undoable before
`they are selected.
`An example of command control would be a telecommunication
`program with menu selection. If the user selects the option PHONE, the
`system executes a procedure to dial and connect to a remote system.
`The user may then select RECORD to open a file and save the text of the
`interaction. Later the user may select STOP RECORDING to close the
`file and HANG UP to disconnect from the system.
`
`3.4.3 Output: Displaying Information
`
`The main function of menu selection may be to display information. The
`user may be searching for a specific piece of information in a database,
`or merely browsing through information contained in a menu hierarchy.
`
`
`
`SKYHAWKE EX. 1025, page 17
`
`
`
`SKYHAWKE Ex. 1025, page 17
`
`

`

`Tasks and Flow of Control
`
`5’
`
`The output function is very similar to the pointing function of menu
`selection except that from the perspective of the user, attention is fo-
`cused on the content of the output information rather than on the
`pointer to it. Like the pointing function, the output function is non-
`destructive. If the user gets off track, he or she may loose time but
`should be able to recover from selection errors. Information search may
`be either goal-directed or casual browsing, but the path taken will be
`determined by the content material and the user's interests. Conse-
`quently, users will spend considerable effort processing output informa-
`tion in order to evaluate subsequent menu items.
`Online technical manuals provide a good example of the output
`function. A particularly good example is the interactive encyclopedia
`system (HyperTies) developed by Shneiderman and his associates
`(Shneiderman & Kearsley, 1989) which displays articles containing high—
`lighted words or phrases. If the user selects an item, the system displays
`a definition and/or a related article. The user may then browse through a
`set of interrelated articles.
`
`3.4.4 Input: Data or Parameter Specification
`
`The last function is one of input. Each selection by the user specifies a
`piece of data to be input into the system or the desired value of some
`parameter. Input values may be indicated by single menu selections or
`by traversing a menu hierarchy. In the latter case, traversing the menu
`specifies an input value incrementally. Although this type of input
`function is again similar to the pointing function, the emphasis from the
`perspective of the user is on input of information to the system. Menu
`selection adds structure to data input by limiting input to allowable
`values and reduces errors due to incorrect syntax and typing. In general,
`selection errors can be easily corrected if detected. Nevertheless, unde-
`tected errors remain a problem, as usual, in data entry.
`
`3.4.5 Four Menu Functions in Perspective
`
`It should be emphasized that this fourfold taxonomy of menu selection
`should be interpreted from the perspective of the user. In terms of the
`code driving the system, it is no doubt meaningless. In actuality the
`code may be written so that for every selection (a) a new frame is
`pointed to, (b) a procedure is evoked, (c) information is displayed, and
`(d) data is input. The main distinction among these functions is not so
`much in what the software does but in what the user thinks it is doing.
`Furthermore, these functions apply most directly to individual menus
`or sequences of menus in a system; whereas, most menu systems are
`
`
`
`SKYHAWKE Ex. 1025, page 18
`
`
`
`SKYHAWKE Ex. 1025, page 18
`
`

`

`‘0
`
`The Psychology of Menu Selection
`
`mixtures of these functions. Parts of the menu tree may exist merely to
`branch to some procedure; other parts of the system may exist for the
`purpose of displaying information; and still other parts may provide
`menus of executable procedures.
`Having said this, it is also true that systems may emphasize only one
`function. Menus for timesharing systems, file management, and docu-
`ment retrieval systems lean more toward traversal of a database via the
`pointing function. Menus for operating systems and application pro-
`grams, such as word processors and spread sheets, lean more toward
`executing procedures via the command control function. Menus for help
`systems, tutorials, and information retrieval systems lean more toward
`displaying information via the display function. Finally, menus for on-
`line questionnaires and data entry systems lean more toward data and
`parameter specification via the input function.
`The way in which a menu is designed should be commensurated with
`the perceived task and the way in which the system is used to accom-
`plish the task. MacGregor, Lee, and Lam (1986) distinguished between
`“command" menus and ”videotext” menus, and noted that command
`menus are designed to select a relatively limited set of items (30 to 100).
`Experienced users have learned the positions of menu items. On the
`other hand, videotext menus are likely to access relatively large
`databases with thousands of documents requiring a large number of
`menu frames. In command menus the user generally does not read all of
`the items but merely scans to the desired one and selects it. In videotext
`menus the user may need to read each item carefully in order to deter—
`mine the next selection. While command menus may be designed with a
`relatively large'number of options, videotext menus, according to Paap
`and Roske-Hofstrand (1986), should focus the user down a narrower
`path by presentin