Does it bother anyone else when the "k" is not capitalized in "Ok" on a button?
The cache size is currently 0k. Increase the cache size?
Ok-0k
Ok-Cancel versus Cancel-Ok
201–210 of 286 posts
Re: Ok-Cancel versus Cancel-Ok
#202Re: Ok-Cancel versus Cancel-Ok
#203Earlier quoted context omitted.
Toy cars in shops have the cars and trucks all facing right in the packaging. Maybe they've done some ab-testing to get this way. Maybe not. Maybe putting his airplanes facing left made your veteran's models pop because they were inconsistent with other models. Anyway, if you want to make people read the options on buttons, randomize the order each time the popup appears but always destructive buttons like "delete" r…
Please don't randomise the location of UI components. I don't want to have to find the button I want. Your users will thank you.
Agreed, but I would still do it on a small traffic/user to see its impact. This kind of data is invaluable.
Re: Ok-Cancel versus Cancel-Ok
#204This 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 bottom right corner, as that corner is one of the places we start looking for the button. With the OK-Cancel order, the OK-button would be hidden behind the Cancel-button.
Nevertheless, this factor doesn't change anything about your conclusion. I think your argument is very balanced and I agree with your conclusion about consistency being the most important factor.
Re: Ok-Cancel versus Cancel-Ok
#205Earlier quoted context omitted.
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.
I agree, but what's the use-case for such a dialog in the first place?
If there is a cancel button for a long running expensive operation it sounds like a good idea to confirm the cancellation.
Or if you are half way through paying for your cart, the merchant should check you really meant to press cancel.
Re: Ok-Cancel versus Cancel-Ok
#206Earlier quoted context omitted.
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.
Proceed seems to be the wrong verb here, as that dialog looks like it appeared after clicking a cancel button, and if I don't want to cancel I "return" to the previous screen where my data still is and don't "proceed" to somewhere.
That's what cancel does - you click proceed when you want to cancel. If cancelling isn't what you want, you simply click the button labelled "Cancel"
Clear as mud, right?
Re: Ok-Cancel versus Cancel-Ok
#207Technically, 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.
>Button labels should be verbs. According to who? Why? I've never heard this before and it doesn't sound like a remotely necessary rule.
Because verbs are actionable.
Re: Ok-Cancel versus Cancel-Ok
#208Earlier quoted context omitted.
Proceed seems to be the wrong verb here, as that dialog looks like it appeared after clicking a cancel button, and if I don't want to cancel I "return" to the previous screen where my data still is and don't "proceed" to somewhere.
That's what cancel does - you click proceed when you want to cancel. If cancelling isn't what you want, you simply click the button labelled "Cancel" Clear as mud, right?
Well years ago at a convention I came across a little company that made Key caps out of Tempe, Arizona.
I bought a couple of bags of just two keys. Red panic buttons "Panic", and, "Any" keys.
We replaced the escape key cap with those when we sold new systems.
The "Any" key was a big hit and quite popular with the n00bs back in those AT (286) days.
I think I may still have a few of those around lolz.
Re: Ok-Cancel versus Cancel-Ok
#209There was a widely used program on Windows back in the 95 days that on the nag dialog asking free users to get the paid version would random switch between the two orders. The idea was to keep people from unconsciously clicking through that dialog. I think this was WinZip, but am not certain.
It's an effective dark pattern. Many websites practice similar trickery.
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)
Re: Ok-Cancel versus Cancel-Ok
#210All 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?
I feel like you're on to something here!