Should I use Yes/No or Ok/Cancel on my message box?
Semantically, the Yes/No buttons are roughly equivalent to the Ok/Cancel buttons, but in general what would you recommend to use? Should I always use Yes/No or always use Ok/Cancel? Or does it depend on the case?
Not directly related, but here's the relevant windows edutainment on the matter http://www.youtube.com/watch?v=mKkLjJHwRec
**Never use «Cancel»** because of a potential ambiguity on two levels of understanding: http://ux.stackexchange.com/a/35844/28034 (an answer of mine).
Never use 'Yes' or 'OK' when you could use a verb instead.
And you can almost always use a verb instead of 'Yes' or 'OK'.
I agree with Lukas Mathis' postulation that nobody reads your dialog boxes. Use a verb whenever possible instead of 'Yes' or 'OK' because your buttons will make sense out of context with the explanatory text or title. This is a view that's further reinforced in Microsoft's user interface guidelines:
If you want to make sure that users read specific text related to an action, place it on an interactive control.
In this example, there's a chance that users won't read the text that explains what they're confirming.
In this example, you can be sure that at least users understand that they are about to format a disk.
Apple's Human Interface Guidelines expand on this even further, recommending multi-word verbs instead of "OK" or "Yes" buttons, and clearly defining the suggested regions for an alert box:
They advise to only use an alert box in the first place if the action is not undoable. On the subject of button labels, they offer this:
Ensure that the default button name corresponds to the action you describe. In particular, it’s a good idea to avoid using OK for the default button. The meaning of OK can be unclear even in alerts that ask if the user is sure they want to do something. For example, does OK mean “OK, I want to complete the action” or “OK, I now understand the negative results my action would have caused”?
Using a more focused button name, such as Erase, Convert, Clear, or Delete, helps make sure that users understand the action they’re taking.
In short, even if it might seem like the only or most logical options are to offer the user a "Yes" or "No" button (e.g. "Are you sure you wish to log out?"), you can almost always use a verb or phrase instead.
"Do you want to log out?"
[Log Out] -or- [Cancel]
In this way, a user need not read the title or explanatory text to understand how to proceed, and the meaning of clicking either button cannot be misinterpreted.
Also note that, given a choice between 'No' and 'Cancel', 'Cancel' is almost always better for exactly the same reasons as above: the meaning of 'Cancel' is clear even if the user hasn't read the rest of the dialog box. The meaning of 'No' is probably clear, but makes less sense when paired with a verb (e.g. 'Log Out' and 'Cancel' make more sense read alone than 'Log Out' and 'No').
While the first dialog can look extremely weird, basic Windows dialogs can only choose from a limited number of button texts (ok, cancel, yes, no) and if you do not want to implement your own dialogs you're stuck with those. This is why you can see even weirder things such as "Hit OK to quit or Cancel to debug the application". (With reservation that this is probably fixed in newer versions of Windows)
As a side comment - for the formatting dialog, and other important non-undoable actions, I'd put the focus on the "Cancel" button.
@MatsT On the other hand, I would suggest it's worth the effort to roll your own dialog box in the name of easier-to-use software.
All I can say, is be careful with synonyms of cancel. The Ok/Cancel and Yes/No paradigm is often less confusing than some of the dialogs I've used on a few Linux apps.. who apparently agree with your assessment. My conclusion is that 'Yes/No' should be avoided less than 'Ok/Cancel'
For OK/Cancel you should think about what the question is. These days even Apple reverses the button order when the default answer should be cancel.
I read the section of the article surrounding that post and it makes no mention of why they chose to have no title. Any ideas on that? Personally, I like the idea of a title, but that's just me.
Kind of ironic that Apple's guideline example is ambiguous. Am I securing the empty trash, or am I securely emptying the trash? It should've been "Securely Empty Trash / Cancel"
@mskfisher: it wasn't so bad this time around since the longer help text does explain which clearly, but yes, it certainly could be improved.
Phrasing the message to fit within the confines of windows messages works as well: "Are you sure you want to format your hard drive?" will fit grammatically with Yes and No option buttones.
@MatsT @Phil I decided to do this a while back, so I created a customizable WPF clone of the native .NET/Windows `MessageBox`. It's a plug-and-play replacement for the standard `MessageBox`, but offers methods to add custom strings to the `Ok`, `Ok/Cancel`, `Yes/No`, and `Yes/No/Cancel` buttons. You can check it out on Github: https://github.com/evanwon/WPFCustomMessageBox
@Michael — Apple reversing the button order ? Do you have an example ?
@NicolasBarbulesco Erase in Disk Utilities has the button order as Cancel/Erase but sets the default to Cancel instead of Erase. In this dialog hitting return will not complete the action instead of completing it. The user in the Erase dialog will have to deliberately click the Erase button, not just mindlessly go OK. Also Quit in Disk Utilities brings up a Quit/Don't Quit with Don't Quit as the default, the order in other programs is Cancel/Quit with Quit as the default.
@Michael — In your examples, Apple does not reverse the button order. The buttons are in the good order, with the action button being the last one. Regarding the button *Cancel* being the default button : yes this is unusual, but this is justified for an action bearing a huge risk such as formatting a volume.
https://www.joelonsoftware.com/2000/04/26/designing-for-people-who-have-better-things-to-do-with-their-lives/ The earliest observation in print I know of the 'Users don't Read' problem.