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:

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:

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:

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.

Creating and placing buttons

Here are the guidelines we use for button design:

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:

Option placement guidelines

Here are the guidelines we use for positioning controls within the dialog box:

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:

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.

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.


Comments or suggestions? Contact Adobe Developer Support
Copyright © 1997 - 2001 Adobe Systems Incorporated. All rights reserved.
Legal notices and trademark attributions