Live data from Hacker News

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

uxmovement.com

11–20 of 83 posts

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

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

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

#12
post #4

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.

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?

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

#14

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

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.

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

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

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

#16
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…

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.

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

#17
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…

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.

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

#18
post #15

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

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

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

#19
post #4

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.

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?

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.

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

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

Post reply on HN