Ok-Cancel versus Cancel-Ok • Hacker News Board

Re: Ok-Cancel versus Cancel-Ok

#241

Post by latexr » Sat, Jun 09, 2018, 1:13 PM UTC

Too wrote: post #166

latexr wrote: 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…

Wow, you have to manually activate such an option? On windows it's default. One of the things i love about windows is that it's always been designed for keyboard only use, not just bolted on as an afterthought. Every dialog, widget, application and feature can be used with only the keyboard and it's fast, easy and predictable how to. Unfortunately since windows 8 there's been some regressions in this area with the ne…

> Wow, you have to manually activate such an option? On windows it's default.

I don’t think that’s deserving of “wow”. I don’t think it’s that big of a deal. It’s a clear option that is quite visible and present in the exact preference pane you’d expect. And you don’t need to activate it manually. You can do it via CLI:

    defaults write NSGlobalDomain AppleKeyboardUIMode -int 3

> not just bolted on as an afterthought.

I haven’t used Windows in years so I can’t compare, but keyboard support on macOS doesn’t feel like an afterthought to me. Without leaving the same screen where one activates keyboard support for all controls, one can also change and set keyboard shortcuts for every other action including every menu option of every app. And if doing it manually isn’t your thing, you can also define those keyboard shortcuts via CLI. It even works for setting single key (no modifier) shortcuts.

Re: Ok-Cancel versus Cancel-Ok

#242

Post by Ensorceled » Sat, Jun 09, 2018, 1:16 PM UTC

I briefly managed a team where the two senior developers were in the middle of a style war. Half the team was K&R the other OTBS. And half the UI was Ok-Cancel and the other half Cancel-Ok.

Years ago, we had a critical for a “company saving trade show demo” setup on an early version of Windows NT. There was a server fault and when we brought it back up there was a glitch. No matter what we did the system kept presenting us with a modal warning that proceeding would probably destroy the data on the hard drive. The choices where Ok and Continue. After several calls to MS we finally called our partners and GE was able to back channel us to the developer who wrote the modal who told us “Continue” was the safe option. At least he admitted it wasn’t the best way of presenting “do it” or “skip this step” options.

Personally, I’m firmly in the Cancel —- “verb the thing” camp these days.

Re: Ok-Cancel versus Cancel-Ok

#243

Post by latexr » Sat, Jun 09, 2018, 1:17 PM UTC

red75prime wrote: post #185

latexr wrote: 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…

When you need to optimize the speed of going through dialog boxes, something is wrong with your UI, I think.

I don’t need to optimise the speed. I like that I can.

When you make a mistake that prompts a dialog box, having to move your cursor to undo can feel slightly punishing. Doing it with a single key press makes it feel like part of the process.

Re: Ok-Cancel versus Cancel-Ok

#244

Post by tigershark » Sat, Jun 09, 2018, 1:17 PM UTC

noisem4ker wrote: post #216

arendtio wrote: post #204

Earlier quoted context omitted.

I think there is one factor missing: While it might be true that many of us are reading from left to right, our usage of UI is not necessarily defined by the same patterns as reading. When we start using a UI we certainly read every button before clicking on one, but after a while we just want to find the correct button. And in that case it might be helpful to place the button for the primary action right next to the…

The button group at the lower right corner is where we start looking for our button. Inside that button group, which is quickly located, buttons are parsed left to right. To add to this, if we're doing a task, it's probably safe to assume we're more interested in going on with it, so there's a reason for the affirmative button being at the left of the group (first to be parsed). Also, you typically ask "Yes or no?",…

Exactly it’s incredibly unnatural to ask “are you not sure or yes?” compared with “are you sure or not?”

Re: Ok-Cancel versus Cancel-Ok

#245

Post by erichurkman » Sat, Jun 09, 2018, 1:43 PM UTC

ProxCoques wrote: post #215

pasta wrote: post #164

Earlier quoted context omitted.

This is how it should be done. People don't read the message in the popup. But when presented with a Delete button users start to think about what they are doing. Also: 'Delete - Cancel' sets 'Cancel' in a much better context. You are going to cancel a delete action not an 'Ok' action.

When it comes to OK/Cancel for a non-recoverable event (like delete), it's ALWAYS been the case that the dialogue should NOT appear in the first place. Instead, the UI should be seen to do the operation, but then delay its execution while showing an "undo" for a few seconds. The reason for this is that 99.9% of people know what they're doing. So don't bother them for the sake of the 0.1% who make a mistake. But more…

Maybe for power users. Time based UI actions are not accessible, though. Novice users, elderly, those with lowered motor functions, etc will struggle with time-based interactions.

In your example, you could use a dialog during the first delete with a toggle option in the delete confirmation dialogue of "don't show this next time."

Re: Ok-Cancel versus Cancel-Ok

#246

Post by justherefortart » Sat, Jun 09, 2018, 1:46 PM UTC

fnordsensei wrote: post #162

jaysonelliot wrote: post #19

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…

Great summary. Another thing to note in the Factorio mockups is the use of a guideline that I originally picked up from the macOS HIG[1]: use descriptive verbs rather than a generic confirmation. "Apply settings" vs "OK" "Load game" vs "OK" "Delete file" vs "OK" "Send email" vs "OK" "Print" vs "OK" and so on. [1]: https://developer.apple.com/design/human-interface-guideline...

It's because they're using default dialogs specific to the OS.

People could override them but after decades of use most make sense.

I'm sure MS flipped the MacOS ones simply for liability reasons (initially).

Re: Ok-Cancel versus Cancel-Ok

#247

Post by scrollaway » Sat, Jun 09, 2018, 1:52 PM UTC

masklinn wrote: post #225

codeflo wrote: post #8

Earlier quoted context omitted.

Oh, you will regret it. That’s like saying “Try heroin! You’ll absolutely love it.” Not technically wrong... (Edit: I’m joking. It’s a great game.)

> (Edit: I’m joking. It’s a great game.) It's a joke, but like all the best jokes it's one with a large grain of truth and exactly why I've held off buying Factorio for now (Frostpunk as well).

You're probably safer with Frostpunk. It seems much more self-contained; you'll play it through once, and then you're unlikely to pick it up again.

Re: Ok-Cancel versus Cancel-Ok

#248

Post by dchest » Sat, Jun 09, 2018, 2:12 PM UTC

code_duck wrote: post #235

dchest wrote: post #209

Earlier quoted context omitted.

I wouldn't call it a dark pattern: there's no trickery or deception; nothing bad happens if you pressed the wrong button. It's called a "nag screen", and in many cases it's the only difference between a trial version and a paid one. Here's an example from Total Commander: https://www.dedoimedo.com/images/computers_new_2/windows-coo... (the number to press changes randomly between launches)

It's an attempt to trick the user into clicking the wrong button. Maybe not dark, since all that happens is it annoyingly opens an website, but nonetheless, it is not pleasant or user friendly to intentionally deceive others into doing something they wish to avoid. I believe that practices that are labeled the dark patterns on websites often have no more impact than that. I'd call it 'user hostile'.

No, it's a attempt to intentionally slow down user. I don't remember nag screens that open websites: it either tells you that you press the wrong button and re-randomizes the button order or quits the program. There are also versions that just have a timer that enable "Continue" button after a few seconds (e.g. https://kinzuakid.files.wordpress.com/2009/05/gsak-nag-scree...). It's very different from websites that trick you into clicking a button that leads you somewhere. It's a nag screen in a demo version that you can get rid of by purchasing the program. It intentionally nags/annoys users, but very far from dark or gray patterns. In fact, many of them only appear if you violate the license by using the program after the allowed period; being slightly less user friendly but still allowing users to use the program.

Re: Ok-Cancel versus Cancel-Ok

#249

Post by oldcynic » Sat, Jun 09, 2018, 2:15 PM UTC

ProxCoques wrote: post #215

pasta wrote: post #164

Earlier quoted context omitted.

This is how it should be done. People don't read the message in the popup. But when presented with a Delete button users start to think about what they are doing. Also: 'Delete - Cancel' sets 'Cancel' in a much better context. You are going to cancel a delete action not an 'Ok' action.

When it comes to OK/Cancel for a non-recoverable event (like delete), it's ALWAYS been the case that the dialogue should NOT appear in the first place. Instead, the UI should be seen to do the operation, but then delay its execution while showing an "undo" for a few seconds. The reason for this is that 99.9% of people know what they're doing. So don't bother them for the sake of the 0.1% who make a mistake. But more…

I've never come across that recommendation before. I can't immediately think of a case where I'd want that or it would be anything but annoying.

> 99.9% of people know what they're doing

You have very different users than those of anything I've ever written then. :)

Re: Ok-Cancel versus Cancel-Ok

#250

Post by morganvachon » Sat, Jun 09, 2018, 2:21 PM UTC

fnordsensei wrote: post #162

jaysonelliot wrote: post #19

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…

Great summary. Another thing to note in the Factorio mockups is the use of a guideline that I originally picked up from the macOS HIG[1]: use descriptive verbs rather than a generic confirmation. "Apply settings" vs "OK" "Load game" vs "OK" "Delete file" vs "OK" "Send email" vs "OK" "Print" vs "OK" and so on. [1]: https://developer.apple.com/design/human-interface-guideline...

Indeed. Factorio's use of the arrows to indicate a sense of direction ("back" points backwards on the timeline and "OK/Confirm/Play etc. point forwards, towards progress) makes it instantly clear what will happen after each button press.

I've always looked at interface choices like this: As a non-Chinese reader, if I see a dialog in Chinese and the "Yes/Confirm" and No/Back" buttons are the same size, shape, and color, I will have no clue which does what. However, if the "Yes" option is a darker shade, or has bolder text, or the button shape makes it scream "click me!", I'll feel relatively confident that this is the button I need to press to proceed with whatever I'm trying to do.