Designing Around Dialogs
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Designing Around Dialogs

  • 5,929 views
Uploaded on

Ensuring User Interface Flow By Staying out of the Way

Ensuring User Interface Flow By Staying out of the Way

More in: Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
5,929
On Slideshare
5,926
From Embeds
3
Number of Embeds
1

Actions

Shares
Downloads
84
Comments
1
Likes
8

Embeds 3

http://www.slideshare.net 3

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 .
  • 31. Exterminating a Dialog
  • 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
  • 35.  
  • 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
  • 49.