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.
Not really, Ok can be a verb. You can “Ok” a change.
Ok-Cancel versus Cancel-Ok
21–30 of 286 posts
Re: Ok-Cancel versus Cancel-Ok
#22Re: Ok-Cancel versus Cancel-Ok
#23Technically, 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.
Re: Ok-Cancel versus Cancel-Ok
#24HN 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".
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.)
Re: Ok-Cancel versus Cancel-Ok
#25HN 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.
Re: Ok-Cancel versus Cancel-Ok
#26Windows managed to do this as backwardly as possible (no pun intended). Switching their button order vs. the Mac might not have mattered if Windows put the first button in the bottom left corner for predictability. Instead, they right-justified an entire group of left-ordered buttons so you have no way of knowing if the corner button will be the main action. Then they tended to use nondescript button titles, made worse by APIs that make it easier to pop up yes/no questions than Action1/Action2 (i.e. custom titles) so apps lazily trend toward nondescript. And then the OS had relatively tiny fonts without formatting that made it hard to understand at a glance what a message is even asking, requiring careful reading to proceed.
A good UI is not a very simple thing, there are lots of details to be considered.
Re: Ok-Cancel versus Cancel-Ok
#27Technically, 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.
Not really, Ok can be a verb. You can “Ok” a change.
But it's better to mirror the action verb for your confirmation button, because users don't necessarily read the text you present them with. So, instead of this:
Delete xyz.jpg?
--------------------------
The file 'xyz.jpg' will be
permanently deleted.
--------------------------
[ OK ] [ Cancel ]
You have: Delete xyz.jpg?
--------------------------
The file 'xyz.jpg' will be
permanently deleted.
--------------------------
[ Delete ] [ Cancel ]
And you get one more chance for the user to see what action they're about to perform.There's very good, detailed guidance on this in the Windows design guidelines (the design-specific aspects are a bit dated since everything there refers to Vista/7-era UI elements, but their guidance on text and dialog styles is still applicable):
Text: https://msdn.microsoft.com/en-us/library/windows/desktop/dn7...
Dialog Boxes: https://msdn.microsoft.com/en-us/library/windows/desktop/dn7...
Re: Ok-Cancel versus Cancel-Ok
#28HN 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".
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.)
Re: Ok-Cancel versus Cancel-Ok
#29This 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 this is the right answer. Personally and anecdotally, I doubt it makes a noticeable difference which way they are, as long as they are that way everywhere. I will soon learn that "confirm/apply/proceed" is one way, and "back/cancel/revert" is the other way, whichever way those tend to be. Just make sure you don't flip on me.
Re: Ok-Cancel versus Cancel-Ok
#30Some of the reasons behind the suggestions (which are clearer when you view the associated pictures in the pdf):
"The Western reader’s eye tends to move from the upper-left corner of the dialog box to the lower right. Put the initial impression that you want to convey in the upper-left area (like the alert icon), and place the buttons that a user clicks in the lower right. Following this guideline makes it easier for users to identify what’s important in a dialog box."
"The button names in the save changes alert box correlate to the action users perform by pressing the button. The buttons read Save, Don’t Save, and Cancel. Using these verbs reinforces the identity of each possible action to the user. In other words, the Don’t Save label provides much more context for the user than the word No does."
"In order to prevent accidental clicks of the wrong button, you should always keep safe buttons apart from buttons that could cause data loss. Standardizing the location of buttons in a safe configuration provides an additional safeguard for the user. Place the Save button in the lower-right corner with the Cancel button to its left. Place the Don’t Save button left-aligned with the message text. Make the Save button the default button, which means that it should be linked to the Return or Enter key. This way, the user is less likely to accidentally click the Don’t Save button or activate it with a keystroke and cause irretrievable loss of data."
"Whenever possible, name a button with a verb that describes the action that it performs. Button names should be limited to one word whenever possible. You should never use more than three words for a button name."
One good justification for the Cancel->OK order is that it means the default button (usually the OK button, but also Save, Print etc) is always in the same position in the dialog -- far bottom right -- regardless of how many other buttons there are, and how wide they are. This gives consistency / familiarity / muscle memory.
It also lets you place "data loss" buttons well away, in the far bottom left, as "an additional safeguard for the user". On classic Mac OS, you always knew pressing a button towards the lower left corner, and set away from the other buttons, could spell trouble.
The problem with the Windows way of doing things is that the default button moves depending on the width and number of other buttons, and there is no "safe button place" and "unsafe button place".