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