Cooper Part III Interaction Details Design Details Controls

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 Ed 4, Ch 21

Outline 1. Controls 2. Dialogs 3. Eliminating Errors, Alerts, and Confirmations 07 September 2021 © Jeff Offutt 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 – HTML implements very few GUI controls – Windows and Mac use only a fraction of the invented controls 07 September 2021 © Jeff Offutt 3

Types of Controls Imperative 1. Buttons 2. Icon buttons 3. Hyperlinks 4. 5. 6. 7. 8. 9. 07 September 2021 Selection Check boxes Toggle buttons State-switching buttons Radio buttons Switches Combo icon buttons © Jeff Offutt 11. 12. 13. 14. 15. Entry Bound Value Spinner Dials and sliders Thumbwheels Validated entry 16. 17. 18. 19. Display Text Scrollbars Splitters Drawers 4

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) 07 September 2021 © Jeff Offutt 5

Controls Summary Don’t use the first control that comes to mind Think about the user’s needs and design the right solution 07 September 2021 © Jeff Offutt 6

Outline 1. Controls 2. Dialogs 3. Eliminating Errors, Alerts, and Confirmations 07 September 2021 © Jeff Offutt 7

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 07 September 2021 © Jeff Offutt 8

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 Use dialogs for functions out of the main GUI 07 September 2021 © Jeff Offutt 9

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 07 September 2021 © Jeff Offutt 10

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 • Modeless dialog boxes: boxes The message should disappear with the next – Have terminating commands interaction (close) • Modal boxes are : – Are less intrusive – easy to program – easy to understand – annoying – too common Differentiate modeless from modal dialog boxes 07 September 2021 © Jeff Offutt 11

Five Kinds of Dialog Boxes • 1. Property dialog box Users can change object settings • font • printing options • Explain what’s happening Express that it is unusual State how much longer … this is hard! Provide a cancel 4. Notification dialog box Messages from software to users • Should be non-intrusive • Users can delay viewing User performs some function • find • print • spell checking 5. Bulletin dialog box Tells user the system is busy • Hour glass is not always 07 September 2021 • • • 2. Function dialog box 3. Process dialog box Process box should: © Jeff Offutt Gives the user feedback • error message • confirmation messages User does not request 12

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 07 September 2021 © Jeff Offutt 13

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 07 September 2021 © Jeff Offutt 14

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 07 September 2021 © Jeff Offutt 15

Outline 1. Controls 2. Dialogs 3. Eliminating Errors, Alerts, and Confirmations 07 September 2021 © Jeff Offutt 16

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 understand Most error dialogs stop to them ? proceedings with idiocy 07 September 2021 © Jeff Offutt 17

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 assuming I meant “good Makebyerrors impossible afternoon” 07 September 2021 © Jeff Offutt 18

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 Do; don’t everything ask 07 September 2021 Make all actions reversible Provide modeless feedback to help users avoid mistakes © Jeff Offutt 19

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 07 September 2021 © Jeff Offutt 20