Should you use Yes/No or Ok/Cancel on your message boxes?(ux.stackexchange.com)
ux.stackexchange.com
Should you use Yes/No or Ok/Cancel on your message boxes?
http://ux.stackexchange.com/q/9946/7235
16 comments
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?
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?
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.
My favorite anti-pattern to this is the following:
"Would you like to cancel this transaction?"
"OK" – "Cancel"
"Would you like to cancel this transaction?"
"OK" – "Cancel"
It's like that joke about a Belarusian referendum ballot:
Do you not object for the president to remain in power indefinitely?
[ ] No, I don't object
[ ] Yes, I don't objectThese kinds of things can be life or death in airplanes.
It used to be in the Air Force that full throttle was called "takeoff power". Then one day a jet was making a landing, and the copilot decided they needed to abort. The first thing you do on abort is go to full power, so he yelled "takeoff power". The pilot chopped the throttle, thinking he meant "take off power", causing an accident.
The offical phrase for full throttle was then changed to "full power" (or "maximum power", I forgot).
It used to be in the Air Force that full throttle was called "takeoff power". Then one day a jet was making a landing, and the copilot decided they needed to abort. The first thing you do on abort is go to full power, so he yelled "takeoff power". The pilot chopped the throttle, thinking he meant "take off power", causing an accident.
The offical phrase for full throttle was then changed to "full power" (or "maximum power", I forgot).
In general aviation the term "takeoff/go-around" or "TOGA" is used, with the go-around phase used for aborting landings.
Talk about an unambiguous sign that whoever is writing this software is truly and deeply giving zero (0) shits about their job.
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.
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.
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.
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.
It's much more elegant in your reading.
The basics of UX design can be learned, so if you really care you'll learn.
Or, the error message was written by someone whose first language is not English... and the company in question did not enforce review.
or even that the message makes perfet sense to the person writing it, because they are not reading the message, but reading what they thought the message was in their head!
Or maybe the backend code is analogous to
bool exit_handler(obj) {
return confirm_exit(obj->description)
}
I actually prefer the idea of using "Don't" instead of "Cancel." When combined with always using a verb instead of "Yes" or "OK", I think it makes for completely unambiguous dialog.
"Would you like to format this disk?"
"Format" - "Don't"
"Would you like to cancel this transaction?"
"Cancel" - "Don't"
"Would you like to format this disk?"
"Format" - "Don't"
"Would you like to cancel this transaction?"
"Cancel" - "Don't"
Not completely unambiguous, though. I've seen plenty of software with negations in their dialog messages ("Don't delete x?") Particularly egregious with driver installations. Everything considered, buttons with actual verbs seem the most foolproof.
When would someone ever need to confirm not doing something?
Considering Windows used to have an "Error: no error" dialog somewhere, I'd leave nothing off the table...
I've seen the even simpler dialog:
"Cancel?"
"OK" - "Cancel"
"Cancel?"
"OK" - "Cancel"
I've seen a better one, with 2 cancel buttons, following "action"/cancel model.
Somehow that one actually sounds less ambiguous, assuming familiarity with dialog boxes.
I've seen set top boxes that offer three answers to yes/no questions.
"Switching the channel will switch to live mode and lose your rewind buffer. Do you want to switch to channels?"
[YES] [NO] [Cancel]
"Switching the channel will switch to live mode and lose your rewind buffer. Do you want to switch to channels?"
[YES] [NO] [Cancel]
I've had to implement an industry-standard medical protocol which had 6 values for "sex".
The more the merrier!
State of California used to allow 5 in healthcare reporting: male, female, indeterminate, unknown, and other.
The first two are largely self-explanatory, self-identification issues largely not considered. "Indeterminate" means that evidence is present but it's not possible to distinguish. "Unknown" means evidence isn't present (and hence it's not possible to make a determination. Example: unidentified human remains found and either grossly mutilated or partial to the point of not being able to determine sex. "Other" means that evidence is present, and it's possible to make a determination, but it doesn't fit any of the previous categories.
State of California used to allow 5 in healthcare reporting: male, female, indeterminate, unknown, and other.
The first two are largely self-explanatory, self-identification issues largely not considered. "Indeterminate" means that evidence is present but it's not possible to distinguish. "Unknown" means evidence isn't present (and hence it's not possible to make a determination. Example: unidentified human remains found and either grossly mutilated or partial to the point of not being able to determine sex. "Other" means that evidence is present, and it's possible to make a determination, but it doesn't fit any of the previous categories.
My absolute favorite on this one is a dialog that pops up if an assertion fails in a .NET program. It has three buttons whose names have a distinguished provenance: Abort, Retry, Ignore.
Those names don't exactly describe what the buttons do. Fortunately, though, someone at Microsoft noticed the problem and fixed it. So now the title bar reads, "Assertion Failed: Abort=Quit, Retry=Debug, Ignore=Continue"
Those names don't exactly describe what the buttons do. Fortunately, though, someone at Microsoft noticed the problem and fixed it. So now the title bar reads, "Assertion Failed: Abort=Quit, Retry=Debug, Ignore=Continue"
I much prefer:
"Application has detected and error!"
"OK" – "Cancel"
"Application has detected and error!"
"OK" – "Cancel"
"Would you like to cancel this transaction?"
"OK" – "Cancel"
Easy, just replace would with wouldn't :)
"OK" – "Cancel"
Easy, just replace would with wouldn't :)
"Should you use Yes/No or Ok/Cancel on your message boxes?"
No, you shouldn't.
No, you shouldn't.
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/
Be careful, you may be stepping on Microsoft's IP. Windows Vista's UAC feature had it first.
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.
Small surprise that once $14B/yr company just sold its remaining patent portfolio for $500M.
Sounds kind of like the real issue was how the two modes should be communicated to the user throughout the product. Either the real issue was being ignored, or it was just the representational case for a valid UX question (although that process still sounds like overkill).
[deleted]
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:
I remember the old DOS days when reading a floppy disk failed:
Abort, Retry, Fail?
What is the difference? I never knew.
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.
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.
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.
I had this same problem once upon a time, so I created a WPF clone of the standard Windows/.NET MessageBox which allows for custom strings for button text (OK, OK/Cancel, Yes/No, YesNoCancel).
It's on Github: https://github.com/evanwon/WPFCustomMessageBox
There's more to be done, but it's been handy for me so far!
It's on Github: https://github.com/evanwon/WPFCustomMessageBox
There's more to be done, but it's been handy for me so far!
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):
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.? |
+----------------------------------------------------+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.
... just a thought, I'm no UX designer.
If you click the link, you'll see that is the preferred solution.
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.
I've always confused about UI and UX. This is def. consider UX right?
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.
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.
I think UI is a subset of UX. UI design is the choice, arrangement, and labeling of widgets on screens, whereas UX design also includes more abstract decisions such as whether to require that the user sign up before they start using your website or whether to provide permalinks to individual pieces of content or only have a link for collections. In this case, choosing labels of buttons on dialogue boxes is related to the UI, so it’s both UI design and UX design.
[deleted]
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.
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.
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.
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.
It depends on how the question is phrased in the message box.
The point is that the question should not be phrased in such a way the the meanings of the text on the buttons could be ambiguous.
OK/Cancel is better than Yes/No, but (as noted in the top answer) worse than stating specifically what clicking the button will do.
OK/Cancel is better than Yes/No, but (as noted in the top answer) worse than stating specifically what clicking the button will do.
The problem is people didn't read the question carefully
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.
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.
> 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.
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.
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.
If you wanted the software to warn you it was buggy before you turned it on, haha good luck.
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.
And it'll still be there. But if you know what you're doing you won't have to read it to select the right option to move forward.
My point was that there are scenarios where data can be lost and a quick ok/cancel dialog with a short summary is not enough. Even when we know what we're doing a reminder of consequences is sometimes helpful to look at.
You know what formatting means, my grandmother does not. For the sake of less tech savvy users there should be a warning if the operation is dangerous in the sense that it will delete data. Maybe not as part of the question but as a sentence before, in another paragraph, so that you can easily skim it, while others may read it.
That's exactly the point though - you want to make the UI deep. Ideally when I hit "Format" I should get a confirmation dialog warning that I'll irreversibly erase things, with an "expand" button for more information. But, as a power user the correct button to hit should be self-evident without actually reading the dialog at all.
This way the user can go as deep or shallow as they want without losing context.
This way the user can go as deep or shallow as they want without losing context.
Agreed. 2/3 words on a button allows those who know what they're doing (or think they know) to make the decision quickly, and leaves the dialog text to give a bit more explanation for those that need it and would choose to read it.
Good point, I think we should always assume that the user just didn't read the question at all, and make the button actions explicit.
If the required action takes more space than a button label, perhaps it's a sign that the UX should be reviewed.
If the required action takes more space than a button label, perhaps it's a sign that the UX should be reviewed.
Haha, trick question right? Of course, use 确认 and 取消
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.
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.
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.
Although verbs like Save along with icons like a floppy disk might increase familiarity, so graphics could be applied moderately.
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.
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.
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.
Buttons & Labels: http://developer.apple.com/library/mac/#documentation/userex...
Alert Dialogs: http://developer.apple.com/library/mac/#documentation/userex...
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...