Why ‘Ok’ Buttons in Dialog Boxes Work Best on the Right • Hacker News Board

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

#31

Post by nathan_long » Sun, Jun 17, 2012, 3:09 AM UTC

twelvechairs wrote: post #23

zaptheimpaler wrote: post #14

Earlier quoted context omitted.

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.

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 h…

Kind of like how when you're going to choose a variable name, you don't do a linguistic study first?

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

#32

Post by nathan_long » Sun, Jun 17, 2012, 3:10 AM UTC

quesera wrote: post #29

ars wrote: post #27

Earlier quoted context omitted.

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!

"OK" can mean: "ok yes you've changed my mind, I agree, bad idea". "Cancel" never means: "cancel and proceed".

"Do you really want to cancel?" Cancel/OK

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

#33

Post by makecheck » Sun, Jun 17, 2012, 3:28 AM UTC

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

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

#34

Post by rtkwe » Sun, Jun 17, 2012, 3:40 AM UTC

rtkwe wrote: post #10

revolutions wrote: post #5

Earlier quoted context omitted.

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 differe…

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.

"More better"? Jesus I should proof a bit...

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

#35

Post by bztzt » Sun, Jun 17, 2012, 3:42 AM UTC

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"

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

#36

Post by huhtenberg » Sun, Jun 17, 2012, 3:45 AM UTC

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.

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

#37

Post by hammock » Sun, Jun 17, 2012, 3:55 AM UTC

capex wrote: post #22

51Cards wrote: post #8

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 a…

This has nothing to do with English language. As a culminating point of a dialog box, I believe the suggested action should be towards the corner, not hidden between a 'Cancel' button in the right corner and the rest of the dialog box.

This is what I came here to say- one more reason not mentioned for putting the primary action in the corner is that it's easier to find and fix on with your eyes and the mouse.

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

#38

Post by slig » Sun, Jun 17, 2012, 3:57 AM UTC

losvedir wrote: post #30

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

Maybe the Apple HIG https://developer.apple.com/library/mac/#documentation/usere...; ?

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

#39

Post by SoftwareMaven » Sun, Jun 17, 2012, 4:33 AM UTC

unconed wrote: post #24

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…

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.

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

#40

Post by Someone » Sun, Jun 17, 2012, 4:45 AM UTC

lnanek2 wrote: post #20

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 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 test…

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.