Cooper Part III
Interaction Details
Design Details: Controls and Dialogs
Jeff Offutt
http://www.cs.gmu.edu/~offutt/
SWE 632
User Interface Design and Development
Cooper Ed4, Ch 21
Outline
1. Controls
2. Dialogs
3. Eliminating Errors, Alerts, and Confirmations
4. The Devil Is in the Details
1 July 2016
© Jeff Offutt, 2004-2014
2
Controls (also: Widgets)
•
Controls are objects on the screen that communicate
between users and software
Four types of controls
•
1.
2.
3.
4.
•
Imperative controls : used to initiate a function
Selection controls : used to select options or data
Entry controls : used to enter data
Display controls : used to visually manipulate the program
We see a limited set of controls
– Windows and Mac use only a fraction of the invented controls
– HTML implements very few GUI controls
1 July 2016
© Jeff Offutt, 2004-2014
3
Types of Controls
Imperative
1.
2.
3.
Buttons
Icon buttons
Hyperlinks
Selection
4. Check boxes
5. Toggle buttons
6. State-switching buttons
7. Radio buttons
8. Switches
9. Combo icon buttons
10. Lists
1 July 2016
11.
12.
13.
14.
15.
Entry
Bound Value
Spinner
Dials and sliders
Thumbwheels
Validated entry
Display
16.
17.
18.
19.
© Jeff Offutt, 2004-2014
Text
Scrollbars
Splitters
Drawers
4
Imperative : 1. Buttons
• Used to activate a particular action
• This is usually unrecoverable ... do not use in dangerous
situations without a hesitation
• Often offers no feedback
• A 3-D look is a visual cue that the button can be pressed
1 July 2016
© Jeff Offutt, 2004-2014
5
Imperative : 2. Icon Buttons
• Used to collect a group of push buttons together
• Can be thought of as a “menu of buttons”
• Buttons are usually
– Square
– Use an icon (no text)
• Icons are sometimes confusing, hence tooltips were added
to explain what they do
1 July 2016
© Jeff Offutt, 2004-2014
6
Imperative : 3. Hyperlinks
• Originally used to link to detailed documents
• Now inherent to the navigation in web apps
• Hyperlinked images are a problem because users may not
notice the hyperlink
• Using hyperlinks to execute an action is confusing
Use links for navigation and
buttons for actions
1 July 2016
© Jeff Offutt, 2004-2014
7
Selection : 4. Checkbox
•
•
•
•
Allows users to make single binary choices
Simple, visual, elegant
If the text label is unclear, they don’t work
“Latching butcons” combine butcons (an imperative
control) with checkboxes
– Selecting bold, italics, underline in MS Office products
• Checkboxes are traditionally square
– Don’t change it … you’ll confuse users
1 July 2016
© Jeff Offutt, 2004-2014
8
Selection : 5. Toggle Buttons
• Also called “flip-flops”
• Can be used to inform user or to allow user to make
choices
• Two states: on or off
• Indicates state by color, icon, text, …
• Problem is the ambiguity …
– Do these buttons tell us the current state or indicate the next
state if the button is pressed?
1 July 2016
© Jeff Offutt, 2004-2014
9
Selection : 6. State-Switching
• State-switching buttons do two things :
– Change the state of the software
– Display the state
– Example: Play and pause on music players
• Does the current displayed icon indicate :
– Current state ?
– State reached when the button is pressed ?
• One button should not do two things
• My car has a button to change the fans
–
–
–
–
1 July 2016
foot  face  foot+face  foot+windshield  windshield
When I push the button, the new state is shown on the display
How do I know what the current state is ?
Only by pushing the button … which also changes the state …
© Jeff Offutt, 2004-2014
10
Selection : 7. Radio Buttons
• Selects one from of a set of mutually exclusive options
• Actually a specialized menu (single-selection)
– Collection of checkboxes
• Uses :
– set some state in system
– set options for customization
• 3 – 8 options
• Originally diamonds, MS changed to circles
• Very fast, reduces errors, easy to learn but uses screen
space
1 July 2016
© Jeff Offutt, 2004-2014
11
Radio Buttons
•
•
•
•
A variant is the “radio butcon”
Small group of mutually exclusive choices
If crowded, use a drop-down list (slower)
Same as single selection lists
Printer A
1 July 2016
Printer B
© Jeff Offutt, 2004-2014
Printer C
12
Pull-down Menus vs Radio Buttons
• They both accomplish the same task
• Radio buttons are fixed on the screen,
Pull-down menus show up on-demand
• Radio buttons are faster to learn, faster to use, less error
prone
• Use radio buttons except when :
– More than 8 choices
– Screen is crowded
– Choices available depend on other selections (the choices
change dynamically)
1 July 2016
© Jeff Offutt, 2004-2014
13
Selection : 8. Switches
• A control that has two states
• Can be viewed as a variant of the toggle button or a
compact form of 2-choice radio button
Sound on
Color on
• These work better with the swipe gesture on touch
screens
1 July 2016
© Jeff Offutt, 2004-2014
14
Selection : 9. Combo Icon Buttons
• A button that opens a menu of latching butcons
• A variant on drop-down menus
• Visio’s connector tool :
Connector Tool
Connection Point Tool
Stamp Tool
1 July 2016
© Jeff Offutt, 2004-2014
15
Selection : 10. Lists
•
•
•
•
Use as a menu
Sometimes called picklists, list boxes and listviews
All the menu guidelines should apply here
Sometimes text only, sometimes text + icons
Distinguish important text
items in lists with graphic icons
1 July 2016
© Jeff Offutt, 2004-2014
16
List Variants
• Earmarking: Checkboxes are added to a long list to allow
users to choose multiple items
– Usually involves scrolling, which increases memory burden
• Dragging and dropping from lists: Two lists, and elements
can be moved from one to the other
– sftp allows this to copy from one computer to another
• Ordering lists: Moving list items around
– PPT uses this for slide animation
– Firefox allows this to rearrange bookmark menus
• Horizontal scrolling: Painful for users
Avoid scrolling text horizontally
1 July 2016
© Jeff Offutt, 2004-2014
17
Combo Box List
•
•
•
•
Combines a list box and a text edit field
Users can type or select
Optimizes for speed, flexibility, accuracy, and fast learning
Text box can allow arbitrary (invalid) inputs or only inputs
within the range
2009
2008
2009
2010
2011
2012
2013
2014
2015
Year
1 July 2016
© Jeff Offutt, 2004-2014
18
Tree List
• Lists of hierarchical data
• Usually shown sideways and often with icons
• Useful when the data is “naturally” hierarchical – and
programmers think more hierarchically than most users
• Thunderbird mail folders:
Name
-
offutt@gmu.edu
Inbox
Junk
swe632
swe642
+
-
Research
Local Folders
Unsent
Family
1 July 2016
© Jeff Offutt, 2004-2014
19
Entry : 11. Bound Value
• Use when user needs to select a value from a large range
• Often combined with text selection for flexibility
• Only allows valid inputs
– Applies data immunity
Scale
0
100
0
__
1 July 2016
5
5000
5
© Jeff Offutt, 2004-2014
20
Entry : 12. Spinner
• Use when user needs to select a value from a range
• The value has to be precise, but the range is fairly large
– Age
– Weight
– Day of year
• Can be combined with text selection for flexibility
• Edit window can allow arbitrary (invalid) inputs or only
inputs within the range
49
48
47
46
45
44
Age
1 July 2016
© Jeff Offutt, 2004-2014
21
Entry : 13. Dials and Sliders
• Designed to look like physical knobs and sliding levers
• They can be hard to manipulate
• Powerful, but only use for expert-user applications
1 July 2016
© Jeff Offutt, 2004-2014
22
Entry : 14. Thumbwheels
• A variant of the dial
– Controlled by a thumb on a touch screen
• Useful for panning and zooming
• The range can be infinite
1 July 2016
© Jeff Offutt, 2004-2014
23
Entry : 15. Validated Entry
• Used when text with specific constraints is entered
– Credit card numbers, phone numbers, dates, …
• Feedback should be in real-time, not after the complete
text is entered and submitted
• Active validation : Invalid keystrokes are ignored
– Must tell the user … but unobtrusively
• Hints pop up in real-time to describe valid values
• Try to speak the user’s language
– Interpret “nine” as ‘9’
– Interpret 5”, 5i, and 5in as 5 inches
• Don’t use text boxes for output
1 July 2016
© Jeff Offutt, 2004-2014
24
Display : 16. Text
• Appropriate size (vertically and horizontally)
• Do not use when it is possible to select
• This is the most flexible but slowest and most errorprone selection method
– Also can present security vulnerabilities
• Operations: insert, delete, copy, cut, paste, select
• Text boxes must be validated
– Active: Invalid keystrokes are ignored
– Passive: String is checked after user enters data
1 July 2016
© Jeff Offutt, 2004-2014
25
Display : 17. Scrollbars
•
•
•
•
Use when list or text is too long to fit in the window
Better to expand the window, if possible
Horizontal scrolling is very hard
Scrollbars require mixing fine motor control (holding a
button on a tiny icon) with large motor control (moving
your arm)
Vertical
Horizontal
1 July 2016
© Jeff Offutt, 2004-2014
26
Scrollbars are Difficult
• Scrollbars should give more information (PPT thumbnails):
– Total number of pages (screens)
– The current page number
– Thumbnails of the text
• Scrollbars should let us :
– Skip ahead by pages, chapters, sections, or keywords
– Jump to the beginning and end
– Set bookmarks
• It’s just hard to scroll with the mouse
• Think about all the abilities in vi
1 July 2016
© Jeff Offutt, 2004-2014
27
Display : 18. Splitters
• Splitters split windows into two areas, separated by a line
– Sometimes called a “sash”
•
•
•
•
Used to offer the user flexibility
Often separates text from command or menu windows
PPT’s outline view uses a splitter
Some splitters are movable, some are not
– This must be clear to users
text
Sash
commands
1 July 2016
© Jeff Offutt, 2004-2014
28
Display : 19. Drawers
• Drawers are window panes that can be opened and
closed by the users
– Clicking a button
– Swiping from the edge of the screen
• Drawers hold controls that are :
– Infrequently used
– Relevant to the app’s main work area
• They are most common in mobile apps
1 July 2016
© Jeff Offutt, 2004-2014
29
Controls Summary
Don’t use the first control that
comes to mind
Think about the user’s needs and
design the right solution
1 July 2016
© Jeff Offutt, 2004-2014
30
Outline
1. Controls
2. Dialogs
3. Eliminating Errors, Alerts, and Confirmations
4. The Devil Is in the Details
1 July 2016
© Jeff Offutt, 2004-2014
31
Dialog Design
• Dialog boxes are the most inconveniently designed part of
most GUIs (according to Cooper)
• We have already talked about:
– Unnecessary dialog boxes
– Placement
– Confusing button labels
• Remember : You are designing a language
– Unfortunately, you have been trained to expect languages to be
poorly designed (C, C++, Z), but you can do better!
– You have the advantages of a class in UI design
Put primary interactions in
the primary window
1 July 2016
© Jeff Offutt, 2004-2014
32
Purpose of Dialogs
• Dialog boxes are interruptions and inherently intrusive
– We cannot always afford to spend 20 minutes talking every time
someone comes to our office
• Dialog boxes are excise tasks
• Use dialog boxes for :
– Exceptional interaction (errors, printing, …)
– Dangerous interaction (requiring extra concentration)
• My favorite worst use of a dialog box:
– Find in Netscape, MS Word and PPT
– Adobe integrates find into the toolbar
– Firefox uses keyboard accelerator: “/string”
• This is the first use I’ve seen of using advanced vi-style navigation in a GUI
Use dialogs for functions out of the main flow
1 July 2016
© Jeff Offutt, 2004-2014
33
Dialog Interaction
Use dialogs to organize controls and
information about a single domain object
or application function
Use verbs in function
dialog title bars
Use object names in
property dialog title bars
1 July 2016
© Jeff Offutt, 2004-2014
34
Modal Dialog Boxes
• Modal : No other interaction is allowed until the dialog
box is closed
• Error messages should almost NEVER be in modal dialog
boxes
The message should disappear with the next interaction with the
parent window
• Modal boxes are :
–
–
–
–
easy to program
easy to understand
annoying
too common
Differentiate modeless
dialogs from modal dialgs
1 July 2016
© Jeff Offutt, 2004-2014
35
Modeless Dialog Boxes
•
•
•
•
The “owning” program continues
Usually have terminating commands (close)
Much less intrusive than modal dialog boxes
Can be confusing – when do they go away?
– people expect them to be modal
• Example : Find (^F) in MS Office
1 July 2016
© Jeff Offutt, 2004-2014
36
Five Kinds of Dialog Boxes
•
1. Property dialog box
Users can change object settings
• font
• printing options
2. Function dialog box
•
•
•
•
Explain what’s happening
Express that it is unusual
State how much longer … this
is hard!
Provide a cancel
4. Notification dialog box
User performs some function
• find
• print
• spell checking
5.
3. Process dialog box
Tells user the system is busy
• Hour glass is not always
sufficient
1 July 2016
Process box should:
Messages from software to users
• Should be non-intrusive
• Users can delay viewing
Bulletin dialog box
Gives the user feedback
• error message
• confirmation messages
User does not request these!
© Jeff Offutt, 2004-2014
37
(1) Property Dialog Boxes
User can change settings of an object
•
•
1 July 2016
font
printing options
© Jeff Offutt, 2004-2014
38
(2) Function Dialog Boxes
User performs some function
•
•
•
1 July 2016
find
print
spell checking
© Jeff Offutt, 2004-2014
39
(3) Process Dialog Boxes
Tells the user the system is busy
•
•
Hour glass is not always sufficient
Process box should:
•
•
•
•
1 July 2016
Explain to the user what’s happening
Express that it is unusual
State how much longer … this is hard!
Provide a cancel
© Jeff Offutt, 2004-2014
40
(4) Notification Dialog Box
• Much more common in mobile apps
• Notification centers let users view modifications later
• Most notifications should be modeless
1 July 2016
© Jeff Offutt, 2004-2014
41
(5) Bulletin Dialog Boxes
Gives the user some feedback
• error message
• confirmation messages
Note that the user does not request!
When opening
Blackboard
My favorite
1 July 2016
© Jeff Offutt, 2004-2014
42
Dialog Etiquette
• A lot of UI design is about writing software that is polite
to users – users simply want respect
– Respect my goals
– Respect my time
• Property and function dialogs are requested by users
• Process, notifications and bulletin dialogs are sent by
software
1 July 2016
© Jeff Offutt, 2004-2014
43
Dos and Don’ts of Dialog Boxes
• All dialog boxes should be movable
• Dialog title bars should indicate function (verb) and object
• Dialog boxes should behave as transient programs, but be as small
as possible
• If a user moves a dialog box once, it should remember and return
to its new home
• Don’t use them unless necessary
• Always include OK and Cancel
• Semantics of a close button on a dialog box is unclear – don’t use it
• “Help” is not equivalent to “cancel” and should not be adjacent
1 July 2016
© Jeff Offutt, 2004-2014
44
Variants of Dialogs
• Tabbed dialogs allow convenient organization
– Stacking tabs is confusing
• Expanding dialogs – hide rare options and make them accessible
through a button
– If I go to the “expert” pane once, it should reappear the next time
• Cascading dialogs – dialog boxes beget more dialog boxes …
– Like coming to office hours to ask me a question, then making me give the
answer to someone else, who then brings in a third friend for clarification …
• Dynamic dialogs – A selection in one pane changes the contents of
another
– Confusing but useful
– PPT (2003) – More Buttons – Add or remove buttons – Customize
– PPT (2007) – Quick access toolbar – More commands – Customize
1 July 2016
© Jeff Offutt, 2004-2014
45
Summary : Using Dialogs
Dialog boxes are hard to get right
and often annoying
1 July 2016
© Jeff Offutt, 2004-2014
46
Summary : Dialog Etiquette
Dialog boxes are hard to get
right and often very annoying
Dialog boxes are often poorly designed
because they are NOT designed
Programmers use default built-in boxes
without thinking
1 July 2016
© Jeff Offutt, 2004-2014
47
Outline
1. Controls
2. Dialogs
3. Eliminating Errors, Alerts, and Confirmations
4. The Devil Is in the Details
1 July 2016
© Jeff Offutt, 2004-2014
48
Error Dialog Boxes
• These are often poorly designed and always unwelcome
– Users want to avoid errors, not told they made errors
– Users want software to deal with their errors
– Users want to do things their way, not the software’s way
• Polite people don’t announce their friends’ mistakes
publicly
• Is the purpose of an error message to …
– tell the users they made mistakes ?
– tell the users the software is too stupid to understand them ?
Most error dialogs stop the
proceedings with idiocy
1 July 2016
© Jeff Offutt, 2004-2014
49
Eliminate Error Messages
• Input validation only checks the simplest of mistakes
• Go read chapter 15 again
– Make the software immune to unexpected inputs
– Assume the users know what they’re doing
• Use widgets that make syntactic mistakes impossible
– Spinners, lists, masking
• Correct the mistake automatically
– If I say “good morning” at 5:00 in the afternoon, you will selfcorrect by assuming I meant “good afternoon”
Make errors impossible
1 July 2016
© Jeff Offutt, 2004-2014
50
Alerts and Confirmations
• Users don’t need to know everything the software does
– Users don’t care that the software successfully printed
– Users don’t care that the software synchronized
• Users don’t need to be asked to confirm everything
Do; don’t ask
Make all actions reversible
Provide modeless feedback to
help users avoid mistakes
1 July 2016
© Jeff Offutt, 2004-2014
51
Outline
1. Controls
2. Dialogs
3. Eliminating Errors, Alerts, and Confirmations
4. The Devil Is in the Details
1 July 2016
© Jeff Offutt, 2004-2014
52
Details, Details
None of these things are
technically complicated
But they require the
programmers to do more work
1 July 2016
© Jeff Offutt, 2004-2014
53
Summary
Using the right controls allows you to
apply effectively all the concepts we
discussed throughout the course
1 July 2016
© Jeff Offutt, 2004-2014
54