To the front pageThe Interaction Designer's Coffee Break - Weekly postings and quarterly articles about interaction design  
  To the front pageSign inTo the frontpageSearch in GUUUI postingsAbout GUUUI  

OK button first or Cancel first?

Should the OK button come before or after the Cancel button? According to Jakob Nielsen, this is one of the questions that people can argue about for hours but really doesn\'t matter much.

But if you really want an objective decision criterion, follow the platform conventions. If you users are primarily Windows users, put Cancel last. If your users are primarily Mac users, put Cancel first.

If Windows users equals Mac users, flip a coin.


  • OK–Cancel or Cancel–OK? Open link in new window

Henrik Olsen - June 01, 2008

See also: Forms (30) 



how about removing the cancel button completely?

Martin Polley | May 29, 2008


I would say that the last button (bottomed right) should always be the one executing the main feature of what you are doing. So, since you never enter a functional form field to cancel, the cancel-button should come first.

What you are saying about Win-/Mac-users is really interesting, but I wish I could follow my own thoughts regardless of the users platforms/habits. I have a strong belief that one thing is the better solution, objectively. Very often there is a correct answer. Isn't it?

John Eivind Hallen | May 29, 2008


And if you are using GNOME on Linux, Unix, or Solaris, you will put the action/OK button in the lower rightmost area of the dialog, and the cancel to the left of it. Although it's preferred to use a more descriptive verb than the word "OK" whenever possible:

KDE, of course, is the opposite of this and cancel always appears further to the right than the action button(s).

M | May 29, 2008


Surely what matters more is that the tab order is correct so that keyboard users can hit enter once they've completed necessary fields. I was recently auditing a website and in a search facility I entered a name hit return and the form cleared. I found it annoying that I had to use my mouse or tab onto the submit button.

Darren Taylor | May 30, 2008


The wxWidgets cross-platform GUI toolkit provides a component called wxStdDialogButtonSizer which automatically handles placement of standard dialog buttons like OK, Cancel, Yes, No, Apply, Save, and Help in the location recommended by the platform's user interface guidelines.

I personally believe that staying consistent with the given platform is what should be done.

Bryan Petty | May 30, 2008


As Jakob said in his article, "it's best to follow the platform GUI standard". For desktop applications, you've got to know which platform you're running on, so it's easy to put the buttons where the users expect them. That's the only definition of "right" that makes sense.

For web applications, ask yourself why you're showing a dialog box in the first place. Why not just use forward and back links? If you *must* use a popup dialog, check the OS the user's running on and put the buttons where the users expect them.

It really *does* matter if you annoy your users. Finally, as Alan Cooper keeps reminding us, the best way to implement a dialog box is to design the application so you don't need to bug the user with a dialog in the first place.

Eric Hartwell | May 31, 2008


This is a very interesting topic. I have a question for everyone. Why even have a cancel button on a form? Depending on your demographic, aren\'t most people savvy enough to know that if you don\'t want to submit a form, visit a different page on the site or close out the browser.

I\'m not saying that I support not having a cancel button but I would like to hear other people\'s thoughts.

Grant Novey | June 13, 2008


I would detect the OS and make the default the same as the platform default.

Michael McNicholas | June 22, 2008



Ad for TechSmith Morae

Browse GUUUI postings

Methods and the design process

Prototyping and wireframing (119)  Usability testing (68)  Cost-justification and ROI (27)  User research (23)  Personas (19)  The design process (24)  Eye-tracking (14)  Card sorting (13)  Web traffic analysis (12)  Expert reviews (11)  Implementing user-centred design (9)  Site and flow diagramming (6)  Envisionments (4)  Use Cases (3) 

Design elements

Navigation (63)  Web page design (40)  Search (27)  Text (24)  Forms (30)  Links (19)  Guidelines and Standards (15)  Site design (14)  Ads (9)  Design patterns (8)  Sections (8)  Shopping Carts (9)  Error handling (7)  Home pages (9)  Help (3)  E-mails (3)  Sitemaps (2)  Personalization (1)  Print-friendly (1)  Landing pages (5) 

General aspects

E-commerce (27)  Persuasive design (21)  Visual design (19)  Information architecture (15)  Accessibility (13)  Search engines (7)  Credibility, Trust and Privacy (6)  Emotional design (10)  Simplicity vs. capability (7)  Web applications (6)  Intranets (3) 


Flash (6)  Download time (5)  Javascript (3)  URLs (3)  Browsers (3)  Web standards (2) 


Bad designs (20)  Cartoons (14)  Fun music and videos (13)  Funny tools and games (12)  Misc humor (8)  Fun with Jakob Nielsen (9)  Designs with humor (3)  Fun posters (5)  Funny 404 pages (2) 

Resource types

Research (129)  Tips and guidelines (95)  Tools (106)  Books (47)  Audio and video (48)  Interviews (30)  Cases and Examples (28)  Talks and presentations (18)  GUUUI articles (11)  Primers (14)  Online books (5)  Posters (5)  Glossaries (3)  People and organisations (3) 

Information sources

Blogs (12)  Websites (11)  Discussion lists (4)  News (3)  Newsletters (3)  Online magazines (3)  Wikis (1) 

  To the front pageSign inTo the frontpageSearch in GUUUI postingsAbout GUUUI