
Should you use Yes/No or Ok/Cancel on your message boxes? - laurent123456
http://ux.stackexchange.com/q/9946/7235
======
nathos
Apple's Human Interface Guidelines continue to be a good resource:

Buttons & Labels:
[http://developer.apple.com/library/mac/#documentation/userex...](http://developer.apple.com/library/mac/#documentation/userexperience/conceptual/applehiguidelines/Controls/Controls.html#//apple_ref/doc/uid/TP30000359-TPXREF104)

Alert Dialogs:
[http://developer.apple.com/library/mac/#documentation/userex...](http://developer.apple.com/library/mac/#documentation/userexperience/conceptual/applehiguidelines/Windows/Windows.html#//apple_ref/doc/uid/20000961-TP10)

 _edit:_ It's also cool to see how much has (and hasn't) changed over the
years. Here's a 1995 version of the Macintosh HIG:
[http://dropbox.scripting.com/dave/misc/appleHumanInterfaceGu...](http://dropbox.scripting.com/dave/misc/appleHumanInterfaceGuidelines.pdf)

~~~
greggman
I fully agree that the verb is better.

At the same time, for localization a verb needs to be translated into XX
languages. The default Yes/No/Cancel text is already translated. Of course
that's not much of an argument since you'd have to translate the rest of your
program too but is there something to be said for helping people not familiar
with English to be able to use your untranslated program?

~~~
panic
You could use the verb in English, but fall back to Yes/No/Cancel in other
languages for which you don't have a localization.

------
timerickson
My favorite anti-pattern to this is the following:

"Would you like to cancel this transaction?"

"OK" – "Cancel"

~~~
jfb
Talk about an unambiguous sign that whoever is writing this software is truly
and deeply giving zero (0) shits about their job.

~~~
igul222
I don't think that's the case. It's very possible to be a good programmer and
care deeply about your work, but at the same time be a terrible UX designer.
Unfortunately a lot of software companies don't realize this and give UX the
priority it deserves; instead they make their coders guess about it, which
leads to things like this dialog.

~~~
jfb
Oh sure, I'm a living disaster area at UX. I meant more that whoever is the
"designated responsible individual" (if one even exists -- _doubtful_ ) has
given the fuck up.

~~~
evincarofautumn
For some reason I didn’t read “the fuck” as emphasis, but as a direct
object—the person _had had_ a fuck previously, but have since given up that
fuck.

I’m going to use that as an example of why UX is hard: not only are people
generally not paying attention, but sometimes they misfire even when they are.

~~~
jfb
It's much more elegant in your reading.

------
Samuel_Michon
_"Should you use Yes/No or Ok/Cancel on your message boxes?"_

No, you shouldn't.

~~~
Deestan
If you have trouble convincing someone of this, I wrote a little helper
application you can install on their computer. It pops up a focus-stealing
"WARNING: Are you sure? [Ok] [Cancel]" dialog at random every 10-40 minutes,
irrespective of what they are doing at that time. A day of that, and they
should get the point. Executable and source download at the bottom of the
rant: <http://www.expert-overflow.com/areyousure/>

~~~
Samuel_Michon
Be careful, you may be stepping on Microsoft's IP. Windows Vista's UAC feature
had it first.

------
ctdonath
I once held a meeting for higher-ups (I was rather a peon) to decide whether a
single switch should be labeled "online/offline" or "remote/local". 6 managers
attended. The meeting lasted 3 hours.

Small surprise that once $14B/yr company just sold its remaining patent
portfolio for $500M.

~~~
fleitz
What color was the bikeshed there?

~~~
rmrfrmrf
They're currently A/B testing for that.

------
laumars
It's not just GUI message boxes that thought has to be applied to - any form
of user input (including command line apps).

I remember the old DOS days when reading a floppy disk failed:

    
    
        Abort, Retry, Fail?
    

I never could remember the difference between _Abort_ and _Fail_.

~~~
randall
What is the difference? I never knew.

~~~
mdb31
Abort would terminate the entire process, whereas Fail would return an error
code to it. Older (pre-2.x?) versions of DOS did not support the concept of
I/O error codes at all, so the Fail option wasn't present: instead, you had
the charming 'Ignore', which would pretend the operation had succeeded,
returning the I/O buffer with (partially) corrupted information.

------
Osiris
One problem is that the standard Windows API for creating a MessageBox only
has standard options for the button labels. If you to use custom text you have
to create your own form.

~~~
simonh
This is due to localisation. Standard dialogues with limited and clearly
defined text options can be automatically localised by the system, but if you
put arbitrary text on your buttons and you want localisation, you have to
provide translations yourself.

------
kps
My favourite was a disk backup program for MacOS (non-X) called Silverkeeper,
which was included with LaCie external drives: <http://i.imgur.com/VMlQH.jpg>

Or in ASCII art (spelling and punctuation as shown):

    
    
        +----------------------------------------------------+
        |                          [  Nah!  ]  [ Somewhat ]  |
        |                                                    |
        | Are you sure you want to permanently remove backup |
        | of files in Set "Desktop > Sneech"                 |
        |                                                    |
        | Thsi will completely remove                        |
        | any reference to these file.?                      |
        +----------------------------------------------------+

------
myg204
A random idea, maybe an alternative is to label the buttons w/ the actions
themselves, i.e. no message + Y/N,Ok/Cancel labels. For Example, instead of:
Would you like to cancel this transaction? {Yes,No} just have: {Continue
Transaction|Stop Transaction}

... just a thought, I'm no UX designer.

~~~
notatoad
If you click the link, you'll see that is the preferred solution.

~~~
myg204
Ah, yes indeed. I suppose yes/no scheme may be applicable to command line
tools where the user actually has to type, in the model ui world, it's not
really applicable.

~~~
mserdarsanli
y

------
tuananh
I've always confused about UI and UX. This is def. consider UX right?

~~~
mscarborough
Yes, the UI is the mechanism that pops up the messaging, but the UX is the
consideration of how the message will be used or misused by the user.

Ha, a terrible sentence. That's why I'm a back-end not a UX person :)

It's definitely a blurry line a lot of the time but having worked with a UX
guy who was part of our design department, he definitely added a lot of value
to the design process.

------
pixl97
I remember a site on MacOS vs Windows dialog boxes from way back in the late
90's, a time in which many confusing UI patterns abound. It's too bad it's
still not around as it is a great guide on how to display the question to the
user correctly.

It went on to display a few common(windows 95 I think) dialogs that would
leave most users confused. Then showed the Mac dialog in similar operations
where it was very clear what the intended outcome of each button would be.

~~~
goostavos
If you ever stumble across it, I'd love to take a look at it. That sounds like
a great resource.

I'm currently writing my first "big" GUI for work where I serve as both the
main programmer _and_ the UX designer. Things such as button ambiguity are
things that, until this point, had never crossed my mind.

------
sigzero
It depends on how the question is phrased in the message box.

~~~
tuananh
The problem is people didn't read the question carefully

~~~
InclinedPlane
The problem is that too many dialogs are designed to require reading an overly
verbose message when in reality the vast majority of the time the 2 or 3 words
on an appropriately named button are all the context a user needs.

If I initiate a format on a drive volume I don't need a lecture on what a
format does and what the risks are, I know them already, I just need a
confirmation step.

~~~
pestaa
> _If I initiate a format on a drive volume I don't need a lecture on what a
> format does and what the risks are, I know them already, I just need a
> confirmation step._

When I was 12, I compressed drive C:\ in the hope more free space will be
available. I think I'd have benefited from a lecture in the application.

~~~
Dylan16807
I'm not quite clear on your point here. Did the compression cause problems?
Did it keep reserved space so you still didn't have any free? Compression on a
slow hard drive should generally improve performance and at the very least
shrinking files means fewer fragmentation problems.

If you wanted the software to warn you it was buggy before you turned it on,
haha good luck.

~~~
pestaa
I don't recall all the details, but it was Windows 95 times. This embedded
system utility basically zipped the root directory and rendered the computer
unable to boot. I could have saved my parents a headache if I had been aware
of the consequences.

------
contingencies
Haha, trick question right? Of course, use 确认 and 取消

------
Zenst
I would go with a happy face and a sad face or a thumbs up or a thumbs down
and save alot of language issues in one simple approach.

I would also have the `yes`/`no` options apart and not how must people do it
with them next to each other, avoids mistakes more.

~~~
pestaa
Apart from accessibility issues, I don't think emoticons work well in this
context. At least they would make me stare more at the dialog and not less.

Although verbs like Save along with icons like a floppy disk might increase
familiarity, so graphics could be applied moderately.

~~~
Zenst
a very interesting and valid point about mixing the text with graphics. Though
I standard of PLAY/PAUSE/STOP/FWD/BACK icons on VCR a is a example of a
standard that is embraced and known globaly, no text involved. That said the
old stories of people having problems programming there VCR may well have
roots in the iconic only introduction only to be dumped into the non-standard
programming interfaces that changed from model to model.

I certianly do believe signs/symbols when known have a very intuative
communication medium and once adopted and used the comfort value is as good
and if not better than some words which are after all a collection of symbols
in themselfs. Road sighs would be another area which has at least some
universal symbols, maybe those would be more adoptable for a user interface.

Perish the thought that one day we have a computer that you set up and asks
you how you the user would like certain common dialogues to be handeled and
propergated that customised standard across all applications running upon
them. I'm all for graphic symbols to indicate across languages the actions
available as apposed to limiting to words alone, which are in themself (for
English and many other languages) only a collection of 26 or so symbols
combined in themself.

The example you give about the word Save with a icon with a floppy disc is
very common in alot of applications, though I do wonder for a new user who is
starting out with computers if they would even be able to identify with the
image of a floppy disc, let alone know they ever existed and there use. So
some symbols are, if not thought out limited in there use and some are
timeless classics that still endure today, like some roadsigns. It is also
worth noting that colours play a important part and with that also have
limitations. If you saw a road stop sign in green instead of red you would
think it was a go sign and not a stop one; So careful use is wise. With that
the mix you say of text and symbols is perhaps not that bad an approach after
all, albiet language biased it would still allow say a user of a mobile phone
to navigate the menu's using the symbols to change the menu language back to
say English with ease having been comfronted with russian text due to a child
changing the settings or the like.

------
jackbauer
I wish the position of the positive or negative action was standardised i.e.
YES/OK/Secure Empty Trash (positive) always on the right, Cancel(Negative) on
the left.

------
dakimov
The answer there is perfect. Nothing to add.

~~~
rm999
Yeah my thoughts too, I haven't seen anyone improve on the top answer. No one
wants to read the dialogue box, so make it as easy as possible.

~~~
flogic
Quite often the dialogue text leaves one unclear in what the button will do.

