7 ms·

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

82 points by niico 14y ago

deleted 14y ago
[deleted]
constantx 14y ago
+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.
- revolutions 14y ago
  I agree that in the long run it would be better for users; yet as a user, I'm used to clicking on the Okay button on the left. Every time I see one isolated application with the Okay button on the right, I'm going to have a slower/harder time knowing which button I need to press. If one of your users uses 50 applications, and he uses yours once in a week, he's going to be annoyed at your application for being different; even if that "different" is supposedly better, reflexes have taught the user to scan the buttons in a certain way. I'm not suggesting that the order we have now is better; but until one of the OSs or an application like Facebook moves to the "better" button order, I can't see why a designer might do so for his own application.
  - veeti 14y ago
    Android changed the order of positive/negative buttons in dialogs with 4.0 and it took me ages to get used to the new order. Just stick with the platform default, please: it's what users expect.
  - constantx 14y ago
    couldn't agree more ;)
  - rtkwe 14y ago
    I agree, platform consistency is more better for your app than following something which is theoretically better. I'd be reticent to change the Ok -> Cancel order without some harder evidence than this.
    - rtkwe 14y ago
      "More better"? Jesus I should proof a bit...
bztzt 14y ago
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.
- ShirtlessRod 14y ago
  To me, this seems like a great example of unnecessary optimization. Yes, the number of "visual fixations" is slightly less but in the grand scheme of a person's day, we're talking about a difference of milliseconds, if that. Aren't there far more egregious examples of UI design to spend time agonizing over?
  - bztzt 14y ago
    Well, to steal a riff from Steve Jobs, milliseconds per day * days over years of use * tens/hundreds of millions of users (if you're designing the conventions for a big platform) = years or lifetimes. I'm just not convinced by the reasoning.
    - ShirtlessRod 14y ago
      Yes, I've heard that reasoning over and over again and it just doesn't hold water at all for me. "Time-saving" just doesn't work at that level of minutiae. Again, it's simply optimization where none is needed.
51Cards 14y ago
I still can't stand this in Android 4.0 Yes/No, OK/Cancel, Open/Close, On/Off, Come/Go, Stay/Leave, Buy/Sell, Gas/Brake, Thanks/No Thanks... 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.
- RobAtticus 14y ago
  Maybe Android switched it to be "easier" to use for most people. Since most people are right-handed, if they hold the phone one-handed in their dominant hand, putting the positive action puts it closer to the thumb that's being used to navigate.
- Swizec 14y ago
  In most of the world, though, it's Brake/Gas. And I personally prefer Cancel/OK because I usually want to click OK and my right thumb happens to be on the right side of the screen.
  - ars 14y ago
    That just because if you had gas in the middle it would be uncomfortable for long drives. It's the same reason the clutch is on the side as well, not in them middle. I suppose you could swap the cluch and gas (leaving brake in the middle) - but clutch comes first, then gas, so the convention of first on the left is realized.
    - Retric 14y ago
      Possible, but more likely more people are right footed than left so it's more natural to control acceleration with your right foot vs. the more mechanical shift process.
    - michaelcampbell 14y ago
phil 14y ago
Better yet, avoid modal dialogs.
- nativeblogger 14y ago
  Yes . Modal Dialogs with Yes/No , OK/Cancel are becoming old... :)
dcminter 14y ago
"...if you’re a knowledgeable and experienced designer ... then you can solve this problem through design analysis [as opposed to user testing]" 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.
- zaptheimpaler 14y ago
  Exactly. Most of the article was based on some sort of unjustified "innate" knowledge of how users behave. He dismisses platform consistency as being unscientific and then goes on to present his own equally unscientific arguments for ignoring the convention. In the face of these two alternatives, I'd choose platform consistency every single time.
  - twelvechairs 14y ago
    Designers work like this for good reason. Yes it reads like unproven pseudo-science, and it is, but there is reason behind this. When you work with thousands of concepts like this every day you can't empirically test them all across all cultures and environments (it would take forever and a day!) - you just develop a thought of what makes sense for you and have a basic think about why that might be so. This may not hold for all situations, but its going to be on average a better opinon than that of most other people (who will put a dialog box in one order or other without even stopping to think about why).
    - nathan_long 14y ago
      Kind of like how when you're going to choose a variable name, you don't do a linguistic study first?
      - hrktb 14y ago
        Well, ultimately it's the balance between your time and you user's time.
    - 14y ago
DrJokepu 14y ago
These arguments obviously only work for left-to-right scripts. For RTL scripts such as Arabic, you want exactly the opposite.
quesera 14y ago
Platform consistency has to come first, but I agree with the argument that OK/Cancel is backwards. 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 a lot. "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!" 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. And here we are.
- anigbrowl 14y ago
  "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!" Eh, that's rubbish. I did IT support for almost a decade in two countries and not once did I hear anyone express confusion about that.
- ars 14y ago
  Actually Cancel/OK is backwards. :) I had to swap their positions in firefox - one of the first things I changed when I ran it for the first time. > "OK" can be construed to mean "OK, well then obviously don't do that!" And yes can be construed to mean "yes don't do that" - come on, that's a completely ridiculous argument!
  - quesera 14y ago
    "OK" can mean: "ok yes you've changed my mind, I agree, bad idea". "Cancel" never means: "cancel and proceed".
    - nathan_long 14y ago
      "Do you really want to cancel?" Cancel/OK
lnanek2 14y ago
Here's an actual eye tracking study that comes to the opposite result of the linked article: http://www.lukew.com/ff/entry.asp?571 http://www.lukew.com/ff/entry.asp?571 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. 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.
- scott_meade 14y ago
  The lukew eye tracking study is for forms, not dialog boxes. And not just any forms, but it looks only at forms which have a list of left-aligned items which the user is working and scanning down. As stated: "the alignment of actions with a form’s input elements provides a clear path to completion that helps people complete forms faster." This article is about dialog boxes. They are different. Dialog boxes usually have no form input elements and usually do not have a list of items all aligned on the left like on the lukew tracking study.
- Someone 14y ago
  I do not think that comes to the opposite result. The only variant they test that has Cancel, OK in that order also is the only one where the rightmost button is far away from the other content. How far way, the report does not state. Being a web study, this could have been dependent on window width. The study also doesn't go into the consequences of various error rates. It is just about “Please complete the form fully and accurately". It does not test average performance if, say, users want to cancel out of the input in 5% of cases. It does not even ask me whether they feel confident that they can do so if they want.
felonioiusjones 14y ago
Created an account just to say this... 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.
- tjoff 14y ago
  And if you do that you force the user to read all options, which is completely unnecessary. If the question is "Reboot?" and you have Yes/No as alternatives I will see that it is a Yes/No-dialogue-box instantly, way before I read the buttons I see the button structure and recognize it as a typical Yes/No-dialogue-box. I read the question and because I already know my alternatives I have go directly to the option I want, if the buttons change every time I have to read and assess the situation every single time. This is good for critical questions (like, do you want to format this drive?) but bad for common questions (such as Save?). The author never even considered this, which is exactly why you should follow platform conventions. If you don't people are going to feel weird coming to your application and even if you manage to gain 10% in comprehension by switching to a non-standard layout you are going to loose 80% in comprehension and 10540% in speed just because you are different than what the user expected. Android ICS changed the place for the Cancel/OK buttons when unlocking the sim-card, my muscle memory still haven't learned this despite using ICS for many months. The only thing this article managed to get through to me was: follow your platform guidelines.
unconed 14y ago
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. 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. 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.
- SoftwareMaven 14y ago
  I was on the phone troubleshooting a webcam problem with my dad for an hour before he even mentioned the popup he had been clicking through (the one that told us why it wasn't working). If you are expecting users to read your error messages, you're doing it wrong.
  - lloeki 14y ago
    > If you are expecting users to read your error messages, you're doing it wrong. Hence it's even more important to call for action, not status in the button. If a button reads 'save' it has a much higher chance of being read than then long text before 'Ok'
- roryokane 14y ago
  The section of the Apple HIG about specific button labels is "UI Element Guidelines: Windows > Alerts": https://developer.apple.com/library/mac/#documentation/userexperience/Conceptual/AppleHIGuidelines/Windows/Windows.html#//apple_ref/doc/uid/20000961-TP10 https://developer.apple.com/library/mac/#documentation/usere... Microsoft's interface guidelines also give similar advice: http://msdn.microsoft.com/en-us/library/aa511268.aspx#respondMainInstruction http://msdn.microsoft.com/en-us/library/aa511268.aspx#respon... bonus: Here is a bug report whose comments includes a long explanation that I wrote, on why we should label the buttons "Save/Don't Save/Cancel" whether the platform standard says to or not: http://sourceforge.net/apps/ideatorrent/notepad-plus/ideatorrent/idea/370/ http://sourceforge.net/apps/ideatorrent/notepad-plus/ideator...
losvedir 14y ago
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. Not "Do you really want to quit? OK / Cancel" but "Do you really want to quit? Quit / Cancel".
- slig 14y ago
  Maybe the Apple HIG <https://developer.apple.com/library/mac/#documentation/userexperience/Conceptual/AppleHIGuidelines/Intro/Intro.html&#62 https://developer.apple.com/library/mac/#documentation/usere...; ?
makecheck 14y ago
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. 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. Another (admittedly minor) issue is the spelling "Ok". It's not pronounced "awk" or "oke"; it's both spelled and pronounced "OK". It does 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".
bztzt 14y ago
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"
huhtenberg 14y ago
It's a rational explanation that just happens to be ... wrong. 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.
- ajanuary 14y ago
  Unless you're trained to start with the right most button (something the article ignores). Also, positioning isn't the only factor - you can also highlight the primary action with colour and texture, which I would guess is far more effective at implanting a button as the primary option than positioning. Most OS's do this as a part of their keyboard accessibility.
ancelotpinto 14y ago
"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." ... I really like the `either go with me or your an idiot` push... false dilemma anyone?
eta_carinae 14y ago
Never take GUI advice from a web site that hardcodes the width of its paragraphs to 600px. Seriously, who does this in 2012?
- rimantas 14y ago
  People who understand, that there is such a thing as optimal line length, and that line running across 24" monitor does not have it?
  - eta_carinae 14y ago
    While this is theoretically correct, it goes against the principle of the web. Write the content, provide some structural guidance (paragraphs, item lists, etc...) and let readers decide how to render it.
Tooluka 14y ago
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. 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. 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. I confess that I'm Windows biased a little. But the author is biased just the same, only he is using Mac :) .
ikken 14y ago
Come on guys, claims with no backing data? 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." 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.
ravivyas 14y ago
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 & where the negative button is. Its more about habit than of user experience. No one actually reads that many lines of text.
city41 14y ago
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. 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. 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.
- ajanuary 14y ago
  I don't understand why putting "OK" first makes it a more deliberate choice. Why does it take more effort to get there? If a numb user's objective is to make it go away as quickly as possible they will become trained to where the "OK" button is and click it without reading anything else.
kree10 14y ago
How did we end up with OK/Cancel in the first place? 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. Is there a UI 'best practice' reason OK/cancel "won" over yes/no?
- ajanuary 14y ago
  I'm sure the Macintosh wasn't the first to go with OK/Cancel, but an interesting anecdote none the less about why "OK" won out over "Do It" http://folklore.org/StoryView.py?project=Macintosh&story=Do_It.txt&characters=Larry%20Tesler&sortOrder=Sort%20by%20Date http://folklore.org/StoryView.py?project=Macintosh&story...
ajanuary 14y ago
To me the assertion that users read buttons the same direction they read text is bogus. 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. 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. 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). 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.
antidoh 14y ago
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.
- ajanuary 14y ago
  The article does rather skip over that and starts by assuming that regardless of ordering you're aligning your buttons to the right of the dialog. You could go with OK/Cancel and left align the buttons so it's easier to find the OK button. Windows seems to go with OK/Cancel right aligned, which would be a little odd given the point you made. I guess the use of whitespace to visually group the buttons makes it easy enough to find the button group and from there you read them left to right. Would definitely be a interesting study to see the relative effects of aligning things to borders and visual grouping through use of whitespace.
wdewind 14y ago
Users will look at all of their options before they choose which action to take. Nope.

82 points by niico 14y ago

deleted 14y ago

[deleted]

+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.

revolutions 14y ago
I agree that in the long run it would be better for users; yet as a user, I'm used to clicking on the Okay button on the left. Every time I see one isolated application with the Okay button on the right, I'm going to have a slower/harder time knowing which button I need to press. If one of your users uses 50 applications, and he uses yours once in a week, he's going to be annoyed at your application for being different; even if that "different" is supposedly better, reflexes have taught the user to scan the buttons in a certain way. I'm not suggesting that the order we have now is better; but until one of the OSs or an application like Facebook moves to the "better" button order, I can't see why a designer might do so for his own application.
- veeti 14y ago
  Android changed the order of positive/negative buttons in dialogs with 4.0 and it took me ages to get used to the new order. Just stick with the platform default, please: it's what users expect.
- constantx 14y ago
  couldn't agree more ;)
- rtkwe 14y ago
  I agree, platform consistency is more better for your app than following something which is theoretically better. I'd be reticent to change the Ok -> Cancel order without some harder evidence than this.
  - rtkwe 14y ago
    "More better"? Jesus I should proof a bit...

bztzt 14y ago

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.

ShirtlessRod 14y ago
To me, this seems like a great example of unnecessary optimization. Yes, the number of "visual fixations" is slightly less but in the grand scheme of a person's day, we're talking about a difference of milliseconds, if that. Aren't there far more egregious examples of UI design to spend time agonizing over?
- bztzt 14y ago
  Well, to steal a riff from Steve Jobs, milliseconds per day * days over years of use * tens/hundreds of millions of users (if you're designing the conventions for a big platform) = years or lifetimes. I'm just not convinced by the reasoning.
  - ShirtlessRod 14y ago
    Yes, I've heard that reasoning over and over again and it just doesn't hold water at all for me. "Time-saving" just doesn't work at that level of minutiae. Again, it's simply optimization where none is needed.

51Cards 14y ago

I still can't stand this in Android 4.0 Yes/No, OK/Cancel, Open/Close, On/Off, Come/Go, Stay/Leave, Buy/Sell, Gas/Brake, Thanks/No Thanks... 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.

RobAtticus 14y ago
Maybe Android switched it to be "easier" to use for most people. Since most people are right-handed, if they hold the phone one-handed in their dominant hand, putting the positive action puts it closer to the thumb that's being used to navigate.
Swizec 14y ago
In most of the world, though, it's Brake/Gas. And I personally prefer Cancel/OK because I usually want to click OK and my right thumb happens to be on the right side of the screen.
- ars 14y ago
  That just because if you had gas in the middle it would be uncomfortable for long drives. It's the same reason the clutch is on the side as well, not in them middle. I suppose you could swap the cluch and gas (leaving brake in the middle) - but clutch comes first, then gas, so the convention of first on the left is realized.
  - Retric 14y ago
    Possible, but more likely more people are right footed than left so it's more natural to control acceleration with your right foot vs. the more mechanical shift process.
  - michaelcampbell 14y ago

phil 14y ago

Better yet, avoid modal dialogs.

nativeblogger 14y ago
Yes . Modal Dialogs with Yes/No , OK/Cancel are becoming old... :)

dcminter 14y ago

"...if you’re a knowledgeable and experienced designer ... then you can solve this problem through design analysis [as opposed to user testing]" 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.

zaptheimpaler 14y ago
Exactly. Most of the article was based on some sort of unjustified "innate" knowledge of how users behave. He dismisses platform consistency as being unscientific and then goes on to present his own equally unscientific arguments for ignoring the convention. In the face of these two alternatives, I'd choose platform consistency every single time.
- twelvechairs 14y ago
  Designers work like this for good reason. Yes it reads like unproven pseudo-science, and it is, but there is reason behind this. When you work with thousands of concepts like this every day you can't empirically test them all across all cultures and environments (it would take forever and a day!) - you just develop a thought of what makes sense for you and have a basic think about why that might be so. This may not hold for all situations, but its going to be on average a better opinon than that of most other people (who will put a dialog box in one order or other without even stopping to think about why).
  - nathan_long 14y ago
    Kind of like how when you're going to choose a variable name, you don't do a linguistic study first?
    - hrktb 14y ago
      Well, ultimately it's the balance between your time and you user's time.
  - 14y ago

DrJokepu 14y ago

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

quesera 14y ago

Platform consistency has to come first, but I agree with the argument that OK/Cancel is backwards. 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 a lot. "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!" 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. And here we are.

anigbrowl 14y ago
"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!" Eh, that's rubbish. I did IT support for almost a decade in two countries and not once did I hear anyone express confusion about that.
ars 14y ago
Actually Cancel/OK is backwards. :) I had to swap their positions in firefox - one of the first things I changed when I ran it for the first time. > "OK" can be construed to mean "OK, well then obviously don't do that!" And yes can be construed to mean "yes don't do that" - come on, that's a completely ridiculous argument!
- quesera 14y ago
  "OK" can mean: "ok yes you've changed my mind, I agree, bad idea". "Cancel" never means: "cancel and proceed".
  - nathan_long 14y ago
    "Do you really want to cancel?" Cancel/OK

lnanek2 14y ago

Here's an actual eye tracking study that comes to the opposite result of the linked article: http://www.lukew.com/ff/entry.asp?571 http://www.lukew.com/ff/entry.asp?571 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. 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.

scott_meade 14y ago
The lukew eye tracking study is for forms, not dialog boxes. And not just any forms, but it looks only at forms which have a list of left-aligned items which the user is working and scanning down. As stated: "the alignment of actions with a form’s input elements provides a clear path to completion that helps people complete forms faster." This article is about dialog boxes. They are different. Dialog boxes usually have no form input elements and usually do not have a list of items all aligned on the left like on the lukew tracking study.
Someone 14y ago
I do not think that comes to the opposite result. The only variant they test that has Cancel, OK in that order also is the only one where the rightmost button is far away from the other content. How far way, the report does not state. Being a web study, this could have been dependent on window width. The study also doesn't go into the consequences of various error rates. It is just about “Please complete the form fully and accurately". It does not test average performance if, say, users want to cancel out of the input in 5% of cases. It does not even ask me whether they feel confident that they can do so if they want.

felonioiusjones 14y ago

Created an account just to say this... 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.

tjoff 14y ago
And if you do that you force the user to read all options, which is completely unnecessary. If the question is "Reboot?" and you have Yes/No as alternatives I will see that it is a Yes/No-dialogue-box instantly, way before I read the buttons I see the button structure and recognize it as a typical Yes/No-dialogue-box. I read the question and because I already know my alternatives I have go directly to the option I want, if the buttons change every time I have to read and assess the situation every single time. This is good for critical questions (like, do you want to format this drive?) but bad for common questions (such as Save?). The author never even considered this, which is exactly why you should follow platform conventions. If you don't people are going to feel weird coming to your application and even if you manage to gain 10% in comprehension by switching to a non-standard layout you are going to loose 80% in comprehension and 10540% in speed just because you are different than what the user expected. Android ICS changed the place for the Cancel/OK buttons when unlocking the sim-card, my muscle memory still haven't learned this despite using ICS for many months. The only thing this article managed to get through to me was: follow your platform guidelines.

unconed 14y ago

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. 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. 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.

SoftwareMaven 14y ago
I was on the phone troubleshooting a webcam problem with my dad for an hour before he even mentioned the popup he had been clicking through (the one that told us why it wasn't working). If you are expecting users to read your error messages, you're doing it wrong.
- lloeki 14y ago
  > If you are expecting users to read your error messages, you're doing it wrong. Hence it's even more important to call for action, not status in the button. If a button reads 'save' it has a much higher chance of being read than then long text before 'Ok'
roryokane 14y ago
The section of the Apple HIG about specific button labels is "UI Element Guidelines: Windows > Alerts": https://developer.apple.com/library/mac/#documentation/userexperience/Conceptual/AppleHIGuidelines/Windows/Windows.html#//apple_ref/doc/uid/20000961-TP10 https://developer.apple.com/library/mac/#documentation/usere... Microsoft's interface guidelines also give similar advice: http://msdn.microsoft.com/en-us/library/aa511268.aspx#respondMainInstruction http://msdn.microsoft.com/en-us/library/aa511268.aspx#respon... bonus: Here is a bug report whose comments includes a long explanation that I wrote, on why we should label the buttons "Save/Don't Save/Cancel" whether the platform standard says to or not: http://sourceforge.net/apps/ideatorrent/notepad-plus/ideatorrent/idea/370/ http://sourceforge.net/apps/ideatorrent/notepad-plus/ideator...

losvedir 14y ago

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. Not "Do you really want to quit? OK / Cancel" but "Do you really want to quit? Quit / Cancel".

slig 14y ago
Maybe the Apple HIG <https://developer.apple.com/library/mac/#documentation/userexperience/Conceptual/AppleHIGuidelines/Intro/Intro.html&#62 https://developer.apple.com/library/mac/#documentation/usere...; ?

makecheck 14y ago

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. 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. Another (admittedly minor) issue is the spelling "Ok". It's not pronounced "awk" or "oke"; it's both spelled and pronounced "OK". It does 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".

bztzt 14y ago

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"

huhtenberg 14y ago

It's a rational explanation that just happens to be ... wrong. 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.

ajanuary 14y ago
Unless you're trained to start with the right most button (something the article ignores). Also, positioning isn't the only factor - you can also highlight the primary action with colour and texture, which I would guess is far more effective at implanting a button as the primary option than positioning. Most OS's do this as a part of their keyboard accessibility.

ancelotpinto 14y ago

"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." ... I really like the `either go with me or your an idiot` push... false dilemma anyone?

eta_carinae 14y ago

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

rimantas 14y ago
People who understand, that there is such a thing as optimal line length, and that line running across 24" monitor does not have it?
- eta_carinae 14y ago
  While this is theoretically correct, it goes against the principle of the web. Write the content, provide some structural guidance (paragraphs, item lists, etc...) and let readers decide how to render it.

Tooluka 14y ago

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. 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. 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. I confess that I'm Windows biased a little. But the author is biased just the same, only he is using Mac :) .

ikken 14y ago

Come on guys, claims with no backing data? 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." 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.

ravivyas 14y ago

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 & where the negative button is. Its more about habit than of user experience. No one actually reads that many lines of text.

city41 14y ago

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. 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. 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.

ajanuary 14y ago
I don't understand why putting "OK" first makes it a more deliberate choice. Why does it take more effort to get there? If a numb user's objective is to make it go away as quickly as possible they will become trained to where the "OK" button is and click it without reading anything else.

kree10 14y ago

How did we end up with OK/Cancel in the first place? 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. Is there a UI 'best practice' reason OK/cancel "won" over yes/no?

ajanuary 14y ago
I'm sure the Macintosh wasn't the first to go with OK/Cancel, but an interesting anecdote none the less about why "OK" won out over "Do It" http://folklore.org/StoryView.py?project=Macintosh&story=Do_It.txt&characters=Larry%20Tesler&sortOrder=Sort%20by%20Date http://folklore.org/StoryView.py?project=Macintosh&story...

ajanuary 14y ago

To me the assertion that users read buttons the same direction they read text is bogus. 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. 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. 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). 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.

antidoh 14y ago

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.

ajanuary 14y ago
The article does rather skip over that and starts by assuming that regardless of ordering you're aligning your buttons to the right of the dialog. You could go with OK/Cancel and left align the buttons so it's easier to find the OK button. Windows seems to go with OK/Cancel right aligned, which would be a little odd given the point you made. I guess the use of whitespace to visually group the buttons makes it easy enough to find the button group and from there you read them left to right. Would definitely be a interesting study to see the relative effects of aligning things to borders and visual grouping through use of whitespace.

wdewind 14y ago

Users will look at all of their options before they choose which action to take. Nope.