Cancel vs. Go Back

26 Jul 2005 - 2:08am
9 years ago
6 replies
1073 reads
Ryan Nichols
2005

I was curious about anyone research or testing on labels for
buttons/links that return the user from an action screen. Let's say a
screen to update their information.

1) What is the preferred label? A label which denotes what the link will
do (go back where you came from) or a label that matches what the user
wants to do ("I want to cancel what I had chosen to do")
2) Should they look similar? Should they look alike to give a visual
relationship that the two 'buttons' which represent your two options, or
should they be different so the user does not accidentally hit 'cancel'
when they meant 'save'?
3) Or does all of it depend on the circumstance?

Interested to hear some of your thoughts.

Ryan Nichols
Apples To Oranges
http://www.apples-to-oranges.com

Comments

26 Jul 2005 - 6:20am
Gerard Torenvliet
2004

Ryan:

One of the important questions driving the choice of a label is what
you are going to do with the data when returning to a 'parent' screen.
If you are going to be disregarding and possibly discarding user
entries, then 'cancel' or the like is a good choice. If you are going
to be processing and acting on user entries, then 'update' or
'confirm' or the like is a good choice. If you are moving between a
set of view only screens, then 'back' is probably a good choice.

The other point that you raise is the importance of letting people
know where they will be going back to. This can be implicit in the
design (think of modal dialogs in Windows / Mac), or a conscious
addition (a statement that instructs people, "click update to save
your changes and return to x").

In terms of the location of the buttons, in the Windows world a
defacto standard has developed in which the cancelling button is to
the right and the action button is to the left. Lots of designs seem
to follow this convention (e.g., the order of processing buttons on
GMail is, left to right, SEND [most critical action], SAVE DRAFT
[temporary action], and DISCARD [like cancel]).

I don't know about any user research on this. It's all pretty defacto,
and few seem to contradict it.

Hope that helps,
-Gerard

On 26/07/05, Ryan Nichols <info at apples-to-oranges.com> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> I was curious about anyone research or testing on labels for
> buttons/links that return the user from an action screen. Let's say a
> screen to update their information.
>
> 1) What is the preferred label? A label which denotes what the link will
> do (go back where you came from) or a label that matches what the user
> wants to do ("I want to cancel what I had chosen to do")
> 2) Should they look similar? Should they look alike to give a visual
> relationship that the two 'buttons' which represent your two options, or
> should they be different so the user does not accidentally hit 'cancel'
> when they meant 'save'?
> 3) Or does all of it depend on the circumstance?
>
> Interested to hear some of your thoughts.
>
> Ryan Nichols
> Apples To Oranges
> http://www.apples-to-oranges.com
>
>
>
>
>
> _______________________________________________
> Welcome to the Interaction Design Group!
> To post to this list ....... discuss at ixdg.org
> (Un)Subscription Options ... http://discuss.ixdg.org/
> Announcements List ......... http://subscribe-announce.ixdg.org/
> Questions .................. lists at ixdg.org
> Home ....................... http://ixdg.org/
>

--
Gerard Torenvliet
g.torenvliet at gmail.com

26 Jul 2005 - 7:36am
Todd Warfel
2003

On Jul 26, 2005, at 4:08 AM, Ryan Nichols wrote:

> 1) What is the preferred label? A label which denotes what the link
> will do (go back where you came from) or a label that matches what
> the user wants to do ("I want to cancel what I had chosen to do")

Well, that's a little "leading" ;). Cancel doesn't really match what
the user expectations, nor does it test well. It does have traction,
but even with the traction it's confusing.

We've done quite a bit of testing on transaction based applications
with Cornell (around 25 different applications, probably 200
participants, over the course of 2.5 years), and recently did some
testing on labels for action buttons with a large telecom on a web-
based app we were (re)designing.

Cancel is a bit confusing. It's not nearly as cut and dry as you make
it out to be. Cancel doesn't clearly mean "I want to cancel what I
had chosen to do..." because what does that really mean? Clear the
information out of this form and take me back? Take be back where?
Does cancel mean exit? Does it mean back? Does it mean clear? You
have to keep in mind how it's been implemented as well as the
ambiguity of cancel, which leads to the confusion.

Most participants we've studied (observed) aren't quite sure what
cancel actually does. It's a bit of a "I'll cross my fingers and hope
for the best." When it does, it's met with a sigh of relief. When it
doesn't, well, you can guess what types of things we've heard.

So, we've started using "Save" and "Exit" instead of "Okay" and
"Cancel." To date, these have tested much better - we're around 1.5
years, a dozen applications, and about 70-80 participants so far.

What we've found is that the expectation with "Exit" is that is "get
me out of here and don't save anything I did" or "I'm leaving and
don't expect you to save anything" - more definitive actually. "Save"
is pretty clear, as it's an action (as is exit), whereas "Okay" isn't
really an action at all. We're trying to reduce ambiguity.

Cheers!

Todd R. Warfel
Partner, Design & Usability Specialist
Messagefirst | making products & services easier to use
--------------------------------------
Contact Info
Voice: (607) 339-9640
Email: twarfel at mac.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

26 Jul 2005 - 8:06am
Lyle_Kantrovich...
2004

Other considerations:

1. Is this a form or app the users will use once, or will they use it
daily and develop proficiency with it (and maybe get some training as
well)?

2. Any actions that are "destructive" (e.g. "leave this long form you
just spent 10 minutes filling out without saving any of your data")
should have some kind of confirmation (e.g. "Are you sure you want to
lose all that data you just entered, buddy?").

Bad labels can cause users to be confused or "slip"...lack of
confirmations can allow painful things to happen to them. Note, not all
"destructive" things should have a confirmation. A howitzer, for
example, shouldn't ask "are you sure you want to kill that guy who's
going to kill you while you read this damn confirmation message?"

Lyle
----
Lyle Kantrovich
User Experience Director, Cargill
Cargill: http://www.cargill.com/

My Blog: Croc O' Lyle - http://crocolyle.blogspot.com/

26 Jul 2005 - 8:08am
Jack L. Moffett
2005

Todd Warfel stated:
> What we've found is that the expectation with "Exit" is that is "get
> me out of here and don't save anything I did" or "I'm leaving and
> don't expect you to save anything" - more definitive actually. "Save"
> is pretty clear, as it's an action (as is exit), whereas "Okay" isn't
> really an action at all. We're trying to reduce ambiguity.

How much of the meaning attributed to "Exit" in this case do you think comes
from it's juxtaposition with "Save?" The word "Exit" in and of itself, I
would argue, is more ambiguous as to what will become of the data entered on
the screen than "Cancel." I agree that "Exit" better states that the user
will be taken someplace else, but it doesn't communicate the target
destination any better. In the ambiguity tradeoff between "where does it
take me?" and "what happens to the data I entered?," I would think that the
data is more important. In either case, I think the changing of the label
from "Okay" to "Save" will have more impact on understanding than the label
it is coupled with.

Gerard Torenvliet stated:
> In terms of the location of the buttons, in the Windows world a
> defacto standard has developed in which the cancelling button is to
> the right and the action button is to the left. Lots of designs seem
> to follow this convention (e.g., the order of processing buttons on
> GMail is, left to right, SEND [most critical action], SAVE DRAFT
> [temporary action], and DISCARD [like cancel]).
>
> I don't know about any user research on this. It's all pretty defacto,
> and few seem to contradict it.

I would say that the button order mentioned here is not "defacto," but in
fact the standard set forth by Microsoft for the Windows operating system.
The reasoning for this order is that the action the user is most-likely to
perform should be the first listed. The button order in the Mac OS is the
opposite, the reasoning being that the "confirmation" action that will move
things forward should be in the lower, right-hand corner, following the
Romantic languages which read left to right, top to bottom. The debate
between these two methods is long-standing. I have not been able to find any
usability studies that have dealt with this either-just a lot of discussion.

My own preference for web applications that don't have to follow a specific
OS is to place the Cancel button in the lower left corner, and the Save
button in the lower right corner. This follows the "reading direction"
theory (right = forward, left = back), and adds a spatial separation that
lessens the chance that a button will be pressed accidentally.

The debate continues...
Jack

Jack L. Moffett
Interaction Designer
inmedius
412.690.2360 x219
http://www.inmedius.com

First, recognize that the Œright¹ requirements
are in principle unknowable by users, customers
and designers at the start.

Devise the design process, and the formal
agreement between designers and customers and users,
to be sensitive to what is learnt by any of the
parties as the design evolves.

- J.C. Jones

***********************************************************************
Confidentiality Note: The information contained in this email and document(s) attached are for the exclusive use of the addressee and contains confidential, privileged and non-disclosable information. If the recipient of this email is not the addressee, such recipient is strictly prohibited from reading, photocopying, distributing or otherwise using this email or its contents in any way.
***********************************************************************

26 Jul 2005 - 8:43am
Todd Warfel
2003

On Jul 26, 2005, at 10:08 AM, Jack L. Moffett wrote:

> The button order in the Mac OS is the opposite, the reasoning being
> that the "confirmation" action that will move things forward should
> be in the lower, right-hand corner, following the Romantic
> languages which read left to right, top to bottom.

We've actually studied this as well. One of the things we've observed
is that customers/users/participants migrate towards the bottom right
corner of the screen. There are several things we think contribute to
this:

1. We read left to right (in the west anyway)
2. As you fill out forms, you're typing left to right, you use the
mouse button to move from field to field, and your mouse is typically
in that region anyway. *1
3. Scroll bars are on the right side. Again, the mouse is already in
that area (Fitt's Law). *2

I've never really understood why Windows puts the default action
button to the left. In the Web world, there's a good technical reason
to do this, but it's still not a good reason... On the web, the
default button which will be executed when someone hits "Return" or
"Enter" on their keyboard will be the first button in the list. So,
if I hit "Return" then which ever button listed first will be executed:

Cancel Okay (cancel)
Okay Cancel (okay)
Exit Save (exit)
Save Exit (save)

But that doesn't match default user actions - migrate and target
bottom right. So, they should be:

Exit Save
Cancel Okay

With the default expected action highlighted in some way (more
emphasis).

The easy fix for the "Return" key - place a hidden submit button
first in the order of the code. So, technically, you'd have:

(save) Exit Save

We've been doing this successfully for years. It fixes the SWE
(software engineers') concerns and matches user expectations.

*1 - Personally, I tab between fields, but I'm statistically
insignificant ;). Our most common observation is for people to use
the mouse to go move between fields.

*2 - Fitt's Law is about targeting. The time needed to acquire a
target is a function of the distance to the target, and the size of
the target. So, the closer you are to the mouse pointer, the faster
someone will get there, given the object (action button) is a decent
size. It's pretty simple, really.

Cheers!

Todd R. Warfel
Partner, Design & Usability Specialist
Messagefirst | making products & services easier to use
--------------------------------------
Contact Info
Voice: (607) 339-9640
Email: twarfel at mac.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
--------------------------------------
Problems are just opportunities for success.

26 Jul 2005 - 7:23pm
Larry Tesler
2004

Gerard (see below) referred to the Mac/Windows conventions, and
mentioned that he knew of no user research on the subject. There
surely has been a lot, beginning with the Apple Lisa user interface
(http://www.jmusheneaux.com/9001.htm) in 1980-82.

We designed the Lisa for an audience who had never touched a mouse,
let alone seen a dialog box. We felt we had to make the user
interface friction-free in order to sell what was a quite expensive
PC into the office market that was the Lisa's target.

The closest things to dialog boxes in the market at that time were
the property sheets of the Xerox Star, which were mainly used to view
and change properties of objects. For an example , see
http://vividpicture.com/aleks/xeroxstar/starfs.jpg. Note that the
Star placed action buttons in the title bar of the property sheet.

The Lisa team designed our dialog boxes before the Star design became
public. Having no standard to follow, we used iterative design
punctuated by what is now called discount usability testing to design
dialogs. The initial design was done by Rod Perkins, a software
engineer whose main project was LisaCalc, a spreadsheet. He decided
that a dialog box should look and feel like a form.

In the end, the Lisa had both dialog boxes and alert boxes. Both of
those names were coined by the Lisa team.

As in the Mac OS, a command that required parameters appeared in the
menu with an ellipsis after the name, e.g., "Print...". Invoking the
command made a dialog box appear:

http://www.jmusheneaux.com/%20%20%20LISA%20PHOTO%20.JPG/Print1.JPG

Notice that the OK button is in the lower right hand corner. The
Cancel button is in the upper right hand corner. We tried other
layouts but this tested best.

The original Mac had a narrower screen. Its dialog box was detached
from the menu bar and from the edges of the screen. Reduced
horizontal space was, I think, one reason the Mac team moved Cancel
to the bottom of the box, alongside OK.

The Lisa had an elaborate set of Alert boxes, of four types, which
were--in increasing order of severity--Wait, Note. Caution, "?", and
Stop. The alert type appeared on the left side of the box in an icon
resembling a traffic sign. Examples:

Wait:
http://www.jmusheneaux.com/%20%20%20LISA%20PHOTO%20.JPG/Diskette-Put%20Away.JPG

Note: http://www.jmusheneaux.com/SPREADSHEET%20LISA/Dialog-SoftW01

Caution: http://www.jmusheneaux.com/SPREADSHEET%20LISA/Dialog-SoftW10

Stop: http://www.jmusheneaux.com/SPREADSHEET%20LISA/Dialog-Pref3

A Caution Alert offered both OK and Cancel buttons. A Stop Alert
offered only a Cancel button. A Note Alert offered only an OK
button. A Wait Alert had no buttons at all, but it explained how to
terminate the operation using a keystroke, when early termination was
possible.

The names OK and Cancel were inspired by the interface of my local
bank's ATM. ATM's were new at that time. I figured they'd catch on
fast and that millions of people would become familiar with OK and
Cancel. I also figured that the manufacturer had done a lot of user
testing on the interface.

Although OK and Cancel were the default names, we used more specific
names in these special situations:
- In "?" Alerts, which tended to appear in dire circumstances;
- When the consequences of clicking the wrong button would have been serious;
- When there were more than two choices to display;
- When the word Cancel would have created a confusing double-negative.

I think all but the first situation have analogs in web experiences.

Examples:

http://www.jmusheneaux.com/%20%20%20LISA%20PHOTO%20.JPG/Diskette-Repair2.jpg

http://www.jmusheneaux.com/%20%20%20LISA%20PHOTO%20.JPG/Diskette-Lisa%20Guide,JPG

http://www.jmusheneaux.com/SPREADSHEET%20LISA/Dialog-Lisa%20Office

Not every dialog was user tested. But each type of dialog was.

I hope that helps.

Larry Tesler

At 8:20 AM -0400 7/26/05, Gerard Torenvliet wrote:
>The other point that you raise is the importance of letting people
>know where they will be going back to. This can be implicit in the
>design (think of modal dialogs in Windows / Mac), or a conscious
>addition (a statement that instructs people, "click update to save
>your changes and return to x").
>
>In terms of the location of the buttons, in the Windows world a
>defacto standard has developed in which the cancelling button is to
>the right and the action button is to the left. Lots of designs seem
>to follow this convention (e.g., the order of processing buttons on
>GMail is, left to right, SEND [most critical action], SAVE DRAFT
>[temporary action], and DISCARD [like cancel]).
>
>I don't know about any user research on this. It's all pretty defacto,
>and few seem to contradict it.

Syndicate content Get the feed