User Interface Design and Development 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 Controls Dialogs Eliminating Errors, Alerts, and Confirmations 11 November 2018 © Jeff Offutt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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