Cooper Part II
Well-Behaved Products
Etiquette, Posture, and Intermediates
Jeff Offutt
http://www.cs.gmu.edu/~offutt/
SWE 632
User Interface Design and Development
Cooper Ed4, Ch 8—10
Outline
1. Digital Etiquette (ch 8)
2. Platform and Posture (ch 9)
3. Optimizing for Intermediates (ch 10)
1 July 2016
© Jeff Offutt, 2004-2014
2
•
Ch 8 : Digital Etiquette
People respond to computer user interfaces as if they
are sentient beings
–
–
•
This is not hard …
–
–
•
We should make our software considerate, likeable, supportive
What does the human need ?
But being considerate takes more time than being inconsiderate
Inconsiderate people think they are being efficient …but many
of their colleagues think they’re self-centered, curt, and cryptic
Remember that the software is there to help the user,
not the other way around
People should think,
computers should work
1-Jul-16
© Jeff Offutt, 2004-2014
3
Making Software Considerate
• Take an interest
– Considerate people ask what you like once, then remember
– Google map, firefox, …
– PPT never remembers my print or file saving preferences
• Considerate products are deferential
– Give users choices, not orders
– Never judge users—don’t tell users they’re wrong, tell them the
software doesn’t understand
• Considerate products are forthcoming
– Give users related information that might help them
– Suggest possible words on misspellings
Software should behave like a
considerate human
1-Jul-16
© Jeff Offutt, 2004-2014
4
Making Software Considerate
• Considerate products use common sense
(cont’d)
– Put controls in logical places
– A considerate program would never think I want my class roster
for the next semester
• Considerate products anticipate human needs
– Operating systems “pre-fetch” sectors that are near the last
sector we read … why don’t web browsers do the same ?
• Considerate products are conscientious
– Consider the broader goal
– When copying a file with the same name—let me merge, show
me the differences, rename the old file, or simply overwrite
– When printing color ppt to a black-and-white printer, should
automatically change to “pure black and white”
1-Jul-16
© Jeff Offutt, 2004-2014
5
Making Software Considerate
• Considerate products don’t burden you with their
personal problems
(cont’d)
– A receptionist who complains about her schedule is annoying
– Software should not :
• Tell us it successfully saved …
• Whine about a full recycle bin …
• Tell us it cannot render some weird fonts …
– Take care of your own stuff !
• Considerate products keep us informed
–
–
–
–
–
1-Jul-16
Tell users about what matters to the users
What can I do next ?
How do I complete my order ?
How do I quit ?
How can I change something later ?
© Jeff Offutt, 2004-2014
6
Making Software Considerate
• Considerate products are perceptive
(cont’d)
– If I check my roster in the morning, then I log into the system
that afternoon, shouldn’t it automatically tell me if anybody
added or dropped the class since my last check ?
– If I resize adobe reader to use the full height of my screen and be
just wide enough to fit a document … shouldn’t it open the
window with that size next time ?
– When I print with “Adobe PDF” in PPT, I always choose
“Handouts”, “Pure Black and White” and “Slides per page” = 2 ...
PPT should notice and remember
• Considerate products are self-confident
– “are you sure ?” just gets in the way … on the other hand, the
software should provide an “undelete”
1-Jul-16
© Jeff Offutt, 2004-2014
7
Making Software Considerate
• Considerate software does not ask questions
(cont’d)
– Give users choices, not questions
– Don’t offer choices nobody ever wants
– Don’t offer choices whose consequences are not clear
• “are you sure you want to quit? (yes, no, cancel)”
• What does cancel do ?
– About once a week I shut down my computer and go to bed …
the next morning when I look at my computer I find a dialog box
“something is still open, should I shut down?” … when I say
“yes,” then it shuts down, wasting time as well as electricity
• Considerate products fail gracefully
– When you fail, apologize and try to fix it (kindergarten lesson)
– Don’t throw away data when crashing …
– If I fill out 10 form fields and get one wrong, keep the data from
the other 9
1-Jul-16
© Jeff Offutt, 2004-2014
8
An Inconsiderate Question
•
•
•
•
•
•
•
•
1-Jul-16
Uhmmmm …. I didn’t change anything …
All I did was print !
Did I accidentally change something else ?
Did I make a change and forget ?
Why are you bothering me ?
Are you stupid or am I ?
What does “Cancel” do ?
Mommy ! Help !
© Jeff Offutt, 2004-2014
9
Making Software Considerate
• Considerate products know when to bend rules
(cont’d)
– To reimburse a visitor for a trip, we have to create a record
• Need a G-number, which needs a social security number !
• The automated system is stupid enough to check that the SSN is valid ...
– Allow users to complete part of the process today and come
back later to finish
• Binary logic : yes/no, true/false, done/not done
• Trinary logic : yes/no/maybe, true/false/possibly, done/not done/started …
– In real life, we never get the rules right
• We need some way to allow for when the rules don’t quite fit
• Considerate products take responsibility
– Software should understand hardware and deal with them
– When my printer runs out of paper, my computer tells me
“could not print” … so I fill the printer up and print again …
then the printer finishes my first print and happily prints my
second copy!
1-Jul-16
© Jeff Offutt, 2004-2014
10
Designing Smart Products
• This section makes some interesting general points, but
few specific actionable suggestions ( research agenda? )
• Smart products take care of users
– They don’t behave intelligently
• Smart products are proactive, not just reactive
– Most computers spend > 90% of their time doing … nothing
– Use the time to look for files the user might need
– Cooper spends several paragraphs complaining that computers
don’t use spare cycles to help the users, but does not offer any
other concrete suggestions
1-Jul-16
© Jeff Offutt, 2004-2014
11
Designing Smart Products
• Smart products have a memory : A way to track and use
actions that users take over multiple sessions
– Remember previous preferences and choices
– “Dynamic defaults” resets defaults based on the user’s past
history
– It’s easier for programmers to let the UI ask the user what to do
each time – it’s easier for users if the UI remembers
• What should a program remember ? EVERYTHING !
– Disk space is now not a problem for saving information – save
everything !
– My TA emails me the same file at least once a week and I put it
in the same place every time … yet every time, my mail client
asks me where to put it … can you imagine an assistant acting
that stupidly ?
1-Jul-16
© Jeff Offutt, 2004-2014
12
Memory—Auto-customization
• Remember what the user did the last time
• Avoid unnecessary questions
• Imagine a secretary that asked you every time whether
you wanted copies on front and back!
• Dialog boxes ask questions, buttons offer choices
1-Jul-16
© Jeff Offutt, 2004-2014
13
Auto-customization Examples
• MS Word : I always put my files in C:\offutt
But MS Word always thinks I’m going to open a file in C:\Program
Files\ …
(took me years to find the customization!)
• PPT : I often print “Handouts”, “2”, “Pure black and
white”
If I print several PPT files in a row, I have to click all three
boxes every time!
• ATM : I usually withdraw $150.
Why does the ATM always use $40 and $60 as defaults?
1-Jul-16
© Jeff Offutt, 2004-2014
14
Designing Smart Products
• Task coherence : Our goals and how we achieve them is
usually similar from day to day
–
–
–
–
Similar usage patterns in software
Often the same document, or documents in the same directory
Why should I tell Word to full justify paragraphs … every time ?
Why should my phone keep asking “did you say …” when I say
“yes” … every time ?
– Applications should remember how big they were and where
they were on-screen
– If a user goes through the same sequence of commands several
times – the application should automatically create a macro
If it’s worth the user’s time, it’s worth
the software’s time to remember
1-Jul-16
© Jeff Offutt, 2004-2014
15
Outline
1. Digital Etiquette (ch 8)
2. Platform and Posture (ch 9)
3. Optimizing for Intermediates (ch 10)
1 July 2016
© Jeff Offutt, 2004-2014
16
Ch 9 : Posture
Posture
The way the program appears to users
Platform
Type of computer
Desktop, web apps, mobile, …
Posture depends heavily on the platform
1-Jul-16
© Jeff Offutt, 2004-2014
17
Posture for the Desktop
1) Sovereign
– Only program running, user’s complete attention, full screen
– Editors, spreadsheets, games, browsers (usually)
– Experienced users—optimize for speed and power
2) Transient
–
–
–
–
Invoked when needed, does something, goes away
Scanning a picture, file manager, email, music players
Intermittent users—clear instructions, less screen, larger widgets
Avoid dialog boxes and remember state from last use
3) Daemonic
–
–
–
–
1-Jul-16
Services that do not interact with the user
Printer & network drivers, compilers
Try not to bother users unless absolutely necessary
Include configuration panels, but simple and streamlined
© Jeff Offutt, 2004-2014
18
Posture for the Web
• HTML supports a very limited widget set
– Javascript can be used to create many more widgets, but that is
relatively complicated
– This is becoming more common
• On the other hand, it takes fewer technical skills to
implement a GUI front-end with HTML than with other
technologies
• Complex, multi-screen transactional applications are just
as hard, and perhaps harder, to develop
• HTML provides greater separation between engineers,
GUI designers, and graphics designers
Some Web-specific usability points …
1-Jul-16
© Jeff Offutt, 2004-2014
19
1. Sovereign
–
–
–
–
Web App Usability
Make users feel they are in an environment, not web pages
Design as if desktop applications
Emphasize interaction, not navigation
Hide request / response cycle
2. Transient
– Quick occasional access to information or functions (login)
– Small, simple, non-intrusive
3. Internet-enabled
– Uses internet, but not from inside a browser
– Java applets, tools, music players
– Can access disk and have controls HTML does not support
1-Jul-16
© Jeff Offutt, 2004-2014
20
Posture for Mobile Devices
• Very small screen and keyboard
– Help users with the fat finger problem
• Avoid huge hierarchical menus that are very confusing
– All functions are equally difficult to find
– But some are more commonly used
•
•
•
•
•
•
Make it easy to synchronize with full computer
UI designer needs to specify the buttons on the hardware
Function bloat : who uses all that junk?
No pop-up or dialog windows
Avoid dragging
Controls should be large and bright
1-Jul-16
© Jeff Offutt, 2004-2014
21
Mobile Postures
• Satellite (PDAs, palm pilots, kindle, …)
– Allows part of our desktop environment to go mobile
– Periodically synchronize with the mother ship (desktop or the web)
– Emphasizes viewing and retrieving data
• Standalone (phones)
– Small, complete “pocket” computers
– Full interaction, but small screens, text, and controls
– Often mimic desktop applications but with reduced functionality
• Tablet
– Same restrictions as standalone, but less severe
– Mostly only allow sovereign applications (full-screen)
1-Jul-16
© Jeff Offutt, 2004-2014
22
ATMs and Kiosks
• These are publicly accessible computers with specialized
applications
• Consider the environment:
– Lighting, noise, privacy, security
– The ATM in Johnson Center blocks foot traffic
• Kiosks are infrequently used
• Consider the main uses
– Transactions : provide a service (ATM, tickets, self-checkout)
– Exploration : present information (museums)
• No dragging, scrolling, or on-screen keyboards
Optimize for first-time users
1-Jul-16
© Jeff Offutt, 2004-2014
23
Designing for Embedded Systems
• Embedded software is integrated into a device that is not
primarily for computing
– Phones, PDAs, remotes, ATMs, TVs, appliances, cars, planes, …
• The input / output devices are often much different
– Often much more constrained in abilities
• Designing the UI is very different from designing UIs for
desktop applications
–
–
–
–
–
1-Jul-16
Don’t think of the product as a computer
Coordinate UI design with hardware design
External environment will affect the UI
Should use many fewer modes
Navigation is harder and should be reduced
© Jeff Offutt, 2004-2014
24
Posture Summary
Don’t design everything like a sovereign
Effective UI designers must know their users
1-Jul-16
© Jeff Offutt, 2004-2014
25
Outline
1. Digital Etiquette (ch 8)
2. Platform and Posture (ch 9)
3. Optimizing for Intermediates (ch 10)
1 July 2016
© Jeff Offutt, 2004-2014
26
Ch 10 : Design for Intermediates
• Designers are usually experts
– They view all functions as having equal weight
• Marketing want UIs designed for beginners
– They sell to beginners
– Many have only novice semantic knowledge
• Most users are in between—intermediates !
Don’t weld on training wheels
1-Jul-16
© Jeff Offutt, 2004-2014
27
Distribution of Users
Beginners
What does the
application do?
Intermediates
What doesn’t it
do?
Where is it?
How do I print?
Where do I start?
Forgot how
Remind me …
Can I undo?
More features?
Experts
Automate?
Shortcuts?
Can I change?
Customize?
Keyboard
shortcut?
Dangerous?
1-Jul-16
© Jeff Offutt, 2004-2014
28
Most Users are Intermediates
• Beginners are incompetent—and nobody likes that
– They either move up or move on
• Experts often move on
– Or use it less and become intermediates
Optimize for intermediates
1-Jul-16
© Jeff Offutt, 2004-2014
29
Inflecting the Interface
• Inflecting means organizing the UI to minimize the most
common navigation
– Most commonly used functions up front
– Less frequently used functions can be on the back shelf
• Choose defaults for intermediates
– Microwaves : Make the “timed cook option” an easy default
• Very valuable functions can be harder to reach
– Slide animation features are deeper than font changing
– Google mail is default, google drive is further in
Users will make a strong effort if the
rewards justify it
1-Jul-16
© Jeff Offutt, 2004-2014
30
Progressive Disclosure
• Advanced controls are hidden in an expanding pane
– PPT – drawing palette – bottom right arrow
– Google mail, hover over “Starred” to get other folders
• Criteria for organizing :
– Frequency of use—how often “typical” users use the functions
– Degree of dislocation—how much the screen and UI changes
when the choice is made
– Degree of risk exposure—functions that are irreversible or
dangerous
• Remember that advanced users will eventually want
shortcuts to some of these functions
– And their frequency of use may change
1-Jul-16
© Jeff Offutt, 2004-2014
31
What Beginners Need
•
•
•
•
Help beginners become intermediates
They want actions, not theory
They want examples, not definitions
Match their mental models to
– Reduce errors
– Hasten learning
• Extra help must disappear for intermediate users
Imagine users are very intelligent but
very busy
1-Jul-16
© Jeff Offutt, 2004-2014
32
What Experts Need
• Remember the experts are often more vocal and
influential in who uses your product
– Beginners listen to experts (even when they should listen to
intermediates)
•
•
•
•
Experts want shortcuts to everything
Experts are often also frequent users
Experts want higher information density
Experts will adopt new features quickly
1-Jul-16
© Jeff Offutt, 2004-2014
33
What Intermediates Need
• Mostly, they need attention!
– Far too many products are designed for beginners or experts,
rather than the majority of users
• They need :
– Fast access to common functions
– Reference materials—online help (or the interweb)
– Knowledge that advanced functions are available, but not yet
necessary
• They do not need :
– Long explanations
When making tradeoffs, intermediate
users should usually have priority
1-Jul-16
© Jeff Offutt, 2004-2014
34
Summary : Three Powerful Basics
1. Be polite
2. Think about how you present yourself
3. Optimize for the intermediate majority
Remember to think about
the users and you’ll be fine
1-Jul-16
© Jeff Offutt, 2004-2014
35