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, mostof 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

ActionSpecification

Execution

Intention

activity

physicalactivity

expectation

Figure 1: Donald Norman’s Model of Human Task Performance.

Norman’s Model of Task PerformanceSee Figure 1.

NotesThis 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 thegoal

• 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”.) Forexample, 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 stateof the world at this point, at least the relevant part, the Emacs window, isshown in Figure 2. (Emacs actually calls this a frame, reserving the termwindow for the viewports onto file buffers that a frame may contain. Whilethis is just at one level a peculiarity of Emacs terminology, at another level itmakes the point that different programs and interface toolkits may use termslike “window” and “frame” with different meanings. So beware.)

Then I form the intention to do something to save the file. Next I haveto decide on (specify) what action to perform. Suppose I decide to clickwith the mouse on the colored floppy-disk icon in the Emacs toolbar. (HowI make this decision we’ll consider later.) Then I actually have to go aheadand perform that action. That action has an effect on the world: the patternof colors and shapes in the Emacs window changes. See Figure 3. I have toperceive those changes (at the lowest level of perception); and then interpretthem: 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 evaluatewhether (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 combinationof what actions I can see that the interface offers and what I know aboutthe interface (my mental model—see later). In general, for an unfamiliarinterface I’ll have to depend mainly on what visible options the interfacepresents to me; for a familiar interface I can make more use of my specificknowledge 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 toremove 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 spawnsubgoals. For example, my goal might be to fit a note I’m writing onto oneprinted page (it’s slightly too long). I could achieve that top-level goal byachieving any one of the three subgoals: reword the text of the note, orchange the font size, or change the page layout (e.g., narrower margins). InAI 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 oneafter another until one succeeds. In other situations, the subgoals might beconnected under an AND node, that is, all the subgoals have to be achievedin 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 aWYSIWYG (“What you see is what you get.”) system, then checking thatmy actions succeeded in achieving my goal (fitting the note on one page),may require setting up a subgoal of previewing or printing the note. Orin 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 forwhich 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 changedsince Figure 2? What does it mean for the achievement of my goal?

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

– Easily visible and interpretable feedback on effect of actions

• E.g., I clicked on the “save” menu item. How do I know that mydocument actually got saved?

• The smaller the gulf the better.

NotesThe Gulf of Execution and Gulf of Evaluation are two aspects of users’

interaction with an interface. The Gulf of Execution is about the difficultyusers have in deciding what to do, which action to try. The Gulf of Evaluationis about the difficulty that users have in deciding whether the action theytook did in fact have the intended effect.

Note that these two gulfs are not processes; they refer to the gap (ineach case) between what the user wants and what the interface provides. Onthe execution side, an interface that makes visible what actions it providesand makes it easy for users to choose the correct action has a small Gulf ofExecution—and that’s good. An interface for which it’s difficult for users tochoose 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 feedbackso that they can easily know whether the action they chose had the intendedeffect has a small Gulf of Evaluation—and that’s good. If users don’t getgood feedback about what effect their action had, then that interface has alarge 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.

NotesAs 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 beused.

For example, I want to pick up a suitcase. I look at it and see that ithas a handle that looks suitable for grasping and picking the suitcase. Thehandle is an affordance for picking up the suitcase.

For example, I come up to a door, which I want to open. The door has apush-plate on it, which suggests that I open this door by pushing.

Figure 4 shows an example of what Norman was thinking about in theabove quote. Here the door has a two-word instruction manual: “PUSH” onone 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 theneed 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 thedoor in the dark, and reached out and felt that it had a push-plate, thenthat would still suggest that I could open the door by pushing, even thoughI 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 beused by an organism (whether visible or not). Norman changed the meaningto require visibility, which is how it’s generally used in HCI. As well as beingused 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 constructionexample

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 ofconstraints

• 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 limitson 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 successfullywithout reading the instructions, and without even seeing a picture of whatthe final assembly looks like. He attributes this to the constraints inherentin the Lego set, which normally permit only one (reasonable) way of puttingthe 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 reasoningabout their meaning or use. For example, the purpose of the windscreenis 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 theworld-wide convention for motor vehicles is that the tail light is red.Therefore this block, representing the tail light, should go at the rearof the motorcycle.

Logical Some parts can be placed by logical reasoning: For example, ifthere’s only one part remaining, then it has to go in last availableposition.

It’s best not to take this list of constraint types as being definitive. Thatis, don’t feel that every interface constraint you encounter has to fit exactlyinto one of these categories. Think of Norman’s classification as illustratingsome of the different ways in which constraints can arise.

In practice, there is often a bit of overlap amongst these concepts, orscope for differences of interpretation. Take a USB-A plug and socket (thebig ones, of the several kinds of USB connectors). Suppose I want to connectup my digital camera to my laptop via a USB cable. I’m holding the USBplug. It looks like I can insert the plug into one of the USB sockets onmy 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 inonly 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 socketaffords 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 linedup, 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 fittogether only one way. Or if you can see the USB logo on the plug (manyare just embossed on black plastic so are very difficult to see), and the socketis mounted horizontally, and the socket is mounted right way up, then youknow you can insert the plug with the USB logo on top. But this isn’t veryobvious, nor very reliable. On my office machine, the front-panel USB socketsare mounted upside down; so is the (smaller) USB-B socket on my digitalcamera mounted upside down.

Clearly, there are degrees of affordance and constraint. On my MacBookPro, I often mistakenly try to insert a USB plug into the “MagSafe” powersocket 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 thisproblem 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 mountedvertically—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 aregrouped together; on the MacBook Pro, one USB port is on the left side ofthe case, next to the power socket, and the other is on the right side, nextto 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 ofthe ways of differentiating them. Note, here “constraint” is being used in adifferent sense from constraints in user interfaces.

There are also cultural considerations, which often escape notice. Forexample, that the last piece has to go in the last place, Norman classifiesas a logical constraint. But there’s an implicit cultural consideration herein that we don’t expect the Lego company to include in the set pieces thataren’t needed.

Natural Mapping

• Natural mapping between controls and effects

• E.g., position of light switches corresponds spatially with position oflights

• 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 wouldbe a natural mapping if the light switches were arranged horizontally on theswitch panel so that the switch on each side of the panel controlled the lighton that side of the room. The reverse arrangement, or arranging the switchesvertically, 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 heightof the corresponding floors of the building. (This picture also has anotherstory to tell: The pattern of wear on the buttons reveals that people mostoften travel between the ground and second floors, and that they often areimpatient because the doors close too slowly. Notice that each button, thoughlabelled on the button itself, also has a non-button label next to it. This mayseem redundant at first, but as the buttons in use are continually pushed, thelabels actually on the buttons wear off, so the “redundant” labels becomenecessary. Still, it would have been a better design if the labels lookeddifferent from the buttons. First time I used this lift, intending to go tothe second floor, like most people, I pushed the label “2”. I was looking forsomething that looked like a push-button associated with “2”. The “2” onthe actual push-button had worn off, so the only thing visible with “2” on itwas the passive label. It was only after stopping and analysing the situationthat 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 thethird 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 ina way just a special case of making the system state visible. However, itneeds greater prominence, since it’s what the user is most interested in atthe moment. The effect of user actions may be to change the set of currentlypossible 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 afew 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 storedlocally, with the potential to access quickly millions more on the Web. These“classical” notions of making everything visible break down. Norman himselfhas addressed this very problem in later work. Nowadays we have to be muchmore clever and much more selective about visibility—to present to userswhat’s relevant to their current tasks.

Feedback may be accidental rather than deliberate. The early Applecomputers had quite noisy disk drives. So when users saved files, they gotfeedback that their files were being saved by hearing the noise of the disks.Even though their interface became unresponsive (no multi-threading), theyknew from the disk noise that the computer was still working and hadn’tcrashed (a more common occurrence in those days, with no memory mappingto protect the system from bad pointers in application code). Later on, whendisk drives became quieter, this accidental feedback went away, and had tobe 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 areculturally dependent, and may vary from country to country. Mail programsmay 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 greaterdepth 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, nowcarried across into various software media players. Even though widely used,and in some ways suggestive of their meanings, they are still just arbitrarysymbols, invested with their meanings by a (mostly) shared culture. Theycould easily have been different. Even today, there is variability in inter-pretation: On different media players I use, the “fast forward” symbol canvariously mean: “playback faster”, “skip to next (DVD) chapter”, or “skipto next playlist item”.

Causality

• How do you infer what causes what?

• People often assume that what happens immediately after an action iscaused by it.

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

13

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

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

• Can lead to superstitious behavior.

NotesBeing able to infer causality is core business for any being (human, animal,or 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 atransfer effect (see below) from other contexts where you do need to double-click to make something happen. However, this behavior gets reinforced bythe fact that it does work.

It’s a bit more complicated than this. Originally with web browsers ifyou double-clicked on a link, the first click would cause the browser to followthe link. The second click would be queued up in the event queue while thebrowser fetched and rendered the new page. Then the second click wouldbe processed with respect to this new page. If (as most of the time) thesecond click fell on some inactive part of the new page (just background orplain 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 secondclick by accident landed on a link in the new page, then that link would beimmediately followed, going to a different page and confusing the user. Ofcourse, since this sort of “mistaken” behavior got to be quite common, mostbrowsers now handle it more intelligently, treating a double-click on a linkthe same as a single click. No surprises.

Transfer Effects

• People transfer their learning and expectations to objects perceived tobe 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 modelledthe behavior of a real, mechanical typewriter. The place where the charactersappeared (as you typed) stayed fixed in the middle near the bottom of thescreen. (There might even have been a simple animation of a typebar strikingthe paper—too long ago to remember.) There was a graphic of a white sheetof paper that moved across the screen picking up the characters, in the sameway as a physical sheet of paper moved in a real typewriter. This may seemquaint nowadays. But in a time when most people would have been usedto mechanical typewriters, having the “computer typewriter” behave in thesame way would have been helpful (up to a point).

In the real world we can get rid of objects by putting them in the rubbishbin. This is transferred to the computer desktop: we get rid of a file bydragging its icon to the “trash” icon. In earlier versions of MacOS, this sameaction, of dragging to the trash, was also used for ejecting media like floppydisks. When you inserted a floppy disk in the drive, and it was mounted asa filesystem, a floppy-disk icon would appear on the desktop. You had todrag this icon to the trash to unmount and eject the floppy disk. When Ifirst started using MacOS, I found this quite alarming. Since dragging a fileto the trash gets rid of it, it seemed to me that dragging a floppy-disk iconto 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 theproblem: When you start dragging something ejectable (like the icon of aDVD or flash drive), the trash icon changes into an “eject” icon—showingmore clearly what is going to happen.

InterplayThere 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’tobvious

• 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 (likemost 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 moreobvious.

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 upbeing used by a very broad range of users. Such interfaces have to be layeredand configurable so they can work across this range of users.

Many user interfaces will be used by particular groups of users, and willwork best if they are targeted at the specific needs of those users. To do thisproperly you need to know your users: who they are, what they do, how theywork.

Visibility, as mentioned above, is problematic. You can’t make everythingvisible: You need to make visible what’s most relevant to your users inperforming 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

NotesHow 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.), butit 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 withintensity slider/dial

NotesI 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. Forexample, 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 comeout more. Some of these lever taps have little blue and red arrows on themto indicate which direction the lever has to move (left or right) to get colderor hotter water. In some designs these arrows are reduced to dots. Theseare ambiguous, and have led me to make the following mistake: The watercomes out of the tap. To make the water cold, I have to move the lever sothat the blue dot aligns with the tap (making the water flow cold). This, isthe opposite of what I’m supposed to do. So in this case my mental model isincorrect—and it’s a failure of the interface design that it leads me to buildan incorrect mental model.

All these concepts are multilayered. The operating system provides filesand directories. For our users, we might choose to provide a system imageof 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 adeeper system model of disk blocks and index structures.

Color ChooserSee Figure 7.

NotesThe color choosers are shown here to emphasize the concepts system model,system image and user’s mental model. The system model is how the systemactually works: that is, colors internally are almost certainly represented inRGB 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 asHSB (hue, saturation, brightness); and color as color circle and intensity. Theuser’s mental model is how the user thinks the system works. Put anotherway, the system image is the mental model the designers would like the userto 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 performedon 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 flagsand operations.

Analogies (metaphors)

• e.g., ubiquitous desktop metaphor

Models and Interaction StylesParticular 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 ModelsUsers 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

display1.10

H Home hand(s) on keyboard orother device

0.40

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

(Also line-segment drawing—rather specialized, not of such broad interest.)

GOMSKLM 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 buttonmove mouse pointer to end of word release mouse button [makesa 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 numericargument strings proper (e.g., text or numbers). Place Ms in front ofall Ps that select commands (not arguments).

Rule 1. If an operator following an M is fully anticipated in an operatorjust 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 acommand), then delete all Ms but the first.

Rule 3. If a K is a redundant terminator (e.g., the terminator of a commandimmediately following the terminator of its argument), then delete theM in front of it.

Rule 4. If a K terminates a constant string (e.g., a command name), thendelete 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 TimesAgain, from Card et al. (1983)

Subsystem Average Cycle Time RangePerceptual 100 50–200Cognitive 70 25–170Motor 70 30–100

Times are in milliseconds

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

23

Perceive/Think/Act Cycle

50−200ms

Subsytem30−100ms

Act

Think

Perceive

CognitiveSubsystem25−170ms

PerceptualSubsystem

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 takeapprox. 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 empiricalconstant, around 100 milliseconds, that accounts for the cycle time ofhuman 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

DblArrow

LineType

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 toaccomplish—a task.

Exploration Users explore the system’s interface to discover actions usefulin accomplishing their current task.

Selection Users select actions that they think will accomplish their currenttask.

• Selection is often based on a match between what they are tryingto 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 thecorrect 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 canbe 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