Human Interface Note #8    
_____________________________________________________________________________

Note #10   Alert Box Guidelines

           Written by:    John Sullivan                             June 1990
           (Slightly plagiarized from Kate Gomoll)
_____________________________________________________________________________

Some simple rules to follow for alert boxes.
_____________________________________________________________________________


Why there are alert box guidelines

From the feedback the Human Interface group has received, it is clear 
that the discussion of alert boxes in Human Interface Guidelines:  The 
Apple Desktop Interface is both imperfect and incomplete.

These guidelines serve at least three major purposes.  First, they 
provide a simple recipe for making attractive alert boxes.  Second, they 
provide a simple recipe (the same one, in fact) for making alert boxes 
that have a standard appearance and behavior.  This standardization is 
important, because the more familiar the appearance of an alert box is 
to users, the easier it is for them to concentrate on the specific 
message being communicated.  Finally, these guidelines provide simple 
rules that can be extended for designing more complicated dialog boxes.

This Note supplements and partially replaces the discussion in Human 
Interface Guidelines:  The Apple Desktop Interface, so where this Note 
and the book disagree, believe this Note.


Alert box layout

Alert boxes drawn with the toolbox calls _StopAlert, _NoteAlert, and 
_CautionAlert place the icon in the rectangle (top = 10, left  = 20, 
bottom = 42, right = 52); however, placement of all other elements is 
left to the individual designer.  Figure 1 shows a simple alert box in 
which spacing between elements is based upon this placement of the icon.

    | B |      | B |                                        | A |
  |-|<->|------|<->|----------------------------------------|---|-|
--|-|===|======|===|========================================|===| |
A | |   |      |   |                                        |   | |
--|-|---|--/\--|---|This is where the text goes.  Be sure to|   | |
  | |   | /  \ |   |use wording that makes sense to the     |   | |
  | |   |/ !  \|   |typical user.                           |   | |
  | |   |------|   -----------------------------------------|---|-|--
  | |                                                       |   | | A
  | |                          ___________     #############|---|-|--
  | |                         /  Cancel   \  //    Xxxxxx   \\  | |                                                      
  | |                         \___________/  \\_____________//--|-|--
  | |                                     |   |#############    | | A
  | |=====================================|===|=================|-|--
  |---------------------------------------|<->|-------------------|
    A = 13 white pixels                   | A |
    B = 23 white pixels

              Figure 1-Simple alert box with spacing

Following are the exact coordinates used in Figure 1 and how they were 
derived, in Rez format.  Note that there are three white pixels built 
into the dialog frame and that the upper left corner of the text item is 
not the same as the upper left corner of the first character.

The first set of definitions are not actual coordinates, but instead are 
intermediate values used to derive them:

#define A                  13  // white space between most elements
#define B                  23  // white space to left and right of icon
#define NumTextLines        3  // number of lines of text in the alert
#define LineHeight         16  // height of a single line of Chicago-12
#define ButtonHeight       20  // standard button height
#define LongestButtonName  41  // width of "Cancel" in Chicago-12
#define ButtonWidth        59  // (LongestButtonName + 18)

The rest of the definitions are actual coordinates defining the window 
size (AlertWidth and AlertHeight) and the icon, text, and button 
locations:

#define AlertWidth        341  // chosen to make the right margin = A

#define IconLeft           20  // (B - 3)
#define IconRight          52  // (IconLeft + 32)
#define IconTop            10  // (A - 3)
#define IconBottom         42  // (IconTop + 32)

#define TextLeft           74  // (IconRight + (B - 1))
#define TextRight         331  // (AlertWidth - (A - 3))
#define TextTop             7  // (A - 6)
#define TextBottom         55  // (TextTop + (NumTextLines * LineHeight))

#define ButtonTop          68  // (TextBottom + A)
#define ButtonBottom       88  // (ButtonTop + ButtonHeight)
#define ActionButtonRight 331  // (AlertWidth - (A - 3))
#define ActionButtonLeft  272  // (ActionButtonRight - ButtonWidth)
#define CancelButtonRight   259  // (ActionButtonLeft - A)
#define CancelButtonLeft    200  // (CancelButtonRight - ButtonWidth)

#define AlertHeight          98  // (ButtonBottom + (A - 3))


The action button

Alert boxes that provide the user a choice should be worded as questions 
to which there is an unambiguous, affirmative response.  The button for 
this affirmative response is called the action button.  Whenever 
possible, label the action button with the action that it performs.  
Button names such as Save, Quit, or Erase Disk allow experienced users 
to click the correct button without reading the text of a familiar 
dialog.  These labels are often clearer than words like OK or Yes.  
Phrase the question to match the action that the user is trying to 
perform.  For instance, if the user selects Revert to Saved, the 
confirmation alert should say something like "Revert to the last saved 
version of the document?  Any changes made since the last save will be 
lost."  This message is much clearer than something like "Discard 
changes made since the last save?"

If the action cannot be condensed conveniently into a word or two, use 
OK.  Also use OK when the alert is simply giving the user information 
without providing any choices.


The cancel button

Whenever possible, provide a button that allows the user to back out of 
the operation that caused the alert box to be displayed.  This button is 
activated when the user types Command-. (period) or presses the Escape 
key.  (Note that the Command key sequence may differ depending upon the 
script system in use.  See Macintosh Technical Note #263, International 
Canceling, for more information.)  Apple recommends naming this button 
Cancel, so that users can easily identify it as the safe escape hatch.  
For more information, see Human Interface Note #5, "What Cancel Means."


The default button

In most cases, the default button should perform the most likely action 
(if that can be determined).  This usually means completing the action 
that the user initiated to display the alert box in the first place; 
therefore, the default button is usually the same as the action button.  
The default button is boldly outlined, and its action is performed when 
the user presses the Return or Enter key.

If the most likely action is dangerous (for example, it erases the hard 
disk), the default should be a safe button, typically the cancel button.  
If none of the choices are dangerous and there is not a likely choice, 
then there should be no default button.

When there is no default button, the user must explicitly click on one 
of the buttons (pressing Return or Enter does not perform an action).  
By requiring users to explicitly click on a button, you can protect them 
from accidentally damaging their work by pressing the Return or Enter 
key out of habit.


Buttons (placement, size, capitalization, and feedback)

Put the action button in the lower right corner, with the cancel button 
to its left.  Use this placement regardless of which button is the 
default button; put the action button in the lower right corner even if 
the cancel button is the default.

Buttons in alert boxes look best when they are 20 pixels high (not 
counting the default button outline) and have at least 8 white pixels on 
either side of each button's name.  These specifications mean that the 
width of the button should be at least 18 pixels larger than the width 
of the longest button name (16 pixels for the white space plus 2 pixels 
for the edges).  It looks best to make all buttons the same width, 
unless the buttons' names have extremely different length names.  If you 
find yourself tempted to make buttons with extremely long names, 
reconsider the names carefully; button names should be simple, concise, 
and unambiguous.

Capitalize the first letter of each button name, but never capitalize 
the entire name--with the single exception of the OK button.  The OK 
button should always be named OK and never ok, Ok, Okay, okay, OKAY, or 
any even stranger variation.  If a button name contains more than one 
word, capitalize each word, such as Replace All or Cancel Printing.

As in all dialog boxes, any buttons that are activated by key sequences 
must flash to give visual feedback as to which item has been chosen.  A 
good rule of thumb is to invert the button for eight ticks; this is long 
enough so that it is always visible, but short enough that it is not 
annoying.  Alert box calls in the Toolbox use the eight tick value by 
default.


_____________________________________________________________________________
Further Reference

  o  Human Interface Note #5, What Cancel Means
  o  Macintosh Technical Note #263, International Canceling
