• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Designing Around Dialogs
 

Designing Around Dialogs

on

  • 5,774 views

Ensuring User Interface Flow By Staying out of the Way

Ensuring User Interface Flow By Staying out of the Way

Statistics

Views

Total Views
5,774
Views on SlideShare
5,771
Embed Views
3

Actions

Likes
8
Downloads
84
Comments
1

1 Embed 3

http://www.slideshare.net 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Designing Around Dialogs Designing Around Dialogs Presentation Transcript

    • Designing around Dialogs
      • Ensuring User Interface Flow By Staying out of the Way
      • Jan Miksovsky
      • Lead Designer, Personal Finance
      • Ensuring User Interface Flow By Staying out of the Way
      • Jan Miksovsky
      • Lead Designer, Personal Finance
      Designing around Dialogs
    • 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
    • Requested Dialogs
      • Property sheets: Let user edit something
      • Progress dialogs: Indicate work is happening
      • Function dialogs: Specify command parameters
      • Message boxes: Inform the user
    • Unrequested Dialogs
      • Property sheets: Let user edit something
      • Progress dialogs: Indicate work is happening
      • Function dialogs: Specify command parameters
      • Message boxes: Inform the user
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
      • 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
      • 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
    • 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
    • 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
    • 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
    • What the User Sees
    • Alert Dialog Reality
      • Alert dialogs:
      • Announce the obvious
      • Are a sign of timidity
    • 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
    • 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
    • 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
    • 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
    • We Put Up With So Much Crap
      • If people interrupted us as much as dialogs do, we’d shoot them.
    • Let’s Make Fun of Some Dialogs
    • Let’s Make Fun of Some Dialogs
    • Let’s Make Fun of Some Dialogs
    • Let’s Make Fun of Some Dialogs
    • Let’s Make Fun of Some Dialogs
      • Imagine a product that never, ever displayed a dialog the user didn’t ask for.
      • Users would love this product.
      • Hypothesis: For every dialog in a product, another design exists without a dialog that can do the same thing, only better .
    • Exterminating a Dialog
    • Iteration #1
      • Observation:
      • Reconciliation warning displayed is before transaction is edited
      • Possible solution:
      • Display dialog after user has actually edited transaction and pressed OK
    • Iteration #2
      • Observation:
      • Transaction amount is actually the only field which affects the reconciled balance
      • Improvement:
      • Only display dialog if user changes amount
    • Iteration #3
      • Observation:
      • Things seem OK... until user presses OK
      • Improvement:
      • Display modeless status text while editing, and lose the dialog altogether
    •  
    • 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
    • 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
      • Ask yourself:
      • Why am I adding this dialog?
      • You can probably come with a better design that doesn’t require the dialog.
    • Avoiding Error Dialogs
      • Disable controls under error conditions
      • Provide advance visual feedback modelessly
      • Use positive audio feedback
      • Cope with any input
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Treat Dialogs Like Rooms
      • Each dialog is like a separate room
      • Have a good reason for making the user go to another room
    • 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
    •