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

Download HCI 510 : HCI Methods I HCI Methods. Some Random Stuff Cognitive Walkthroughs

Post on 19-Dec-2015




3 download

Embed Size (px)


  • Slide 1
  • HCI 510 : HCI Methods I HCI Methods
  • Slide 2
  • Some Random Stuff Cognitive Walkthroughs
  • Slide 3
  • HCI 510 : HCI Methods I Random Stuff Lets start today with an argument
  • Slide 4
  • Macs vs. PCs
  • Slide 5
  • Apple vs. OK and Cancel; or How Ill never learn to stop worrying about UI Design and love the Button, or lack of one.
  • Slide 6
  • 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.
  • Slide 7
  • 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.
  • Slide 8
  • 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.
  • Slide 9
  • Macs vs. PCs So ?
  • Slide 10
  • 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 doesnt say Are you sure you want to remove this e-mail It says:
  • Slide 11
  • 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'...
  • Slide 12
  • 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.
  • Slide 13
  • 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.
  • Slide 14
  • HCI 510 : HCI Methods I Random Stuff Knowledge Transfer
  • Slide 15
  • 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.
  • Slide 16
  • Knowledge Transfer
  • Slide 17
  • HCI 510 : HCI Methods I Random Stuff And some panty hose
  • Slide 18
  • 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).
  • Slide 19
  • 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."
  • Slide 20
  • 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.
  • Slide 21
  • 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.
  • Slide 22
  • 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.
  • Slide 23
  • HCI 510 : HCI Methods I Cognitive Walkthrough
  • Slide 24
  • Cognitive Walkthroughs Introduction Set Up Process Outputs Web Examples
  • Slide 25
  • Cognitive Walkthroughs Introduction Set Up Process Outputs Web Examples
  • Slide 26
  • Cognitive Walkthroughs HCI Influences : Users Tasks Users Experience Systems Interface C. Wharton, J. Rieman, C. Lewis and P. Polson, The Cognitive Walkthrough Method: A Practitioners Guide, in J. Nielsen and R. Mack (eds.), Usability Inspection Methods, John Wiley & Sons, Inc., New York, 1994, Ch. 5.
  • Slide 27
  • Cognitive Walkthroughs 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 users point of view. Such interfaces are called usable.
  • Slide 28
  • Cognitive Walkthroughs 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?
  • Slide 29
  • Cognitive Walkthroughs 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
  • Slide 30
  • Cognitive Walkthroughs 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


View more >