Designing Around Dialogs

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

Unrequested Dialogs

Unrequested Dialogs
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

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

Confirmation Dialogs Assumption: Users have such great difficulty using a mouse, they often unintentionally select commands with dangerous side-effects

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 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

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

Designing Around Dialogs

by blider on Jul 24, 2007

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 3

Statistics

Designing Around Dialogs Presentation Transcript