0
Designing around Dialogs <ul><li>Ensuring User Interface Flow By Staying out of the Way </li></ul><ul><li>Jan Miksovsky </...
<ul><li>Ensuring User Interface Flow By Staying out of the Way </li></ul><ul><li>Jan Miksovsky </li></ul><ul><li>Lead Desi...
Types of Dialogs <ul><li>Property sheets:  Let user edit something </li></ul><ul><li>Progress dialogs:  Indicate work is h...
Requested Dialogs <ul><li>Property sheets:  Let user edit something </li></ul><ul><li>Progress dialogs:  Indicate work is ...
Unrequested Dialogs <ul><li>Property sheets: Let user edit something </li></ul><ul><li>Progress dialogs: Indicate   work i...
Unrequested Dialogs <ul><li>Property sheets: Let user edit something </li></ul><ul><li>Progress dialogs: Indicate   work i...
Error Dialogs <ul><li>An application displays an error dialog when: </li></ul><ul><li>An unexpected situation has occurred...
Error Dialogs <ul><li>An application displays an error dialog when: </li></ul><ul><li>An unexpected situation has occurred...
What the User Sees <ul><li>An application displays an error dialog when: </li></ul><ul><li>An unexpected situation has occ...
Error Dialog Reality <ul><li>Error dialogs: </li></ul><ul><li>Are often unhelpful or incomprehensible </li></ul><ul><li>In...
Confirmation Dialogs <ul><li>Application display confirmation dialogs when: </li></ul><ul><li>The user should understand t...
<ul><li>Application display confirmation dialogs when: </li></ul><ul><li>The user should understand the consequences of wh...
<ul><li>Application display confirmation dialogs when: </li></ul><ul><li>The user should understand the consequences of wh...
Confirmation Dialog Reality <ul><li>Confirmation dialogs: </li></ul><ul><li>Appear in the same places every time </li></ul...
Alert Dialogs <ul><li>Applications display alert dialogs: </li></ul><ul><li>To notify the user a task is complete </li></u...
Alert Dialogs <ul><li>Applications display alert dialogs: </li></ul><ul><li>To notify the user that a task is complete </l...
What the User Sees
Alert Dialog Reality <ul><li>Alert dialogs: </li></ul><ul><li>Announce the obvious </li></ul><ul><li>Are a sign of timidit...
Function Dialogs <ul><li>Many commands ask for more input: </li></ul><ul><li>The user asks to see a chart </li></ul><ul><l...
Function Dialogs <ul><li>Many commands ask for more input: </li></ul><ul><li>The user asks to see a chart </li></ul><ul><l...
Function Dialog Reality <ul><li>Function dialogs: </li></ul><ul><li>Aren’t what the user asked for </li></ul><ul><li>Suffe...
Problems with Unrequested Dialogs <ul><li>Too damn easy to create </li></ul><ul><li>Surprise the user </li></ul><ul><li>Co...
We Put Up With So Much Crap <ul><li>If people interrupted us as much as dialogs do, we’d shoot them. </li></ul>
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
<ul><li>Imagine a product that never, ever displayed a dialog the user didn’t ask for. </li></ul><ul><li>Users would   lov...
<ul><li>Hypothesis: For every dialog in a product, another design exists without a dialog that can do the same thing,  onl...
Exterminating a Dialog
Iteration #1 <ul><li>Observation: </li></ul><ul><li>Reconciliation warning displayed is  before  transaction is edited </l...
Iteration #2 <ul><li>Observation: </li></ul><ul><li>Transaction amount is actually the only field which affects the reconc...
Iteration #3 <ul><li>Observation: </li></ul><ul><li>Things seem OK... until user presses OK </li></ul><ul><li>Improvement:...
 
Iteration #4 <ul><li>Observation: </li></ul><ul><li>The error is really only relevant if problems arise  later  when balan...
Iteration #5 <ul><li>Observation: </li></ul><ul><li>The user wouldn’t be editing reconciled amounts in the first place if ...
<ul><li>Ask yourself: </li></ul><ul><li>Why am I adding this dialog? </li></ul><ul><li>You can probably come with a better...
Avoiding Error Dialogs <ul><li>Disable controls under error conditions </li></ul><ul><li>Provide advance visual feedback m...
Data Integrity is a False God <ul><li>Error dialogs are most often justified in the pursuit of data integrity </li></ul><u...
Designing Error Dialogs <ul><li>If you absolutely must have an error dialog: </li></ul><ul><li>Explain the situation in na...
Avoiding Confirmations and Alerts <ul><li>Display advance feedback modelessly </li></ul><ul><li>Support Undo </li></ul><ul...
Designing Confirmations and Alerts <ul><li>If you absolutely must have a confirmation or alert: </li></ul><ul><li>Make it ...
Avoiding Function Dialogs <ul><li>Create  anything , then let the user change it </li></ul><ul><li>Learn what the user usu...
Designing Function Dialogs <ul><li>If you absolutely must have a function dialog: </li></ul><ul><li>Add ellipsis (…) to th...
The Parable of the GOTO <ul><li>At dawn of time, programmers used the GOTO statement everywhere </li></ul><ul><li>Structur...
Treat Dialogs Like Rooms <ul><li>Each dialog is like a separate room </li></ul><ul><li>Have a good reason for making the u...
For More Info <ul><li>Much of this material has been inspired by the book  About Face  by Alan Cooper (Programmer’s Press,...
 
Upcoming SlideShare
Loading in...5
×

Designing Around Dialogs

3,991

Published on

Ensuring User Interface Flow By Staying out of the Way

Published in: Business, Technology
1 Comment
8 Likes
Statistics
Notes
No Downloads
Views
Total Views
3,991
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
86
Comments
1
Likes
8
Embeds 0
No embeds

No notes for slide

Transcript of "Designing Around Dialogs"

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

    Clipping is a handy way to collect important slides you want to go back to later.

×