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



parametersMessage boxes: Inform the user

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

actionAssumption: Users are pathological beings who, given the chance, will enter perversely incorrect information in order to crash an application




Error Dialogs




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



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



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

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

designing around dialogs

Business

alert dialogs applications

user interface flow

users way

invalid action assumption

incorrect information

dangerous sideeffects

pathological beings

great difficulty