Why ‘Ok’ Buttons in Dialog Boxes Work Best on the Right

Ok and Cancel are the wrong button labels anyway. The Apple HIG say that buttons should be labeled with verbs that signify the action taken.<p>For example, Cancel/No/Yes becomes "Don't Quit" "Don't Save" "Save". Much more intuitive, and it gives additional reason to put the positive button last: users should be encouraged to read all the options available before deciding—and can get the gist by reading just the buttons and ignoring the message.<p>Otherwise you get dialog box blindness. If you've ever observed someone doing this, it's maddening. They try something, a dialog pops up, they dismiss it, nothing happens (because the dialog box said "Can't complete this action"). I've seen people repeat this up to 4 times.

Here's an actual eye tracking study that comes to the opposite result of the linked article: <a href="http://www.lukew.com/ff/entry.asp?571" rel="nofollow">http://www.lukew.com/ff/entry.asp?571</a><p>This isn't really surprising. The article claimed he just knew from experience and didn't need to do a test, so the whole article was just bullshit.<p>I was laughing out loud when he said users read all the options before picking one anyway, since I've seen that not happen in countless tests. Users don't generally give a crap about your interface, won't read instructions or screens fully, and will just scan and grab on to something that matches their current goal.

"...if you’re a knowledgeable and experienced designer ... then you can solve this problem through design analysis [as opposed to user testing]"<p>But if you're an empirical scientist you will use user testing to confirm or deny your hypothesis rather than assuming your rationalisations hold in the real world.

I still can't stand this in Android 4.0<p>Yes/No, OK/Cancel, Open/Close, On/Off, Come/Go, Stay/Leave, Buy/Sell, Gas/Brake, Thanks/No Thanks...<p>In English anyhow we are used to Positive option first, Negative option second... it's how our language flows and thus how we think. We read Left to Right... we expect the positive option on the Left, i.e. first, and the negative option on the Right, second. Just how I view it anyhow. To me it feels backwards the other way around and I don't feel that's just a learned convention. I will continue to curse Android 4 every time I mis-click on a dialog.

Platform consistency has to come first, but I agree with the argument that OK/Cancel is backwards.<p>Apple chose those labels (as Cancel/OK) for the buttons in the original Mac dialogs in 1984. They tested other pairs, but those two labels won. With those two labels, order matters <i>a lot</i>.<p>"Cancel" is the more meaningful word of the two. You've just told the user that something unexpected will happen if they proceed. "OK" can be construed to mean "OK, well then obviously don't do that!"<p>So yeah, platform consistency first. But Apple tested that stuff back in the early 80s, those two labels won, and (in addition to all the reasonable arguments in the article), that's the only rational order for those two labels. Microsoft got it backwards and trained millions of people by confusing them until they learned. Gnome aped Microsoft.<p>And here we are.

I think the article's explanations for button-ordering are good but I wish their examples didn't violate other dialog design principles in the process.<p>One mistake their examples make is to include an "X" (close) button in dialogs that contain button choices. The "X" action is ambiguous in dialogs and is especially bad if all actions are equally probable (e.g. "Don't Save", "Cancel" and "Save" all seem likely to map to "X"). GUI toolkits don't seem to force any consistent interpretation of "X", and in fact the programmer might forget to wire up the "X" to any action at all. It's preferable for the "X" button to not be there so that the user can focus on the action buttons.<p>Another (admittedly minor) issue is the spelling "Ok". It's not pronounced "awk" or "oke"; it's both spelled and pronounced "OK". It <i>does</i> have a whole-word form and that word is "Okay". So it can either be "OK" or "Okay" but it should not be "Ok". In dialogs it is very conventional to use the short form of "OK".

I suspect most (moderately) experienced people see the OK/Cancel pattern as a unit and don't scan the whole thing before deciding and clicking.

Come on guys, claims with no backing data?<p>The author writes "user testing is probably your best bet. But if you’re a knowledgeable and experienced designer who can think about problems from the user’s perspective, then you can solve this problem through design analysis."<p>This is so wrong. Actually design analysis can turn out to be completely wrong. You need to test it, get some numbers, and then you can claim that conclusions of your analysis are correct. Right now it's just a claim that may or may not hold.

Created an account just to say this...<p>This is the wrong question all together. Yes/No is the wrong idea. Think about labeling the buttons Save/Reboot/Cancel, This allows the user to be sure they are going to get the expected results.

Never take GUI advice from a web site that hardcodes the width of its paragraphs to 600px.<p>Seriously, who does this in 2012?

I know I read somewhere (but I can't remember where now), that it's far superior to put the actual actions you're doing in the buttons, rather than a completely non-descriptive OK/Cancel.<p>Not "Do you really want to quit? OK / Cancel" but "Do you really want to quit? Quit / Cancel".

Picture 1, "Less Visual Fixation": I think it is wrong, if I'm processing simple (or repeating) stack of windows I do not read all labels (at least after a few similar tasks), I see OK button and I click it.<p>Picture 3, "Maps to the expected button functions" This is also wrong, there are specific labels for actions on the picture - Back/Next, Backward/Forward, Return/Continue.<p>Picture 4, "Gives users a more efficient task flow" I agree with eyesight map (left to right, up to down) and this is precisely why OK should be on the left side - so we don't need to read further.<p>I confess that I'm Windows biased a little. But the author is biased just the same, only he is using Mac :) .

To me the assertion that users read buttons the same direction they read text is bogus.<p>I'm an OS X user and I'm trained to read the right most button first as it has the description of what will happen (Save, Log Out etc.) Often it means I don't even have to read the rest of the dialog.<p>As others have pointed out, this indicates the whole idea that users will read all the options is bogus. But even when I do read them all (marginally complex set of options presented, or high risk scenario) I read the right most one first before skipping back to read left to right because I'm trained to skip to the right most button at the bottom of a dialog.<p>This invalidates much of the analysis on visual fixations and comes to the conclusion that placing the primary action on the left actually makes it easier under certain conditions (it's easier to track back to the left most button than to the right most).<p>It just goes to show that training can affect behaviour. If you did extensive eye-tracking tests explaining you're looking for high accuracy, with people who are unfamiliar with technology or who are used to the primary action being on the left, placing the primary action on the right will lead to less effort. But as the user is trained, the effort would probably increase.

I disagree that OK/cancel are backwards. Placing OK on the left makes it a more deliberate choice. Thus the system can be more confident the user consciously chose OK, as it takes a smidge more effort to get there. OK/Cancel dialogs are (unfortunately) very common, it's very easy for users to become numb to them and just click whatever it takes for them to go away.<p>For similar reasons, Mac OS Classic placed the trash can in the lower right corner of the screen. If you had dragged something that far, there was nothing else you could possibly be shooting for. Therefore making the system more confident you were actually dragging that file to the trash. Which is one reason MacOS never asked "are you sure you want to delete that?" like Windows's recycle bin does by default.<p>Another similar example: MacOS classic placed the close button of Windows on the opposite side, on its own. Again, if you are clicking there, the system is more confident that closing the window is what you're really after. It's interesting to note that OSX did away with many of these well thought out devices.

"If you’re an inexperienced designer who doesn’t trust your own judgment, then user testing is probably your best bet. But if you’re a knowledgeable and experienced designer who can think about problems from the user’s perspective, then you can solve this problem through design analysis."<p>... I really like the `either go with me or your an idiot` push... false dilemma anyone?

These arguments obviously only work for left-to-right scripts. For RTL scripts such as Arabic, you want exactly the opposite.

I believe studies on this are worthless. Show 2-3 modals to a user and he/she tends to understand where the positive button is &#38; where the negative button is. Its more about habit than of user experience.<p>No one actually reads that many lines of text.

I'm surprised Fitts' law hasn't come up. While not exactly the same domain as Fitts (minimize the need for fine motor control for a potentially gross action by placing the active area at the end of a gross movement, e.g. pointing to the edge of the screen) it would seem that gaze would be easier to fix on the edge or corner of a dialog, rather than somewhere in the interior.

How did we end up with OK/Cancel in the first place?<p>When I run into an OK/Cancel box (usually on a web page using the generic built-in confirm()), it often feels to me like the meaning would be far more clear if the options were "yes" or "no", no matter which order they're displayed.<p>Is there a UI 'best practice' reason OK/cancel "won" over yes/no?

It's a rational explanation that just happens to be ... wrong.<p>Cancel/OK suggests Cancelling first, OK'eying second. Whether your eye has already moved on from Cancel is secondary to the fact that you brain got implanted with Cancel as a primary option.

Better yet, avoid modal dialogs.

BTW, what's caused me more confusion than any of this is Cancel vs. the third option: "hit Back button on browser/phone / Close button on dialog"

<i>Users will look at all of their options before they choose which action to take</i>.<p>Nope.

+1 and yet, most arguments will end up toward the direction of "platforms consistency," especially on Facebook-related application since they have it "OK" | "Cancel" order.