hci 510 : hci methods i hci methods. some random stuff cognitive walkthroughs

HCI 510 : HCI Methods I• HCI Methods

HCI Methods

• Some Random Stuff

• Cognitive Walkthroughs

HCI 510 : HCI Methods I• Random Stuff

Let’s start today with an argument

Macs vs. PCs

Macs vs. PCs

Apple vs. OK and Cancel; or “How I’ll never learn to stop worrying about UI Design and love the Button, or lack of one.”

Macs vs. PCs

This question is brought to you by an argument I had today with a developer I work with -- an argument that will surely continue in the coming weeks until our latest project is released -- about the presence of OK and Cancel buttons in dialog-boxes.

We both have a long history of using and developing in Windows and Linux, but 6 months ago a MacBook Pro became my main workhorse.

One of the most striking things I discovered was the apparent lack of buttons that "dismiss" or "apply changes" in a dialog-box in OS X -- even in parts of an application that perform non-trivial tasks.

Macs vs. PCs

One of the best places to see the distinction is in the OS configuration pages:

1. In Windows Control Panel and Linux equivalents -- with few exceptions -- every single icon you double-click leads you to a dialog-box with an OK, Cancel, and oftentimes an Apply button. If you're not, you're led to a second page of icons that will.

2. In OS X System Preferences -- with one exception (Network) -- not one of the default configuration pages offer such buttons. Sure, you can "Show all" or press the back-button in the window-shade; but neither of these perform "OK" or "Cancel" behaviours -- the changes you make in the widgets of those dialogs are applied as soon as you manipulate them.

Macs vs. PCs

Similar behaviours can be found in dialogs all over OS X.

Interestingly, the only default Apple app where "Preferences..." has both OK and Cancel is iTunes -- which is also the only Apple app that has a Windows equivalent.

It seems that, unless the user finds themselves in a place that's sure to break their Mac, Apple UI designers just "don't do" buttons in dialog-boxes.

Needless to say, after 6 months of basking in the Steve Jobs Reality Distortion Field such curiosities are influencing my work. I end up arguing with the back-end designer about why my front-end doesn't have buttons in its dialog-boxes, and I confess I'm having difficulty in arguing the point without sounding evangelical about it.

Macs vs. PCs

So ?

Macs vs. PCs

Best Answer :

* For Windows apps keep using Ok/Cancel* For OSX apps don't use it

For the rest of the world: Never use warning when you mean undo

For instance :

Gmail doesn’t say “Are you sure you want to remove this e-mail”

It says:

Macs vs. PCs

Second Answer :

Simple:

The best UI behavior is the one that the end user expects

If you use OSX long enough, you will come to expect things to work that way as opposed to the traditional OK,Cancel,Apply way.

This isn't a question of what is best, only what does the user's intuition expect.

Personally, I am all for experimentation and challenging the norms with UI behaviour, providing it is based on concrete usability tests and unguided usage monitoring.

That just leads back to 'what is intuitive' and 'can change be implemented that goes against expectation but the user gets used to' ...

Macs vs. PCs

Third Answer :

Consistency.

Choose one way and stick with it, even if you go the wrong way for the given environment, there's nothing more confusing than mixed set of both behaviors for N different dialogs. This really is the most important rule, as long as it works the same every time the experience is always superior to it working differently every time.

Imagine if the pedals in everyone's car were in a different order because they couldn't decide on which was "best". Imagine now that it changes based on which direction your car is facing... that's what using an inconsistent system feels like.

Macs vs. PCs

Fourth Answer :

The reason Mac OS X avoids OK/Cancel buttons in dialog boxes is because they are redundant. If I've just changed the name of my Fizzbar by editing a text field, why do I have to confirm that change again by pressing a button?

You're a programmer: you understand you are changing stuff on a form and it won't be "committed" to the app until you approve the changes. But not everybody has that same mental model.

Also, if you have a window with an OK/Cancel button and a close button, you wind up with some uncertainty about what the close button does: will it act as "OK" and save my changes or will it "Cancel" them? You can avoid that by disabling the close button, but now you've gotten rid of a consistent way to dismiss a window.

In the end, the Mac convention is about keeping things as simple as possible for the user (fewer needless choices of buttons to press), even if it makes it slightly harder to implement.


Knowledge Transfer

Knowledge Transfer

Of the various attempts to delineate transfer, typological and taxonomic approaches belong to the more common ones.

Taxonomies are concerned with distinguishing different types of transfer, and are as such less involved with labeling the actual vehicle of transfer, i.e., what is the explanatory mental unit of transfer that is carried over.

Hence, a key problem with many transfer taxonomiesy is that they offer an excessive number of labels for different types of transfer without really engaging in a discussion of the underlying concepts that would justify their distinction, i.e., similarity and the nature of transferred information. This makes it very difficult to appreciate the internal validity of the models.

Knowledge Transfer


And some panty hose

Panty Hose

Panty hose

Nisbett and Wilson set up a market survey table outside a big shopping center and asked people to say which of three pairs of panty hose they preferred, and why.

(Nisbett, R.E., and Wilson, T.D. "Telling more than we can know: Verbal reports on mental processes." Psychological Review, 84 (1977), pp. 231-259).

Panty Hose

Panty hose

Most people picked the rightmost pair of the three, giving the kinds of reasons you'd expect: "I think this pair is sheerer" or "I think this pair is better made."

Panty Hose

Panty hose

Most people picked the rightmost pair of the three, giving the kinds of reasons you'd expect: "I think this pair is sheerer" or "I think this pair is better made."

The trick is that the three pairs of panty hose were IDENTICAL.

Panty Hose

Panty hose

Nisbett and Wilson knew that given a choice among three closely- matched alternatives there is a bias to pick the last one, and that that bias was the real basis for people's choices.

But (of course) nobody SAID that's why they chose the pair they chose.

It's not just that people couldn't report their real reasons: when asked they made up reasons that seemed plausible but are wrong.

Panty Hose

Data Collection

What do this (and other) studies say about the usability data you collect?

You won't always hear why people did what they did, or didn't do what they didn't do.

Some portion of what you do hear will be wrong.

And, you're especially taking a risk if you ask people specific questions: they'll give you some kind of an answer, but it may have nothing to do with the facts.

Don't treat the comments you get as some kind of gospel.

Instead, use them as input to your own judgment processes.

HCI 510 : HCI Methods I• Cognitive Walkthrough

Cognitive Walkthroughs

• Introduction

• Set Up

• Process

• Outputs

• Web Examples


HCI Influences :

• Users’ Tasks• Users’ Experience• System’s Interface

C. Wharton, J. Rieman, C. Lewis and P. Polson, The Cognitive Walkthrough Method: A Practitioner’s Guide, in J. Nielsen and R. Mack (eds.), Usability Inspection Methods, John Wiley & Sons, Inc., New York, 1994, Ch. 5 .


• For an interface to be a success, it must provide the right functionality, at the right time, in the right place, and in the right form from the user’s point of view.

• Such interfaces are called usable.


if we are designing an ATM, we should be able to justify each user action:

– Insert card?– Enter PIN?– Press Quick Cash key?– Press Okay?– Remove card?– Remove money?– Remove receipt?


The cognitive walkthrough is a way to test the usability of interactive software.

The cognitive walkthrough focuses on

– Task(s)– Interface– Learnability (one kind of usability)

The cognitive walkthrough may be used

– without “real” uses– before a system is implemented– with prototypes or mockups


History

The method was developed in the early nineties by Wharton, et al., and reached a large usability audience when it was published as a chapter in Jakob Nielsen's seminal book on usability, "Usability Inspection Methods."

The Wharton, et al. method required asking four questions at each step, along with extensive documentation of the analysis.

In 2000 there was a resurgence in interest in the method in response to a CHI paper by Spencer who described modifications to the method to make it effective in a real software development setting.

Spencer's paper followed the example set by Rowley, et al. who described the modifications to the method that they made based on their experience applying the methods in their 1992 CHI paper "The Cognitive Jogthrough".


The origin of the cognitive walkthrough approach to evaluation is the code walkthrough familiar in software engineering.

Walkthroughs require a detailed review of a sequence of actions.

In the code walkthrough, the sequence represents a segment of the program code that is stepped through by the reviewers to check certain characteristics (e.g., that coding style is adhered to, conventions for spelling variables versus procedure calls, and to check that system wide invariants are not violated).


In the cognitive walkthrough, the sequence of actions refers to the steps that an interface will require a user to perform in order to accomplish some task.

The evaluators then step through that action sequence to check it for potential usability problems.

Usually, the main focus of the cognitive walkthrough is to establish how easy a system is to learn.


More specifically, the focus is on learning through exploration.

Experience shows that many users prefer to learn how to use a system by exploring its functionality hands on, and not after sufficient training or examination of a user's manual.

So the kinds of checks that are made during the walkthrough ask questions that address this exploratory kind of learning.

To do this, the evaluators go through each step in the task and provide a story about why that step is or is not good for a new user.


Definition

Cognitive walkthrough is a review technique where expert evaluators construct task scenarios from a specification or early prototype and then role play the part of a user working with that interface--"walking through" the interface.

They act as if the interface was actually built and they (in the role of a typical user) was working through the tasks.

Each step the user would take is scrutinized: impasses where the interface blocks the "user" from completing the task indicate that the interface is missing something.

Convoluted, circuitous paths through function sequences indicate that the interface needs a new function that simplifies the task and collapses the function sequence.


Example

Begin by evaluating a system specification in terms of the tasks users will perform with that system.

It helps to identify the user's goals and purpose for each task. car, this might be a large issue.

For example, the interface for operating a car


Example

The interface for operating a car begins with the goals of opening the door, sitting down in the driver's seat with the controls easily accessible, and starting the car.

And we're not even driving yet!

This example shows the granularity that some walkthroughs attain.


Example

The goal of "opening the door" could be broken down into sub-goals: find the key, orient the key, unlock the door, open the door.

Each of these goals requires cognitive (thinking) and physical actions.

To open the door, do I orient my hand with the palm up or with the palm down? What affordances are provided for opening the door?


Example

During the walkthrough, identify problems in attaining the goals.

For example, some car doors accept keys only if they're oriented one way.

Does this cause an unacceptable delay for the user?

Since the sub-goal of opening the door is a prerequisite to operating the car, this might be a large issue.


• Introduction

• Set Up

• Process

• Outputs

• Web Examples


Defining the Input to the Walkthrough

* Who will be the users of the system?

* What task(s) will be analyzed?

* What is the correct action sequence for each task?

* How is the interface defined?



Who will be the users of the system?

This should include specific background experience or technical knowledge that could influence users as they attempt to deal with a new interface.

The users' knowledge of the task and of the interface should both be considered.

An example user description is "Macintosh users who have worked with MacPaint".



What task(s) will be analyzed?

In general, the system should be limited to a reasonable but representative collection of benchmark tasks.

Task selection should be based on the results of marketing studies, needs analysis, concept testing, and requirements analyses.



What is the correct action sequence for each task?

For each task, there must be a description of how the user is expected to view the task before learning the interface.

There must also be a description of the sequence of actions that should accomplish the task with the current definition of the interface.

Example actions are: "press the RETURN key", "move cursor to 'File' menu".

It can also be a sequence of several simple actions that a typical user could execute as a block, such as, "Select 'Save' from 'File' menu".



How is the interface defined?

The definition of the interface must describe the prompts preceding every action required to accomplish the tasks being analyzed, as well as the reaction of the interface to each of these actions.

If the interface has been implemented, all information is available from the implementation.

Earlier in the development process, the evaluation can be performed with a paper description of the interface.


• Introduction

• Set Up– iTunes

• Process

• Outputs

• Web Examples

HCI 510 : HCI Methods I• Cognitive Walkthrough - iTunes

http://www.youtube.com/watch?v=P72XbgQ-Z_k&feature=related

http://www.youtube.com/watch?v=Ro77wQq0sWo


• Introduction

• Set Up

• Process

• Outputs

• Web Examples


Who Performs the Walkthrough

The walkthrough is typically performed by the interface designer and a group of his or her peers.

Small-scale walkthroughs of parts of an interface can also be done by individual designers as they consider alternative designs.

In a group situation, one of the evaluators usually takes on the duties of "scribe," recording the results of the evaluation as it proceeds, and another group member acts as facilitator, to keep the evaluation moving.


Process

• Define the inputs to the walkthrough.

• Convene the analysis.

• Walk through the action sequences for each task.

• Record critical information.

• Revise the interface to fix the problems.


Define the inputs to the walkthrough.

– Identification of the users.– Sample tasks for evaluation.– Description (mockups) or implementation of the interface.– Action sequences (scenarios) for completing the tasks.

• Convene the walkthrough.

– The facilitator maintains the pace of the discussion.– A scribe keeps two lists:

» problems (and suggested solutions)» assumptions (about tasks and users’ experience)– The participates walk through (discuss) the tasks with respect to the interface (mockups) and action sequences (scenarios); they try to tell a credible story.


The participants walk through (discuss) the tasks withrespect to the interface (mockups) and action sequences (scenarios); they try to tell a credible story.

– What is the user trying to achieve at this point? >> What’s their goal ?>> Why is it their goal ?

– What actions are obviously available in the interface ?– Does the label for the correct action match the user’s goal ?– If the user performs the correct action, will they get good feedbackand not try to undo or redo the action?


Record critical information.

– The credible success (or failure) story.– Assumptions (about tasks and users’ experience).– Problems (and suggested solutions)

Revise the interface to fix the problems.


Process Summary : Ask the following questions …

A. Will the users be trying to produce whatever effect the action has?

Are the assumptions about what task the action is supporting correct given the user's experience and knowledge up to this point in the interaction?

B. Will users be able to notice that the correct action is available?

Will users see the button or menu item, for example, that is how the next action is actually achieved by the system? This is not asking whether they will know that the button is the one they want. This is merely asking whether it is visible to them at the time when they will need to invoke it. An example of a negative score might be if a VCR remote control has a hidden panel of buttons that are not obvious to a new user.

C. Once users find the correct action at the interface, will they know that it is the right one for the effect they are trying to produce?

This complements the previous question. It is one thing for a button or menu item to be visible, but will the user's know that it is the one they are looking for to complete their task?

D. After the action is taken, will users understand the feedback they get?

Assuming the users did the correct action, will they know that. This is the completion of the execution/evaluation interaction cycle. In order to determine if they have accomplished their goal, the user needs appropriate feedback.


Process Summary : Ask the following questions …

C. Once users find the correct action at the interface, will they know that it is the right one for the effect they are trying to produce?

This complements the previous question. It is one thing for a button or menu item to be visible, but will the user's know that it is the one they are looking for to complete their task?

D. After the action, will users understand the feedback they get?

Assuming the users did the correct action, will they know that. This is the completion of the execution/evaluation interaction cycle. In order to determine if they have accomplished their goal, the user needs feedback.


• Introduction

• Set Up

• Process

• Outputs

• Web Examples


Common Features of Success

Users may know "what effect to achieve":

* Because it is part of their original task, or * Because they have experience using a system, or * Because the system tells them to do it

Users may know "an action is available":

* By experience, or * By seeing some device (like a button) or * By seeing a representation of an action (line a menu entry)


Common Features of Success

Users may know "an action is appropriate" for the effect they are trying to achieve:

* By experience, or * Because the interface provides a prompt or label that connects the action to what they are trying to do, or * Because all other actions look wrong

Users may know "things are going OK" after an action:

* By experience, or * By recognizing a connection between a system response and what they were trying to do


Recent Research

Recent experimental work has provided support for the theoretical assumptions underlying the cognitive walkthrough method.

New users of display-based (GUI) applications employ a strategy of first scanning the interface for a well-labeled action, and then quickly narrowing their search by selecting that action.

If further options are displayed as a result, the scan-search cycle will be continued until the guiding goal has been accomplished.


Recent Research

Certain design features determine whether an action will "pop out" at a first-time user.

(1) Subjects will try label-guided actions first (menu items, buttons, etc.) before they experiment with direct manipulations of unlabeled objects (tools, double clicking, moving of objects).

(2) A well-labeled action will be especially salient. (3) Providing few actions in the search set can help to narrow the search if

labeling cannot be provided, or if criteria for a "good" label are difficult to establish.

(4) Set effects may prevent users to try untypical actions. (5) Users are reluctant to extend their search beyond the readily available

menus and controls.


Documentation

It is vital to document the cognitive walkthrough to keep a record of what is good and what needs improvement in the design.

It is therefore good to produce some standard evaluation forms for the walkthrough.

For each action, a separate standard form is filled out that answers each of the questions described previously :

A. Will the users be trying to produce whatever effect the action has?B. Will users be able to notice that the correct action is available?C. Once users find the correct action at the interface, will they know that it is the right

one for the effect they are trying to produce?D. After the action, will users understand the feedback they get?


Accessibility

An accessibility walkthrough follows procedure similar to the cognitive walkthrough described above, with the difference that the user has one of a number of disabilities such as low vision, blindness, impaired hearing, motor control limitations, or cognitive issues.

In an accessibility walkthrough, the main consideration is how these limitations affect the use of websites or software.

For example: blind persons and some persons with limited motor control need keyboard-only operation; some persons with cognitive issues need visuals that reinforce text; persons with low vision must enlarge page content; deaf people require video captioning and visual, rather than auditory, prompts. You also must consider the assistive technology the user will use.


• Introduction

• Set Up

• Process

• Outputs

• Web Examples


http://www.ics.uci.edu/~redmiles/ics104-WQ06/Chapter_4/CognitiveWalkthroughRev2006.pdf



Exploring an “Intuitive” but Incorrect Action Sequence


http://www.lisaedelman.com/Group11Reportv6.pdfa

Palm Pilot

Date Book



We have provided several related design changes to the Palm Pilot Date Book application. One of these is to unify the various existing ways of creating events, making it easier for both experienced and novice users. We also found numerous heuristic violations in the process of setting the time-of-day for a particular event and propose a suite of design changes to facilitate this process.

In addition, we noticed during our contextual inquiry a need forthe ability to view weekly recurring appointments, and have extended the Date Book to provide that functionality.

These and other design ideas are discussed in the pages that follow. We present our design changes in the form of a scenario, followed by a retrospective on the various methods that inspired this redesign.


Let’s Do It For Real

HCI 510 : HCI Methods I• Cognitive Walkthrough

hci 510 : hci methods i hci methods. some random stuff cognitive walkthroughs

Documents

argument slide

pcs best answer

hci methods

presence of ok

pcs similar behaviours

windows apps

apple ui designers

best ui behavior