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

271–280 of 286 posts

Re: Ok-Cancel versus Cancel-Ok

#271

Post by BrandoElFollito »

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 had exactly the same thought as you, I actually imagined myself clicking the button and thought it is less movement for the mouse.

Re: Ok-Cancel versus Cancel-Ok

#272

Post by ProxCoques »

oldcynic wrote: post #249
ProxCoques wrote: post #215

Earlier quoted context omitted.

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

https://www.nngroup.com/articles/ten-usability-heuristics/

https://asktog.com/atc/principles-of-interaction-design/

Re: Ok-Cancel versus Cancel-Ok

#273

Post by cyberferret »

nicoburns wrote: post #227
cyberferret wrote: post #115

Earlier quoted context omitted.

Back when I used to build model aircraft dioramas, a veteran told me "When you arrange vehicles in a diorama setting, always have them facing towards the left side of the board for maximum impact.". His reasoning was that most people's eyes move left to right when examining something - which mimics their eye movement when reading text (at least in Western societies. In R-L countries I guess the opposite would be true…

> important items towards the right of a page, with lesser items further right I think one of these may have been meant to say left!

Ah yes, whoops - thanks for picking up the typo!

Re: Ok-Cancel versus Cancel-Ok

#274

Post by daveheq »

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…

This implies, as I agree with, that a single-action pop-up or form (which does not progress) should have OK-Cancel, and that a progressive form should be Cancel-OK, as clicking OK progresses things to the "right" (or next "page"), whereas Cancel stops that progression.

Re: Ok-Cancel versus Cancel-Ok

#275

Post by badsectoracula »

abrowne wrote: post #253
badsectoracula wrote: post #220

Earlier quoted context omitted.

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

I'm not disagreeing, but on the Ubuntu MATE computer I'm using now, for graphical apps at least, I have only have apps using GTK+ — including partial users like Firefox —, Qt and wxWidgets (plus mpv, which doesn't seem to have any dialogs anyway). Qt and wxWidgets adapt to GTK+ conventions when used with GTK, or use parts of GTK+, like open/save dialogs, so everything, or nearly so, that I use is Cancel/OK. I think G…

AFAIK in Qt you can "tag" the OK/Cancel buttons and the theme can provide a hint to swap them around, however the default seems to be OK/Cancel and KDE uses that going back to KDE1. I've also heard (but not confirmed since i do not have it) that if you use GNOME and run a Qt app, Qt will automatically swap the buttons - if that is the case then it might also do it with other common GTK+-based DEs.

About the vertical orientation, actually i've noticed that not only in Blender but in other programs and toolkits too. In the latter toolkits, it most likely comes from Win9x/2K/XP which used this vertical layout (i think Vista rearranged the buttons to be horizontal).

Re: Ok-Cancel versus Cancel-Ok

#276

Post by Sylos »

oldcynic wrote: post #261
Sylos wrote: post #260

Earlier quoted context omitted.

I think, Google recommends this for Android application development. Not that I would consider Google a shining beacon of great UIs. Well, and it is also much easier to quickly locate and hit an Undo-button on a small touch screen than it is with a mouse on a giant screen.

Interesting. I dropped Android a year or so back but can't remember bumping into an app doing it like that. Definitely encountered a few "are you sure?" style dialogues though.

The UI element typically used for this is the "Snackbar", so if you search for "Android Snackbar", you should find some examples.

But yeah, I definitely also see a lot more confirm-dialogs still.

Seems to be a classic case of such a UI pattern being great and hyper modern and marketable in 99% of cases. But if in 1% of cases, the user accidentally deletes a file that they didn't want to delete, then you lose that user in that exact moment.

That is, if you are not a preinstalled app. If instead you are Google, then users are generally not aware of alternatives and cannot switch away from your app, if this happens to them. They just live with your UI eating their files.

Not to mention that it was quite clearly their fault for not finding the Undo-button quick enough. Which is also generally an opinion that users manage to hold, who have not yet progressed to looking at alternatives of programs and comparing different UIs for their merits.

Re: Ok-Cancel versus Cancel-Ok

#277

Post by zaksoup »

DoreenMichele wrote: post #148
zaksoup wrote: post #146

Earlier quoted context omitted.

I thought the HM guidelines required titles be as true to the article as possible. I’ll keep your feedback in mind next time I submit a link! Thanks.

You are supposed to use the original title. You aren't supposed to editorialize. There are some exceptions to the rule of using the original title. They are listed in the guidelines: https://news.ycombinator.com/newsguidelines.html

That's that I thought! Thanks for the comment.

Re: Ok-Cancel versus Cancel-Ok

#278

Post by ProxCoques »

erichurkman wrote: post #245
ProxCoques wrote: post #215

Earlier quoted context omitted.

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

That's not what the HCI research and general literature on this says.

https://en.wikipedia.org/wiki/Mode_(computer_interface)#Asse...

The issue is that novice, elderly, power or otherwise, if you have dialogues popping up all the time asking you if you're sure, and 99% of the time you ARE sure, then pretty soon you will habituate to just hitting OK whatever until the one time you DON'T mean OK, at which point you have an undo.

This isn't controversial, or just my opinion, it's observed, researched HCI stuff (mainly in the context of aircraft cockpit design but also on desktop software and the web).

Re: Ok-Cancel versus Cancel-Ok

#279

Post by ProxCoques »

jeremyjh wrote: post #240
ProxCoques wrote: post #215

Earlier quoted context omitted.

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 think this depends on the actual semantics of the delete. If the operation is truly non-recoverable, and you simply lie about doing it and do it after a delay, there is a chance you will be caught in that lie when your process is cancelled or failed for whatever reason. That is a worse user experience by far - you should never tell someone something has been done unless you are sure it has been done permanently.

That may be your opinion. But 30 years of HCI research and recommendations on the subject say otherwise:

https://en.wikipedia.org/wiki/Mode_(computer_interface)#Asse...

https://www.nngroup.com/articles/ten-usability-heuristics/

https://asktog.com/atc/principles-of-interaction-design/

Re: Ok-Cancel versus Cancel-Ok

#280

Post by oldcynic »

ProxCoques wrote: post #272
oldcynic wrote: post #249

Earlier quoted context omitted.

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

https://www.nngroup.com/articles/ten-usability-heuristics/ https://asktog.com/atc/principles-of-interaction-design/

That's something entirely different, and very well known. I can't find any reference to providing a delay before you truly perform an action, but allowing undo for that time.

Relevant to delete / undo they talk of the preference for an undo (eg ^Z at any time) to "Are you sure?". No mention of delaying action or availability of undo. Then preference for consistency of action - within app and generally, not deviating from common expectations (eg that a trash can allows restore), and recommendations for visual feedback when latency and delay is involved. None of which fits the original temporary delay/undo.

Post reply on HN