Download - Designing Around Dialogs
Designing around Dialogs
Ensuring User Interface FlowBy Staying out of the Way
Jan MiksovskyLead Designer, Personal Finance
Ensuring User Interface FlowBy Staying out of the Way
Jan MiksovskyLead Designer, Personal Finance
Designing around Dialogs
Types of Dialogs
Property sheets: Let user edit somethingProgress dialogs: Indicate work is
happeningFunction dialogs: Specify command
parametersMessage boxes: Inform the userSome dialogs are good, some are bad
Requested Dialogs
Property sheets: Let user edit somethingProgress dialogs: Indicate work is
happeningFunction dialogs: Specify command
parametersMessage boxes: Inform the user
Unrequested Dialogs
Property sheets: Let user edit somethingProgress dialogs: Indicate work is
happeningFunction dialogs: Specify command
parametersMessage boxes: Inform the user
Unrequested Dialogs
Property sheets: Let user edit somethingProgress dialogs: Indicate work is
happeningFunction dialogs: Specify command
parametersMessage 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
actionAssumption: Users are pathological beings who, given the chance, will enter perversely incorrect information in order to crash an application
An application displays an error dialog when:
An unexpected situation has occurred The user has attempted an invalid
actionAssumption: 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
actionAssumption: Users are pathological beings who, given the chance, will enter perversely incorrect information in order to crash an application
What the User Sees
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 wantedAssumption: Users have such great
difficulty using a mouse, they often unintentionally select commands with dangerous side-effects
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
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
Many commands ask for more input: The user asks to see a chart The application asks “Which chart?”
Function Dialogs
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
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