Live data from Hacker News

Ok-Cancel versus Cancel-Ok

factorio.com

101–110 of 286 posts

Re: Ok-Cancel versus Cancel-Ok

#101

This has been a debate for as long as I've been a UX designer (mid '90s), and probably much longer. Ultimately, the answer about this UX style is very much the same as a question about writing style—there's no objectively right answer, but you have to be consistent. For example, you can pick up any number of style books from Strunk & White to the Chicago Manual of Style and get different "right" answers about writing…

> So the answer from this veteran UX designer would be: Use whichever placement your users are going to be the most familiar with, but whichever you choose, be 100% consistent with the choice you make. Not only that, but make the "OK" choice standout with a different color. If the "default" option is brighter than the rest, your eyes will most likely gravitate towards it first, regardless of the order of the buttons.

In my bank web application the OK button is on the left, and... both buttons are RED because that's the brand's color!

It's a terrible web app.

Re: Ok-Cancel versus Cancel-Ok

#102

Earlier quoted context omitted.

Yes, precisely. The worst UI I've ever seen was: "Cancel this action?" "Yes" "Cancel" Seriously?!

That also shows why the "repeat the verb again" can be more confusing. At least it wasn't "Cancel this action?" "Cancel" "Cancel" On the other hand, I think Yes or No are clearly an answer to "Cancel this action?"

This is the edgiest of edge cases. Intuitively I would assume that such a dialogue box may be a UX smell and there could be better ways to perform a two stage confirmation.

Or you can just bend the UX rules for this one instance.

Or you can consider whether cancel is the best verb anyway; what about “end” or “stop” or “abort”?

Re: Ok-Cancel versus Cancel-Ok

#103

This has been a debate for as long as I've been a UX designer (mid '90s), and probably much longer. Ultimately, the answer about this UX style is very much the same as a question about writing style—there's no objectively right answer, but you have to be consistent. For example, you can pick up any number of style books from Strunk & White to the Chicago Manual of Style and get different "right" answers about writing…

> Use whichever placement your users are going to be the most familiar with, but whichever you choose, be 100% consistent with the choice you make. I think this is the right answer. Personally and anecdotally, I doubt it makes a noticeable difference which way they are, as long as they are that way everywhere. I will soon learn that "confirm/apply/proceed" is one way, and "back/cancel/revert" is the other way, whiche…

Yes, definitely agree. I feel the latest UI for iPhone alarms and the timer are a good example of how inconsistency in button placement can be confusing.

When a timer finishes, you get a large button at the top for Stop, and a smaller one at the bottom for Repeat. When an alarm goes off, the Stop button is the small one at the bottom, and the larger top button says Snooze. Very often I find myself repeating a timer instead of stopping it.

Re: Ok-Cancel versus Cancel-Ok

#104
post #95
post #89

On macOS I have turned on the setting that lets one tab through all controls (System Preferences → Keyboard → Shortcuts → All controls). When a “Cancel OK” dialog appears, “OK” is the default choice (in blue) but Cancel is the highlighted one[1], presumably because it’s the first option. This is incredibly convenient because ↵ will activate “OK”, while pressing the space bar will activate “Cancel”. One gets used fast…

> System Preferences → Keyboard → Text → All controls It's System Preferences → Keyboard → Shortcuts → All controls on my Mac (10.13.5)

You’re correct. Fixed the top post. Thank you.

Re: Ok-Cancel versus Cancel-Ok

#105

Earlier quoted context omitted.

> Use whichever placement your users are going to be the most familiar with, but whichever you choose, be 100% consistent with the choice you make. I think this is the right answer. Personally and anecdotally, I doubt it makes a noticeable difference which way they are, as long as they are that way everywhere. I will soon learn that "confirm/apply/proceed" is one way, and "back/cancel/revert" is the other way, whiche…

Yes, definitely agree. I feel the latest UI for iPhone alarms and the timer are a good example of how inconsistency in button placement can be confusing. When a timer finishes, you get a large button at the top for Stop, and a smaller one at the bottom for Repeat. When an alarm goes off, the Stop button is the small one at the bottom, and the larger top button says Snooze. Very often I find myself repeating a timer i…

That happens to me too, and I find it equally annoying, but I think it is a deliberate design choice. As I understand it they are trying to make it hard to accidentally turn off the alarm and go back to sleep, which would be a critical failure if you missed an interview or were late for work. Presumably irritation at the difficulty of switching it off is seen as the lesser of two evils

Re: Ok-Cancel versus Cancel-Ok

#106

Earlier quoted context omitted.

> Use whichever placement your users are going to be the most familiar with, but whichever you choose, be 100% consistent with the choice you make. I think this is the right answer. Personally and anecdotally, I doubt it makes a noticeable difference which way they are, as long as they are that way everywhere. I will soon learn that "confirm/apply/proceed" is one way, and "back/cancel/revert" is the other way, whiche…

Yes, definitely agree. I feel the latest UI for iPhone alarms and the timer are a good example of how inconsistency in button placement can be confusing. When a timer finishes, you get a large button at the top for Stop, and a smaller one at the bottom for Repeat. When an alarm goes off, the Stop button is the small one at the bottom, and the larger top button says Snooze. Very often I find myself repeating a timer i…

I find myself hitting stop instead of snooze, which may turn into a disaster some day. Simply touching your phone without care may stop the alarm.

iPhone alarm control became so wrong that I stopped using the screen and snooze only via top physical button. I’m not sure, but feels like it wasn’t like that before some idiot decided to change the way alarm works for sleepy subconsciously-trained users. Curious how many $M net cost was put into this “design”.

(Googled it: there was no stop button in ios 5, only slide-to-stop, which you cannot do accidentally)

Re: Ok-Cancel versus Cancel-Ok

#107

Earlier quoted context omitted.

> Some call it "Programming: The Game". This is actually why I haven't bought it (yet). When I have the urge to program something, I think I'd rather put that towards building something real than playing Factorio.

I usually agree, but while it certainly feels like programming it does so in an entirely theoretical environment where both concurrency and parallelism is nearly infinite. I think that makes it feel different enough.

Might as well grab an FPGA. :)

Re: Ok-Cancel versus Cancel-Ok

#108
Countless times i've been victim of the "do you want to save?" dialog where the replies were |Yes|No|Cancel|. In some cases the brain knows it made a mistake, and whatever dialog comes, the reply should be the negative one. And with those options, the subconscious clicked No (the most destructive operation) before I knew what was happening. To me, the buttons should read |Save|Discard|Go back| in whatever order the creator wants. I think that even the dialog could just skip the text, with those button labels it isn't needed at all.

Re: Ok-Cancel versus Cancel-Ok

#109
post #38

This has been a debate for as long as I've been a UX designer (mid '90s), and probably much longer. Ultimately, the answer about this UX style is very much the same as a question about writing style—there's no objectively right answer, but you have to be consistent. For example, you can pick up any number of style books from Strunk & White to the Chicago Manual of Style and get different "right" answers about writing…

Okay/Confirm/Continue on the right is easier to hit with the mouse for me since it is in the corner of the window.

But why? Mouse pointer tends to be at a random position relative to a dialog window. According to GOMS, there should be no difference, unless one of the buttons touches screen border or is significantly closer.

Re: Ok-Cancel versus Cancel-Ok

#110
post #63

This has been a debate for as long as I've been a UX designer (mid '90s), and probably much longer. Ultimately, the answer about this UX style is very much the same as a question about writing style—there's no objectively right answer, but you have to be consistent. For example, you can pick up any number of style books from Strunk & White to the Chicago Manual of Style and get different "right" answers about writing…

Even in film the convention is that if you're character is going back, standing in the way of another character moving the plot forward, or just feeling weak or uncertain, they should face the left. When was the last platformer you saw where you moved left to progress? The right hand side conventionally portrays certainty, strength, and progress in all manner of western arts.

Since you asked... About half of the first Castlevania is right-to-left. There are plenty of cues as to where to go, so you never really notice it.

On the other hand -- it's set in an evil castle, with dark muddy colors and a minor-key soundtrack. So maybe the right-to-left motion is intended to make the player feel uncomfortable.

Post reply on HN