September 17, 2008 at 12:29OK – Cancel or Cancel – OK? Tips Jacob Nielsen.
Does the OK button appear before or after the Cancel button? Following the instructions of the operating systems in this case is more important than improving a single dialog box.
There are a lot of questions in the design of user interfaces that do not really matter for the user experience. A classic example: the order of the buttons in the dialog boxes:
* OK / Cancel
* Cancel / OK
Both options are reasonable, and people can argue for hours about their preferences:
* If you put OK first, this will correspond to the natural reading order in all languages where words are read from left to right. Many other button combinations also have a natural progression (say, Yes / No or Previous / Next). These buttons should always be positioned so that the reading order is logical - in this case, OK / Cancel. Moreover, if we assume that users need the OK button more often than Cancel, it is better to place this option first so that those users who mainly use the keyboard and, in particular, the Tab button to navigate sites, can reach the desired button by one click less.
* If you put OK last, this will improve navigation, because the dialog box will “end” with its logical conclusion. In addition, as in the case of Before / Next, OK is exactly the choice that leads the user further, while Cancel returns it back. Thus, OK should be located in the same place as Next: on the right.
In such cases, it’s often not important what you do: there are serious arguments in favor of each option, and none of them will cause a catastrophe.
Dialog buttons for offline applications
As for application development, the illogical arrangement of buttons can cost users a few minutes if they skip or use interface elements incorrectly. In this matter, it is worth starting from the location of buttons in the corresponding operating systems.
Unfortunately, the Windows Vista User Experience Guidelines differ from the Apple Human Interface Guidelines with respect to the OK / Cancel buttons:
* Windows puts OK first
* Apple puts OK last
If you are developing an offline application for one of these platforms, the question is solved simply: Do it, what the platform developer tells you.
Dialog buttons for web applications
If you are developing a web application, the dilemma is more difficult, but even in this case, you should adhere to the order established by the OS that most of your visitors use. Your server logs will show you the ratio of Windows users compared to the Mac OS, Linux, or FreeBSD on your website. Of course, Windows has a lot more users, so the logic in most situations is as follows:
* OK first, Cancel then, as in this screenshot from Microsoft Office 2007:
This screenshot illustrates two more rules regarding buttons in dialog boxes:
* It’s better that the name of the button explained what she was doing than using general words (like “OK”). The exact name serves as a “timely hint”, giving users more confidence that they are choosing the right action.
* Make the most frequently pressed buttons the default selection and highlight them (except in cases where it can be dangerous; in such cases, the user is better off selecting the desired button himself than accidentally activating the unwanted one by accidentally pressing Enter).
There are a lot of questions in the design of user interfaces that do not really matter for the user experience. A classic example: the order of the buttons in the dialog boxes:
* OK / Cancel
* Cancel / OK
Both options are reasonable, and people can argue for hours about their preferences:
* If you put OK first, this will correspond to the natural reading order in all languages where words are read from left to right. Many other button combinations also have a natural progression (say, Yes / No or Previous / Next). These buttons should always be positioned so that the reading order is logical - in this case, OK / Cancel. Moreover, if we assume that users need the OK button more often than Cancel, it is better to place this option first so that those users who mainly use the keyboard and, in particular, the Tab button to navigate sites, can reach the desired button by one click less.
* If you put OK last, this will improve navigation, because the dialog box will “end” with its logical conclusion. In addition, as in the case of Before / Next, OK is exactly the choice that leads the user further, while Cancel returns it back. Thus, OK should be located in the same place as Next: on the right.
In such cases, it’s often not important what you do: there are serious arguments in favor of each option, and none of them will cause a catastrophe.
Dialog buttons for offline applications
As for application development, the illogical arrangement of buttons can cost users a few minutes if they skip or use interface elements incorrectly. In this matter, it is worth starting from the location of buttons in the corresponding operating systems.
Unfortunately, the Windows Vista User Experience Guidelines differ from the Apple Human Interface Guidelines with respect to the OK / Cancel buttons:
* Windows puts OK first
* Apple puts OK last
If you are developing an offline application for one of these platforms, the question is solved simply: Do it, what the platform developer tells you.
Dialog buttons for web applications
If you are developing a web application, the dilemma is more difficult, but even in this case, you should adhere to the order established by the OS that most of your visitors use. Your server logs will show you the ratio of Windows users compared to the Mac OS, Linux, or FreeBSD on your website. Of course, Windows has a lot more users, so the logic in most situations is as follows:
* OK first, Cancel then, as in this screenshot from Microsoft Office 2007:
This screenshot illustrates two more rules regarding buttons in dialog boxes:
* It’s better that the name of the button explained what she was doing than using general words (like “OK”). The exact name serves as a “timely hint”, giving users more confidence that they are choosing the right action.
* Make the most frequently pressed buttons the default selection and highlight them (except in cases where it can be dangerous; in such cases, the user is better off selecting the desired button himself than accidentally activating the unwanted one by accidentally pressing Enter).