How Humans Work Semester 2, 2009 1 Human-Machine Interaction - - PDF document

How Humans Work

Semester 2, 2009

1 Human-Machine Interaction

Important Concepts

• Norman’s model of human task performance
• affordances
• constraints
• natural mapping
• visibility
• cultural expectations
• causality
• transfer effects
• mental models

Notes These concepts are mainly due to Donald Norman. At a certain level, most

• f them are just common sense. But giving them names helps focus on them,

and to give you a vocabulary for talking about HCI.

mental

Goals

Perception Interpretation Evaluation Action Specification Execution Intention

activity physical activity expectation

Figure 1: Donald Norman’s Model of Human Task Performance. Norman’s Model of Task Performance See Figure 1. Notes This model describes how people perform tasks. It basically says that, in performing a task, a human goes through these seven stages:

• Establishing the goal to be achieved
• Forming the intention to perform some action that will achieve the

goal

• Specifying the action
• Actually executing the action
• Perceiving the system state
• Interpreting the state as perceived
• Evaluating the system state with respect to the goal and intentions

(Hence, it is also sometimes referred to as the “Seven Stages of Action”.) For example, suppose I’m editing a file in Emacs (as I am now), and I decide I 2

want to save the file I’m working on. “Saving the file” is my goal. The state

• f the world at this point, at least the relevant part, the Emacs window, is

shown in Figure 2. (Emacs actually calls this a frame, reserving the term window for the viewports onto file buffers that a frame may contain. While this is just at one level a peculiarity of Emacs terminology, at another level it makes the point that different programs and interface toolkits may use terms like “window” and “frame” with different meanings. So beware.) Then I form the intention to do something to save the file. Next I have to decide on (specify) what action to perform. Suppose I decide to click with the mouse on the colored floppy-disk icon in the Emacs toolbar. (How I make this decision we’ll consider later.) Then I actually have to go ahead and perform that action. That action has an effect on the world: the pattern

• f colors and shapes in the Emacs window changes. See Figure 3. I have to

perceive those changes (at the lowest level of perception); and then interpret them: the floppy-disk icon has changed from colored to “greyed-out”, the * * at the left of the status bar has changed to - -, and the message Wrote /Users/ljk/371/New/lec/body-humanwork-in.tex has appeared in the minibuffer at the bottom. Lastly, I have to evaluate whether (any of) these indicate that my file has in fact been saved—that is, that the action I took did indeed lead to the achievement of my goal. My decision about what action to take will be based on a combination

• f what actions I can see that the interface offers and what I know about

the interface (my mental model—see later). In general, for an unfamiliar interface I’ll have to depend mainly on what visible options the interface presents to me; for a familiar interface I can make more use of my specific knowledge of that interface. For Emacs I know that the key sequence “Ctrl- X Ctrl-S” also saves. (And will be more convenient since I won’t have to remove my hand from the keyboard—but this is a somewhat separate issue.) Note that this process can be multi-level: A top-level goal can spawn

• subgoals. For example, my goal might be to fit a note I’m writing onto one

printed page (it’s slightly too long). I could achieve that top-level goal by achieving any one of the three subgoals: reword the text of the note, or change the font size, or change the page layout (e.g., narrower margins). In AI problem-solving terms, these subgoals are connected under an OR node, that is, achieving any one of the subgoals is sufficient to achieve the top- level goal. If I’m operating sequentially, then I can just try the subgoals one after another until one succeeds. In other situations, the subgoals might be connected under an AND node, that is, all the subgoals have to be achieved in order to achieve the top-level goal. 3

Figure 2: Screengrab of Emacs window before toolbar save. This can happen at various stages. For example, if I’m not using a WYSIWYG (“What you see is what you get.”) system, then checking that my actions succeeded in achieving my goal (fitting the note on one page), may require setting up a subgoal of previewing or printing the note. Or in the file-saving example, if I’m not sure what the floppy-disk icon does, then I might set up the subgoal of finding out what it does, the action for which might be to move the mouse cursor over it to read the pop-up tool-tip. (Tool-tips probably originated with the early Macs as “balloon help”.) Gulf of Execution

• How do users know what to do to achieve their goal?

– What actions are available? – Which one does what I want?

• E.g., How do I save the document I’m working on?
• The smaller the gulf the better.

Gulf of Evaluation 4

Figure 3: Screengrab of Emacs window after toolbar save. What’s changed since Figure 2? What does it mean for the achievement of my goal?

• How do users know (evaluate) whether the action they chose had the

intended effect? – Easily visible and interpretable feedback on effect of actions

• E.g., I clicked on the “save” menu item.

How do I know that my document actually got saved?

• The smaller the gulf the better.

Notes The Gulf of Execution and Gulf of Evaluation are two aspects of users’ interaction with an interface. The Gulf of Execution is about the difficulty users have in deciding what to do, which action to try. The Gulf of Evaluation is about the difficulty that users have in deciding whether the action they took did in fact have the intended effect. Note that these two gulfs are not processes; they refer to the gap (in each case) between what the user wants and what the interface provides. On the execution side, an interface that makes visible what actions it provides and makes it easy for users to choose the correct action has a small Gulf of Execution—and that’s good. An interface for which it’s difficult for users to choose the actions to achieve their goals has a large Gulf of Execution—and 5

that’s bad. On the evaluation side, an interface that gives users good feedback so that they can easily know whether the action they chose had the intended effect has a small Gulf of Evaluation—and that’s good. If users don’t get good feedback about what effect their action had, then that interface has a large Gulf of Evaluation—and that’s bad. Affordances

• Visible properties of objects that suggest what can be done with them—

signals of use

• e.g., a suitable handle affords grasping
• e.g., a suitable door-plate affords pushing
• Norman: When simple things need an instruction manual, even a one-

word manual, then design has failed. Notes As Norman used the term, and as it is commonly used today in HCI, an affordance is a visible property of some object that suggests how it can be used. For example, I want to pick up a suitcase. I look at it and see that it has a handle that looks suitable for grasping and picking the suitcase. The handle is an affordance for picking up the suitcase. For example, I come up to a door, which I want to open. The door has a push-plate on it, which suggests that I open this door by pushing. Figure 4 shows an example of what Norman was thinking about in the above quote. Here the door has a two-word instruction manual: “PUSH” on

• ne side, “PULL” on the other. According to Norman this is a bad design.

For a well-designed door, it should be obvious how to operate it, without the need for any additional written signs. While we mostly think of affordances in terms of “visibility” to sight, they could conceivably apply to other sense modalities. If I encountered the door in the dark, and reached out and felt that it had a push-plate, then that would still suggest that I could open the door by pushing, even though I couldn’t actually see it. The term affordance does have a history. Norman took it from J.J. Gib- son, who used it to refer to those things in an environment that could be used by an organism (whether visible or not). Norman changed the meaning to require visibility, which is how it’s generally used in HCI. As well as being used to refer to individual signals of use, the term affordance is often also 6

Figure 4: A door with a two-word instruction manual. used for the abstract quality: you might say that an interface overall has “good affordance”. Constraints

• Some constraint on the use of objects Norman’s Lego set construction

example Physical blocks fit together in only certain ways Semantic windscreen goes in front of rider Cultural red light is tail light Logical last part has to go in last available position

• Some overlap between the concepts, affordance and various kinds of

constraints

• Sometimes a matter of interpretation
• But usually distinction is reasonably clear
• Cultural factors often escape notice

7

Notes While affordances suggest how something can be used, constraints put limits

• n how things can be used.

Norman made the observation that most people, given a small Lego set (say of a Lego police officer on a motorcycle), can put it together successfully without reading the instructions, and without even seeing a picture of what the final assembly looks like. He attributes this to the constraints inherent in the Lego set, which normally permit only one (reasonable) way of putting the blocks together. He classified the constraints as being of four kinds: Physical The blocks can fit together in only certain ways. Semantic The positioning of certain components can be settled by reasoning about their meaning or use. For example, the purpose of the windscreen is to shield the rider, so it should go in front of the rider. Cultural The use of some components is determined by cultural factors: The Lego set has a little transparent red block. We know that the world-wide convention for motor vehicles is that the tail light is red. Therefore this block, representing the tail light, should go at the rear

• f the motorcycle.

Logical Some parts can be placed by logical reasoning: For example, if there’s only one part remaining, then it has to go in last available position. It’s best not to take this list of constraint types as being definitive. That is, don’t feel that every interface constraint you encounter has to fit exactly into one of these categories. Think of Norman’s classification as illustrating some of the different ways in which constraints can arise. In practice, there is often a bit of overlap amongst these concepts, or scope for differences of interpretation. Take a USB-A plug and socket (the big ones, of the several kinds of USB connectors). Suppose I want to connect up my digital camera to my laptop via a USB cable. I’m holding the USB plug. It looks like I can insert the plug into one of the USB sockets on my laptop. That’s an affordance. The socket affords insertion of the plug. However, there’s also a constraint in that the plug will go in only one way. Part of that constraint is readily visible: it’s clear that the plug will go in

• nly if its long dimension is lined up with the long dimension of the socket.

So, that much of the constraint could be seen as an affordance: The socket affords insertion only for a plug lined up that way. But part of the constraint 8

is invisible (or at least not readily visible): Not only must the plug be lined up, but it must be the right way up: it won’t go in upside down. Of course, if you look very closely at the plug and socket, you can see that they’ll fit together only one way. Or if you can see the USB logo on the plug (many are just embossed on black plastic so are very difficult to see), and the socket is mounted horizontally, and the socket is mounted right way up, then you know you can insert the plug with the USB logo on top. But this isn’t very

• bvious, nor very reliable. On my office machine, the front-panel USB sockets

are mounted upside down; so is the (smaller) USB-B socket on my digital camera mounted upside down. Clearly, there are degrees of affordance and constraint. On my MacBook Pro, I often mistakenly try to insert a USB plug into the “MagSafe” power socket or into the 400Mb Firewire port, since they are all mounted horizon- tally, and have similar shape, at least to a quick glance. I never have this problem with my older (Pismo) Powerbook: the power socket is a very dif- ferent shape (round), and while the USB and Firewire ports are the same, the USB ports are mounted horizontally and the Firewire ports are mounted vertically—which is possible because of the thicker case of the older ma-

• chine. There’s also the issue of grouping: On the Pismo, both USB ports are

grouped together; on the MacBook Pro, one USB port is on the left side of the case, next to the power socket, and the other is on the right side, next to the similar-shaped Firewire port. I mention in passing that this also illustrates how hardware design con- straints can affect (hardware) user-interface design: The thinner case phys- ically constraints all the sockets to be placed horizontally, removing one of the ways of differentiating them. Note, here “constraint” is being used in a different sense from constraints in user interfaces. There are also cultural considerations, which often escape notice. For example, that the last piece has to go in the last place, Norman classifies as a logical constraint. But there’s an implicit cultural consideration here in that we don’t expect the Lego company to include in the set pieces that aren’t needed. Natural Mapping

• Natural mapping between controls and effects
• E.g., position of light switches corresponds spatially with position of

lights

• E.g., Turning steering wheel to left makes car go to left

9

• E.g., Grouping of GUI controls by related function
• Mainly geometric, but other modalities possible

Notes For example, if you had a room with two ceiling lights at either end, it would be a natural mapping if the light switches were arranged horizontally on the switch panel so that the switch on each side of the panel controlled the light

• n that side of the room. The reverse arrangement, or arranging the switches

vertically, would not be a natural mapping. The arrangement of lift buttons in Figure 5 also shows a natural mapping: the vertical arrangement of the buttons corresponds to the actual height

• f the corresponding floors of the building. (This picture also has another

story to tell: The pattern of wear on the buttons reveals that people most

• ften travel between the ground and second floors, and that they often are

impatient because the doors close too slowly. Notice that each button, though labelled on the button itself, also has a non-button label next to it. This may seem redundant at first, but as the buttons in use are continually pushed, the labels actually on the buttons wear off, so the “redundant” labels become necessary. Still, it would have been a better design if the labels looked different from the buttons. First time I used this lift, intending to go to the second floor, like most people, I pushed the label “2”. I was looking for something that looked like a push-button associated with “2”. The “2” on the actual push-button had worn off, so the only thing visible with “2” on it was the passive label. It was only after stopping and analysing the situation that I deduced how the lift controls worked.) Visibility and Feedback

• visibility of possible actions
• visibility of state of system
• visibility of effects of actions (feedback)

– should be immediate and unambiguous

• mainly visual, but other modalities possible, e.g., sound, touch

Notes Notice here that Norman distinguishes three kinds of visibility; only the third is explicitly about feedback on user actions. However, they are all 10

Figure 5: Lift control buttons with a natural mapping. 11

• interlinked. User actions will affect the system state, so user feedback is in

a way just a special case of making the system state visible. However, it needs greater prominence, since it’s what the user is most interested in at the moment. The effect of user actions may be to change the set of currently possible actions. Visibility is problematic. A lot of the user-interface notions of visibility (and of selection) were developed when typical users dealt with at most a few dozen files at a time. It was feasible then to display them all (as icons) “on desktop”. Now users will often have tens of thousand of files stored locally, with the potential to access quickly millions more on the Web. These “classical” notions of making everything visible break down. Norman himself has addressed this very problem in later work. Nowadays we have to be much more clever and much more selective about visibility—to present to users what’s relevant to their current tasks. Feedback may be accidental rather than deliberate. The early Apple computers had quite noisy disk drives. So when users saved files, they got feedback that their files were being saved by hearing the noise of the disks. Even though their interface became unresponsive (no multi-threading), they knew from the disk noise that the computer was still working and hadn’t crashed (a more common occurrence in those days, with no memory mapping to protect the system from bad pointers in application code). Later on, when disk drives became quieter, this accidental feedback went away, and had to be replaced by more explicit feedback as part of the interface itself. Cultural Expectations

• light switches

– up is on, down is off versus up is off, down is on

• water taps

– hot on left or right? – clockwise or anticlockwise to turn off?

• Various “trash” and “mailbox” icons

Notes This is just to make the point that many aspects of user-interfaces are culturally dependent, and may vary from country to country. Mail programs may use some kind of mailbox icon. But what if the program’s icon looks 12

Figure 6: Which is the cold tap? nothing like any mailbox in my culture? We’ll look at this issue at greater depth later under the topic of internationalization. Even things that are so widespread as to be almost universal are still cul- turally dependent. Consider the various symbols used for “play”, “pause”, “fast forward”, “rewind”, etc., originally on audio tape decks and VCRs, now carried across into various software media players. Even though widely used, and in some ways suggestive of their meanings, they are still just arbitrary symbols, invested with their meanings by a (mostly) shared culture. They could easily have been different. Even today, there is variability in inter- pretation: On different media players I use, the “fast forward” symbol can variously mean: “playback faster”, “skip to next (DVD) chapter”, or “skip to next playlist item”. Causality

• How do you infer what causes what?
• People often assume that what happens immediately after an action is

caused by it.

• Probably correct most of the time, but can lead to imputing false

causality. 13

• E.g., start an unfamiliar application, and just then your computer

crashes. – Did the program cause the crash, or was it just coincidence?

• Can lead to superstitious behavior.

Notes Being able to infer causality is core business for any being (human, animal,

• r robot) that wants to get on in the world. We want to make things happen,

so we need to know the causes of those things (which we can control). One example of superstitious behavior is that many users always double- click in a web browser to follow a link. The origins of this behavior lie in a transfer effect (see below) from other contexts where you do need to double- click to make something happen. However, this behavior gets reinforced by the fact that it does work. It’s a bit more complicated than this. Originally with web browsers if you double-clicked on a link, the first click would cause the browser to follow the link. The second click would be queued up in the event queue while the browser fetched and rendered the new page. Then the second click would be processed with respect to this new page. If (as most of the time) the second click fell on some inactive part of the new page (just background or plain text), then nothing more would happen, and the user would be re- inforced in the idea that double-clicking follows the link. But if the second click by accident landed on a link in the new page, then that link would be immediately followed, going to a different page and confusing the user. Of course, since this sort of “mistaken” behavior got to be quite common, most browsers now handle it more intelligently, treating a double-click on a link the same as a single click. No surprises. Transfer Effects

• People transfer their learning and expectations to objects perceived to

be similar

• E.g.

– typewriter to computer – MacOSX: delete files by dragging them to the trash. But also to “eject” media.

• Cuts both ways, depending on how it’s used

14

– Can speed learning and be a source of helpful metaphors – Can lead to confusion and mistakes Notes One of the very early “word processing” programs I used closely modelled the behavior of a real, mechanical typewriter. The place where the characters appeared (as you typed) stayed fixed in the middle near the bottom of the

• screen. (There might even have been a simple animation of a typebar striking

the paper—too long ago to remember.) There was a graphic of a white sheet

• f paper that moved across the screen picking up the characters, in the same

way as a physical sheet of paper moved in a real typewriter. This may seem quaint nowadays. But in a time when most people would have been used to mechanical typewriters, having the “computer typewriter” behave in the same way would have been helpful (up to a point). In the real world we can get rid of objects by putting them in the rubbish

• bin. This is transferred to the computer desktop: we get rid of a file by

dragging its icon to the “trash” icon. In earlier versions of MacOS, this same action, of dragging to the trash, was also used for ejecting media like floppy

• disks. When you inserted a floppy disk in the drive, and it was mounted as

a filesystem, a floppy-disk icon would appear on the desktop. You had to drag this icon to the trash to unmount and eject the floppy disk. When I first started using MacOS, I found this quite alarming. Since dragging a file to the trash gets rid of it, it seemed to me that dragging a floppy-disk icon to the trash would somehow “get rid of” the disk, maybe erase or format it. This method still works in MacOSX, but with better feedback to solve the problem: When you start dragging something ejectable (like the icon of a DVD or flash drive), the trash icon changes into an “eject” icon—showing more clearly what is going to happen. Interplay There is an interplay between all these factors in good design:

• e.g., key in lock
• lock affords insertion of the key
• for many locks the key will fit in only one way up, and which way isn’t
• bvious
• one solution: increase visibility by distinctive design, e.g., T cross-

section key and lock 15

• another solution: symmetric design, key will fit either way up (like

most car keys)

• cultural factors in that we’re used to putting keys in locks

Notes Lying behind this is the more general principle that you can improve usabil- ity by removing unnecessary constraints or by making the constraints more

• bvious.

Some Design Guidelines

• Know your user
• Provide a good conceptual model
• Make things visible

– link intentions, actions, results – provide visible affordances, mappings, constraints Notes There are a few user interfaces, for example, web browsers, that end up being used by a very broad range of users. Such interfaces have to be layered and configurable so they can work across this range of users. Many user interfaces will be used by particular groups of users, and will work best if they are targeted at the specific needs of those users. To do this properly you need to know your users: who they are, what they do, how they work. Visibility, as mentioned above, is problematic. You can’t make everything visible: You need to make visible what’s most relevant to your users in performing their current tasks. Important Concepts Revisited

• Norman’s model of human task performance
• affordances
• constraints
• natural mapping

16

• visibility
• cultural expectations
• causality
• transfer effects
• mental models

2 Mental Models

Mental Models

• user’s mental model

– what “mental picture” the user has of the system

• system model

– how the system actually works: the designers’ mental model – unnecessarily inflicting system model on user is a common failing

• system image

– what the system presents to the user – may hide system model Notes How I interact with a computer system depends in part on what I can immediately see in the interface (in terms of visibility of actions, etc.), but it also depends greatly on how I think the system works, my mental model. Examples

• hot and cold water

– system model: separate controllable supplies of hot and cold water – user’s task: obtain desired flow of water at desired temperature – traditional two-tap user interface doesn’t hide system model – 2-dof single-lever supply provides a more usable system image ∗ up-down controls flow (which way?) 17

∗ left-right controls temperature (which way?)

• files and directories versus documents and folders
• color chooser: RGB numbers versus hue-saturation color wheel with

intensity slider/dial Notes I hope these examples make clearer the distinct concepts of system model, system image, and user’s mental model. A user’s mental model may be in- correct, in that it doesn’t match up properly with the system image. For example, since the water comes down out of the tap, a user might (reason- ably) think that you have to pull the lever down to get the water to come

• ut more. Some of these lever taps have little blue and red arrows on them

to indicate which direction the lever has to move (left or right) to get colder

• r hotter water. In some designs these arrows are reduced to dots. These

are ambiguous, and have led me to make the following mistake: The water comes out of the tap. To make the water cold, I have to move the lever so that the blue dot aligns with the tap (making the water flow cold). This, is the opposite of what I’m supposed to do. So in this case my mental model is incorrect—and it’s a failure of the interface design that it leads me to build an incorrect mental model. All these concepts are multilayered. The operating system provides files and directories. For our users, we might choose to provide a system image

• f documents and folders on top of the system model of files and directories.

But one level down, the files and directories are a system image on top of a deeper system model of disk blocks and index structures. Color Chooser See Figure 7. Notes The color choosers are shown here to emphasize the concepts system model, system image and user’s mental model. The system model is how the system actually works: that is, colors internally are almost certainly represented in RGB format (which is not really intuitive for most people). The three color- choser variations here show three different system images: color as RGB (which just happens to match the system model, but that’s fine); color as HSB (hue, saturation, brightness); and color as color circle and intensity. The user’s mental model is how the user thinks the system works. Put another way, the system image is the mental model the designers would like the user to have. 18

Figure 7: Color chooser. User’s Mental Model

• Can be static or dynamic—runnable
• runnable models are, in effect, internal simulations

– causality, sequencing Model Acquisition Users acquire mental models by:

• using the system
• being taught
• reading documentation
• observing other users
• transfer from similar systems or real-world domains

19

Models—Comments

• Difficult to infer what a user’s mental model is.
• Mental model guides user’s interaction.
• User’s mental model may be faulty.
• Design to help users acquire effective mental models.
• Take user’s mental model into account in walkthroughs:

– how mental model affects user’s selection of actions and interpre- tation of responses, – how interaction with system affects user’s mental model. Some Common Forms of Mental Model

• state-transition models
• object-action models
• mapping models
• analogies (metaphors)

State-transition models

• based on observed changes in system’s overall state
• e.g., telephone dialling

Object-action models

• users see system in terms of objects, their respective states and at-

tributes, causal relationships, and of actions that can be performed

• n the objects
• e.g., typical GUI desktop

20

Mapping models

• users know how to map intentions into “canned” action sequences
• e.g., :wq<return> in vi
• e.g., double-click, control-I to italicize a word
• e.g., common four-function calculator

– Few users model in terms of internal register transfers and flags and operations. Analogies (metaphors)

• e.g., ubiquitous desktop metaphor

Models and Interaction Styles Particular kinds of mental models tend to go hand in hand with particular interaction styles, e.g.

• object-action model with direct-manipulation interface
• state-transition model with function-key interface

Mixtures of Models Users may use mixtures of models, e.g.:

• state-transition model for an individual object in an overall object-

action model

• experienced users may use mapping model for speed in normal opera-

tion, then fall back on deeper model when things go wrong

3 Human Virtual Machine

Kinds of Theories Useful in Design

• explanatory theories

– e.g., turn-taking in conversations

• empirical laws

21

– e.g., Hick’s Law T = k log2(n + 1) for selecting from menus

• dynamic models

– e.g., KLM, Keystroke-Level Modelling – Fitts’s Law – May be partially empirical (e.g., values of model parameters) Keystroke-Level Modelling (KLM) Card et al. (1983)

Operator Description Typical time (seconds) K Press key or button 0.50 (0.08–1.2) P Point with mouse to target on display 1.10 H Home hand(s) on keyboard or

• ther device

0.40 M Mentally prepare 1.35 R(t) Response by system t

(Also line-segment drawing—rather specialized, not of such broad interest.) GOMS KLM is example of GOMS analysis (Goal, Operators, Methods, Selection rules) Goal What the user is trying to achieve

• e.g., set a certain word in bold text

Operators Basic operations available to user

• e.g., press a key, move (mouse) pointer

Methods Procedures, sequences of operators, for achieving a goal

• e.g., move mouse pointer to beginning of word press mouse button

move mouse pointer to end of word release mouse button [makes a selection] press keys of keyboard shortcut to bold text Selection rules Invoked to choose a method (assuming there are alterna- tives) 22

• e.g., make selection via key presses
• e.g., change to bold via menu
• How is choice made?

– fastest? – easiest? (least cognitive load) – least error-prone? GOMS analysis most applicable when choice of methods is limited. KLM Rules for Placing M Operators Rule 0. Insert Ms in front of all Ks that are not part of text or numeric argument strings proper (e.g., text or numbers). Place Ms in front of all Ps that select commands (not arguments). Rule 1. If an operator following an M is fully anticipated in an operator just previous to M, then delete the M (e.g., PMK gives PK). Rule 2. If a string of MKs belongs to a cognitive unit (e.g., the name of a command), then delete all Ms but the first. Rule 3. If a K is a redundant terminator (e.g., the terminator of a command immediately following the terminator of its argument), then delete the M in front of it. Rule 4. If a K terminates a constant string (e.g., a command name), then delete the M in front of it; but if the K terminates a variable string (e.g., an argument string) then keep the M in front of it. Human Information Processing Cycle Times Again, from Card et al. (1983) Subsystem Average Cycle Time Range Perceptual 100 50–200 Cognitive 70 25–170 Motor 70 30–100 Times are in milliseconds

• Note, typical neural firing time is 5–10ms.

23

Perceive/Think/Act Cycle

50−200ms Subsytem 30−100ms

Act Think Perceive

Cognitive Subsystem 25−170ms Perceptual Subsystem Motor

Fitts’s Law Derivation

• x0 – initial distance to cover, amplitude A
• x1 – remaining distance after first “move” (error)
• x2 – . . . after second “move”
• . . .

Fitts’s Law Derivation, comments

• Assume constant relative error,

xn xn−1 ≈ ǫ.

24

• Geometric sequence of errors.
• Want error to be less that half target width.
• Leads to logarithmic formula, number of steps, each assumed to take
• approx. constant cycle time.

Fitts’s Law Formulation

• Original formulation of Fitts’s Law (1954) is

Tpos = K log2(2A/W) where Tpos is the positioning time, A is the “amplitude” of the move- ment (distance), W is the width of the target, and K is an empirical constant, around 100 milliseconds, that accounts for the cycle time of human perceptual, cognitive, and motor subsystems.

• Empirically modified version (MacKenzie, 1992):

Tpos = K log2(A/W + 1) Implications of Fitts’s Law

• Closer is better

– pop-up menus at current position – menu ordering – pie-menus

• Bigger is better

– competition for screen real-estate – variable-size buttons – keyboard key sizes – non-uniform menus

• Roughly logarithmic dependency
• “Infinite” targets
• Screen-edge capture effects

25

Dashed Plain Double Arrow Custom Dbl Arrow Line Type

Figure 8: Pie menu. Exploratory Learning Learning how to use an unfamiliar system through exploration (Polson & Lewis, 1990) Goal setting Users start with a rough description of what they want to accomplish—a task. Exploration Users explore the system’s interface to discover actions useful in accomplishing their current task. Selection Users select actions that they think will accomplish their current task.

• Selection is often based on a match between what they are trying

to do and the interface’s description of actions. Assessment Users assess progress by trying to understand system response.

• Thus users decide whether the action they just performed was the

correct one, and to obtain clues for the next correct action. 26

Social and Organizational Issues in HCI

• People rarely perform a complex task in isolation,
• almost always in collaboration with other people.
• These interactions may not be formalized, may be overlooked, but can

be of great importance. Conceptual Design Heuristics

• Choose the mental model you intend the user to adopt.
• Link your choice of mental model to your choice of interaction style.
• Hide aspects of system model that conflict with user’s performance.
• Exploit the system image to convey the intended mental model.
• Ensure currency and consistency of system image.

27