1. User Interface Design and Development
Cooper Part III Interaction Details Design Details: Controls and Dialogs
Jeff Offutt
SWE 632
User Interface Design and Development
Cooper Ed4, Ch 21

2. Outline Controls Dialogs Eliminating Errors, Alerts, and Confirmations
11 November 2018
© Jeff Offutt

3. Controls (also: Widgets)
Controls are objects on the screen that communicate between users and software
Four types of controls
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
HTML implements very few GUI controls
Windows and Mac use only a fraction of the invented controls
11 November 2018
© Jeff Offutt

4. Types of Controls Imperative Entry Bound Value Buttons Spinner
Icon buttons
Hyperlinks
Entry
Bound Value
Spinner
Dials and sliders
Thumbwheels
Validated entry
Selection
Check boxes
Toggle buttons
State-switching buttons
Radio buttons
Switches
Combo icon buttons
Lists
Display
Text
Scrollbars
Splitters
Drawers
11 November 2018
© Jeff Offutt

5. 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 7 choices
Screen is crowded
Choices available depend on other selections (the choices change dynamically)
11 November 2018
© Jeff Offutt

6. Controls Summary Don’t use the first control that comes to mind
Think about the user’s needs and design the right solution
11 November 2018
© Jeff Offutt

7. Outline Controls Dialogs Eliminating Errors, Alerts, and Confirmations
11 November 2018
© Jeff Offutt

8. Put primary interactions in the primary window
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
Put primary interactions in the primary window
11 November 2018
© Jeff Offutt

9. Use dialogs for functions out of the main flow
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 of using advanced vim-style navigation in a GUI
Use dialogs for functions out of the main flow
11 November 2018
© Jeff Offutt

10. 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
11 November 2018
© Jeff Offutt

11. Modal and Modeless Dialog Boxes
Modal : No other interaction until the dialog box is closed
Modeless : Users can still interact with “owning” program
Do not put error messages in modal dialog boxes
The message should disappear with the next interaction
Modal boxes are :
easy to program
easy to understand
annoying
too common
Modeless dialog boxes:
Have terminating commands (close)
Are less intrusive
Differentiate modeless from modal dialog boxes
11 November 2018
© Jeff Offutt

12. Five Kinds of Dialog Boxes
Property dialog box
Users can change object settings
font
printing options
Function dialog box
User performs some function
find
print
spell checking
Process dialog box
Tells user the system is busy
Hour glass is not always sufficient
Process box should:
Explain what’s happening
Express that it is unusual
State how much longer … this is hard!
Provide a cancel
Notification dialog box
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!
11 November 2018
© Jeff Offutt

13. 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
11 November 2018
© Jeff Offutt

14. 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
11 November 2018
© Jeff Offutt

15. 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
11 November 2018
© Jeff Offutt

16. Outline Controls Dialogs Eliminating Errors, Alerts, and Confirmations
11 November 2018
© Jeff Offutt

17. Most error dialogs stop the proceedings with idiocy
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
11 November 2018
© Jeff Offutt

18. 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 self-correct by assuming I meant “good afternoon”
Make errors impossible
11 November 2018
© Jeff Offutt

19. 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
11 November 2018
© Jeff Offutt

20. Summary None of these things are technically complicated
But they require the programmers to do more work
Using the right controls allows you to apply effectively all the concepts from the course
11 November 2018
© Jeff Offutt