OK/Cancel on left/right?
Should OK button be on left of Cancel button or vice versa?
Are there any studies suggesting either of the solutions?
It's not a duplicate; your question was about alignment, this is about positioning (close, but still different!)
Just to add to the conversation, Luke Wroblewski also wrote an article called "Primary & Secondary Actions in Web Forms" where he shares the results of some eye tracking research.
As with everything: user test! Thankfully, usability hero Jakob Nielsen jumps to the rescue here in his Alertbox article about OK/Cancel buttons:
Should the OK button come before or after the Cancel button? Following platform conventions is more important than suboptimizing an individual dialog box.
Kostya was right on the mark in advising adherence to platform guidelines. But what about web-based platforms?
If you're designing a Web-based application, the decision is harder, but you should probably go with the platform preferred by most of your users. Your server logs will show you the percentage of Windows vs. Mac users for your specific website or intranet. Of course, Windows generally has many more users, so if you can't be bothered to check the logs, then the guideline that will apply to most situations is OK first, Cancel last.
He also mentions two additional important guidelines you might consider when creating OK/Cancel buttons:
- It's often better to name a button to explain what it does than to use a generic label (like "OK"). An explicit label serves as "just-in-time help," giving users more confidence in selecting the correct action.
- Make the most commonly selected button the default and highlight it (except if its action is particularly dangerous; in those cases, you want users to explicitly select the button rather than accidentally activating it by hitting Enter).
Luke Wroblewski also wrote a more in-depth article called "Primary and Secondary Actions in Web Forms" (http://www.lukew.com/resources/articles/psactions.asp) that includes the results of eye-tracking studies.
No offense Rahul, but I can't believe that this answer got that many upvotes. First of all it's not a matter of user tests but about AB testing if anything (which is not the same) Second of all The advice about looking at the server log to see whether you will most likely have mac or windows users is straight out bad advice.
@ThomPete Um, okay. If you're going to argue with Jakob Nielsen, can you provide some reasons other than "it's straight out bad advice"? It sounds like it makes a lot of sense to me: look at the data and make decisions from there instead of guessing. Yes, AB testing would work here too - but so would user testing, and IMO you learn a lot more from user testing than from AB testing, so I recommend that first. Finally, the reason this got a lot of upvotes is because Joel Spolsky tweeted it at some point and that probably blew things out of proportion a bit.
User testing wont tell you anything about where and how to position your buttons. What basis would that be to validate that one? You are setting them up in a pseudo environment not the real environment. In a real environment there are so many other factors that will affect what makes most sense to them. Such as are they interested in the product/service, does the form ask them too many questions, too few questions and so on. This won't be possible to test. User testing is claimed to be the answer to everything. It's not and especially not in this case.
With regards to the bad advice. It's bad because on the web people are not mac or windows users. They are browser users.
User testing variations of the design will tell you a lot, for instance whether you're dealing with users with a Mac background and therefore certain expectations on location of Cancel vs OK. Just because people are using the web platform doesn't mean they don't bring along expectations set by the software platform they're using, so Jakob's advice is good because it reminds you to think about that when designing for the web. It's not mutually exclusive - you can take platform into account while at the same time being aware of the fact that you're designing for the web.
You are confusing things here. Usability testing wont show you anything about where to put the buttons. It will only tell you what users think within the confines of the pseudo environment. But that has no bearing on whether they actually will end up understanding what to click. Designing an application for the web is by no metrics the same as doing it on the desktop. People think about it in a completely different way.
The little problem with Windows and Mac is that on a Mac usually all applications look and behave the same. On Windows, this mostly differs per application (and people don't 'know' by forehand what it will be), due to Windows' architecture vs OSX's one. If many, but not nesssisairally most, users use a Mac, consider doing it the Mac way.
@ThomPete if the user is too stupid to not understand the difference between `Ok` and `Cancel`, then they shouldn't be using a computer unsupervised. The answer is good specifically because it encourages **consistency** which may take priority over usability (see the classic `qwerty` vs `dvorak` argument).
The answer is in user interface guidelines for the system you use.
Present the commit buttons in the following order:
- OK/[Do it]/Yes
- [Don't do it]/No
- Apply (if present)
- Help (if present)
So Cancel is always on the right of OK button.
A button that initiates an action is furthest to the right. The Cancel button is to the left of this button.
So for MacOS users Cancel is on the left of OK button.
The dismissive action of a dialog is always on the left. Dismissive actions return to the user to the previous state.
The affirmative actions are on the right. Affirmative actions continue progress toward the user goal that triggered the dialog.
For Android, Cancel is on the left of the OK button.
For other systems see guidelines.
Unfortunately there are no guidelines for the internets, so you'll have to use best practices there!
I think for web apps you may either try to detect user's OS (and reposition buttons if needed) or use Windows order since this order is more popular (it is used also in many Linux systems as far as I know).
@Kostya - This will cause problems when people view the same websites on different systems, there would be no consistency which is one thing you should expect from a good website.
@Toby But this is actually used, for instance, on this very website! I've worked with the source of the editor they use here, and it has this exact behavior, for the image and hyperlink dialog boxes - take note of it the next time you use it on different OS
@Toby: That would be an interesting follow-up question to this one: is it better for a website to adhere to a single behavior or change depending on the user's platform? Calum Benson also raises a good point about OS detection not being enough for Linux.
I've used both a Mac and a PC every working day for the last 10 years - and I hadn't actually realised the Yes/Save buttons were in a different order until I came across this question... So based on that sample of one observation, the order may not be that important.
So for vertical button stacks, should this same order be applied from top to bottom?
Think "reading" metaphor. Westerners read left to right, our brains are conditioned to flow left to right. CANCEL is basically a step backwards (left) and OK/SUBMIT/YES/Etc., are a step forward (right).
Also timelines usually go from left to right. So Cancel would correspond to go back in time. And OK would be to move forward in time. Good analogy there.
Specific platform conventions trump the broad reading direction argument. Windows does OK|Cancel.
I agree with the reading metaphor, but you could just as easily come to the conclusion that since you read from left to right, top to bottom, that the buttons should go in order from most likely to least likely to do. In other words Ok, then Cancel. Ultimately however, I believe that following what your users expect is the most important and trumps anything else (i.e., platform conventions).
@dbkk: in the case where you are serving a multi-platform userbase, then this would be a good "tie-breaker" argument. It may be better than detecting which OS the user is on and trying to conform to that (and as a result, show the same user different behavior depending on whether he's on his laptop or desktop or iphone).
I think that the most commonly used operations should be first and the least last. Submit/Cancel are not like Prev/Next in the manner that Prev/Next are undo-able (by clicking on Next/Prev) and Submit/Cancel are not.
An excellent link describing this concept in greater detail: http://uxmovement.com/buttons/why-ok-buttons-in-dialog-boxes-work-best-on-the-right/
It seems like Windows OK/ Cancel convention has done a lot of brain conditioning for users. So usability tests would certainly come out with lots of people looking for an OK button on the left, Cancel on the right.
But that doesn't change the most basic instinct of someone who is interacting with the system without any pre-conditioning. My basic instinct says that the OK/ Approval/ Move Forward button, no matter what colour or size you apply to it, needs to be on the right edge of the dialogue box.
Consider this dialogue box, with no labels or colour highlights:
Where would you click? I'd click on the button on the right edge, if I am looking to submit the form. The reason is, that before Windows, I've been conditioned into my instinct in the following ways:
- The English language flows left to right.
- The browser navigation works Back(left) and Forward(Right).
- Old 2D games like Dangerous Dave move the character to the right, when they are progressing further.
Numbers on the number line increase to the right, decrease to the left.
Atomic weights on the periodic table increase to the right.
The clock ticks to the right.
Calendar increases dates to the right.
I think the Windows platform has created an anti-pattern with OK/Cancel, that is now so widespread that its validating usability studies. But if you consider the factors above, I believe keeping the primary button on the right is justified and a defensible position.
EDIT: One additional factor to consider is consistency. If you expect additional buttons in your dialogue boxes, the primary button on the right edge would help to stay consistent with placement. A visual example would make this clear:
But the original poster is not asking about Next and Back buttons, he is asking about OK and Cancel buttons. OK doesn't necessarily mean a flow to the right, it just means a positive action. Actually if your argument is about flow of document, then for a web document your Next button should go *underneath* your Back button.
This is absolutely what i thought too. I also agree above answers to place OK first (thats left) but only when the button-group is aligned left or center. In mobile's world, i like to align button group right, for better touching with the right hand thumb. And in that case, i would also place the "main" button in the right corner.
In the dialog without labels example I would argue that left-right thinking might not apply, even if user is preconditioned by having i.e. turned book pages. If there is a choice to be made by clicking on a dialog button, when thinking left to right, 1st choice can be assumed as the correct one (positive action) while asecond choice is the negative action.
For users whose language is read left to right, I would suggest putting the OK button to the left, since those users would ascribe greater importance to the first thing they see.
This would allow this subset of users to complete their task as quickly as possible.
Interesting mention of LTR, because it implies you would have to think differently about RTL. Surely there is some research done in that area?
@Rahul: That might be a good reason to arrange them vertically if you can. I don't know of any languages where you read from the bottom up, and pretty much all interfaces with vertically arranged buttons put the affirmative at the top, so it would be both culture and platform agnostic.
I don't know about research, but Microsoft put a lot of effort into reversing UI elements like this for RTL.
I disagree. We read left to right (in the West), but we do NOT scan interfaces uniformly left to right. A row of buttons is not read like a sentence, as our brains perceive them as separate objects first, and then we attempt to parse the text inside each one for meaning separately.
@Graham When I am use English UIs, I read buttons or links from left to right until I find the one I am looking for. I don't see how you can read multiple buttons simultaneously, are you a Homo-Sapian?
You read from left to right, but you generally continue scanning until you've read all of them (especially when there are few buttons (2 or 3). So you would either read: "Ok, Cancel, Ok" (once you've reached the end you come back to the one you want) or "Cancel; Ok": great! No need to go back with this one. :)
IMHO it does not matter too much where you will place "OK" button: to left or to right. It does not matter what kind of users visit your site (with hebrew or arabic languages). It does not matter what kind of software they use. The stats tell us that 55% of users want to see "OK" button from the right but if we will put it to the right, then the other 45% of users will be dissatisfied.
The best solution is to emphasize "OK" button (make it more prominent than "Cancel") and all the users will indicate "OK" button easily as more important and primary button.
Google and other companies use this approach in their software.
I agree that the visual weight and labels of action buttons are an important design aspect to consider (and very useful in this case where position alone can't be relied on), but it’s not the only aspect. I feel that a meticulous designer would think about how every design aspect affects the user - position cannot be ignored.
Luke Wroblewski wrote a book about web forms (Web Form Design: Filling in the Blanks) and he also covered some principles like: "Primary & Secondary Actions" ( http:// www.lukew.com/resources/articles/psactions.asp ), "Top, Right or Left Aligned Form Labels" ( http:// www.lukew.com/ff/entry.asp?504 ) or "path to completion", etc. (you can read also http://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php)
So, IMO depending on what label placement you have (preferable vertically) and left-to-right + top-down rules, in order to have a good path to completion you should place primary action first (OK) and then secondary ones (++Cancel)
EDIT: Label placement in forms, by Caroline Jarrett, 2010 http://www.formsthatwork.com/files/Articles/labels-on-forms-for-uxlx-2010.pdf
I think everyone had given good point but there is one more key point to be mention here.
Buttons such as Ok/Submit/Save etc are called positive action buttons. Similarly, buttons such as Cancel/Reset etc are called negative action buttons.
Now to answer the query, most of them has come with some good points but here is another perception that is User Testing of an application usually decide most of the issues. After all any application created are for users only.
There were some eye moment test & heat test were done on users and still being done depending on the labs availability. The best scenario comes up are that most of users start looking at the web application or any other application from Left - to - Right & from top corner and start scrolling toward the bottom picking up key hotspots and generally end toward the left bottom thus it is always good to keep positive action button on left and negative action buttons on right.
Also, not denying the fact that these are research based on few users, it is not necessary that this will always hold well but most of time it will.
There is one more key point here is that there shold be more space between positive & negative action buttons so that users will take little more time to reach to negative buttons and thus will give them ample amount of time to thought and react.
I have tried to explain couples of points are based on my experience and from research papers.
Do comment, so that I can also learn more.
Regards Deepak Bajaj
A lot of applications have been shifting to use different styles for OK vs Cancel buttons. One common UI is to have the OK button but a traditional button whereas the Cancel is a link button. This gives a very clear visual distinction between the two and even though it leads the user to click OK, the visual distinction ends up highlighting the difference and helps the user pick the one they actually want.
I've seen this both in web and desktop applications.
Sam has a point here (which I was about to raise): the question mentions 2 buttons, but there might be a single one, tha positive OK or accept or whatever action. The other actions, like [cancel] but also other options like [clear all] or [whatever] need not to be buttons, and they are better off being another kind of click target. In this case it might be helpful to display them as buttons on hover, in order to communicate the user their hierarchy, but this is not essential.
Wow! Such a lot of answers arguing left or right.
I ran tests on this myself and found them to be statistically inconclusive.
The best answer I found was that it doesn't really matter which order they go it as long as the primary action is clearly marked - I always use a colourful button for [Do it]/go/submit/etc and a smaller text only button for [Don't do it]/cancel/clear/etc.
Very much like the 'Post Your Answer' and 'discard' buttons at the bottom of an answer form right here on UX StackExchange!