OK/Cancel buttons: no mnemonic; why?

12 Jan 2004 - 9:02pm
10 years ago
15 replies
1374 reads
sandeepblues
2003

There is an MS User Experience guideline that
OK/Cancel buttons should not have mnemonics. Would
you know why? Is it to prevent accidents? Seems
rather conservative, given that pressing (Alt+O) or
(Alt+C) couldn't easily be pressed accidentally.

Sandeep

Comments

12 Jan 2004 - 9:38pm
Gerard Torenvliet
2004

Sandeep wrote:

> There is an MS User Experience guideline that
> OK/Cancel buttons should not have mnemonics. Would
> you know why? Is it to prevent accidents? Seems
> rather conservative, given that pressing (Alt+O) or
> (Alt+C) couldn't easily be pressed accidentally.

I think OK and Cancel don't have mnemonics because mnemonics are just a means to an end - a way to remember what key to press to activate a command.

In any dialog, ESC should always perform the same action as Cancel, and Enter should perform the same action as OK. These keys don't have mnemonics, but they should work. Because they are supposed to be used everywhere, users should just know them (as opposed to needing a mnemonic to remember them).

Regards,
-Gerard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.interactiondesigners.com/private.cgi/discuss-interactiondesigners.com/attachments/20040112/38eccd20/attachment.html

12 Jan 2004 - 9:21pm
cfmdesigns
2004

From: Sandeep Jain <sandeepblues at yahoo.com>

>There is an MS User Experience guideline that
>OK/Cancel buttons should not have mnemonics. Would
>you know why? Is it to prevent accidents? Seems
>rather conservative, given that pressing (Alt+O) or
>(Alt+C) couldn't easily be pressed accidentally.

My understanding is that Esc and Enter should be mapped to those
buttons. Why use up valuable combos on those buttons when there are
already standard mappings to use?

(On the other hand, I'm not sure how users acquire the knowledge that
Esc equates to Cancel these days.)

Jim

12 Jan 2004 - 10:23pm
Elizabeth Dykst...
2004

You don't want mnemonics because you don't want the OS to usurp
another keyboard shortcut for them. Also, you don't want to permit
the user's muscle memory to take over - if there is a default choice
between cancel and ok, enter will execute the default. Escape should
always abandon the choice altogether. Remember that there is
frequently more choice involved than simply cancel and ok.

Elizabeth

>Sandeep wrote:
>
> > There is an MS User Experience guideline that
>> OK/Cancel buttons should not have mnemonics. Would
>> you know why? Is it to prevent accidents? Seems
>> rather conservative, given that pressing (Alt+O) or
>> (Alt+C) couldn't easily be pressed accidentally.
>
>I think OK and Cancel don't have mnemonics because mnemonics are
>just a means to an end - a way to remember what key to press to
>activate a command.
>
>In any dialog, ESC should always perform the same action as Cancel,
>and Enter should perform the same action as OK. These keys don't
>have mnemonics, but they should work. Because they are supposed to
>be used everywhere, users should just know them (as opposed to
>needing a mnemonic to remember them).
>
>Regards,
>-Gerard
>
>
>_______________________________________________
>Interaction Design Discussion List
>discuss at interactiondesigners.com
>--
>to change your options (unsubscribe or set digest):
>http://discuss.interactiondesigners.com
>--
>Questions: lists at interactiondesigners.com
>--
>Announcement Online List (discussion list members get announcements already)
>http://interactiondesigners.com/announceList/
>--
>http://interactiondesigners.com/

--

Elizabeth Dykstra-Erickson
eade at acm.org

13 Jan 2004 - 6:35pm
sandeepblues
2003

thanks. That makes sense. Now, I have another recent
posting titled :

"[ID Discuss] Table data entry, dialog win, and widget
focus;"

Basically, suppose that you have a dialog box, with a
spreadsheet equivalent as one of the widgets in the
dialog box. The user will use Tab and Enter to
navigate from one cell to another, and row to another,
respectively. So, now, how to I say "OK" via
keyboard?Also, how can I tab "out" of the spreadsheet
to say a combo-box in the same dialog box.

Sandeep

--- Elizabeth Dykstra-Erickson <eade at acm.org> wrote:
> You don't want mnemonics because you don't want the
> OS to usurp
> another keyboard shortcut for them. Also, you don't
> want to permit
> the user's muscle memory to take over - if there is
> a default choice
> between cancel and ok, enter will execute the
> default. Escape should
> always abandon the choice altogether. Remember that
> there is
> frequently more choice involved than simply cancel
> and ok.
>
> Elizabeth
>

13 Jan 2004 - 6:44pm
sandeepblues
2003

ESC for Cancel makes perfect sense.

Is it just me who sometimes thinks that Enter should
also play to the role of Tab...giving focus to the
next input widget, when one is done typing in one?

Sandeep

--- Gerard Torenvliet <g_torenvliet at hotmail.com>
wrote:
> Sandeep wrote:
>
> > There is an MS User Experience guideline that
> > OK/Cancel buttons should not have mnemonics.
> Would
> > you know why? Is it to prevent accidents? Seems
> > rather conservative, given that pressing (Alt+O)
> or
> > (Alt+C) couldn't easily be pressed accidentally.
>
> I think OK and Cancel don't have mnemonics because
> mnemonics are just a means to an end - a way to
> remember what key to press to activate a command.
>
> In any dialog, ESC should always perform the same
> action as Cancel, and Enter should perform the same
> action as OK. These keys don't have mnemonics, but
> they should work. Because they are supposed to be
> used everywhere, users should just know them (as
> opposed to needing a mnemonic to remember them).
>
> Regards,
> -Gerard
>

13 Jan 2004 - 7:02pm
Andrei Herasimchuk
2004

You can always split the RETURN key and the ENTER key, where one is
used to act like normal spreadsheet functionality and the other is the
OK button. The Return key is the one in the main area of the keyboard,
while the Enter key is on the numeric keypad.

As for tabbing behaviors, there are many various rules and methods you
can apply. It'll be mostly arbitrary.

But that's not really the issue. The issue you have to ask yourself is
why do you have a complex control like a spreadsheet sitting inside a
modal dialog box? I would dare say that the crux of your problem is in
this design decision. The moment you find yourself putting complex
controls into modal environments like a dialog box, you should back up
and take a look at some core architectural decisions you are making,
and see whether they are really holding up as you envisioned when you
started the project.

Andrei

Work: http://www.adobe.com
Personal: http://www.designbyfire.com

On Jan 13, 2004, at 3:35 PM, Sandeep Jain wrote:

> "[ID Discuss] Table data entry, dialog win, and widget
> focus;"
>
> Basically, suppose that you have a dialog box, with a
> spreadsheet equivalent as one of the widgets in the
> dialog box. The user will use Tab and Enter to
> navigate from one cell to another, and row to another,
> respectively. So, now, how to I say "OK" via
> keyboard?Also, how can I tab "out" of the spreadsheet
> to say a combo-box in the same dialog box.
>
> Sandeep

13 Jan 2004 - 7:23pm
IdoShavit
2004

It's not just you Sandeep.
I have observed this behavior many times.

It usually the case with users who are accustomed to single input fields
(such as search boxes, smaller dialog boxes, wizards etc.) rather than
dealing with tables. Users who are more proficient with the use of tables
(DB and spreadsheet users) will tend to use the Tab key, not the enter key
to move to the next input field.

However, the majority of (non-vertical-application) users will just reach
for the mouse to click on the next field. For the average web user, for
example, in the battle of Tab VS Enter, the mouse will win big time.*

* It doesn't help either that many web designers do not dictate tab order,
and in many web forms the Tab key is not likely to move the focus to the
next desired field.

Ido

-----Original Message-----
From: Sandeep Jain [mailto:sandeepblues at yahoo.com]
Sent: Tuesday, January 13, 2004 3:45 PM
To: Gerard Torenvliet; discuss at interactiondesigners.com
Subject: Re: [ID Discuss] OK/Cancel buttons: no mnemonic; why?

ESC for Cancel makes perfect sense.

Is it just me who sometimes thinks that Enter should also play to the role
of Tab...giving focus to the next input widget, when one is done typing in
one?

Sandeep

--- Gerard Torenvliet <g_torenvliet at hotmail.com>
wrote:
> Sandeep wrote:
>
> > There is an MS User Experience guideline that OK/Cancel buttons
> > should not have mnemonics.
> Would
> > you know why? Is it to prevent accidents? Seems rather
> > conservative, given that pressing (Alt+O)
> or
> > (Alt+C) couldn't easily be pressed accidentally.
>
> I think OK and Cancel don't have mnemonics because mnemonics are just
> a means to an end - a way to remember what key to press to activate a
> command.
>
> In any dialog, ESC should always perform the same action as Cancel,
> and Enter should perform the same action as OK. These keys don't have
> mnemonics, but they should work. Because they are supposed to be used
> everywhere, users should just know them (as opposed to needing a
> mnemonic to remember them).
>
> Regards,
> -Gerard
>

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

14 Jan 2004 - 2:44pm
sandeepblues
2003

Well, I have a wizard that simplifies a complex task,
but each step requires a good amount of data entry
that is ideally done using a
spreadsheet-equivalent...actually that widget allows
different widgets in each cell (combo-box, checkbox
etc). I shouldn't have said "spreadsheet". I meant a
grid-table widget with fixed columns...

Given that the wizard is a dialog, this becomes
necessary.

Sandeep

--- Andrei Herasimchuk <andrei at adobe.com> wrote:
> You can always split the RETURN key and the ENTER
> key, where one is
> used to act like normal spreadsheet functionality
> and the other is the
> OK button. The Return key is the one in the main
> area of the keyboard,
> while the Enter key is on the numeric keypad.
>
> As for tabbing behaviors, there are many various
> rules and methods you
> can apply. It'll be mostly arbitrary.
>
> But that's not really the issue. The issue you have
> to ask yourself is
> why do you have a complex control like a spreadsheet
> sitting inside a
> modal dialog box? I would dare say that the crux of
> your problem is in
> this design decision. The moment you find yourself
> putting complex
> controls into modal environments like a dialog box,
> you should back up
> and take a look at some core architectural decisions
> you are making,
> and see whether they are really holding up as you
> envisioned when you
> started the project.
>
> Andrei
>
> Work: http://www.adobe.com
> Personal: http://www.designbyfire.com
>
> On Jan 13, 2004, at 3:35 PM, Sandeep Jain wrote:
>
> > "[ID Discuss] Table data entry, dialog win, and
> widget
> > focus;"
> >
> > Basically, suppose that you have a dialog box,
> with a
> > spreadsheet equivalent as one of the widgets in
> the
> > dialog box. The user will use Tab and Enter to
> > navigate from one cell to another, and row to
> another,
> > respectively. So, now, how to I say "OK" via
> > keyboard?Also, how can I tab "out" of the
> spreadsheet
> > to say a combo-box in the same dialog box.
> >
> > Sandeep
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members
> get announcements already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/

15 Jan 2004 - 8:06pm
Anirudha Joshi
2003

I agree with Andrei, it seems problematic to have a modal dialog with
huge amounts of data. In which case, a modal wizard is not a good
solution. Imagine, I spent good part of half hour populating the fields,
then I make one mistake of clicking the cancel button, and the whole
thing is gone. Instead, try to make a non-modal wizard, one in which I
can save as I go. Perhaps even put an explicit save button somewhere, so
user can fill up a bit of info now, go, have a coffee, or ask someone
doubts, or look up some data that was not at hand, return and fill out
the rest of the stuff. It may also be good to provide a trail to jump to
the necessary page if the wizard has many pages (what did I say on page
3, we have two vehicles, sorry four, if you are counting bicycles?).
More ideas are possible of course, depending on the context of the
application and the target audience.

Anirudha

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com] On Behalf Of Sandeep Jain
Sent: Wednesday, January 14, 2004 11:45 AM
To: Andrei Herasimchuk; discuss at interactiondesigners.com
Subject: Re: [ID Discuss] OK/Cancel buttons: no mnemonic; why?

Well, I have a wizard that simplifies a complex task,
but each step requires a good amount of data entry
that is ideally done using a
spreadsheet-equivalent...actually that widget allows
different widgets in each cell (combo-box, checkbox
etc). I shouldn't have said "spreadsheet". I meant a
grid-table widget with fixed columns...

Given that the wizard is a dialog, this becomes
necessary.

Sandeep

14 Jan 2004 - 6:52pm
Andrei Herasimchuk
2004

Elizabeth,

I think you are making a large assumption here. You say "people who
rely on the keyboard for navigation..."

I use all sorts of keyboard navigation, and yet, if I encountered a
spreadsheet like widget inside a modal dialog, I'm not so sure I would
expect the TAB key to do as you say. When I use Excel, I hardly ever
use the arrow keys, and only use the TAB and ENTER keys.

Do you have hard data to back up that claim?

Andrei

On Jan 14, 2004, at 3:31 PM, Elizabeth Carpenter wrote:

> Sandeep,
>
> I'd used the only the Arrow keys to navigate within a table-like
> widget in a
> dialog box. Then I've used the Tab key to move out of the table-like
> widget
> onto the next widget in the tab order. This will reserve your Tab key
> as
> the dialog navigation key and your Enter/Return as the default or OK
> key.
> If your spreadsheet control recognizes the Tab key, as some controls
> do,
> then you might try Control+Tab to exit the control.
>
> People who rely on the keyboard for navigation expect the Tab key to
> move
> them from one control to another and they also expect the Arrow keys
> to move
> them from one option (or cell) within a particular control. So, they
> would
> expect the Tab key to move from a checkbox to a combo box, and the down
> arrow would move them from option in the combo box to another.
>
> I hope this helps.
>
>
> -----Original Message-----
> From:
> discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
> [mailto:discuss-interactiondesigners.com-
> bounces at lists.interactiondesigners.
> com] On Behalf Of Andrei Herasimchuk
> Sent: Tuesday, January 13, 2004 6:03 PM
> To: discuss at interactiondesigners.com
> Subject: Re: [ID Discuss] OK/Cancel buttons: no mnemonic; why?
>
> You can always split the RETURN key and the ENTER key, where one is
> used to act like normal spreadsheet functionality and the other is the
> OK button. The Return key is the one in the main area of the keyboard,
> while the Enter key is on the numeric keypad.
>
> As for tabbing behaviors, there are many various rules and methods you
> can apply. It'll be mostly arbitrary.
>
> But that's not really the issue. The issue you have to ask yourself is
> why do you have a complex control like a spreadsheet sitting inside a
> modal dialog box? I would dare say that the crux of your problem is in
> this design decision. The moment you find yourself putting complex
> controls into modal environments like a dialog box, you should back up
> and take a look at some core architectural decisions you are making,
> and see whether they are really holding up as you envisioned when you
> started the project.
>
> Andrei
>
> Work: http://www.adobe.com
> Personal: http://www.designbyfire.com
>
> On Jan 13, 2004, at 3:35 PM, Sandeep Jain wrote:
>
>> "[ID Discuss] Table data entry, dialog win, and widget
>> focus;"
>>
>> Basically, suppose that you have a dialog box, with a
>> spreadsheet equivalent as one of the widgets in the
>> dialog box. The user will use Tab and Enter to
>> navigate from one cell to another, and row to another,
>> respectively. So, now, how to I say "OK" via
>> keyboard?Also, how can I tab "out" of the spreadsheet
>> to say a combo-box in the same dialog box.
>>
>> Sandeep
>
> _______________________________________________
> Interaction Design Discussion List
> discuss at interactiondesigners.com
> --
> to change your options (unsubscribe or set digest):
> http://discuss.interactiondesigners.com
> --
> Questions: lists at interactiondesigners.com
> --
> Announcement Online List (discussion list members get announcements
> already)
> http://interactiondesigners.com/announceList/
> --
> http://interactiondesigners.com/
>

14 Jan 2004 - 3:46pm
cfmdesigns
2004

Andrei Herasimchuk <andrei at adobe.com> writes:

>You can always split the RETURN key and the ENTER key, where one is
>used to act like normal spreadsheet functionality and the other is
>the OK button. The Return key is the one in the main area of the
>keyboard, while the Enter key is on the numeric keypad.

Aren't they only split (giving separate return values) on a Mac? My
Windows keyboard has them both labelled "Enter" while the Mac
keyboard differentiates, and I've run into bugs before where the
developers had written code where both keys worked on Win but only
one or the other worked on Mac. (Quite a surprise to find that only
the keypad one works when you are on a laptop which accesses that
only with a key combo!)

Jim

15 Jan 2004 - 7:05pm
sandeepblues
2003

Thanks for the ideas.

A non-modal wizard? That can lead to collisions,
where assumptions made when a wizard was launched
change, due to some other interaction.

Do you think Undo makes sense? Undo would Undo the
cancel. It seems unusual since Undo usually undos
results of actions, versus the cancellation of
actions....

Also, in terms of an object model, let's say that a
wizard is used to create a set of objects of the same
type, and it takes lots of data entry to set their
attributes.

It would be a pain to create default objects first,
and then, enter their attributes separately. So, in
terms of a mental model, what does the user think she
is "saving" when she is in the middle of the wizard?
If she closes the application (of which the wizard was
a non-modal dialog) and reopens it, what objects are
created and what objects are in a semi-created state?

Sandeep

--- Anirudha Joshi <anirudha at iitb.ac.in> wrote:
> I agree with Andrei, it seems problematic to have a
> modal dialog with
> huge amounts of data. In which case, a modal wizard
> is not a good
> solution. Imagine, I spent good part of half hour
> populating the fields,
> then I make one mistake of clicking the cancel
> button, and the whole
> thing is gone. Instead, try to make a non-modal
> wizard, one in which I
> can save as I go. Perhaps even put an explicit save
> button somewhere, so
> user can fill up a bit of info now, go, have a
> coffee, or ask someone
> doubts, or look up some data that was not at hand,
> return and fill out
> the rest of the stuff. It may also be good to
> provide a trail to jump to
> the necessary page if the wizard has many pages
> (what did I say on page
> 3, we have two vehicles, sorry four, if you are
> counting bicycles?).
> More ideas are possible of course, depending on the
> context of the
> application and the target audience.
>
> Anirudha
>

16 Jan 2004 - 10:44pm
Anirudha Joshi
2003

>> It would be a pain to create default objects first,
and then, enter their attributes separately. So, in
terms of a mental model, what does the user think she
is "saving" when she is in the middle of the wizard?
If she closes the application (of which the wizard was
a non-modal dialog) and reopens it, what objects are
created and what objects are in a semi-created state?

'Save' should save the user work, not necessarily what the computer
thinks is complete. The user saves data that she entered, and may choose
to return to complete it later (this situation is more likely, if there
is more data). There has to be a summary level visualization of user's
work, particularly if it is a lot of work. (It could be in terms of
shortcuts to jump to wizard screens, but there could be other
non-layered, non-modal ways). If the work was incomplete (objects were
semi-created), it could be indicated with empty shortcuts that don't
work.

I didn't get the context of what you meant by default objects.
Anirudha

15 Jan 2004 - 7:17pm
Andrei Herasimchuk
2004

On Jan 15, 2004, at 4:05 PM, Sandeep Jain wrote:
> A non-modal wizard? That can lead to collisions,
> where assumptions made when a wizard was launched
> change, due to some other interaction.

You really should consider going out and buying TurboTax. It's $30, and
it handles every issue you bring up in the rest of your message. Some
of their answers are not as good as others, but their wizard approach
to the very complex task of filling out complex tax forms is about as
good as it gets at this stage.

Andrei

17 Jan 2004 - 2:16am
Nathan Moody
2004

Hi there - new to the group, wanted to share on this topic...

On Jan 16, 2004, at 7:44 PM, Anirudha Joshi wrote:
> 'Save' should save the user work, not necessarily what the computer
> thinks is complete.

As a designer and user advocate, I couldn't agree more. However, I've
found that in the web app/rich internet app/x-internet (ad extreme
nauseum) world, we sometimes have to break that rule in order to
benefit user experience.

As counter-intuitive as that seems, it's an issue of server
communication; in a local app, communicating with a filesystem or OS
can be very quick, so every single field entry (or even keystroke) can
be stored in pretty much real-time. Save buttons aren't always needed
in some cases.

However, the challenge of complex forms with many data fields can make
this an incredibly interruptive experience for a user in a web-enabled
world...are we really going to try to send packets of data for every
keystroke? Is a server listening to every user's keystrokes, or for
every tab key to send a field, monitoring hundreds (thousands?) of
potential concurrent users? How will that impact both client and server
side performance? Not only can this introduce back-end problems (and
thereby raise deployment costs), but this can also bog down a client
machine fiercely, no matter what their connection speed is...the
browser becomes a bottleneck at that point.

So, basically we've been sometimes forced to split the needs of the
technical requirements with those of the user, and make sure that we
collect just the right amount of information in each step, and then
shuttle that to the server in one chunk so as to create as little user
waiting as possible, thereby attempting to IMPROVE user experience
through the illusion of high performance per form segment or per wizard
step. Of course, the proof's in how one divides up a complex process
into small, tasty, digestible chunks...

So, totally agreeing on this point, but sharing some experiences where
we found another scenario that trumped this guideline! ;-)

Best,
-Nathan Moody
Director of Interactive Media, Fluid, Inc. (www.fluid.com)
Creative Director, Atomick Industries (www.atomick.net)

Syndicate content Get the feed