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