Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ok-Cancel versus Cancel-Ok

factorio.com

Post reply on HN
Print view View original

211–220 of 286 posts

Re: Ok-Cancel versus Cancel-Ok

#211

Post by mmphosis »

zaksoup wrote: post #2

> Make it so much different and Factorio specific, that the way it is done in your specific system will not interfere with your muscle memory I think this is a really thoughtful way to deal with the problem of x-platform UI that isn't using system chrome/dialogues. Don't get in the user's way, and let them develop muscle memory specific for the game.

Can you imagine a first person shooter game with dialog boxes popping up all the time? Shoot now? Shoot-Don't Shoot. Light switches with a dialog box? Light switch: on-off slider. Cancel-Reset-Apply Web sites that throw up overlays over the content to ask some inane question? oh, wait.

Re: Ok-Cancel versus Cancel-Ok

#212

Post by kchr »

zaksoup wrote: post #154
lamontcg wrote: post #150

You want to know bad design of a cancel button? The lyft app when you want to cancel a ride has a "cancel" button that cancels the ride instead of cancelling the cancel. Accidentally cancelled a ride one time in the middle of it when I fat fingered the first button and then stabbed at "cancel" thinking it meant "abort" and not "ok, continue"...

Genuinely curious, what's a better way of doing this particular flow: user taps "cancel" dialogue asks "Are you sure" and presents options: "cancel" and... "cancel"?? What should the options/dialogue be?

How about Yes/No (or No/Yes)?

Re: Ok-Cancel versus Cancel-Ok

#213

Post by duskwuff »

tootie wrote: post #137
scrollaway wrote: post #6

HN folks will appreciate the entire Factorio blog. They are super open about the design of their game and it's full of micro-postmortems. https://www.factorio.com/blog/ Also, if you're reading this, you are in a demographic that is likely to absolutely love Factorio. Go buy it, it's 20 eur/usd, you won't regret it. Some call it "Programming: The Game".

You could also call it the thinking person's Minecraft.

Factorio was heavily inspired by some of the "industrial" Minecraft mods (IndustrialCraft, BuildCraft, etc). IIRC, one of the first public prototypes of the game was posted on a Minecraft forum.

Re: Ok-Cancel versus Cancel-Ok

#214

Post by duskwuff »

towndrunk wrote: post #116

Does it bother anyone else when the "k" is not capitalized in "Ok" on a button?

Early versions of the Macintosh operating system used "Do It" as the default button text in dialogs, but changed that to "OK" when users reported confusion over why the computer was calling them a "dolt".

https://www.folklore.org/StoryView.py?story=Do_It.txt

Re: Ok-Cancel versus Cancel-Ok

#215

Post by ProxCoques »

pasta wrote: post #164
fnordsensei wrote: post #162

Earlier quoted context omitted.

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

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 importantly - for each dialogue (of whatever kind) you have in an application, the chances of the user reading it declines by the square of the number of dialogues they encounter in a given session to the point where they will never be read, ever.

Re: Ok-Cancel versus Cancel-Ok

#216

Post by noisem4ker »

arendtio wrote: post #204
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…

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?", not "No or yes?". Just a maybe different perspective from a Windows user.

Re: Ok-Cancel versus Cancel-Ok

#217

Post by qwerty456127 »

robbrown451 wrote: post #167

I vote for Ok on the left (even though I have used macs for years) because Ok is the "normal," typical action. "Cancel" is only done when you've basically made a mistake by opening the dialog box. Since we read from left to right, someone working quickly will only have to read the first one to do the action without breaking their flow. If you are hitting cancel, your flow was already broken when you opened the dialog…

I vote for Ok on the left because Cancel should be easiest to find without looking and thinking. When I decide I don't want to change anything this window is for I just click the lower-rightmost button unconsciously, faster than I can read it, e.g. the way you slap yourself when you feel like a mosquito might be there biting you. So, when the button there is not Cancel this can be destructive.

Re: Ok-Cancel versus Cancel-Ok

#218

Post by jdietrich »

udkyo wrote: post #180
psychometry wrote: post #4

Technically, they're both wrong. Button labels should be verbs. The Cancel - Open example from OS X is the right way to do a dialog box.

It's awkward sometimes. AWX: "Are you sure you want to cancel? Cancel/Proceed" e.g. Cancel cancelling / proceed to cancel. To me, that always seemed like a place where a simple "Yes/No" would be more appropriate.

Those verbs need nouns. Cancel what? Proceed with what? Most of the time, it's possible to make buttons self-explanatory if you give some thought to the choice architecture.

Re: Ok-Cancel versus Cancel-Ok

#219

Post by JohnStrangeII »

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…

There is a simpler reason. Apple introduced the GUI (licensed from Xerox) with the Okay button to the right. Microsoft Windows decided to go the other way for legal reasons and in order to look different.

Companies make these 'slightly different' approaches often and probably usually to avoid design patent issues.

Re: Ok-Cancel versus Cancel-Ok

#220

Post by badsectoracula »

abrowne wrote: post #118
Stratoscope wrote: post #93

Earlier quoted context omitted.

This is one of those things where there is no wrong or right answer. We are just trying against all odds to find something that will help users feel comfortable and make the right choice. My philosophy used to be to follow the native platform convention, so on Mac it's Cancel-OK, on Windows or Linux it's OK-Cancel. Seems simple, do what people are used to. But what about a web app that someone uses on Mac at work and…

> Linux it's OK-Cancel. KDE yes, but GNOME and most GTK+ desktops and apps are definitely Cancel/OK. Google used to be pretty mixed, but Android and the Material re-designed stuffs seems to be pretty much Cancel/OK too.

As i show in another reply below, it is only GNOME/GTK that does Cancel/OK, while every other environment and toolkit does OK/Cancel - this includes KDE, Tk, Motif, FLTK and even some classic X11 apps like `bitmap` use OK/Cancel. This is also the case with console-based UIs, like dialog, picotui and free vision which all use OK/Cancel. So GNOME/GTK is really the odd one out going against what everyone else is doing. It is also interesting to note that this was changed in GTK2 days since GTK1 does also use OK/Cancel: http://pike.lysator.liu.se/generated/manual/images/predef.GT...
Post reply on HN