Designing User Interfaces Chapter 6 Squeak ObjectOriented Design

Two Challenges of UI y. How do you create user interface software that you can maintain well, that is truly objectoriented, and that is easy to change pieces without impacting everything? y. How do you create user interfaces that people can actually use? z. The latter is much harder and is what we focus on here y. Briefly! No substitute for a real HCI class 9/7/2021 Copyright 2000, Mark Guzdial 2

Story z Know thy users for they are not you y. Choosing between UI alternatives z Understanding the User and the Task y. Matching Users to Interface Techniques: Avoiding User Error y. Example: Critiquing our Clock Interface z A UI Design Process z Evaluating User Interfaces y. Before user involvement y. Evaluating with users and with groups 9/7/2021 Copyright 2000, Mark Guzdial 3

Know Thy Users for They are Not You z Most important thing to learn: You are almost never the user! y The user may not be anything like you y Making an interface that works for you may not work at all for your users x. Most users are not programmers z Most users have expertise, but not in computers y You probably don’t have their expertise! y They may think about things very different than you! z Particular important when deciding between options 9/7/2021 Copyright 2000, Mark Guzdial 4

How do you decide between interface alternatives? Clock. Morph Ch 5 Clock. UI 9/7/2021

What are our options? z Ask the users? y. They may have no idea—the task may never have been computerized before. z Pick the one you like? y. See two slides back. . . z Use a UI Design Process! y. Understand the user y. Understand the task y. Evaluate your UI options 9/7/2021 Copyright 2000, Mark Guzdial 6

Understanding the User z. What are their skills and limitations? z. What do they know how to do? z. What don’t they know how to do? z. Some important questions: y. How old is the typical user? y. What language is familiar to users about the task? y. What does the user want to do? 9/7/2021 Copyright 2000, Mark Guzdial 7

Example Important Questions z How old is the typical user? y Video games don’t rely on manuals for a reason y Aging of America vs. font size z What language is familiar to users about the task? y Some software attempts to teach physics using the word “gravity” before defining “gravity” y Order of operations, e. g. , data preparation z What does the user want to do? y What does the user already know? y “Stuffy noses” is an important symptom to a parent y “psuedophedrine hydrochloride” may be how a doctor wants to look up a remedy 9/7/2021 Copyright 2000, Mark Guzdial 8

Understanding the Task z Experts often can’t tell you what they do or how they do it y It’s part of expertise: Knowledge gets “compiled” z Investigate the context y When do you perform your task? y What do you need to perform your job? y Examples x. Airport traffic controllers can use windows easier than software x. Lawyers use boilerplate with sophisticated indexing y How often do you perform your task? x. Common, rare, only upon emergency 9/7/2021 Copyright 2000, Mark Guzdial 9

User Interface Techniques z Lots of options in user interfaces y. Buttons for selecting and toggling y. Checkboxes and radio buttons y. Text areas y. Direct manipulation: Drag-and-drop, drag-and-resize y. Menu selections y. Dialog boxes (modal) with buttons and fields y. Natural language y. Command languages like UNIX shell 9/7/2021 Copyright 2000, Mark Guzdial 10

Interactions between Techniques and User/Task Characteristics z Not all techniques work well with all users y Command languages are lousy for novices and infrequent users x. Icons and menus work better for them y Expert users love command languages, and are very efficient with them z Not all techniques work well for all tasks—but there is some dependency on users, too. y Direct manipulation is how most users want to draw simple figures—not command languages y But some users use command languages for complex figures (e. g. , Meta. Post, POV-Ray) y Users who generate fairly simple graphics (e. g. , graphs) frequently want command languages to automate task 9/7/2021 Copyright 2000, Mark Guzdial 11

Interactions are not always obvious! z In laboratory tests, shortcut keys are always slower than mousing! y Fitts Law governs how fast you can click on an object x. When mouse stops at the top of the screen, menus at the top became easier to hit (larger, in some sense) y Time delay between mousing and keyboard is swamped by time required to remember the keystroke z However, those are laboratory tests y Real experts know the keystrokes without remembering, but hard to find a control group for testing. 9/7/2021 Copyright 2000, Mark Guzdial 12

Rules of Thumb for Choosing Between UI Alternatives z Computers are good at remembering, people are not y Make knowledge visible! y Put the knowledge needed by the user in the world y. Avoid modes x. If you have to use modes, make them visible (unlike vi!) z Do what people expect—follow applicable guidelines and physical counterparts y Put the OK and Cancel buttons where expected z Goal: Avoid User Error—but Design Expecting Errors! 9/7/2021 Copyright 2000, Mark Guzdial 13

Example: Consider our Clock Interface z We are reasonable models of users here: We all use clocks z Tasks with clocks (most frequent to least frequent) y. Look at the time y. Look at the date (optional) y. For an alarm clock, set the alarm time y. Set the time (after a power outage, or before/after Daylight Savings Time) 9/7/2021 Copyright 2000, Mark Guzdial 14

Evaluating the Clock Interface for Tasks z. We can see the time (1/2 of display) z. Date and alarm irrelevant here z. But 1/2 of display (busiest part, the part that attracts our eye) is for the least common task 9/7/2021 Copyright 2000, Mark Guzdial 15

Evaluating the Clock Interface based on Rules of Thumb z “Make knowledge visible” y. How do you know when you clicked the button? y. How do you know if you successfully changed the time? z “Avoid user error” y. How easy is it to accidentally change the time? y. And that’s half the display? z Suggestion: The Clock Interface is optimized for error! 9/7/2021 Copyright 2000, Mark Guzdial 16

Brainstorm: Your Favorite Clock Designs z. What are your favorite interface designs for supporting the clock tasks? y. Tasks: Reading the time, setting the time y. Consider the different tasks of different contexts x. Your watch x. Your computer’s clock x. Kitchen watch and timer x. Your alarm clock 9/7/2021 Copyright 2000, Mark Guzdial 17

UI Design Process: Waterfall Method z Requirements specification y. Know the users and their tasks z Architectural design y. How should the UI provide the necessary functions z Detailed design y. Refine to details that a programmer can code z Coding and unit testing y. Build and test components as developed 9/7/2021 Copyright 2000, Mark Guzdial 18

UI Design Process: Waterfall Method (Part 2) z. Integration and testing y. Integrate the low-level components and test them z. Operation and maintenance y. Actually use the system and maintain it over time 9/7/2021 Copyright 2000, Mark Guzdial 19

Problem with Waterfall Method z. Users don’t know what they want y. If they’ve never had a widget like this, they don’t know how they’ll use it z. Worse, technology is a variable! y. Adding technology changes tasks and even users y. Original user and task analysis may no longer be valid once the technology is in place 9/7/2021 Copyright 2000, Mark Guzdial 20

Example: How Technology Gets Incorporated z A Small Matter of Programming by Bonnie Nardi (ethnographer, anthropologist) y. She studied how spreadsheets are used in real offices y. There are hierarchies of spreadsheet users x. Some just fill in others’ spreadsheets x. Others define spreadsheets for others x. Still others define the macros that spreadsheet-definers use x. Finally, there a few people who build low-level tools for the macro-builders 9/7/2021 Copyright 2000, Mark Guzdial 21

Example: How Technology Gets Incorporated (Part 2) z The Spreadsheet roles naturally develop and are stable (they don’t go away after a few weeks/months) z Smart companies build on these observations y. Reward people who play the spreadsheet and macro building roles y. If you want technology adopted, plant a farmer in the department to grow the roles z How would you design the interface to support the way that the users really use the software? 9/7/2021 Copyright 2000, Mark Guzdial 22

Alternative UI Design Process: Iterative Design and Prototype z Requirements gathering y. Again, study the users and their tasks y. Develop measurable usability goals x. Users will be able to do X in time Y z Build a prototype y. Plan on throwing (at least) one away! z Evaluate the prototype y. Test with real users against goals z Iterate until goals are met 9/7/2021 Copyright 2000, Mark Guzdial 23

Evaluation of User Interfaces z Now, you’ve got a user interface design y. You considered the users and the tasks y. You carefully matched UI techniques to users and tasks y. You think that this’ll work z How do you know if you got it right? y. Do you go to the trouble of coding it first? y. Is there anything you can do before hand? y. And once it is coded, how do you test it? 9/7/2021 Copyright 2000, Mark Guzdial 24

Evaluating Before User Involvement z Heuristic evaluation y Carefully analyzing a user interface in terms of a set of standard questions or issues y E. g. , “Is the necessary knowledge always visible? ” z Guidelines review y Using a standard for UI guidelines (e. g. , Apple, IBM, etc. ) determine if meets guidelines y E. g. , “Is the Cancel button always in the right place? ” z Cognitive walkthrough y. Will the system make sense to the user? 9/7/2021 Copyright 2000, Mark Guzdial 25

Sample Useful Heuristics z. Can the user figure out their current state? y. Is everything that the user needs to know about visible on the screen? z. Is the language on the screen in the language of the user (not the programmer)? z. Is help available? z. Are error messages useful? 9/7/2021 Copyright 2000, Mark Guzdial 26

Cognitive Walkthrough z Start out with a description of the system, the users’ goals, and a process description for a useful task z Walk the process description asking at each step: y. Does this make sense for this user? Will they understand it? y. Will the user be able to figure out what to do next? y. Will the users be able to understand the feedback that they get? x. If something goes wrong, can they tell? Can they figure out how to fix it? 9/7/2021 Copyright 2000, Mark Guzdial 27

Example: Netscape 2 z. Whether this interface works is dependent on user and task

Considering Users and Tasks z Intermediate user: “I want to find something on alligators” y Net Search button is evident z Advanced user: “I want to get to http: //www. slashdot. org” y Address field where you can type in an address y New Location menu item in File menu z Beginner (8 year old in Kitchen): “I want today’s weather” y. What would he click on? 9/7/2021 Copyright 2000, Mark Guzdial 29

“Will users understand feedback? ” z. What happens if I type “weather” in the

The Point is not to Pick on Netscape z Purposefully older version of Netscape y. Hopefully, newer versions are better z Heuristic evaluation can point out problems, just by thinking it through and trying it z It’s very hard to come up with a single interface that works for a variety of users and tasks! y. Consider Microsoft Word! 9/7/2021 Copyright 2000, Mark Guzdial 31

Evaluating with Users z In the end, you can never really be sure that your interface works until you face the users z It’s always better (less expensive!) to identify and correct errors earlier rather than later, so pre-user methods are useful z But real users have ways of interpreting things, doing things, and breaking things that you might never expect. x“Know they users for they are not you!” x. Examples: Stories from technical support 9/7/2021 Copyright 2000, Mark Guzdial 32

Deciding How to Evaluate with Users z. What do you want to learn? y. Note that you want to learn something! y. Goal: Can someone use my software? x. Can observe a small number of users y. Goal: Is my software better than X (X=competitor’s software, doing it by hand)? x. You need enough users to conduct a real experiment x. You need an experiment and control group x. Have them perform some standard set of tasks and measure time, accuracy, number of errors, etc. 9/7/2021 Copyright 2000, Mark Guzdial 33

Techniques for User Evaluation z Yogi Berra: “You can see a lot just by watching!” y. Observation can buy you a lot y. But is usually not enough: “Why are you doing that same error-generating thing over-and-over? !? ” z Think-alouds y. Get the users to say out loud what they’re seeing, what they’re doing, and why they’re doing it while they’re doing it 9/7/2021 Copyright 2000, Mark Guzdial 34

Right attitude in user evaluation helps a lot! z. Don’t treat it as just a test y. Nobody wants to feel like they’re being tested z. Treat the user as someone helping you make the software better—which they are! y. Makes the user feel better y. Also encourages more exploration, more freedom to critique, and more openness y“The problem isn’t me, it’s the software!” 9/7/2021 Copyright 2000, Mark Guzdial 35

What if you can’t observe? z Why wouldn’t you be able to observe? y. Natural use is probably not in a laboratory setting y. Your software may only work with lots of people using z Alternative: Questionnaire y. Phrase the questions to get at what you want—and what you don’t know yet y. Ask them what you should change and what you should leave alone 9/7/2021 Copyright 2000, Mark Guzdial 36

Designing questionnaires z Multiple choice and scalar questions (“on a scale of 1 to 5 where…”) are easier to analyze z Ask the same thing in multiple ways y. Determine inconsistencies that may identify confusion y. May find that there are subtleties you were missing earlier z Ask for volunteers for follow-up interviews 9/7/2021 Copyright 2000, Mark Guzdial 37

Evaluating Groupware z With the Web growth, more-and-more software designed for use in groups y. Consider an auction site as an example z But that’s especially hard to evaluate! y. Hard to reach the users y. Different users have different roles: Buyers, sellers, brokers, admins z Often, goals more than just usability y. Social agenda as well as usability agenda y. Do you want broad representation? 9/7/2021 Copyright 2000, Mark Guzdial 38

Log-file analysis for evaluating groupware z. If you can’t observe, get the software to do it for you! z. Record all the users’ actions in a file (with permission!) y. Analyze after the fact x. What errors occurred often? x. What were the common activities? z. Challenge: But what were they trying to do? !? 9/7/2021 Copyright 2000, Mark Guzdial 39

Summary z. Know thy users for they are not you! z. Knowing the user and task is first goal y. But note that technology can change that! z. Match UI to user and task! z. UI Design process: Waterfall and iterative z. UI Evaluation y. Before users, with groups 9/7/2021 Copyright 2000, Mark Guzdial 40