
User Interface Design Guidelines
In general, the user interface design of your plug-in is completely up
to you. However, we recommend using PageMaker as a model. By basing your
plug-in interface on the PageMaker interface, you visually tie your plug-in
and its functions more closely to PageMaker and provide a more consistent
working environment for users.
This page outlines some of the guidelines we used to develop the PageMaker
interface. This chapter also provides some general development tips you
may want to use, especially if your users may be working with multiple plug-ins.
For more interface development information, refer to Inside Macintosh
by Apple Computer, Inc., and the Windows User Interface Guidelines
in SDK Guide for Microsoft Windows and Windows NT.
General development tips
The following tips may help you design and implement a more efficient
interface for your plug-in.
Simplify the plug-ins menu
Remember that the PageMaker Plug-ins menu can become quite long, depending
on the number of plug-ins the user installs. Here are some tips to help
keep the menu uncluttered:
- If you plan to write several related plug-ins, we recommend that you
not list each plug-in separately on the plug-ins menu. Instead, combine
them into a single plug-in and let the user access the various options
in a dialog box. For example, if you plan to write a set of plug-ins that
create automatic headers and footers, don't list "Automatic header"
and "Automatic footer" on the PageMaker Plug-ins submenu. Instead,
use just one command, "Automatic Headers and Footers" that opens
into a dialog box containing all available options for automating headers
and footers.
- If you plan to write several plug-ins that perform unrelated functions,
put them in separate plug-ins. That way, users can install only those plug-ins
they need. (If all your plug-ins are in the same file, the user must install
all the plug-ins.)
Create consistent icons
To maintain a consistent desktop interface with other plug-ins, base
icons for your plug-ins on the PageMaker plug-ins icon.
Follow existing standards and usage
Take advantage of the user's knowledge of existing methods for performing
operations and conventions for naming menu items.
Support existing or de facto standard shortcuts:
Item |
Windows |
Mac OS |
Cut |
Control+X |
Command+X |
Copy |
Control+C |
Command+C |
Paste |
Control+V |
Command+V |
Undo |
Control+Z |
Command+Z |
Cancel |
Esc |
Command+. (period) |
Print |
Control+P |
Command+P |
Quit |
Control+Q |
Command+Q |
New |
Control+N |
Command+N |
Open |
Control+O |
Command+O |
Save |
Control+S |
Command+S |
Place |
Control+D |
Command+D |
Designing dialog boxes
As a rule, all dialog boxes must have:
- A title.
- An "OK" or action (for example, "Print") button.
- A "Cancel" button.
In general, the rest of the dialog box design is up to you. However,
to provide a consistent interface (and one with which the user is already
familiar), we recommend that you make your plug-in dialog boxes look as
similar to PageMaker's as possible.
Common dialog boxes
Where possible, use the common dialog boxes provided in Windows and on
the Macintosh. Both platforms offer standard dialog boxes for opening and
saving files.
PageMaker dialog box guidelines
Here are the guidelines we use for developing dialog boxes:
- Position dialog boxes and alerts 3/10 of the way down the Macintosh
screen and 2/5 of the way down the PC screen.
- Use Chicago 12 and Geneva 9 for text on the Macintosh and Helv 8 and
Helv 7 for text on the PC. Typically, the smaller font sizes are used for
labels, group box titles, and message lines in complex dialog boxes. See
the Links dialog box in PageMaker for an example.
- Capitalize only the first letter of the first word in a dialog box
title, option name, control group name, or group box title.
- Run a 2-pixel rule from the left edge of the title to 18 pixels from
the left edge of the OK button.
- Leave 6 pixels between the baseline of the title and the top of the
rule, and 12 pixels between the bottom of the rule and the top of the first
letter of the option immediately below.
- Leave a 12-pixel margin on all sides.

About pixels
Pixels-as defined by the 13" Macintosh screen or a VGA screen for
the PC-are used as the measurement system to describe spacing guidelines.
The purpose in being so specific is to aid in determining control placement.
However, perceived distance may be preferable to pixel specification, especially
for higher resolution screens. So use what's reasonable; for example, 12
pixels or approximately 3/16 of an inch.
- Offset nested dialogs down and right from the dialog that invoked them.
Typically, it's better to cover the parent dialog's OK and Cancel buttons
(or similar controls) to minimize confusion for the user.
- Use selectable dialog boxes to present groups of related options that
can't all fit in one dialog box. For example, the PageMaker 7.0 Print dialog
box contains a list of push-buttons along the right side. Selecting a button
causes the related items to appear in the dialog box.

Creating and placing buttons
Here are the guidelines we use for button design:
- Center button names within the button, leaving at least 4 pixels between
the button name and the left and right edges of the button.
- Make the "OK" or action button (for example, "Print")
the default button (activated when the user presses the Return or Enter
key). However, message boxes or alerts may designate "Cancel"
as the default when the operation could cause data loss, for example, saving
over an existing document.
- Use the initial letter in the button as its mnemonic when possible.
- Reinforce the default action button visually with a bold border. On
the Macintosh, its border consists of a 1-pixel rule inside and a 2-pixel
rule outside separated by a 2-pixel space; in Windows, its border is defined
by the standard DEFPUSHBUTTON style.
- Set a 1-pixel border around standard (non-default) buttons.
- Make all buttons 19 pixels high, measured from the 1-pixel border.
- Position the "OK" or action button in the upper-right corner
of the dialog box, directly above the "Cancel" button.
- Separate other buttons from the "Cancel" button by stacking
them under a rule that runs the width of the buttons. Use the standard
1-pixel dotted rule on the Macintosh, and a 2-pixel line in Windows.
- Make all buttons the width of the widest non-default button.
- Align buttons along the right side with the main dismissal or "Cancel"
button.
- Gray out the button currently governing the content of a selectable
dialog box.
Radio buttons, check boxes, and edit boxes
The Windows and Macintosh platforms provide standard-sized controls for
most dialog box options. If no standards are provided or if you may determine
the size of options, use the following guidelines:
- Include a descriptive title above or to the side of all logical sets
of controls (e.g., radio button groups).
- Organize related controls within titled boxes. Use a 1-pixel black
border on the Macintosh, and the standard Windows group box on Windows.
- Make radio buttons 12 pixels in diameter and check boxes 12 pixels
square.
- Size edit boxes to 22 pixels high and wide enough to accommodate the
maximum number of characters the user can enter. When text in the box is
highlighted, separate the edge of the highlight from the edit box border
with 2 pixels of space.
- Use a 1-pixel border for radio buttons, check boxes, and edit boxes.
Option placement guidelines
Here are the guidelines we use for positioning controls within the dialog
box:
- Align controls and control labels in the left portion of the dialog
box with the title.
- Arrange groups horizontally.
- Align options along vertical lines.
- Run in the group name with its options, unless the group name is very
long or the option names vary greatly in length. In that case, indent the
option names under the group name.
- Left-align all options in a group.
Note: For boxed groups, use the border, rather than the boxed items,
to left-align with the title and other controls.
Error messages and alerts
Error messages are posted when the user enters invalid data or when the
settings in a dialog box are not within defined ranges. Try to give the
user as much help in solving the problem as possible. Here are some tips
for building dialogs that offer user feedback as well as conform to PageMaker
standards:
- Trap errors when the user OKs the dialog box, not when the user is
navigating between options within a dialog box. Though this is the preferred
method, you may need to trap errors immediately in certain cases, for example,
when values in controls are calculated based on settings in other controls.
- Construct error messages and alerts in two parts: a description of
the problem or condition and a statement containing suggested corrective
action or required state (e.g., "Cannot complete Drop-cap operation.
Click text tool in a textblock and try again.")
- Include a "Continue" button rather than an "OK"
button when applicable. For example, for this message, "Cannot initialize
language dictionaries. No languages supported for hyphenation," "Continue"
is more appropriate than "Cancel."
- Return to a highlighted field containing the invalid value after the
user accepts or cancels the error message.
- Select "Cancel" as the default for potentially destructive
actions. For example, for this message "Delete page and all items
on it?" with its options for "OK" and "Cancel,"
"Cancel" is the default.
- List the acceptable range for illegal values or indicate the source
of the problem in the error message text. For example, "-1 not a valid
measurement. Enter a number between 1 and 16."
- Adopt the measurement system in effect when the error is flagged. For
example, an error message would read "Enter a number between 1 and
3 inches" when the selected measurement system is inches and "Enter
a number between 30 and 600 mm" when in millimeters.
- Avoid using words like "fatal" or "bad." Use "serious"
or "important" instead.
- Point user to help when necessary. For example, when corrective action
requires significant instruction, direct the user to the documentation
or to online help.
Guidelines for making your product easy to localize
PageMaker is distributed in over 20 languages.
A successfully localized product provides more than the ability to translate
text into other languages. Consideration of cultural differences up front
can ease the localization process considerably. Fortunately, the fundamentals
of planning for localizing Windows products are almost identical to planning
for localizing Macintosh products, so you can transfer what you learn when
localizing on one platform to the process on the other platform.
Localizing Windows plug-ins
If you plan to translate your Windows plug-in into different languages,
you can help simplify localization by putting strings in a single resource
file. Tracking the status of one file is much easier than keeping tabs on
several files, each containing different groups of string definitions.
Note: Windows 3.1 and Windows 95 provide resources and language-sensitive
functions that help ensure that your application behaves as expected in
localized versions of Windows.
Organizing your resources
Keep functional code and strings separate. Hard coding strings makes
it impossible to localize without generating a new executable. Instead,
use resources for any information that needs to be modified. On the Macintosh,
the .RSRC contains these items. For Windows applications, the .RC and .DLG
files are used.
Content of resources
Some items requiring localization are obvious, for example, text in menus
and dialog boxes. However, there are additional issues to consider, such
as date format and icons for certain objects. You may discover others during
your localization process. Apple has a "Internationalization Checklist"
document for developers. In addition, the Windows SDK contains a section
on the localization process. You may want to consult these documents for
more information.
Here is a list of items that you should put in resources.
- All text visible on the screen, including menu items, dialog text,
error messages, status line or help information, undo strings, titles and
items listed in palettes, and conditionally displayed items for menus and
dialog boxes (e.g., strings for the PageMaker "Place" dialog
box change depending on the type of file selected).
- Quotation marks or other punctuation and special characters
- Shortcuts and accelerators
Note: When providing translator tables for shortcuts, keep in mind
that the international keyboards have keys in different places than the
U.S. keyboards so that the locations of the VK_OEM keys may change depending
on the keyboard layout chosen by the user.
- Number formats and separators (e.g., commas and decimal marks)
- Currency symbols
- Short and long formats for dates (e.g., 6/22/93 and June 16, 1993)
and provision for European and Non-Gregorian calendars
- Time formats and descriptors (e.g., 12 hr, 24 hr, AM/PM)
- Address formats, including ZIP codes and phone numbers
- Lengths of strings and text resources
- Text translator tables for character, word, and phrases
- Units of measure
- Graphics and icons, including position and size. Items will change
position and size as they get translated, so do not hard code the location
or extent of any element in the window.
- Word and character boundaries
Note: These delimiters are used in search and replace, sorting,
word wrap, selection, backspacing and delete, and cut and paste operations.
If your plug-in does not perform these operations, you won't need these
items in the resource.
Providing for translated text
As you create dialog boxes, keep in mind that translated items will almost
certainly grow in size, possibly in all directions. For example, diacritical
marks are widely used outside the United States and may extend up to the
ascent line, "Ü" and "É," or down to the
descent line, "Ç."
Note: Potential grammar issues may affect the size of error messages,
so keep them flexible.
Design dialog boxes and other elements to give text room to grow up,
down, and sideways. Use this rule of thumb to allocate extra space for strings:
For this number of English characters |
Allocate this much additional space |
1-10 |
200% |
11-20 |
100% |
21-30 |
80% |
31-50 |
60% |
51-70 |
40% |
70 and above |
30% |
Note: Do not put text inside an icon. It's unlikely that translated text
will fit within the confines of an icon.
Special considerations
Here are some other items to take into account.
- Determine appropriate settings and use them as the defaults. For example,
page size should default to A4 in products intended for European English
markets.
- Right-to-left and mixed-direction text can cause problems in justification,
cursor positioning, highlighting.
- Restrict use of <Command><Space> (and arrow keys) for Command-key
equivalents since these are used to select keyboards.