Transcript Designing User Interfaces

Designing User Interfaces
Chapter 6
Squeak: Object-Oriented
Design with Multimedia
Applications
Two Challenges of UI
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?
How do you create user interfaces that
people can actually use?
The latter is much harder and is what we
focus on here
Briefly! No substitute for a real HCI class
7/17/2015
Copyright 2000, Mark Guzdial
2
Story
Know thy users for they are not you
Choosing between UI alternatives
Understanding the User and the Task
Matching Users to Interface Techniques:
Avoiding User Error
Example: Critiquing our Clock Interface
A UI Design Process
Evaluating User Interfaces
Before user involvement
Evaluating with users and with groups
7/17/2015
Copyright 2000, Mark Guzdial
3
Know Thy Users for They are Not
You
 Most important thing to learn: You are almost never the
user!
The user may not be anything like you
Making an interface that works for you may not work at all for
your users
Most users are not programmers
 Most users have expertise, but not in computers
You probably don’t have their expertise!
They may think about things very different than you!
 Particular important when deciding between options
7/17/2015
Copyright 2000, Mark Guzdial
4
How do you decide between
interface alternatives?
ClockMorph
Ch5 ClockUI
7/17/2015
Copyright 2000, Mark Guzdial
5
What are our options?
Ask the users?
They may have no idea—the task may never have
been computerized before.
Pick the one you like?
See two slides back...
Use a UI Design Process!
Understand the user
Understand the task
Evaluate your UI options
7/17/2015
Copyright 2000, Mark Guzdial
6
Understanding the User
What are their skills and limitations?
What do they know how to do?
What don’t they know how to do?
Some important questions:
How old is the typical user?
What language is familiar to users about the
task?
What does the user want to do?
7/17/2015
Copyright 2000, Mark Guzdial
7
Example Important Questions
 How old is the typical user?
Video games don’t rely on manuals for a reason
Aging of America vs. font size
 What language is familiar to users about the task?
Some software attempts to teach physics using the word
“gravity” before defining “gravity”
Order of operations, e.g., data preparation
 What does the user want to do?
What does the user already know?
“Stuffy noses” is an important symptom to a parent
“psuedophedrine hydrochloride” may be how a doctor wants to
look up a remedy
7/17/2015
Copyright 2000, Mark Guzdial
8
Understanding the Task
 Experts often can’t tell you what they do or how they do
it
It’s part of expertise: Knowledge gets “compiled”
 Investigate the context
When do you perform your task?
What do you need to perform your job?
Examples
Airport traffic controllers can use windows easier than software
Lawyers use boilerplate with sophisticated indexing
How often do you perform your task?
Common, rare, only upon emergency
7/17/2015
Copyright 2000, Mark Guzdial
9
User Interface Techniques
Lots of options in user interfaces
Buttons for selecting and toggling
Checkboxes and radio buttons
Text areas
Direct manipulation: Drag-and-drop, drag-and-resize
Menu selections
Dialog boxes (modal) with buttons and fields
Natural language
Command languages like UNIX shell
7/17/2015
Copyright 2000, Mark Guzdial
10
Interactions between Techniques
and User/Task Characteristics
 Not all techniques work well with all users
 Command languages are lousy for novices and infrequent users
Icons and menus work better for them
 Expert users love command languages, and are very efficient with them
 Not all techniques work well for all tasks—but there is some
dependency on users, too.
 Direct manipulation is how most users want to draw simple figures—not
command languages
 But some users use command languages for complex figures (e.g.,
MetaPost, POV-Ray)
 Users who generate fairly simple graphics (e.g., graphs) frequently
want command languages to automate task
7/17/2015
Copyright 2000, Mark Guzdial
11
Interactions are not
always obvious!
In laboratory tests, shortcut keys are always
slower than mousing!
Fitts Law governs how fast you can click on an object
When mouse stops at the top of the screen, menus at the
top became easier to hit (larger, in some sense)
Time delay between mousing and keyboard is swamped by time
required to remember the keystroke
However, those are laboratory tests
Real experts know the keystrokes without remembering, but
hard to find a control group for testing.
7/17/2015
Copyright 2000, Mark Guzdial
12
Choosing Between UI
Alternatives
 Computers are good at remembering, people are not
Make knowledge visible!
Put the knowledge needed by the user in the world
Avoid modes
If you have to use modes, make them visible (unlike vi!)
 Do what people expect—follow applicable guidelines
and physical counterparts
Put the OK and Cancel buttons where expected
Goal: Avoid User Error—but Design Expecting
Errors!
7/17/2015
Copyright 2000, Mark Guzdial
13
Example: Consider our
Clock Interface
We are reasonable models of users here:
We all use clocks
Tasks with clocks (most frequent to least
frequent)
Look at the time
Look at the date (optional)
For an alarm clock, set the alarm time
Set the time (after a power outage, or
before/after Daylight Savings Time)
7/17/2015
Copyright 2000, Mark Guzdial
14
Evaluating the Clock
Interface for Tasks
We can see the
time (1/2 of display)
Date and alarm
irrelevant here
But 1/2 of display
(busiest part, the
part that attracts
our eye) is for the
least commonCopyright
task2000, Mark Guzdial
7/17/2015
15
Evaluating the Clock Interface based
on Rules of Thumb
“Make knowledge visible”
How do you know when you clicked the button?
How do you know if you successfully changed the
time?
“Avoid user error”
How easy is it to accidentally change the time?
And that’s half the display?
Suggestion: The Clock Interface is optimized for
error!
7/17/2015
Copyright 2000, Mark Guzdial
16
Brainstorm: Your Favorite
Clock Designs
What are your favorite interface designs
for supporting the clock tasks?
Tasks: Reading the time, setting the time
Consider the different tasks of different
contexts
Your watch
Your clock’s computer
Kitchen watch and timer
7/17/2015
Copyright 2000, Mark Guzdial
17
UI Design Process:
Waterfall Method
Requirements specification
Know the users and their tasks
Architectural design
How should the UI provide the necessary functions
Detailed design
Refine to details that a programmer can code
Coding and unit testing
Build and test components as develop
7/17/2015
Copyright 2000, Mark Guzdial
18
UI Design Process:
Waterfall Method (Part 2)
Integration and testing
Integrate the low-level components and test
them
Operation and maintenance
Actually use the system and maintain it over
time
7/17/2015
Copyright 2000, Mark Guzdial
19
Problem with Waterfall
Method
Users don’t know what they want
If they’ve never had a widget like this, they
don’t know how they’ll use it
Worse, technology is a variable!
Adding technology changes tasks and even
users
Original user and task analysis may no
longer be valid once the technology is in
place
7/17/2015
Copyright 2000, Mark Guzdial
20
Example: How Technology
Gets Incorporated
 A Small Matter of Programming by Bonnie Nardi
(ethnographer, anthropologist)
She studied how spreadsheets are used in real offices
There are hierarchies of spreadsheet users
Some just fill in others’ spreadsheets
Others define spreadsheets for others
Still others define the macros that spreadsheet-definers use
Finally, there are a few people who build low-level tools for the
macro-builders
7/17/2015
Copyright 2000, Mark Guzdial
21
Example: How Technology
Gets Incorporated (Part 2)
The Spreadsheet roles naturally develop and
are stable (they don’t go away after a few
weeks/months)
Smart companies build on these observations
Reward people who play the spreadsheet and macro
building roles
If you want technology adopted, plant a farmer in the
department to grow the roles
How would you design the interface to support
the way that the users really use the software?
7/17/2015
Copyright 2000, Mark Guzdial
22
Alternative UI Design Process:
Iterative Design and Prototype
Requirements gathering
Again, study the users and their tasks
Develop measurable usability goals
Users will be able to do X in time Y
Build a prototype
Plan on throwing one away!
Evaluate the prototype
Test with real users against goals
Iterate until goals are met
7/17/2015
Copyright 2000, Mark Guzdial
23
Evaluation of User
Interfaces
Now, you’ve got a user interface design
You considered the users and the tasks
You carefully matched UI techniques to users and
tasks
You think that this’ll work
How do you know if you got it right?
Do you go to the trouble of coding it first?
Is there anything you can do before hand?
And once it is coded, how do you test it?
7/17/2015
Copyright 2000, Mark Guzdial
24
Evaluating Before User
Involvement
Heuristic evaluation
Carefully analyzing a user interface in terms of a set of standard
questions or issues
E.g., “Is the necessary knowledge always visible?”
Guidelines review
Using a standard for UI guidelines (e.g., Apple, IBM, etc.)
determine if meets guidelines
E.g., “Is the Cancel button always in the right place?”
Cognitive walkthrough
Will the system make sense to the user?
7/17/2015
Copyright 2000, Mark Guzdial
25
Sample Useful Heuristics
Can the user figure out their current state?
Is everything that the user needs to know
about visible on the screen?
Is the language on the screen in the
language of the user (not the
programmer)?
Is help available?
Are error messages useful?
7/17/2015
Copyright 2000, Mark Guzdial
26
Cognitive Walkthrough
 Start out with a description of the system, the user, the
users’ goals, and a process description for a useful task
Walk the process description asking at each
step:
Does this make sense for this user? Will they understand it?
Will the user be able to figure out what to do next?
Will the users be able to understand the feedback that they get?
If something goes wrong, can they tell? Can they figure out
how to fix it?
7/17/2015
Copyright 2000, Mark Guzdial
27
Example: Netscape 2
Whether this interface works is dependent
on user and task
7/17/2015
Copyright 2000, Mark Guzdial
28
Considering Users and
Tasks
 Intermediate user: “I want to find something on
alligators”
Net Search button is evident
 Advanced user: “I want to get to http://www.slashdot.org”
Address field where you can type in an address
New Location menu item in File menu
 Beginner (8 year old in Kitchen): “I want today’s
weather”
What would he click on?
7/17/2015
Copyright 2000, Mark Guzdial
29
“Will users understand
feedback?”
What happens if I type “weather” in the
address field?
7/17/2015
Copyright 2000, Mark Guzdial
30
The Point is not to Pick on
Netscape
Purposefully older version of Netscape
Hopefully, newer versions are better
Heuristic evaluation can point out problems, just
by thinking it through and trying it
It’s very hard to come up with a single interface
that works for a variety of users and tasks!
Consider Microsoft Word!
7/17/2015
Copyright 2000, Mark Guzdial
31
Evaluating with Users
In the end, you can never really be sure that
your interface works until you face the users
It’s always better (less expensive!) to identify
and correct errors earlier rather than later, so
pre-user methods are useful
But real users have ways of interpreting things,
doing things, and breaking things that you might
never expect.
“Know they users for they are not you!”
Examples: Stories from technical support
7/17/2015
Copyright 2000, Mark Guzdial
32
Deciding How to Evaluate
with Users
What do you want to learn?
Goal: Can someone use my software?
Can observe a small number of users
Goal: Is my software better than X
(X=competitor’s software, doing it by hand)?
You need enough users to conduct a real experiment
You need an experiment and control group
Have them perform some standard set of tasks and
measure time, accuracy, number of errors, etc.
7/17/2015
Copyright 2000, Mark Guzdial
33
Techniques for User
Evaluation
Yogi Berra: “You can see a lot just by watching!”
Observation can buy you a lot
But is usually not enough: “Why are you doing that
same error-generating thing over-and-over?!?”
Think-alouds
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
7/17/2015
Copyright 2000, Mark Guzdial
34
Right attitude in user
evaluation helps alot!
Don’t treat it as just a test
Nobody wants to feel like they’re being
tested
Treat the user as someone helping you
make the software better—which they are!
Makes the user feel better
Also encourages more exploration, more
freedom to critique, and more openness
“The problem isn’t me, it’s the software!”
7/17/2015
Copyright 2000, Mark Guzdial
35
What if you can’t observe?
Why wouldn’t you be able to observe?
Natural use is probably not in a laboratory setting
Your software may only work with lots of people using
Alternative: Questionnaire
Phrase the questions to get at what you want—and
what you don’t know yet
Ask them what you should change and what you
should leave alone
7/17/2015
Copyright 2000, Mark Guzdial
36
Designing questionnaires
Multiple choice and scalar questions (“on
a scale of 1 to 5 where…”) are easier to
analyze
Ask the same thing in multiple ways
Determine inconsistencies that may identify
confusion
May find that there are subtleties you were
missing earlier
Ask for volunteers for follow-up interviews
7/17/2015
Copyright 2000, Mark Guzdial
37
Evaluating Groupware
With the Web growth, more-and-more software
designed for use in groups
Consider an auction site as an example
But that’s especially hard to evaluate!
Hard to reach the users
Different users have different roles: Buyers, sellers,
brokers, admins
Often, goals more than just usability
Social agenda as well as usability agenda
Do you want broad representation?
7/17/2015
Copyright 2000, Mark Guzdial
38
Log-file analysis for
evaluating groupware
If you can’t observe, get the software to
do it for you!
Record all the users’ actions in a file (with
permission!)
Analyze after the fact
What errors occurred often?
What were the common activities?
Challenge: But what were they trying to
do?!?
7/17/2015
Copyright 2000, Mark Guzdial
39
Summary
Know thy users for they are not you!
Knowing the user and task is first goal
But note that technology can change that!
Match UI to user and task!
UI Design process: Waterfall and iterative
UI Evaluation
Before users, with users, with groups
7/17/2015
Copyright 2000, Mark Guzdial
40