Skip to content

The great OK/Cancel button dilemma

Today I created a simple web form. So simple indeed that it has only three design elements:

Turquoise Ceramic Buttons
Image by panavatar via Flickr
  • input field
  • OK button, in this case labeled “Save”
  • Cancel button

Since I’m always confused about the order of OK  – Cancel buttons (you, should it be OK / Cancel or Cancel / OK), I checked a few dialogs around my OS X and they all read Cancel / OK.

I personally prefer the second option, as I usually like to confirm my dialog boxes and it’s much easier to hit OK in down right corner vs. finding the item next to it.

Second choice it’s probably that I’m brainwashed from seeing this choice all the time on my Mac.

After showing my choices to the person in charge, I got the obvious feedback: “Reverse the Cancel / OK button”.

Fine! (I change the button order and go looking in various HIG documents).

Here are results:

Apple’s HIG states:

Always put the action button in the bottom-right corner of the alert. This is the button that completes the action that the user initiated before the alert was displayed. [ed. note: this would make it Cancel / OK]

GNOME’s HIG states:

Show a Cancel button that will prevent authentication and close the alert. Place this button to the immediate left of the OK or equivalent button. [ed. note: this would make it Cancel / OK]

Place command buttons that apply to all property pages at the bottom of the property window. Right-align the buttons and use this order (from left to right): OK, Cancel, and Apply. [ed. note: this makes it OK / Cancel]
KDE’s HIG doesn’t state anything (or at least I couldn’t find it), but it seems that it standardizes on OK / Cancel.
So here we have two camps. The OK / Cancel one is clearly bigger because of the whole Windows platform using this convention. I’ll leave out different argumentations out of this document, as it’s kind of a holy war between certain UX factions.
Interesting thing with this issue is that it doesn’t matter, as long as you standardize. Nobody managed to measure any difference as long as it was the same across the whole environment.
But what to do in case of Web applications, where you can’t standardize the whole Internet? Jakob Nielsen thinks that you should go with the option that is natural to more of your users.
At the end of the day, this translates to use OK / Cancel as majority of your users will probably be on Windows or KDE, unless you’re running some kind of OS specific niche site. Even then you should only switch if you’re working for OS X crowd as you can’t really know Window Manager usage distribution of your users.
What about you? Do you OK / Cancel or Cancel / OK things? Or are you just constantly twitching because that OK never feels right?
Reblog this post [with Zemanta]

— ideas, usability

10 responses to “The great OK/Cancel button dilemma”

  3. Just make the cancel button secondary – either make it text instead of the button, or colour it so the Save button will stand out. Having two equally “powerful” buttons that do opposite things is wrong no matter what their order in a form is – it makes you think.

  4. Same dilemma here. At web forms i tend to avoid “cancel” and other destructive commands in general, because there is always some other way for user to escape. If “Cancel” or “Reset” is unavoidable, then i use a secondary button or a command link.

  5. As speaking from the aspect of graphic design, the upper right -> lower left diagonal is the natural perception of the visual space. This is probably the cause of Apple's HIG statement to put the action button there, because it is visually the logic way of the “end of visual form”. So the question probably is more: are the UI windows supposed to make you approve or disapprove the meaning they are communicating. Usually, this is also done by highlighting one choice, as fry said in the previous post.

  6. I'm clearly in the Cancel / OK crowd (Gnome-centric). Hitting lower-right to continue seems to me as the natural way to go forward in a process.

    On the web I tend to place the continue/OK button in the lower-right, and the go-back/Cancel button in the lower-left. I think this better matches how the web works, as all browsers have go-back/go-forward buttons in the same order.

    As an additional bonus, with both buttons far apart users can't accidentally hit the cancel-button and if you have any additional buttons (apply, clear) that don't move the user off the current page you can stick them in the center.

    On showing the way that is most natural to users, you could parse the useragent to figure out how to order the buttons 🙂

    (as a side-note, I'm really annoyed by web apps that place the Save/OK button _above_ the form that you're working on. Zimbra and a couple of other email apps suffer from this. Joomla makes it even worse by placing the Save button above the form, right-aligned with other buttons to the right of it. Madness).

  7. Hi, first of all – interesting article!

    we prefer to use OK/Cancel order, but create hierarchy at the same time by letting only “OK” to appear as a button, and “Cancel” as an ordinary link.

    Despite what conventions say, I personally think the main action should be first available to choose from, and for left-to-right languages this would put OK to the left side.

    Cheers!

  8. I had exactly the same dilemma yesterday. Apart from making visually OK button primary and Cancel secondary, I guess it all comes down to what your users prefer. For users more familiar with Windows it's OK/Cancel, for Mac-s it's Cancel/OK. Look at you analytics data and probably swallow you Mac pride 🙂 Or go bold 🙂

  10. In KDE 3 the default was OK/Cancel but it was possible to change it for Cancel/OK by editing a resource. I prefer the last one. Don’t know how to make the same change with KDE 4.

Comments are closed.