Ok-Cancel versus Cancel-Ok • Hacker News Board

Re: Ok-Cancel versus Cancel-Ok

#121

Post by briandear » Sat, Jun 09, 2018, 2:27 AM UTC

kevin_thibedeau wrote: post #84

RussianCow wrote: post #36

Earlier quoted context omitted.

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

Better yet, follow the Apple dialog guidelines for labeling buttons and eschew the ambiguity of "OK".

Those Human Interface Guidelines are incredible. There is also an Apple Style Guide that’s very awesome as well. For example, “don’t use ‘please’ as in “Please click yes to continue.” Instead, simply “click yes to continue.” I forget the rationale but it was pretty sound reasoning if I remember correctly.

Re: Ok-Cancel versus Cancel-Ok

#122

Post by ggg9990 » Sat, Jun 09, 2018, 2:28 AM UTC

hoosieree wrote: post #112

All of these are wrong, because they're answering the wrong question. Stop second-guessing the user! Get rid of all these buttons, but provide a mechanism to UNDO the change. Linear undo plus the option to reinstate "factory default" settings is probably optimal for most applications. Would you tolerate a text editor that asked you to confirm each letter you typed?

Undo support can 5x the cost of a feature and in some cases is impossible (instructing some other entity to perform an action). It’s not feasible in all scenarios.

Re: Ok-Cancel versus Cancel-Ok

#123

Post by [deleted] » Sat, Jun 09, 2018, 2:28 AM UTC

smichel17 wrote: post #10

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

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

[deleted]

Re: Ok-Cancel versus Cancel-Ok

#124

Post by amelius » Sat, Jun 09, 2018, 2:28 AM UTC

pmiller2 wrote: post #114

hoosieree wrote: post #112

All of these are wrong, because they're answering the wrong question. Stop second-guessing the user! Get rid of all these buttons, but provide a mechanism to UNDO the change. Linear undo plus the option to reinstate "factory default" settings is probably optimal for most applications. Would you tolerate a text editor that asked you to confirm each letter you typed?

Some actions aren’t undoable.

"Launch missiles" is the prototypical example, although in reality I hope there is some sort of undo functionality.

Re: Ok-Cancel versus Cancel-Ok

#125

Post by dnaf » Sat, Jun 09, 2018, 2:29 AM UTC

hoosieree wrote: post #112

All of these are wrong, because they're answering the wrong question. Stop second-guessing the user! Get rid of all these buttons, but provide a mechanism to UNDO the change. Linear undo plus the option to reinstate "factory default" settings is probably optimal for most applications. Would you tolerate a text editor that asked you to confirm each letter you typed?

a mechanism to undo the change. hmmmm. a button that takes you back. some sort of... back button?

Re: Ok-Cancel versus Cancel-Ok

#126

Post by lewisinc » Sat, Jun 09, 2018, 2:31 AM UTC

ggg9990 wrote: post #122

hoosieree wrote: post #112

All of these are wrong, because they're answering the wrong question. Stop second-guessing the user! Get rid of all these buttons, but provide a mechanism to UNDO the change. Linear undo plus the option to reinstate "factory default" settings is probably optimal for most applications. Would you tolerate a text editor that asked you to confirm each letter you typed?

Undo support can 5x the cost of a feature and in some cases is impossible (instructing some other entity to perform an action). It’s not feasible in all scenarios.

It depends how you architect. Generally yes. Check out the Elm architecture (and Redux by extension) to see situations where undo is essentially free.

Re: Ok-Cancel versus Cancel-Ok

#127

Post by dpark » Sat, Jun 09, 2018, 2:36 AM UTC

briandear wrote: post #121

kevin_thibedeau wrote: post #84

Earlier quoted context omitted.

Better yet, follow the Apple dialog guidelines for labeling buttons and eschew the ambiguity of "OK".

Those Human Interface Guidelines are incredible. There is also an Apple Style Guide that’s very awesome as well. For example, “don’t use ‘please’ as in “Please click yes to continue.” Instead, simply “click yes to continue.” I forget the rationale but it was pretty sound reasoning if I remember correctly.

Rationale is probably primarily that it’s just less wordy and secondarily that it sounds like an option instead of a request.

Re: Ok-Cancel versus Cancel-Ok

#128

Post by jacobolus » Sat, Jun 09, 2018, 2:37 AM UTC

userbinator wrote: post #97

jacobolus wrote: post #78

Earlier quoted context omitted.

Please force the reader to directly click an action verb. It is much easier to skip over text (even text that comes immediately before) misinterpret the dialog, and click the wrong button when using generic button labels "yes" and "no". And more generally, before disregarding industry best practices and findings from research literature and implementing something based on ad-hoc personal hunches, make sure you run so…

industry best practices and findings from research literature That's the cop-out answer I get whenever I ask about unnecessary and infuriating UI changes. It has only given rise to increasingly dumbed-down, stupifying interfaces.

Huh? It is a “cop out answer” to suggest reading the research literature as a general practice? It is an “unnecessary and infuriating UI change” to roughly follow UI guidelines written down by experts with decades of experience?

I am recommending that instead of just making something up based on the developer’s speculation and personal preference (which in your particular example happens to be terrible, as you would discover if you actually tested it in a real-world setting), it is a better idea as a general rule to go read actual user studies about what works and why, or if you are too lazy to do that go find some interface guidelines written by someone who did large-scale user studies and spent decades honing their interfaces in response to user feedback and copy it.

If you insist on rejecting those findings and past experience with a novel implementation, then I am recommending running your own mini studies (ideally something semi-formal, but at least test the two versions on a couple buddies at a coffee shop), to make sure you don’t shoot your foot off. To do anything less is in my opinion lazy and irresponsible.

Why do you think that will lead to “stupefying interfaces”?

You think that doing at least a tiny bit of user research before blindly rushing ahead based on personal preferences renders people unable to think or feel?

Or maybe you have a non-standard definition of “stupefy”? To be honest I don’t understand what you are trying to say.

Re: Ok-Cancel versus Cancel-Ok

#129

Post by jeremiep » Sat, Jun 09, 2018, 2:37 AM UTC

lewisinc wrote: post #126

ggg9990 wrote: post #122

Earlier quoted context omitted.

Undo support can 5x the cost of a feature and in some cases is impossible (instructing some other entity to perform an action). It’s not feasible in all scenarios.

It depends how you architect. Generally yes. Check out the Elm architecture (and Redux by extension) to see situations where undo is essentially free.

Anything where your app state is modelled as a series of actions over immutable data, undo and replay will be essentially free to implement :)

Re: Ok-Cancel versus Cancel-Ok

#130

Post by freddie_mercury » Sat, Jun 09, 2018, 2:38 AM UTC

lewisinc wrote: post #126

ggg9990 wrote: post #122

Earlier quoted context omitted.

Undo support can 5x the cost of a feature and in some cases is impossible (instructing some other entity to perform an action). It’s not feasible in all scenarios.

It depends how you architect. Generally yes. Check out the Elm architecture (and Redux by extension) to see situations where undo is essentially free.

How does Elm undo a charge to my credit card if I change my mind 2 minutes later? How does Elm un-print a document if I decide I didn't want to print it after all? How does Elm un-send the email telling a person they were fired if I decide I misspelled the recipient name? How does Elm help the Linux kernel undo a write operation to write-once media? How does Elm help a payroll system undo ACH transfers to thousands of employees?

I feel like you mostly missed the OP's point.