Confirmation dialogs - the devil himself, or a necessary evil?

8 Jun 2007 - 3:18pm
7 years ago
24 replies
1754 reads
Billie Mandel
2005

Hi all -

So our esteemed colleagues Messrs. Cooper and Reimann have told us that
confirmation dialogs are insulting and stupid, to be avoided at all
costs -- and in general, I agree with them.

The question, though, is whether there are any cases where it makes
sense to use them. The potential ones my team has discussed are

- when the user is about to delete something that s/he has
already gone out of the way to pay for, and would need to pay for again
if s/he wanted to re-add

- when it's relatively easy to make a mistake, because of
something out of your control about the hardware you're designing for
(i.e. the hardware manufacturer didn't sufficiently "hide the ejector
seat lever" - I love that metaphor...)

- for an important edge case in an overall system where such
dialogs aren't frequently used

What do you guys think? Are these, in fact, cases in which to use
confirmation dialogs? If so, are there others? Or are these things
inherently evil?

Cheers,

- Billie

* * * * * * *

Billie Mandel

Manager, User Experience Design & Research

OPENWAVE

billie.mandel at openwave.com <mailto:billie.mandel at openwave.com>

Comments

8 Jun 2007 - 3:50pm
Tanya Rabourn
2004

> What do you guys think? Are these, in fact, cases in which to use
> confirmation dialogs? If so, are there others? Or are these things
> inherently evil?

To greatly generalize, use whenever there's no undo, and on the whole
an undo is preferable. (Necessary evil when dev balks at your request
for an undo.)

-Tanya

8 Jun 2007 - 5:10pm
Billie Mandel
2005

Tanya said:

> To greatly generalize, use whenever there's no undo, and on the whole
> an undo is preferable. (Necessary evil when dev balks at your request
> for an undo.)

I agree - and therein lies the rub. We're a mobile company, and "undo"
is not always something one can pull off on mobile devices -- especially
when we're talking about "delete thing X from my handset" types of
actions, of which there are many required variations.

So I think that using them "whenever" there's no undo, sadly, won't fly
as an axiom in this context.

The devil, as usual, is in the details....

Cheers,
- Billie

* * * * * * *
Billie Mandel
Manager, User Experience Design & Research
OPENWAVE
billie.mandel at openwave.com

8 Jun 2007 - 9:04pm
Josh
2006

To say that confirmation dialogs are pure evil or completely unnecessary
would be a mistake. I've found that they can be extremely useful in web apps
in two specific cases.

The first, when there is no "undo" and the desired action risks permanent
change is fairly significant. Consider a content management system about to
publish changes to a site live. Not such a bad idea to ask "are you sure you
want to publish something that everyone with web access can see?" before
publishing.

The second, when you don't want users to do something. This is a tricky
case, but there are occasions when users must be allowed to do something
that is not optimal for the business. Think about a subscription based
service. Putting a small roadblock in front of users who want to cancel
their accounts can be huge.

Of course, I think that confirmation dialogs are frequently abused and
products of poor product design or messaging. In the subscription based
service example above - isn't there a better way to increase lifetime value
of users than preventing them from leaving? There probably is.

--
Josh Viney
EastMedia Group
http://www.eastmedia.com

10 Jun 2007 - 8:28am
pnuschke
2007

For a project at my previous job, I wrote a standardization document for
confirmation dialogs or "prompts" (for desktop applications).

I think that Cooper says in About Face or maybe "Inmates" that these prompts
are really there to hide flaws in the software and I think that is a good
guiding principle.

However, I can think of at least two prompts which are pretty useful. One of
the most obvious prompts is the Yes/No/Cancel dialog that many apps use when
you make changes and don't save them before you attempt to exit. It is far
easier to ask before they leave if they want to save those changes than when
they return. Another useful prompt is when an action may take a long time
and it is difficult to note that through the interface (this latter prompt
may be helpful initially but annoying later, so the user should be able to
disable it).

I really dislike the delete confirmation prompts. There is almost always a
way to avoid them through clever programming.

Paul Nuschke
Human Factors Analyst
www.electronicink.com

On 6/8/07, Josh Viney <jviney at gmail.com> wrote:
>
> To say that confirmation dialogs are pure evil or completely unnecessary
> would be a mistake. I've found that they can be extremely useful in web
> apps
> in two specific cases.
>
> The first, when there is no "undo" and the desired action risks permanent
> change is fairly significant. Consider a content management system about
> to
> publish changes to a site live. Not such a bad idea to ask "are you sure
> you
> want to publish something that everyone with web access can see?" before
> publishing.
>
> The second, when you don't want users to do something. This is a tricky
> case, but there are occasions when users must be allowed to do something
> that is not optimal for the business. Think about a subscription based
> service. Putting a small roadblock in front of users who want to cancel
> their accounts can be huge.
>
> Of course, I think that confirmation dialogs are frequently abused and
> products of poor product design or messaging. In the subscription based
> service example above - isn't there a better way to increase lifetime
> value
> of users than preventing them from leaving? There probably is.
>
> --
> Josh Viney
> EastMedia Group
> http://www.eastmedia.com
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

10 Jun 2007 - 8:49pm
cfmdesigns
2004

On Jun 10, 2007, at 7:28 AM, Paul Nuschke wrote:

> I think that Cooper says in About Face or maybe "Inmates" that
> these prompts
> are really there to hide flaws in the software and I think that is
> a good
> guiding principle.
>
> However, I can think of at least two prompts which are pretty
> useful. One of
> the most obvious prompts is the Yes/No/Cancel dialog that many apps
> use when
> you make changes and don't save them before you attempt to exit. It
> is far
> easier to ask before they leave if they want to save those changes
> than when
> they return.

I though About Face was pretty clear that this was one of the worst
places to put that sort of an alert. Why do we need to remind the
user to save? Why can't we just do the save for him? (And stash a
temp copy of the original file to revert back to if needed, tossing
it when he closes the doc with its changes.) The only reason we
"need" this alert is that we've always had it, so users are trained
to think that they need to explicitly save and thus that if they
don't save, their changes are reverted.

> Another useful prompt is when an action may take a long time
> and it is difficult to note that through the interface (this latter
> prompt
> may be helpful initially but annoying later, so the user should be
> able to
> disable it).

Wasn't this one also pooh-poohed there? If not, it should have
been. Don't tell the user "Hey, wait, we're not going to start
this long long operation yet, we're going to wait a while longer
and slow you down more by simply telling you it will take a while --
and not even let you cancel." Have a status/progress indicator that
gives that info instead. And make the application multi-threaded so
as few action block the process as possible.

-- Jim

11 Jun 2007 - 7:31am
pnuschke
2007

I don't recall which prompts he specifically disliked. Word has a dialog
similar to what Cooper was suggesting (the "recovery" dialog when there is a
cached version and the original) and it is much more confusing than a
Yes/No/Cancel prompt because it's often not in context. Imagine is you make
edits in Word and close it out, knowing that you didn't want to save the
changes. Then you go off to do something and don't get back to the document
until the next day. Would you remember which version was which?

You make the point that these prompts are only necessary because we are
trained to explicitly save. If you have a new interface where this auto-save
paradigm works, then it makes sense. But if you are a Word user and rely on
Yes/No/Cancel when you exit a document to either save or discard your
changes, then changing that paradigm is going to cause a lot of confusion
and problems.

Regarding the operations that take a long time, there are unfortunately some
operations (such as database processing) where it is very difficult to offer
a stop button on a progress indicator. And it is not always evident how long
the operation will take beforehand (especially to new users), so a prompt is
warranted. It's not perfect, but it's better than accidentally starting an
operation that takes half an hour.

You also have to evaluate the cost-benefit of using a prompt or trying to
code the prompt out. The prompt is almost always much shorter, so while
ideally we'd live in a prompt free world, I don't think that it is going to
happen any day soon. :)

Paul

On 6/10/07, Jim Drew <cfmdesigns at earthlink.net> wrote:
>
>
> On Jun 10, 2007, at 7:28 AM, Paul Nuschke wrote:
>
> > I think that Cooper says in About Face or maybe "Inmates" that
> > these prompts
> > are really there to hide flaws in the software and I think that is
> > a good
> > guiding principle.
> >
> > However, I can think of at least two prompts which are pretty
> > useful. One of
> > the most obvious prompts is the Yes/No/Cancel dialog that many apps
> > use when
> > you make changes and don't save them before you attempt to exit. It
> > is far
> > easier to ask before they leave if they want to save those changes
> > than when
> > they return.
>
> I though About Face was pretty clear that this was one of the worst
> places to put that sort of an alert. Why do we need to remind the
> user to save? Why can't we just do the save for him? (And stash a
> temp copy of the original file to revert back to if needed, tossing
> it when he closes the doc with its changes.) The only reason we
> "need" this alert is that we've always had it, so users are trained
> to think that they need to explicitly save and thus that if they
> don't save, their changes are reverted.
>
>
> > Another useful prompt is when an action may take a long time
> > and it is difficult to note that through the interface (this latter
> > prompt
> > may be helpful initially but annoying later, so the user should be
> > able to
> > disable it).
>
> Wasn't this one also pooh-poohed there? If not, it should have
> been. Don't tell the user "Hey, wait, we're not going to start
> this long long operation yet, we're going to wait a while longer
> and slow you down more by simply telling you it will take a while --
> and not even let you cancel." Have a status/progress indicator that
> gives that info instead. And make the application multi-threaded so
> as few action block the process as possible.
>
> -- Jim
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

11 Jun 2007 - 8:38am
jrrogan
2005

It seems that stating that "confirmation dialogs are insulting and stupid,
to be avoided at all
costs " is a similar generalization as Jakobs, "99% of Flash is bad" or some
such statement by Mr. Usability.

Egregious and unthinking usage of any UI feature is "insulting and stupid,
to be avoided at all
costs". Generalizations shouldn't be strict rules for experienced
designers. There's got to be a plethora of good reasons to have
confirmation/cancel buttons, such as...

Engineering doesn't have resources to build in undo feature, so at a minimum
you want to make sure the user clicked the right button, (imagine usability
requirements getting cut for more feature requirements, anyone else heard of
this happening???)

Or user's may be model information then save when they're done. Saving
before they're finished modeling could cause big problems, a simple
confirmation slows the user down, and gets them to consider at least a bit
of what they're committing themselves too. Note the above scenario is
simplified as there can be draft state/undo/work flow/etc.

Other applications may be legal in nature where confirmation is a safeguard
for all parties.

and the list goes on...

11 Jun 2007 - 1:51pm
cfmdesigns
2004

>From: Paul Nuschke <plnii11 at gmail.com>
>
>You make the point that these prompts are only necessary because we are
>trained to explicitly save. If you have a new interface where this auto-save
>paradigm works, then it makes sense. But if you are a Word user and rely on
>Yes/No/Cancel when you exit a document to either save or discard your
>changes, then changing that paradigm is going to cause a lot of confusion
>and problems.

What I meant there is that the world of computing has become so used to the "Don't forget to save" alert that even though it is inferior to "save as you go" behaviors, it's a pipe dream to think that we are likely to be able to escape from it. People are so trained that you have to do an explicit save that they don't trust or rebel against apps which do the "right" thing, because it goes against the societal norm and thus is "wrong". Produce an app that does things "right" and you'll likely be shunned for bucking the trend.

The only app I regular use that does such "save as you go" is FileMaker, and even knowing better, I find myself regularly running up against this wall, both trying to do explicit saves and having to keep close tabs on my work such that I don't accidentally hit an ejector seat and delete or mangle data. (Which means, of course, that the app doesn't have adequate undo and restore mechanisms to buffer the autosave power.)

>Regarding the operations that take a long time, there are unfortunately some
>operations (such as database processing) where it is very difficult to offer
>a stop button on a progress indicator. And it is not always evident how long
>the operation will take beforehand (especially to new users), so a prompt is
>warranted. It's not perfect, but it's better than accidentally starting an
>operation that takes half an hour.

There are two types of these "takes a while" alerts: the ones that let you cancel before starting and the ones which simply inform and don't allow cancel. The latter are the big offenders: if I can't stop you, just get on with it.

I would bow to having alerts for unstoppable activities of unknowable duration. For stoppable ones, though, and for either stoppable or unstoppable known duration ones, don't bother with the alert. Just put the right sort of progress indicator up -- filling bar for known duration, scrolling or bouncing barlet for unknown duration -- and get on with it. (Of course, add some animation indicator to sweep the user's attention to the newly added progress indicator to make sure he knows what's up, and have good labelling and all that.)

>You also have to evaluate the cost-benefit of using a prompt or trying to
>code the prompt out. The prompt is almost always much shorter, so while
>ideally we'd live in a prompt free world, I don't think that it is going to
>happen any day soon. :)

Ah, yes: we don't have time in the schedule (read: didn't put enough time in) to do it right, so we'll just hack in an alert that stops the user in his tracks, and we'll say that's "the design". Poor planning is the very worst reason for tying up the user and leaving him for the hot sun and the ants.

-- Jim

11 Jun 2007 - 7:06pm
Alan Cooper
2004

Jim, et al,

"... there are unfortunately some operations (such as database
processing) where it is very difficult to offer a stop button on a
progress indicator ..."

All software is "very difficult." Offering a "stop button or a
progress indicator" is always possible.

Good interaction design is much more of a power play between
programmers having fun playing with their toys and interaction designers
looking out for the needs of users than it is a puzzle for someone to
solve. Confirmation dialogs simply don't achieve the goals they are
asked to. Making everything undo-able does.

Pardon me, I must go play with my toys now.

Good luck,
Alan

PS. I understand that we must compromise with the larger forces of
business that buffet us, but that doesn't mean we have to become
quislings. Just because they force ill-chosen compromises upon us does
not mean that we are required to justify them as being necessary or even
adequate.

__________
Cooper | design for a digital world
Alan Cooper
alan at cooper.com | www.cooper.com
__________
"Starbucks is selling a public gathering place. Coffee is the enabling
mechanism."-James Howard Kunstler

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Paul Nuschke
Sent: Monday, June 11, 2007 6:32 AM
To: Jim Drew
Cc: ixd-discussion
Subject: Re: [IxDA Discuss] Confirmation dialogs - the devil himself,or
a necessary evil?

I don't recall which prompts he specifically disliked. Word has a dialog
similar to what Cooper was suggesting (the "recovery" dialog when there
is a
cached version and the original) and it is much more confusing than a
Yes/No/Cancel prompt because it's often not in context. Imagine is you
make
edits in Word and close it out, knowing that you didn't want to save the
changes. Then you go off to do something and don't get back to the
document
until the next day. Would you remember which version was which?

You make the point that these prompts are only necessary because we are
trained to explicitly save. If you have a new interface where this
auto-save
paradigm works, then it makes sense. But if you are a Word user and rely
on
Yes/No/Cancel when you exit a document to either save or discard your
changes, then changing that paradigm is going to cause a lot of
confusion
and problems.

Regarding the operations that take a long time, there are unfortunately
some
operations (such as database processing) where it is very difficult to
offer
a stop button on a progress indicator. And it is not always evident how
long
the operation will take beforehand (especially to new users), so a
prompt is
warranted. It's not perfect, but it's better than accidentally starting
an
operation that takes half an hour.

You also have to evaluate the cost-benefit of using a prompt or trying
to
code the prompt out. The prompt is almost always much shorter, so while
ideally we'd live in a prompt free world, I don't think that it is going
to
happen any day soon. :)

Paul

On 6/10/07, Jim Drew <cfmdesigns at earthlink.net> wrote:
>
>
> On Jun 10, 2007, at 7:28 AM, Paul Nuschke wrote:
>
> > I think that Cooper says in About Face or maybe "Inmates" that
> > these prompts
> > are really there to hide flaws in the software and I think that is
> > a good
> > guiding principle.
> >
> > However, I can think of at least two prompts which are pretty
> > useful. One of
> > the most obvious prompts is the Yes/No/Cancel dialog that many apps
> > use when
> > you make changes and don't save them before you attempt to exit. It
> > is far
> > easier to ask before they leave if they want to save those changes
> > than when
> > they return.
>
> I though About Face was pretty clear that this was one of the worst
> places to put that sort of an alert. Why do we need to remind the
> user to save? Why can't we just do the save for him? (And stash a
> temp copy of the original file to revert back to if needed, tossing
> it when he closes the doc with its changes.) The only reason we
> "need" this alert is that we've always had it, so users are trained
> to think that they need to explicitly save and thus that if they
> don't save, their changes are reverted.
>
>
> > Another useful prompt is when an action may take a long time
> > and it is difficult to note that through the interface (this latter
> > prompt
> > may be helpful initially but annoying later, so the user should be
> > able to
> > disable it).
>
> Wasn't this one also pooh-poohed there? If not, it should have
> been. Don't tell the user "Hey, wait, we're not going to start
> this long long operation yet, we're going to wait a while longer
> and slow you down more by simply telling you it will take a while --
> and not even let you cancel." Have a status/progress indicator that
> gives that info instead. And make the application multi-threaded so
> as few action block the process as possible.
>
> -- Jim
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

11 Jun 2007 - 7:08pm
Alan Cooper
2004

Jim,

I miss-addressed my last posting to you rather than to Paul, the
actual author of the comments I quoted. Maybe someday I'll have an email
program that doesn't suck.

Thanx,
Alan

__________
Cooper | design for a digital world
Alan Cooper
alan at cooper.com | www.cooper.com
__________
"Starbucks is selling a public gathering place. Coffee is the enabling
mechanism."-James Howard Kunstler

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Paul Nuschke
Sent: Monday, June 11, 2007 6:32 AM
To: Jim Drew
Cc: ixd-discussion
Subject: Re: [IxDA Discuss] Confirmation dialogs - the devil himself,or
a necessary evil?

I don't recall which prompts he specifically disliked. Word has a dialog
similar to what Cooper was suggesting (the "recovery" dialog when there
is a
cached version and the original) and it is much more confusing than a
Yes/No/Cancel prompt because it's often not in context. Imagine is you
make
edits in Word and close it out, knowing that you didn't want to save the
changes. Then you go off to do something and don't get back to the
document
until the next day. Would you remember which version was which?

You make the point that these prompts are only necessary because we are
trained to explicitly save. If you have a new interface where this
auto-save
paradigm works, then it makes sense. But if you are a Word user and rely
on
Yes/No/Cancel when you exit a document to either save or discard your
changes, then changing that paradigm is going to cause a lot of
confusion
and problems.

Regarding the operations that take a long time, there are unfortunately
some
operations (such as database processing) where it is very difficult to
offer
a stop button on a progress indicator. And it is not always evident how
long
the operation will take beforehand (especially to new users), so a
prompt is
warranted. It's not perfect, but it's better than accidentally starting
an
operation that takes half an hour.

You also have to evaluate the cost-benefit of using a prompt or trying
to
code the prompt out. The prompt is almost always much shorter, so while
ideally we'd live in a prompt free world, I don't think that it is going
to
happen any day soon. :)

Paul

On 6/10/07, Jim Drew <cfmdesigns at earthlink.net> wrote:
>
>
> On Jun 10, 2007, at 7:28 AM, Paul Nuschke wrote:
>
> > I think that Cooper says in About Face or maybe "Inmates" that
> > these prompts
> > are really there to hide flaws in the software and I think that is
> > a good
> > guiding principle.
> >
> > However, I can think of at least two prompts which are pretty
> > useful. One of
> > the most obvious prompts is the Yes/No/Cancel dialog that many apps
> > use when
> > you make changes and don't save them before you attempt to exit. It
> > is far
> > easier to ask before they leave if they want to save those changes
> > than when
> > they return.
>
> I though About Face was pretty clear that this was one of the worst
> places to put that sort of an alert. Why do we need to remind the
> user to save? Why can't we just do the save for him? (And stash a
> temp copy of the original file to revert back to if needed, tossing
> it when he closes the doc with its changes.) The only reason we
> "need" this alert is that we've always had it, so users are trained
> to think that they need to explicitly save and thus that if they
> don't save, their changes are reverted.
>
>
> > Another useful prompt is when an action may take a long time
> > and it is difficult to note that through the interface (this latter
> > prompt
> > may be helpful initially but annoying later, so the user should be
> > able to
> > disable it).
>
> Wasn't this one also pooh-poohed there? If not, it should have
> been. Don't tell the user "Hey, wait, we're not going to start
> this long long operation yet, we're going to wait a while longer
> and slow you down more by simply telling you it will take a while --
> and not even let you cancel." Have a status/progress indicator that
> gives that info instead. And make the application multi-threaded so
> as few action block the process as possible.
>
> -- Jim
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

11 Jun 2007 - 7:17pm
Alan Cooper
2004

Paul, et al,

"Word has a dialog similar to what Cooper was suggesting (the
"recovery" dialog when there is a cached version and the original) and
it is much more confusing than a Yes/No/Cancel prompt because it's often
not in context. "

"...it is much more confusing..." not because the original problem
wasn't so bothersome, but because the new solution is even worse.

I generally find that Microsoft does not offer stellar examples of how
Things Should Be Done. They do have the single bold characteristic of
being omnipresent, but that confers nothing on their design cred. If
they attempt to solve a problem with a new design, and that design
fails, it should not reflect *anything* back on the quality of the
original problem. It should simply be noted that Microsoft, once again,
tried and failed (and they will certainly try and fail many more times,
proving once again that Thomas Edison's reliance on brute force as a
product development tool has longer legs than any of us might wish for).

Good luck,
Alan

__________
Cooper | design for a digital world
Alan Cooper
alan at cooper.com | www.cooper.com
__________
"Starbucks is selling a public gathering place. Coffee is the enabling
mechanism."-James Howard Kunstler

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Paul Nuschke
Sent: Monday, June 11, 2007 6:32 AM
To: Jim Drew
Cc: ixd-discussion
Subject: Re: [IxDA Discuss] Confirmation dialogs - the devil himself,or
a necessary evil?

I don't recall which prompts he specifically disliked. Word has a dialog
similar to what Cooper was suggesting (the "recovery" dialog when there
is a
cached version and the original) and it is much more confusing than a
Yes/No/Cancel prompt because it's often not in context. Imagine is you
make
edits in Word and close it out, knowing that you didn't want to save the
changes. Then you go off to do something and don't get back to the
document
until the next day. Would you remember which version was which?

You make the point that these prompts are only necessary because we are
trained to explicitly save. If you have a new interface where this
auto-save
paradigm works, then it makes sense. But if you are a Word user and rely
on
Yes/No/Cancel when you exit a document to either save or discard your
changes, then changing that paradigm is going to cause a lot of
confusion
and problems.

Regarding the operations that take a long time, there are unfortunately
some
operations (such as database processing) where it is very difficult to
offer
a stop button on a progress indicator. And it is not always evident how
long
the operation will take beforehand (especially to new users), so a
prompt is
warranted. It's not perfect, but it's better than accidentally starting
an
operation that takes half an hour.

You also have to evaluate the cost-benefit of using a prompt or trying
to
code the prompt out. The prompt is almost always much shorter, so while
ideally we'd live in a prompt free world, I don't think that it is going
to
happen any day soon. :)

Paul

On 6/10/07, Jim Drew <cfmdesigns at earthlink.net> wrote:
>
>
> On Jun 10, 2007, at 7:28 AM, Paul Nuschke wrote:
>
> > I think that Cooper says in About Face or maybe "Inmates" that
> > these prompts
> > are really there to hide flaws in the software and I think that is
> > a good
> > guiding principle.
> >
> > However, I can think of at least two prompts which are pretty
> > useful. One of
> > the most obvious prompts is the Yes/No/Cancel dialog that many apps
> > use when
> > you make changes and don't save them before you attempt to exit. It
> > is far
> > easier to ask before they leave if they want to save those changes
> > than when
> > they return.
>
> I though About Face was pretty clear that this was one of the worst
> places to put that sort of an alert. Why do we need to remind the
> user to save? Why can't we just do the save for him? (And stash a
> temp copy of the original file to revert back to if needed, tossing
> it when he closes the doc with its changes.) The only reason we
> "need" this alert is that we've always had it, so users are trained
> to think that they need to explicitly save and thus that if they
> don't save, their changes are reverted.
>
>
> > Another useful prompt is when an action may take a long time
> > and it is difficult to note that through the interface (this latter
> > prompt
> > may be helpful initially but annoying later, so the user should be
> > able to
> > disable it).
>
> Wasn't this one also pooh-poohed there? If not, it should have
> been. Don't tell the user "Hey, wait, we're not going to start
> this long long operation yet, we're going to wait a while longer
> and slow you down more by simply telling you it will take a while --
> and not even let you cancel." Have a status/progress indicator that
> gives that info instead. And make the application multi-threaded so
> as few action block the process as possible.
>
> -- Jim
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

11 Jun 2007 - 7:28pm
Alan Cooper
2004

Paul, et al,

" But if you are a Word user and rely on Yes/No/Cancel when you exit a
document to either save or discard your changes, then changing that
paradigm is going to cause a lot of confusion and problems."

While this is factual, it doesn't really represent the truth. Changing
paradigms does indeed cause problems. But living day to day with a bad
paradigm *also* causes problems. Changing from a bad paradigm to a
different, but equally bad, paradigm, does, indeed, raise the Net
Problem Quotient. However, changing from a bad paradigm to a good
paradigm eliminates the problem source in perpetuity, which lowers the
Net Problem Quotient.

Yes, there are hundreds of millions of people out there using Word who
are all too familiar with confirmation dialogs, but it seems awfully
funny to me that we haven't heard too many of them squawk about Outlook,
which doesn't have them, and yet it purports to be a good little Windows
app, too. The facts contradict our expectations.

Our guts tell us that changing dialogs in the face of hundreds of
millions of users is bad, but interaction design is a discipline where
relying on our gut instinct typically doesn't work well.

Good luck,
Alan

__________
Cooper | design for a digital world
Alan Cooper
alan at cooper.com | www.cooper.com
__________
"Starbucks is selling a public gathering place. Coffee is the enabling
mechanism."-James Howard Kunstler

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Paul Nuschke
Sent: Monday, June 11, 2007 6:32 AM
To: Jim Drew
Cc: ixd-discussion
Subject: Re: [IxDA Discuss] Confirmation dialogs - the devil himself,or
a necessary evil?

I don't recall which prompts he specifically disliked. Word has a dialog
similar to what Cooper was suggesting (the "recovery" dialog when there
is a
cached version and the original) and it is much more confusing than a
Yes/No/Cancel prompt because it's often not in context. Imagine is you
make
edits in Word and close it out, knowing that you didn't want to save the
changes. Then you go off to do something and don't get back to the
document
until the next day. Would you remember which version was which?

You make the point that these prompts are only necessary because we are
trained to explicitly save. If you have a new interface where this
auto-save
paradigm works, then it makes sense. But if you are a Word user and rely
on
Yes/No/Cancel when you exit a document to either save or discard your
changes, then changing that paradigm is going to cause a lot of
confusion
and problems.

Regarding the operations that take a long time, there are unfortunately
some
operations (such as database processing) where it is very difficult to
offer
a stop button on a progress indicator. And it is not always evident how
long
the operation will take beforehand (especially to new users), so a
prompt is
warranted. It's not perfect, but it's better than accidentally starting
an
operation that takes half an hour.

You also have to evaluate the cost-benefit of using a prompt or trying
to
code the prompt out. The prompt is almost always much shorter, so while
ideally we'd live in a prompt free world, I don't think that it is going
to
happen any day soon. :)

Paul

On 6/10/07, Jim Drew <cfmdesigns at earthlink.net> wrote:
>
>
> On Jun 10, 2007, at 7:28 AM, Paul Nuschke wrote:
>
> > I think that Cooper says in About Face or maybe "Inmates" that
> > these prompts
> > are really there to hide flaws in the software and I think that is
> > a good
> > guiding principle.
> >
> > However, I can think of at least two prompts which are pretty
> > useful. One of
> > the most obvious prompts is the Yes/No/Cancel dialog that many apps
> > use when
> > you make changes and don't save them before you attempt to exit. It
> > is far
> > easier to ask before they leave if they want to save those changes
> > than when
> > they return.
>
> I though About Face was pretty clear that this was one of the worst
> places to put that sort of an alert. Why do we need to remind the
> user to save? Why can't we just do the save for him? (And stash a
> temp copy of the original file to revert back to if needed, tossing
> it when he closes the doc with its changes.) The only reason we
> "need" this alert is that we've always had it, so users are trained
> to think that they need to explicitly save and thus that if they
> don't save, their changes are reverted.
>
>
> > Another useful prompt is when an action may take a long time
> > and it is difficult to note that through the interface (this latter
> > prompt
> > may be helpful initially but annoying later, so the user should be
> > able to
> > disable it).
>
> Wasn't this one also pooh-poohed there? If not, it should have
> been. Don't tell the user "Hey, wait, we're not going to start
> this long long operation yet, we're going to wait a while longer
> and slow you down more by simply telling you it will take a while --
> and not even let you cancel." Have a status/progress indicator that
> gives that info instead. And make the application multi-threaded so
> as few action block the process as possible.
>
> -- Jim
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

11 Jun 2007 - 7:42pm
Oleh Kovalchuke
2006

An example of useful transitional dialog box by the notorious IxD-evil-doers
is attached. It is helpful for the people, like myself, who got used to one
tab per window paradigm. Eventually I will dismiss this confirmation box via
provided option...

But wait! I am having second thought... I guess, much better option would
have been to reopen the same browser tabs with the same URLs (as well as
browsing history) I had, when I closed the window. Oh well, some day the
prince will come...

But wait! ... Nope, false alarm...

--
Oleh Kovalchuke
Interaction Design is the Design of Time
http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm

On 6/11/07, Alan Cooper <Alan at cooper.com> wrote:
>
> Paul, et al,
>
> "Word has a dialog similar to what Cooper was suggesting (the
> "recovery" dialog when there is a cached version and the original) and
> it is much more confusing than a Yes/No/Cancel prompt because it's often
> not in context. "
>
> "...it is much more confusing..." not because the original problem
> wasn't so bothersome, but because the new solution is even worse.
>
> I generally find that Microsoft does not offer stellar examples of how
> Things Should Be Done. They do have the single bold characteristic of
> being omnipresent, but that confers nothing on their design cred. If
> they attempt to solve a problem with a new design, and that design
> fails, it should not reflect *anything* back on the quality of the
> original problem. It should simply be noted that Microsoft, once again,
> tried and failed (and they will certainly try and fail many more times,
> proving once again that Thomas Edison's reliance on brute force as a
> product development tool has longer legs than any of us might wish for).
>
> Good luck,
> Alan
>
> __________
> Cooper | design for a digital world
> Alan Cooper
> alan at cooper.com | www.cooper.com
> __________
> "Starbucks is selling a public gathering place. Coffee is the enabling
> mechanism."-James Howard Kunstler
>
>
> -----Original Message-----
> From: discuss-bounces at lists.interactiondesigners.com
> [mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
> Paul Nuschke
> Sent: Monday, June 11, 2007 6:32 AM
> To: Jim Drew
> Cc: ixd-discussion
> Subject: Re: [IxDA Discuss] Confirmation dialogs - the devil himself,or
> a necessary evil?
>
> I don't recall which prompts he specifically disliked. Word has a dialog
> similar to what Cooper was suggesting (the "recovery" dialog when there
> is a
> cached version and the original) and it is much more confusing than a
> Yes/No/Cancel prompt because it's often not in context. Imagine is you
> make
> edits in Word and close it out, knowing that you didn't want to save the
> changes. Then you go off to do something and don't get back to the
> document
> until the next day. Would you remember which version was which?
>
> You make the point that these prompts are only necessary because we are
> trained to explicitly save. If you have a new interface where this
> auto-save
> paradigm works, then it makes sense. But if you are a Word user and rely
> on
> Yes/No/Cancel when you exit a document to either save or discard your
> changes, then changing that paradigm is going to cause a lot of
> confusion
> and problems.
>
> Regarding the operations that take a long time, there are unfortunately
> some
> operations (such as database processing) where it is very difficult to
> offer
> a stop button on a progress indicator. And it is not always evident how
> long
> the operation will take beforehand (especially to new users), so a
> prompt is
> warranted. It's not perfect, but it's better than accidentally starting
> an
> operation that takes half an hour.
>
> You also have to evaluate the cost-benefit of using a prompt or trying
> to
> code the prompt out. The prompt is almost always much shorter, so while
> ideally we'd live in a prompt free world, I don't think that it is going
> to
> happen any day soon. :)
>
> Paul
>
>
> On 6/10/07, Jim Drew <cfmdesigns at earthlink.net> wrote:
> >
> >
> > On Jun 10, 2007, at 7:28 AM, Paul Nuschke wrote:
> >
> > > I think that Cooper says in About Face or maybe "Inmates" that
> > > these prompts
> > > are really there to hide flaws in the software and I think that is
> > > a good
> > > guiding principle.
> > >
> > > However, I can think of at least two prompts which are pretty
> > > useful. One of
> > > the most obvious prompts is the Yes/No/Cancel dialog that many apps
> > > use when
> > > you make changes and don't save them before you attempt to exit. It
> > > is far
> > > easier to ask before they leave if they want to save those changes
> > > than when
> > > they return.
> >
> > I though About Face was pretty clear that this was one of the worst
> > places to put that sort of an alert. Why do we need to remind the
> > user to save? Why can't we just do the save for him? (And stash a
> > temp copy of the original file to revert back to if needed, tossing
> > it when he closes the doc with its changes.) The only reason we
> > "need" this alert is that we've always had it, so users are trained
> > to think that they need to explicitly save and thus that if they
> > don't save, their changes are reverted.
> >
> >
> > > Another useful prompt is when an action may take a long time
> > > and it is difficult to note that through the interface (this latter
> > > prompt
> > > may be helpful initially but annoying later, so the user should be
> > > able to
> > > disable it).
> >
> > Wasn't this one also pooh-poohed there? If not, it should have
> > been. Don't tell the user "Hey, wait, we're not going to start
> > this long long operation yet, we're going to wait a while longer
> > and slow you down more by simply telling you it will take a while --
> > and not even let you cancel." Have a status/progress indicator that
> > gives that info instead. And make the application multi-threaded so
> > as few action block the process as possible.
> >
> > -- Jim
> >
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://listguide.ixda.org/
> > List Help .................. http://listhelp.ixda.org/
> > (Un)Subscription Options ... http://subscription-options.ixda.org/
> > Announcements List ......... http://subscribe-announce.ixda.org/
> > Questions .................. lists at ixda.org
> > Home ....................... http://ixda.org/
> > Resource Library ........... http://resources.ixda.org
> >
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: an example of useful dialog box.jpg
Type: image/jpeg
Size: 58161 bytes
Desc: not available
Url : http://lists.interactiondesigners.com/pipermail/discuss-interactiondesigners.com/attachments/20070611/975b6456/attachment.jpg

12 Jun 2007 - 10:02am
pnuschke
2007

>
> "Yes, there are hundreds of millions of people out there using Word who
> are all too familiar with confirmation dialogs, but it seems awfully
> funny to me that we haven't heard too many of them squawk about Outlook,
> which doesn't have them, and yet it purports to be a good little Windows
> app, too. The facts contradict our expectations."

Thanks for the comments, Alan.

Not trying to be contrarian, but Outlook does have prompts. Try to empty
your deleted items and you will get a prompt about it being permanent. Or
create a mail message and exit it- you will see the Yes/No/Cancel prompt.
The big difference is that you can delete from the calendar or your inbox
without getting hassled.

I think we are on the same page regarding the delete prompts--- for every
such prompt I've seen there is a fairly easy way to provide undo. Outlook
actually does this right (or close to right) by prompting only when you're
deleting your undo cache/trash bin. But I agree that MS is not exactly one
to look at for how to do things normally. For example, they provide a
recycling bin for XP, but then they insist on prompting every time you
delete anyway! (BTW, if this annoys anyone, you can turn it off by
right-clicking the bin and unchecking a box).

Paul

12 Jun 2007 - 8:16pm
Billie Mandel
2005

Alan -

Thanks for chiming in - I was hoping you would :-)

You said:

"Good interaction design is much more of a power play between
programmers having fun playing with their toys and interaction designers
looking out for the needs of users than it is a puzzle for someone to
solve."

I'd say it's both - in particular when designing in constrained
spaces/devices. You're always going to have the
people/communication/negotiation piece in product development - that's
one of the things that makes my job, at least, fun and exciting.

I do think that there is a "puzzle to be solved" aspect of designing
within technology constraints (such as what we've got in the mobile
space, with small screens, hardware predefinitions, weird technical
"what's under the hood-ness" like client/server models and memory
constraints, and operator requirements). To me it's kind of like
writing sonnets - some of the beauty comes from the overall finesse of
the craft, and some of it comes from fitting artfully into that very
defined structure.

Which brings me to:
"Confirmation dialogs simply don't achieve the goals they are
asked to. Making everything undo-able does."

I totally agree. However -- I'm working in a constrained technology
space that (in the words of a designer I interviewed recently) can be
compared to designing for the Atari. Fewer pixels with which to
gracefully warn users what's going to happen when they press button X,
less memory in which to cache things on the device and from which to
restore them if they are mistakenly deleted. Plus, less contextual
patience within the users' mental models for waiting for operations that
take their sweet time to talk to the server.

To me, at least, this is a very interesting set of problems. How would
you say these type of constraints change the discussion?

Cheers,
- Billie

* * * * * * *
Billie Mandel
Manager, User Experience Design & Research
OPENWAVE
billie.mandel at openwave.com

13 Jun 2007 - 1:21pm
Shaun Bergmann
2007

In general, I also agree that in most cases they are insulting and at
least annoying, if not stupid. However, to answer your question, I
can think of situations where they may indeed be a necessary evil.

When working with touchpanel interfaces that control various physical
subsystems of an automation system for example, a single button push
may result in a drastic system wide change in state. For example: a
'Vacation Mode' button may trigger a series of events including
locking out certain gates, shutting down pool systems, activating
security partitions in remote locations, opening the gates on the
moat etc.

You, the end user, better be darned sure that you REALLY wanted to do
this. There will not be a simple 'undo' presented to you, and what
you are about to launch could take 2 or 3 minutes to complete.

A less severe situation could be something more benign like turning
off your home theatre system. The simple 'power off' button again
triggers a series of events, and it's entirely possible that the
equipment requires a cooldown period before it can be turned on
again. Not quite releasing the hounds, but still extremely annoying
if you 'accidentally' touched the 'home' then
'power off' button when picking up the touchpanel from the
sofa.

There are two solutions that I can see:

1. The devil incarnate: the Confirmation Dialog.
2. Obfuscation of button location (better hiding the ejector seat
lever)

To abolish the confirmation dialog box in this case (Are you
SURE you want to release the hounds? Yes / No) you are forced to
increase the cognitive / motion steps required to achieve the desired
result. You've possibly made it difficult now for a new user to
figure out how to 'just turn the darned thing off'.

Human error is always lurking, so of the two options, how to better
protect the user from an undesired result?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=17129

13 Jun 2007 - 1:40pm
Alan Cooper
2004

Billie,

Thanks for the dialog.

"I'd say it's both..."

Agreed. I use this analogy: interaction designers are like Yo-yo Ma
playing his cello on the ramp at SFO, with the jumbo jets taxiing by and
taking off on the nearby runway being the business/programming duopoly.
Regardless of Yo-yo's quality and volume, the noise of the jets
overwhelms. This doesn't detract from the virtuosity of his playing, it
just means the ambient noise problem dwarfs the musical one. While we
are solving the puzzle, they are winning because they own the code and
the money.

"I'm working in a constrained technology.... Fewer pixels ... less
memory ... "

I've heard that same justification from programmers and business
people quite a bit. I don't buy it. I simply do not believe that there
is a shortage of pixels or memory. There is a shortage of respect for
humans. There is also a severe shortage of product development
expertise.

For example, I want to buy a navigator for my new truck (because
pickups don't come with integral nav systems yet). All of the latest nav
devices are offering mp3 players, photo storage, texting, and voice
recognition. These are memory and pixel hog solutions looking for a
problem that doesn't exist, while ignoring the real problem that nav
systems are notoriously hard to use FOR NAVIGATION. The pixels and the
memory are there. They are being squandered by people who should not
have the authority to design products. I want a good nav system. An mp3
player is a nice-to-have, but ONLY after the nav problem is solved.*

Interaction design is product design. Product design is determining
what is needed to achieve the user's goals, and then marshalling the
technology to accomplish them. Techno-biznics make pre-emptive decisions
based on instinct, hearsay, and self-interest, then they tell us
user-advocates that "there isn't enough ______ to do that." It's like
saying that a piece of string is too short. Yes. It's too short because
some idiot cut it before they knew how long it needed to be.

Funny, but all of the users of mobile devices that I have ever
observed fall into two distinct camps: Apologists and survivors.

Yes, we are often tasked with designing interactions within
pre-determined resource constraints. This burdens us with TWO
responsibilities: 1) inform the pre-determiners that they have screwed
up big time; and 2) make lemonade. It is my personal opinion that we
should devote about 75% of our time and energy to addressing
responsibility #1, and the remaining 25% to responsibility #2. If we
don't do this, it just means that *we* will be blamed for the inevitable
failure of the product, and the true perpetrators--the
pre-determiners--will be exonerated.

"...less contextual patience within the users' mental models for waiting
for operations that take their sweet time to talk to the server."

I think you have the cart before the horse here. Humans haven't
changed much over the last hundred decades or so. They don't have any
less patience than they ever did. What has changed is our attitude that
technology is the given and that it is we humans who are/can/must
change. Operations that take their sweet time talking to the server may
be inevitable, but dropping that minor technical problem in the user's
lap is an indication of shitty design and implementation.

Thanx,
Alan

PS. "Shitty" as applied to design and implementation is a technical term
of great expressiveness and sophistication.

PPS. I kind of like that term, "business/programming duopoly". It echoes
Eisenhower's famous warning about the "military/industrial complex". The
military and industry are weak-kneed tyros compared to a gung-ho
programmer backed by a terrified MBA...

*Just for those of you who are designing in-car nav systems: I have used
nav systems for many years, and designed some, too. What is with the
landscape orientation of screens? The single biggest waste of pixels is
those wasted showing what is off to the sides instead of what is ahead;
where you are going. Simply changing the aspect ratio of nav screens to
portrait would make about a third of all pixels useful instead of
wasted.

__________
Cooper | design for a digital world
Alan Cooper
alan at cooper.com | www.cooper.com
__________
"Starbucks is selling a public gathering place. Coffee is the enabling
mechanism."-James Howard Kunstler

-----Original Message-----
From: Billie Mandel [mailto:Billie.Mandel at openwave.com]
Sent: Tuesday, June 12, 2007 7:17 PM
To: Alan Cooper; ixd-discussion
Subject: RE: [IxDA Discuss] Confirmation dialogs - the devil himself, or
a necessary evil?

Alan -

Thanks for chiming in - I was hoping you would :-)

You said:

"Good interaction design is much more of a power play between
programmers having fun playing with their toys and interaction designers
looking out for the needs of users than it is a puzzle for someone to
solve."

I'd say it's both - in particular when designing in constrained
spaces/devices. You're always going to have the
people/communication/negotiation piece in product development - that's
one of the things that makes my job, at least, fun and exciting.

I do think that there is a "puzzle to be solved" aspect of designing
within technology constraints (such as what we've got in the mobile
space, with small screens, hardware predefinitions, weird technical
"what's under the hood-ness" like client/server models and memory
constraints, and operator requirements). To me it's kind of like
writing sonnets - some of the beauty comes from the overall finesse of
the craft, and some of it comes from fitting artfully into that very
defined structure.

Which brings me to:
"Confirmation dialogs simply don't achieve the goals they are
asked to. Making everything undo-able does."

I totally agree. However -- I'm working in a constrained technology
space that (in the words of a designer I interviewed recently) can be
compared to designing for the Atari. Fewer pixels with which to
gracefully warn users what's going to happen when they press button X,
less memory in which to cache things on the device and from which to
restore them if they are mistakenly deleted. Plus, less contextual
patience within the users' mental models for waiting for operations that
take their sweet time to talk to the server.

To me, at least, this is a very interesting set of problems. How would
you say these type of constraints change the discussion?

Cheers,
- Billie

* * * * * * *
Billie Mandel
Manager, User Experience Design & Research
OPENWAVE
billie.mandel at openwave.com

13 Jun 2007 - 1:45pm
Alan Cooper
2004

shaunbergman,

It's a point of view thing.

" Human error is always lurking "

Actually, human *NATURE* is always lurking. Technologists don't
recognize this simple fact and so typically fail to deal with it, thus
introducing lots of software error and design error.

Thanx,
Alan

__________
Cooper | design for a digital world
Alan Cooper
alan at cooper.com | www.cooper.com
__________
"Starbucks is selling a public gathering place. Coffee is the enabling
mechanism."-James Howard Kunstler

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
shaunbergmann at gmail.com
Sent: Wednesday, June 13, 2007 12:22 PM
To: discuss at lists.interactiondesigners.com
Subject: Re: [IxDA Discuss] Confirmation dialogs - the devil himself,or
a necessary evil?

In general, I also agree that in most cases they are insulting and at
least annoying, if not stupid. However, to answer your question, I
can think of situations where they may indeed be a necessary evil.

When working with touchpanel interfaces that control various physical
subsystems of an automation system for example, a single button push
may result in a drastic system wide change in state. For example: a
'Vacation Mode' button may trigger a series of events including
locking out certain gates, shutting down pool systems, activating
security partitions in remote locations, opening the gates on the
moat etc.

You, the end user, better be darned sure that you REALLY wanted to do
this. There will not be a simple 'undo' presented to you, and what
you are about to launch could take 2 or 3 minutes to complete.

A less severe situation could be something more benign like turning
off your home theatre system. The simple 'power off' button again
triggers a series of events, and it's entirely possible that the
equipment requires a cooldown period before it can be turned on
again. Not quite releasing the hounds, but still extremely annoying
if you %u2018accidentally%u2019 touched the %u2018home%u2019 then
%u2018power off%u2019 button when picking up the touchpanel from the
sofa.

There are two solutions that I can see:

1. The devil incarnate: the Confirmation Dialog.
2. Obfuscation of button location (better hiding the ejector seat
lever)

To abolish the confirmation dialog box in this case (%u201CAre you
SURE you want to release the hounds? Yes / No) you are forced to
increase the cognitive / motion steps required to achieve the desired
result. You%u2019ve possibly made it difficult now for a new user to
figure out how to %u2018just turn the darned thing off%u2019.

Human error is always lurking, so of the two options, how to better
protect the user from an undesired result?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=17129

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

13 Jun 2007 - 1:52pm
cfmdesigns
2004

>From: shaunbergmann at gmail.com, shaunbergmann at gmail.com
>
>You, the end user, better be darned sure that you REALLY wanted to do
>this. There will not be a simple 'undo' presented to you, and what
>you are about to launch could take 2 or 3 minutes to complete.
>
>A less severe situation could be something more benign like turning
>off your home theatre system. The simple 'power off' button again
>triggers a series of events, and it's entirely possible that the
>equipment requires a cooldown period before it can be turned on
>again. Not quite releasing the hounds, but still extremely annoying
>if you %u2018accidentally%u2019 touched the %u2018home%u2019 then
>%u2018power off%u2019 button when picking up the touchpanel from the
>sofa.
>
>There are two solutions that I can see:
>
>1. The devil incarnate: the Confirmation Dialog.
>2. Obfuscation of button location (better hiding the ejector seat
>lever)

There's a third one you haven't listed:
3. Design the system to be more tolerant of human error and change-of-mind

Thus, in the "release the hounds" case, recognizing that the action may have been done by accident or by curiosity, and can be dangerous to foxes or groundskeepers (depending on the hound), don't code the system to release the hounds *now*, but rather to release them in 30 seconds or so.

In the prominent status area, you then put a progress counter: "Releasing hounds in 29, 28, 27... Press Abort button to stop release..." At the end of the 30 seconds -- enough time for a "Whoops, that's not what I wanted, abort" reaction, then you really do proceed with the release. (You maybe also turn on the outdoor audio "The hounds will be released in 29, 28, 27..." to warn the groundskeepers, just in case.) You would also want a means of bypassing the 30 second delay -- I know what I'm doing, release them now, it's an emergency.

(Alternately, the countdown could be done to require the confirm, automatically aborting if not confirmed in 30 seconds. Depends on whether you want to err on the side of caution or not.)

The point being that the user should have the *option* of making a choice, not be *required* to do so.

-- Jim

13 Jun 2007 - 2:56pm
Alan Cooper
2004

Jim,

Thanks for pointing out the flaws in shaunbergmann's reasoning.

"The point being that the user should have the *option* of making a
choice, not be *required* to do so."

It's really easy when you think about it...

We did some design work for a chip fab company several years ago.
Their machine contained what they euphemistically referred to a
"Two-step gas." They explained that if any of this gas escaped the
machine, humans who breathed it would take two steps AND THEN DIE.
Needless to say, releasing this gas would be bad, and undo is not an
option.

The typical technologist would simply say, "Tough beans." A good
designer would (as you pointed out) make it more involved to initially
select the risky action. The goal is to FORCE THE USER TO THINK about
what he is doing while ASSURING THAT HE IS FULLY INFORMED OF THE
CONSEQUENCES. Confirmations don't do that. But there are certainly many
ways to accomplish this. None of them are very enjoyable for typical
programmers to do, so they claim that they can't be done.

Alan

__________
Cooper | design for a digital world
Alan Cooper
alan at cooper.com | www.cooper.com
__________
"Starbucks is selling a public gathering place. Coffee is the enabling
mechanism."-James Howard Kunstler

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Jim
Drew
Sent: Wednesday, June 13, 2007 12:53 PM
To: UI List
Subject: Re: [IxDA Discuss] Confirmation dialogs - the devil himself, or
a necessary evil?

>From: shaunbergmann at gmail.com, shaunbergmann at gmail.com
>
>You, the end user, better be darned sure that you REALLY wanted to do
>this. There will not be a simple 'undo' presented to you, and what
>you are about to launch could take 2 or 3 minutes to complete.
>
>A less severe situation could be something more benign like turning
>off your home theatre system. The simple 'power off' button again
>triggers a series of events, and it's entirely possible that the
>equipment requires a cooldown period before it can be turned on
>again. Not quite releasing the hounds, but still extremely annoying
>if you %u2018accidentally%u2019 touched the %u2018home%u2019 then
>%u2018power off%u2019 button when picking up the touchpanel from the
>sofa.
>
>There are two solutions that I can see:
>
>1. The devil incarnate: the Confirmation Dialog.
>2. Obfuscation of button location (better hiding the ejector seat
>lever)

There's a third one you haven't listed:
3. Design the system to be more tolerant of human error and
change-of-mind

Thus, in the "release the hounds" case, recognizing that the action may
have been done by accident or by curiosity, and can be dangerous to
foxes or groundskeepers (depending on the hound), don't code the system
to release the hounds *now*, but rather to release them in 30 seconds or
so.

In the prominent status area, you then put a progress counter:
"Releasing hounds in 29, 28, 27... Press Abort button to stop
release..." At the end of the 30 seconds -- enough time for a "Whoops,
that's not what I wanted, abort" reaction, then you really do proceed
with the release. (You maybe also turn on the outdoor audio "The hounds
will be released in 29, 28, 27..." to warn the groundskeepers, just in
case.) You would also want a means of bypassing the 30 second delay --
I know what I'm doing, release them now, it's an emergency.

(Alternately, the countdown could be done to require the confirm,
automatically aborting if not confirmed in 30 seconds. Depends on
whether you want to err on the side of caution or not.)

The point being that the user should have the *option* of making a
choice, not be *required* to do so.

-- Jim

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

13 Jun 2007 - 2:57pm
Shaun Bergmann
2007

Alan --
'Human Nature' vs 'Human Error'...
Good point. Interesting how years and years of hearing (and
admittedly sometimes being) the apologist, my kneejerk categorization
of a user triggering an undesired result was 'Human Error'.

I'd compare it to a toddler reaching out and grabbing the cherry of
a lit cigarette in the ashtray: We certainly wouldn't blame the
blister on the baby.

Jim --
Nice! Elegant solution. With that in mind I'm definately leaning
towards the answer being 'The Devil himself'. I can't come up
with any other circumstances at this point that justify the prompt.

Unless, of course, we wanted to add one to the cancel button of the
countdown:
"Are you sure you want to cancel the countdown?"
yes / no / cancel / abort / restart"
Shaun

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=17129

13 Jun 2007 - 3:01pm
Shaun Bergmann
2007

Alan --
'Human Nature' vs 'Human Error'...
Good point. Interesting how years and years of hearing (and
admittedly sometimes being) the apologist, my kneejerk categorization
of a user triggering an undesired result was 'Human Error'.

I'd compare it to a toddler reaching out and grabbing the cherry of
a lit cigarette in the ashtray: We certainly wouldn't blame the
blister on the baby.

Jim --
Nice! Elegant solution. With that in mind I'm definately leaning
towards the answer being 'The Devil himself'. I can't come up
with any other circumstances at this point that justify the prompt.

Unless, of course, we wanted to add one to the cancel button of the
countdown:
"Are you sure you want to cancel the countdown?"
yes / no / cancel / abort / restart"
Shaun

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=17129

13 Jun 2007 - 3:13pm
Alan Cooper
2004

"Unless, of course, we wanted to add one to the cancel button of the
countdown: "Are you sure you want to cancel the countdown?"
yes / no / cancel / abort / restart""

Please, tell me that was a joke.

__________
Cooper | design for a digital world
Alan Cooper
alan at cooper.com | www.cooper.com
__________
"Starbucks is selling a public gathering place. Coffee is the enabling
mechanism."-James Howard Kunstler

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Shaun Bergmann
Sent: Wednesday, June 13, 2007 1:58 PM
To: discuss at lists.interactiondesigners.com
Subject: Re: [IxDA Discuss] Confirmation dialogs - the devil himself,or
a necessary evil?

Alan --
'Human Nature' vs 'Human Error'...
Good point. Interesting how years and years of hearing (and
admittedly sometimes being) the apologist, my kneejerk categorization
of a user triggering an undesired result was 'Human Error'.

I'd compare it to a toddler reaching out and grabbing the cherry of
a lit cigarette in the ashtray: We certainly wouldn't blame the
blister on the baby.

Jim --
Nice! Elegant solution. With that in mind I'm definately leaning
towards the answer being 'The Devil himself'. I can't come up
with any other circumstances at this point that justify the prompt.

Unless, of course, we wanted to add one to the cancel button of the
countdown:
"Are you sure you want to cancel the countdown?"
yes / no / cancel / abort / restart"
Shaun

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=17129

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

13 Jun 2007 - 3:28pm
Shaun Bergmann
2007

;) I was Definitely kidding.
I was hoping it was ridiculous enough to obviously be tongue in
cheek, but when I think of some of the prompts I've seen, I suppose
anything's possible.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=17129

Syndicate content Get the feed