Local Links

External Links


Search this site

Correct button placement in confirmation dialogs on Mac OS X

Please make sure your modal dialogs allow the user to depend on these clear rules, or you'll cause confusion for the trained Mac user:

  • Clicking on the rightmost button continues the action that was trigged.
  • The button second to right is called Cancel and aborts the action.
  • Pressing the Esc key aborts the action.
  • Pressing the Return key performs the safest operation, which may be to abort or continue.
(E.g, if the action is destructive, and there's no Undo, then it might be a good idea to invoke the Cancel button, otherwise it should invoke the operation.)
  • The rightmost button should name the action it performs (Send, Delete, Proceed etc.) instead of saying just OK, if possible.
  • The buttons should never read Yes and No, but should always be verbs.

Detailed discussion

The rule Apple has stated since the dawn of the Macintosh is as follows (from Apple Human Interface Guidelines for dialogs):

An action button, which initiates the dialog’s primary action, should be farthest to the right.
A Cancel button should be to the immediate left of the action button. If a third dismissal button exists, it should be to the left of the Cancel button.

This means that the rightmost button is the one that proceeds with the operation that the user had just invoked.

This also means that the button next to it on the left is the one that cancels the operation.

Here is a good example of this:

The user had just given the command to close a window and now the application wants a confirmation that this is really what the user meant to happen. To proceed, the user clicks on the rightmost button, to cancel he clicks on the middle button.

Note that this has nothing to do with the choice of the default button - i.e. the button that is activated if the user pressed the Return or Enter key!

Pressing the Return key does not mean the same as clicking on the rightmost button, after all: The Return key just executes the preferred action. It's up to the author of the application to decide what's the right way for this.

If you feel that the default action is a destructive action without Undo, then you may choose to make the Cancel button the default button as well. See NSAlert: Make second button both the default and cancel button for code examples on how to implement this.

There is, however, a reliable key for cancelling the operation: The Esc key shall always perform the action of the Cancel button, meaning to cancel the invoked action.

This means that if you are performing any operation that pops up a modal dialog (or sheet) asking you for confirmation, it is always safe to press the Esc key in order to cancel what you just, maybe accidentally, did. If you get such a dialog and you are not sure about what it tells you, press Esc and start over.

Now a bad example:

Here, the rule is not observed and can easily lead to data loss if the user is used to using the mouse: I want to delete a single mail in Microsoft Entourage, but did not notice that I had not selected a single mail in the list, but selected an entire folder in the mailbox view. Entourage pops up this confirmation dialog to make sure I really wanted to delete an entire folder (which does not get moved to the Trash folder but gets erased right away). I see this dialog, think "oh my, I better cancel this before I lose my precious mails!", and click, as I'm trained, on the left button, which is supposed to be the Cancel button. It's even not the default button - it just looks like the right one! And sure, damage is done before I realize the trap.

Microsoft did apparently put some thought into it: It made the Cancel button the default button, so that pressing the Return as well as the Esc key get me safely back without performing the unwanted deletion. That's good.

But while the choice of the default button is left to the programmer, the button placement is clearly defined by Apple, and Entourage violates this to the worst effect.

So, please pay attention to this when you design the user interface for a Macintosh application.

Page last modified on 2020-06-26, 01:27 UTC (do)
Powered by PmWiki