Jure Cuhalev

08 Mar, 2009

The great OK/Cancel button dilemma

Posted by: Jure Cuhalev In: ideas| usability

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]

Related posts:

  1. Usability Reflections: Provide a way to resolve and indicate failure
  2. Usability reflections: Power of consistency (ted.com)
  3. iTunes 8 UX genius login problem
  4. Usability reflections: information overflow (vcrd.net)
  5. Vertical markets of a shaving cream
Tags: , , , ,

10 Responses to "The great OK/Cancel button dilemma"

1 | Anze

March 8th, 2009 at 12:55 am

Avatar

I'm the “OK / Cancel” kinda guy. :)

2 | Chris Charabaruk

March 8th, 2009 at 1:24 am

Avatar

Yeah, same here. Then again, I've been using Windows since 3.0, so I'm just used to Microsoft's HIG.

3 | fry

March 8th, 2009 at 11:35 am

Avatar

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 | Miha Ceglar

March 9th, 2009 at 10:53 am

Avatar

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

March 10th, 2009 at 11:12 am

Avatar

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

March 11th, 2009 at 9:40 am

Avatar

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

March 11th, 2009 at 10:14 pm

Avatar

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

March 24th, 2009 at 11:06 am

Avatar

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

9 | Mugunth Kumar

September 23rd, 2009 at 6:44 am

Avatar

My two cents…
http://blog.mugunthkumar.com/tech/elements-of-usability-design-okcancel-vs-cancelok-is-it-just-a-matter-of-taste/

10 | Pierre Thibault

October 22nd, 2009 at 4:06 pm

Avatar

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.

Search


  • gost: You could also try the follow one "Cultivating Communities of Practice" (http://www.bookdepository.co.uk/book/9781578513307/Cultivating-Communities-of
  • Orsa: Huh Nice! Laws of simplicity my mantra!!
  • Jure Cuhalev: If I can make a career analyzing punk subculture or disco drug eating scene .. why not the interwebs :)

Flickr PhotoStream

    Workspacebooks I am readingQWIKI TODO

About

jure100px_colour Jure Cuhalev is an Open Source Hacker, with background in Social Sciences and Usability and User Experience (UX).







Copyright © 2007 Jure Cuhalev is proudly powered by WordPress

Fervens - C Theme is created by: Design Disease brought to you by Smashing Magazine