Designing Around Dialogs
- 1. Designing around Dialogs Ensuring User Interface Flow By Staying out of the Way Jan Miksovsky Lead Designer, Personal Finance
- 2. Ensuring User Interface Flow By Staying out of the Way Jan Miksovsky Lead Designer, Personal Finance Designing around Dialogs
- 3. Types of Dialogs Property sheets: Let user edit something Progress dialogs: Indicate work is happening Function dialogs: Specify command parameters Message boxes: Inform the user Some dialogs are good, some are bad
- 4. Requested Dialogs Property sheets: Let user edit something Progress dialogs: Indicate work is happening Function dialogs: Specify command parameters Message boxes: Inform the user
- 5. Unrequested Dialogs Property sheets: Let user edit something Progress dialogs: Indicate work is happening Function dialogs: Specify command parameters Message boxes: Inform the user
- 6. Unrequested Dialogs Property sheets: Let user edit something Progress dialogs: Indicate work is happening Function dialogs: Specify command parameters Message boxes: Inform the user Errors Confirmations Alerts
- 7. Error Dialogs An application displays an error dialog when: An unexpected situation has occurred The user has attempted an invalid action Assumption: Users are pathological beings who, given the chance, will enter perversely incorrect information in order to crash an application
- 8. Error Dialogs An application displays an error dialog when: An unexpected situation has occurred The user has attempted an invalid action Assumption: Users are pathological beings who, given the chance, will enter perversely incorrect information in order to crash an application
- 9. What the User Sees An application displays an error dialog when: An unexpected situation has occurred The user has attempted an invalid action Assumption: Users are pathological beings who, given the chance, will enter perversely incorrect information in order to crash an application
- 10. Error Dialog Reality Error dialogs: Are often unhelpful or incomprehensible Invariably put the blame on the user Reflect a programmer’s view of the world, not the user’s Are a sign of concern for the needs of the program than the user
- 11. Confirmation Dialogs Application display confirmation dialogs when: The user should understand the consequences of what is about to happen The application needs more information about what a user really wanted Assumption: Users have such great difficulty using a mouse, they often unintentionally select commands with dangerous side-effects
- 12. Application display confirmation dialogs when: The user should understand the consequences of what is about to happen The application needs more information about what a user really wanted Confirmation Dialogs Assumption: Users have such great difficulty using a mouse, they often unintentionally select commands with dangerous side-effects
- 13. Application display confirmation dialogs when: The user should understand the consequences of what is about to happen The application needs more information about what a user really wanted What the User Sees Assumption: Users have such great difficulty using a mouse, they often unintentionally select commands with dangerous side-effects
- 14. Confirmation Dialog Reality Confirmation dialogs: Appear in the same places every time Are almost always answered the same way Can be immediately ignored Don’t prevent the user from making mistakes Are often used to prevent trivial side-effects Get in the user’s way Are a sign of indecisiveness
- 15. Alert Dialogs Applications display alert dialogs: To notify the user a task is complete To provide more detail on the operation the user is currently performing Assumption: In the midst of performing an action, users love to stop and learn more about how software works
- 16. Alert Dialogs Applications display alert dialogs: To notify the user that a task is complete To provide more detail on the operation the user is currently performing Assumption: In the midst of performing an action, users love to stop and learn more about how software works
- 17. What the User Sees
- 18. Alert Dialog Reality Alert dialogs: Announce the obvious Are a sign of timidity
- 19. Function Dialogs Many commands ask for more input: The user asks to see a chart The application asks “Which chart?” Assumption: Users want to get a perfect result the first time
- 20. Function Dialogs Many commands ask for more input: The user asks to see a chart The application asks “Which chart?” Assumption: Users want to get a perfect result the first time
- 21. Function Dialog Reality Function dialogs: Aren’t what the user asked for Suffer from same problems as confirmations Can lead to endless questions: “Soup or Salad?” “Salad.” “House salad or Ceasar?” “House.” “Italian or Ranch dressing?” “Italian.” “Regular or Low-Fat?” … Are a sign of over-eagerness
- 22. Problems with Unrequested Dialogs Too damn easy to create Surprise the user Completely stop the flow of the user accomplishing what they really want to do Diminish the software experience Don’t actually accomplish their objectives
- 23. We Put Up With So Much Crap If people interrupted us as much as dialogs do, we’d shoot them.
- 24. Let’s Make Fun of Some Dialogs
- 25. Let’s Make Fun of Some Dialogs
- 26. Let’s Make Fun of Some Dialogs
- 27. Let’s Make Fun of Some Dialogs
- 28. Let’s Make Fun of Some Dialogs
- 29. Imagine a product that never, ever displayed a dialog the user didn’t ask for. Users would love this product.
- 30. Hypothesis: For every dialog in a product, another design exists without a dialog that can do the same thing, only better .
- 32. Iteration #1 Observation: Reconciliation warning displayed is before transaction is edited Possible solution: Display dialog after user has actually edited transaction and pressed OK
- 33. Iteration #2 Observation: Transaction amount is actually the only field which affects the reconciled balance Improvement: Only display dialog if user changes amount
- 34. Iteration #3 Observation: Things seem OK... until user presses OK Improvement: Display modeless status text while editing, and lose the dialog altogether
- 36. Iteration #4 Observation: The error is really only relevant if problems arise later when balancing; the user may be fixing a legitimate problem Improvement: If there is, in fact, a problem the next time the user balances, remind them which transactions they edited
- 37. Iteration #5 Observation: The user wouldn’t be editing reconciled amounts in the first place if some other problem hadn’t occurred Improvement: Fix the underlying problems that cause users to edit reconciled transactions
- 38. Ask yourself: Why am I adding this dialog? You can probably come with a better design that doesn’t require the dialog.
- 39. Avoiding Error Dialogs Disable controls under error conditions Provide advance visual feedback modelessly Use positive audio feedback Cope with any input
- 40. Data Integrity is a False God Error dialogs are most often justified in the pursuit of data integrity Data integrity principally makes things easier for programmers, rarely for users Yet, somehow, paper-based systems in the real world manage to cope with unusual data all the time
- 41. Designing Error Dialogs If you absolutely must have an error dialog: Explain the situation in natural language If situation is normal, make it sound normal Have the program take the blame Indicate what can be done to fix the error Considering burying error details that would only be interesting to a technician Recover gracefully
- 42. Avoiding Confirmations and Alerts Display advance feedback modelessly Support Undo Learn what the user usually wants If you’re really providing two features, provide two commands Take a guess Consider the severity of the side-effects Have some guts
- 43. Designing Confirmations and Alerts If you absolutely must have a confirmation or alert: Make it unexpected: determine the exact conditions under which it needs to appear Consider a “Don’t show this again” check box
- 44. Avoiding Function Dialogs Create anything , then let the user change it Learn what the user usually wants If you’re really providing two features, provide two commands
- 45. Designing Function Dialogs If you absolutely must have a function dialog: Add ellipsis (…) to the command name Use a wizard to ask more than one question Propose a default choice Select the defaults intelligently Let users double-click to choose and continue
- 46. The Parable of the GOTO At dawn of time, programmers used the GOTO statement everywhere Structured programming obviated GOTO: reduced bugs, improved maintainability For a while, GOTO became taboo But… some special situations like error handling are better handled with GOTO Now, GOTO is used sparingly—the developer feels a little guilty, and needs to justify its use
- 47. Treat Dialogs Like Rooms Each dialog is like a separate room Have a good reason for making the user go to another room
- 48. For More Info Much of this material has been inspired by the book About Face by Alan Cooper (Programmer’s Press, IDG Books Worldwide) Good bibliography on www.cooper.com