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
9/19/00 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
9/19/00 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
9/19/00 Copyright 2000, Mark Guzdial 4

How do you decide between
interface alternatives?
ClockMorph
Ch5 ClockUI
9/19/00 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
9/19/00 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?
9/19/00 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
9/19/00 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
9/19/00 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
9/19/00 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
9/19/00 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.
9/19/00 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!
9/19/00 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)
9/19/00 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 common task
9/19/00 Copyright 2000, Mark Guzdial 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!
9/19/00 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
9/19/00 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
9/19/00 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
9/19/00 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
9/19/00 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
9/19/00 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?
9/19/00 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
9/19/00 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?
9/19/00 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?
9/19/00 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?
9/19/00 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?
9/19/00 Copyright 2000, Mark Guzdial 27

Example: Netscape 2
❚ Whether this interface works is dependent
on user and task
9/19/00 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?
9/19/00 Copyright 2000, Mark Guzdial 29

“Will users understand
feedback?”
❚ What happens if I type “weather” in the
address field?
9/19/00 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!
9/19/00 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 breakingthings that you might
never expect.
❘
❘
“Know they users for they are not you!”
Examples: Stories from technical support
9/19/00 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.
9/19/00 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
9/19/00 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!”
9/19/00 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
9/19/00 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
9/19/00 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?
9/19/00 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?!?
9/19/00 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
9/19/00 Copyright 2000, Mark Guzdial 40