GUI Guidelines.

Topics.

• Environmental Management Systems
• Climate Change
• Microsoft .NET™
• Misc. Development
• Sybase PowerBuilder™

 

Miscellaneous Development Articles.

• ASCII Character Chart
• Color Chart
• Design Mistakes
• GUI Guidelines

 

Introduction.

In general, the Graphical User Interface (GUI) Guidelines are intended to follow the Microsoft Windows interface guidelines, as set forth in "The Windows Interface Guidelines for Software Design," published by Microsoft Press. As a developer, you should take the time to scan through all the guidelines therein, and read any sections that have to do with topics on which you are less than expert. These guidelines will typically expand upon or, in rare cases, may contradict a Microsoft guideline in favor of a more user-friendly standard.

 

Beyond those standards in "The Windows Interface Guidelines for Software Design," this document will also seek to define some specific guidelines for application behavior.

 

As you read these guidelines, please keep in mind that these are only guidelines. In any application development effort, there may be specific circumstances that suggest a deviation from the guidelines suggested here and in the aforementioned Microsoft guidelines.

 

In those cases where a deviation is suggested, please follow these guidelines:

• Before deviating from a published guideline, be certain that the deviation is in the best interests of the ultimate users of the application. The customer should define your development goals, and their word can and should supersede development guidelines if the success of the application is at stake. Don't let a design imperative force a poor design into the user's hands, and don't let your personal design preferences override guidelines purely for preference sake.
• Make sure that any departures from the guidelines are self-consistent within the context of the application. For instance, if you're going to deviate from the standards for button sizing, do so consistently, rather than having a random sizing of buttons within the application. If done properly, this can be an easier rule to follow than to break… do it right.
• When possible, make any departure from guideline covered interface elements appear graphically different from the standard. For instance, try not to change the behavior of a standard 'OK' button without attempting to change the button's caption or some other element of it's appearance. This visual difference alerts the user that there is something different about this interface element, and makes it far easier for a user to deal with a new behavior. Don't surprise the user if you can avoid it.

 

Much of the material in these standards is derived from additional interface design and development literature. A full bibliography of suggested alternate readings will be included as an appendix to the guidelines. If your role is that of interface designer, it is strongly suggested that you make an effort to educate yourself in the art of interface design and the practice of that field.

 

 

Date Compliance.

The standard for date compliance is as follows:

Whenever you collect, display, manipulate, store, or pass through any application interface, any date value which includes a year portion, you must include all four digits of the year whenever possible. If possible, use either the long or short date format defined in the Windows Regional Settings.

 

Suggestions for compliant date formats are:

[shortdate]
[longdate]
YYYY-MM-DD
DD Month, YYYY
Month DD, YYYY
DD-Mon-YYYY
YYYYMMDD

 

Where:

 

All other characters are taken to be literals.

 

 

Use of Fonts.

Suggested Default Font

The suggested font for use is an 8pt MS Sans Serif font. This is the default system font and it is recommended in the Microsoft interface guidelines.

 

PowerBuilder Font Settings

The following settings may be set within PowerBuilder by opening the Application Painter and choosing the appropriate Tabs as listed below:

 

Tab Title	Property	Value
Column Font	Font	MS Sans Serif
	Font styles	Regular
	Size	8
	Effects	Nothing selected
	Text Color	WndText
	Background	WndBkrnd
Header Font	Font	MS Sans Serif
	Font styles	Regular
	Size	8
	Effects	Nothing selected
	Text Color	WndText
	Background	WndBkrnd
Label Font	Font	MS Sans Serif
	Font styles	Regular
	Size	8
	Effects	Nothing selected
	Text Color	WndText
	Background	WndBkrnd
Text Font	Font	MS Sans Serif
	Font styles	Regular
	Size	8
	Effects	Nothing selected
	Text Color	WndText
	Background	WndBkrnd

 

In most cases, you will not have to change the settings for the colors, font styles, or the effects.

 

 

Use of Color.

In General

Color may be used with great effect to highlight important elements of the interface. However, too much color in one interface will generally lead to confusion on the part of the user. Use color sparingly, and with the following concepts in mind:

• More than two or three colors of highlight will generally lead to a confusing interface. If that many colors are required to make your message known, you should consider giving the user the capability to limit the information they have to deal with at any given time.
• For the sake of those who might be color blind, choose colors not only on the basis of base-color (Red vs. Green), but also on basis of contrasting brightness. Consider whether another interface device (use of an icon, for instance) could convey the same message.

 

PowerBuilder Color Settings

Generally speaking, PowerBuilder sets the colors for objects on an individual basis. However, you can cause most controls to default to the Windows 95 coloring scheme by opening the Window Painter, choosing the Design->Options… menu item and checking the ‘Default to 3D’ checkbox. This will cause most controls to exhibit a three dimensional appearance, using system colors for their properties.

 

Use the following colors whenever possible:

Color	Recommended Usage
WndText	Foreground or text color of all controls.
WndBkrnd	Background for all editable controls. DataWindow background color, if used as list interactive data entry device.
ButtonFace	Button background. Background for all non-editable controls. Window background color. DataWindow background color, if used as freeform interactive data entry device.
AppWrkSpc	Application MDI window background color.

 

 

Screen Layout.

Spacing of Controls

As a general rule, there should be a consistent amount of space between any two adjacent controls and between any control and the screen or group-box border in which the control sits.

 

The sizes for those spaces proposed by the Microsoft interface guidelines are given in 'Dialog Units' (DUs). Unfortunately, DUs are specified relative to the default system font, and PowerBuilder does not use DUs as it's means of measuring size or position of controls. For that reason, it is difficult to give appropriate sizing or spacing guidelines in PowerBuilder units.

 

Below you see an example dialog that exhibits appropriate spacing for its controls. In this example the PowerBuilder Screen Painter is set to a grid width of 5 and height of 4, with 'Snap to Grid' enabled. There is no requirement that you use those settings in your development… that information is purely intended to give you a sense of scale.

 

 

Aligning Controls

Controls should be aligned based upon their relationship to each other. The Windows 95 interface standards indicate that labels and controls being aligned together should be aligned on the left. Further, radio buttons and check boxes should generally have their interactive component on the left, with their text following to the right.

 

Note the same dialog below, with lines indicating the alignment of controls.

 

 

Radio Buttons vs. Drop-down List Boxes

Use radio buttons when:

• The number of choices is less than or equal to eight. Beyond about six radio buttons, users typically start becoming overwhelmed, beyond eight they are definitely overwhelmed. In cases where more than eight choices are to be provided, consider using a drop-down list box.
• If you must use radio buttons, and there are more than eight potential choices, you should provide breaks in the field of choices up by adding additional space between logical sub-groups of eight buttons or less.
• The choices provided are mutually exclusive within a given group-box.
• There is enough onscreen real estate to the radio buttons with sufficient space between them for readability. If space is at a premium, consider using a drop-down list box.

 

Use drop-down list boxes when:

• The number of choices is greater than eight.
• Space is at a premium and there are two or more mutually exclusive choices.
• When the selection process is to be expedited by associating icons with the choices in the list (PowerBuilder has a picture-list-box available that provides this capability).

 

 

Interaction with the User.

Indicating Processing

Whenever the program has to spend significant time (more than about a quarter second) processing, the user should receive an indication that processing is occurring. There are basically 3 varieties of such indication that should be considered:

 

Time Period	Method of Indicating Progress
Short (about 5 seconds or less)	Set the mouse cursor to indicate processing is occurring (Hourglass). (Optionally) indicate progress through use of a progress-bar.
Medium (between about 5 and 30 seconds)	Set the mouse cursor to indicate processing is occurring. Give status-bar type messaging to the user indicating the variety of processing that is occurring. (Optionally) use a progress dialog to indicate the processing that is occurring and its expected total processing time. If possible, give the user a way to cancel the processing by pressing a 'Cancel' button on the dialog.
Long (greater than 30 seconds)	Set the mouse cursor to indicate processing is occurring. Use a progress dialog to indicate the processing that is occurring and its expected total processing time. If possible, give the user a way to cancel the processing by pressing a 'Cancel' button on the dialog.

 

Disabling vs. Hiding Inactive Controls.

Whenever the use of a given control is inappropriate, for whatever reason, that control should be disabled. You should never make a control appear and disappear based on whether its use is appropriate. Typically, having controls appear and disappear is far more disconcerting to the user than having them enable and disable.

 

Although it is possible, you should not enable and disable group-boxes. They are a non-interactive elements in the interface, and are typically not used to indicate the availability of the controls they contain.

 

When to Disable Controls.

In short, you should disable controls whenever it is inappropriate for the user to interact with those controls. Following this guideline can greatly reduce the number of error messages that a user might encounter in navigating an application and generally makes for a more positive impression on the part of the user.

 

A note of warning: If a set of circumstances must be satisfied before the user can continue doing whatever it is they've set out to do, you must be certain that the user is made aware of the circumstances in which they will be allowed to continue. Failure to make the users aware of these circumstances will lead inevitably to frustration and lots of support calls. If the set of circumstances that must be satisfied before a control can be appropriately used is too complex to easily indicate on-screen, you should leave the control active and be prepared to issue an extensive error message indicating the requirements of using the control. On-line help should also be very explicit in these circumstances.

 

 

Controls.

Controls are graphic objects that are designed to provide specific interfaces for user interaction.

 

There are four basic types of controls:

• Controls that invoke actions. These controls include CommandButtons and PictureButtons.
• Controls that display data. These controls include ListBoxes, PictureListBoxes, DropDownListBoxes, DropDownPictureListBoxes, DataWindow controls, StaticText, ListViews, TreeViews. RichTextEdit, Graphs, Pictures, SingleLineEdits, MultiLineEdits, EditMasks, and OLE 2.0 controls.
• Controls that indicate choices. These controls include RadioButtons and CheckBoxes. You can group these controls in a GroupBox.
• Controls that are decorative only. These controls are the drawing objects (Line, Rectangle, RoundRectangle, and Oval).

 

PowerBuilder's PFC provides a set of visual user objects for developing standard controls. These are available in the PFC libraries: PFCMAIN.PBL (ancestor) and PFEMAIN.PBL (descendant).

 

The PFC visual user objects are designed to be used with windows that are descendants of w_master (the ancestor for all PFC windows).

 

Use these visual objects in windows instead of the standard PowerBuilder controls. The event scripts provide integration with PFC menus.

 

The following is a list of common PowerBuilder controls:

CheckBox	OLECustomControl
CommandButton	Oval
DataWindow	Picture
DropDownListBox	PictureButton
DropDownPictureListBox	PictureListBox
EditMask	RadioButton
Graph	Rectangle
GroupBox	RichTextEdit
HScrollBar	RoundRectangle
Line	SingleLineEdit
ListBox	StaticText
ListView	Tab
MultiLineEdit	TreeView
OLEControl	VScrollBar

 

CommandButtons

A CommandButton is a control, usually rectangular in shape, that has a label. The label can be text or graphic (A CommandButton with a graphic label is commonly referred to as a PictureButton). The label should represent the action the CommandButton is to start; i.e., a CommandButton with a label of Close will execute a close script. For buttons that will prompt the user for more information, the label text is generally followed by an ellipsis (. . . ).

 

Access keys, shortcut keys, and tab keys can be used to navigate among CommandButtons. Additionally the space bar and/or enter key can activate a CommandButton that has focus.

 

All command buttons (with the exception of OK, Cancel and PictureButtons with no text) should have a unique shortcut key.

 

You can define a CommandButton as being the default button in a window. If you define a default CommandButton, the user's pressing the ENTER key when the focus is not on another CommandButton is the same as clicking the default button.

 

The normal appearance of a control is called the "up" state. Refer to the "Interaction with the User" section for additional guidelines.

 

Below are some example CommandButtons. Note the two placement methods. The example on the left should be used when there are from one to three CommandButtons, the example on the right when there are more than three.

 

 

 

Command Button Functionality

The definitions below are guidelines for common functionality of the most often used command buttons.

 

Button	Functionality
OK	The OK button should perform a save and close the window.
Cancel	The Cancel button should perform differently based upon the complexity of the window. If there is a potential for a significant amount of time spent on a window, the cancel button should prompt the user for a save request prior to closing. If the object is simple, say a response window or a few checkbox settings, just close the window without prompting or saving.
Apply	The Apply button should save any input and leave the window open.
Save	The Save button should save any input and leave the window open.
Exit	The Exit button should prompt the user for a save request prior to closing the window.
Add	The Add button should add input and leave the window open.
Delete	The Delete button should remove input and leave the window open.

 

OptionButton (RadioButton)

An OptionButton, also known as a RadioButton, is a control that is represents a choice, usually of a property, or option, such as 'Read Only' or 'Sort Ascending'. It is advisable to avoid using a RadioButton to start an action such as 'Save' or 'Close'.

 

RadioButtons are grouped in logical sets of two or more and appear as a set of small circles with descriptive text to the right. The Windows 95 Interface Guidelines suggests using sentence capitalization; only capitalize the first letter of the first word, unless there are specific reasons otherwise (such as an acronym specific to the application, a proper noun, etc.). The text label can have multiple lines, and in this case top alignment with the button is suggested.

 

Each RadioButton within a group is mutually exclusive, i.e., only one option can be set on, the remaining buttons will be off.

 

A note of warning: Too many RadioButton choices may prove to be overwhelming. Refer to the "RadioButtons vs. Drop-down List Boxes" section as a guideline.

 

Below are examples of RadioButtons and groupings.

 

CheckBoxes

CheckBoxes are controls used to set independent options; that is, one checkbox's state is independent of another checkbox. The control is a square with text, generally to the right. A checkbox generally has two states, on and off. When selected (on), they contain a checkmark; when they are not selected (off), they are empty. A third state commonly used to denote 'Unknown', displays as a filled box with a checkmark.

 

CheckBoxes can be grouped in a GroupBox, but that does not affect the CheckBoxes' behavior; they are still independent.

 

Below are some examples of checkboxes:

 

ListBoxes

A ListBox displays available choices. You can specify that ListBoxes have scrollbars if more choices exist than can be displayed in the ListBox at one time.

 

ListBoxes are an exception to the rule that a control should either invoke an action or be used for viewing and entering data. ListBoxes can do both. ListBoxes display data, but can also invoke actions. Typically in Windows applications, clicking an item in the ListBox selects the item. Double-clicking an item acts upon the item.

 

For ListBoxes, the following items (there are others as well) may be set by choosing the 'General' tab of the ListBox properties:

• Items in the ListBox are displayed in sorted order
• The ListBox allows the user to select multiple items
• The ListBox displays scrollbars if needed

 

Below is an example of a single selection list box:

 

 

Menus.

Menus provide lists of commands or options, that a user can select to perform a task. Menu items are grouped logically and are a visual tool for navigation to tasks. In PowerBuilder, each choice in a menu is defined as a menu object.

 

Menu objects can exist on a menu bar, in a dropdown menu, or in a cascade menu. All menus objects have the standard functional options-you can select an object with the keyboard, the mouse, and you can define accelerator keys and shortcut keys.

 

Menu Bar

The Menu bar is the area displayed across the top of a window, below the title bar. The menu bar has a set of menu titles that provide access to a drop-down menus that contains various related menu items.

 

Menu Title

A Menu Title is the name of a drop-down menu that sits on the menu bar, or the name of the parent menu for cascade menus. A menu title should have a name that reflects the purpose of all items within the menu. It should be limited to one-word names. Each menu title should have a character defined as its access key-be certain to choose a unique access key for each menu title.

 

Menu Item

Menu Items are the individual choices that appear in a drop-down or cascade menu. These items can be labeled with text, graphics or a combination of both. Each menu item should have a character defined as its access key-be certain to choose a unique access key for each menu item.

 

Menus and PFC

PowerBuilder's PFC provides menu objects to inherit from for standard menu development.

 

For dropdown menus, you use m_master as the ancestor for your application's sheet windows and m_frame as the frame menu ancestor. You can add, modify and hide items as needed.

 

For popup menus, there is a set of objects to inherit from for a variety of visual controls. You can extend these objects to add application-specific right mouse button functionality.

 

The PFC menu integrates with all PFC windows, DataWindows, and visual controls.

 

Menu design

A menu should be kept simple and consistent. Use a dropdown menu to group related items. Use cascade menus judiciously, and try to limit them to one level. Too many cascade levels will overwhelm the user.

 

The intricacies of menu design are beyond the scope of this document. Some guidelines are detailed in the subsequent sections.

 

Naming Guidelines

Consider the following for naming menu objects:

• Define unique names within a menu.
• Use one-word names. If a name is to be multiple words, keep the wording brief. Lengthy names tend to make it harder for the user to quickly scan the menu.
• Define unique access keys for each item on the menu bar, as well as each item in a drop-down or cascade menu.
• Capitalize the first letter of every word (except articles, conjunctions, and prepositions that are not at the beginning or end of a multi-word name).
• Avoid special formatting in individual menu items (like bold, underline, italics). All menu items should have the same text properties for ease in menu review.
• When the menu item will pop up a dialog box, indicate this by inserting ellipsis after the title, with no space.

 

Menu Appearance and Behavior

In PowerBuilder, the appearance and behavior of menu objects can be defined by selecting different settings on each menu object's property sheet, or dynamically assigning the setting in the script. Below are some guidelines to consider and the tab where the property can be set:

 

Tab	Property
General	Define MicroHelp
Shortcut	Define shortcut key Commonly used menu items should have unique shortcut keys. Generally, shortcut keys are not used in pop-up menus, since they are already a shortcut method of accessing menu items.
Style	Define if a menu object is enabled
Style	Define if a menu object is visible
Style	Define the menu object type
Style	Define if the menu object is to display as checked Independent settings: Behave like checkboxes. For example, the menu object View may have a group of items to select various bars to display: Toolbar, StatusBar, FormatBar. All (or none) of these can be checked, because they may be all be needed. Interdependent settings: Behave like radiobuttons. For example, the menu object View may have a group of items to choose the display of a document: Normal, Outline, PageLayout, MasterDoc. Only one of the items can be checked.
Toolbar and Picture	Define Toolbar and picture (Commonly used menu items should have a button on the toolbar)

 

Menu Types

Drop-down Menu

A drop-down menu sits on a menu bar and is made up of one or more menu item choices. When displayed, the menu items are arranged in one column, with any shortcuts to the right of an associated menu item. The grouping of menu items into a drop-down menu should be determined by common functionality. For example, the File menu is a common menu title for tasks that apply to a file (such as Open, Close, Save, and Print). Commonly used drop-down menus are File, Edit, View, Window, and Help.

 

Custom menu titles may be used for application specific operations, such as 'Transactions'; its menu items may be named 'Purchases', 'Redemptions', and 'Exchanges'.

 

Below is an example of a drop-down menu:

 

Cascade Menu

A cascade menu is a menu to the side of an item in a drop-down menu. Other common descriptions are submenu or child menu. The visual indicator of a cascade menu is a right-facing arrow to the right of the parent menu item.

 

Be economical in using cascading menus, as they add a level of complexity to navigation. They do, however, prevent the parent menu from becoming too cluttered. Generally, one level of cascading is recommended.

 

Below is an example of a cascade menu:

 

Pop-up Menu

Pop-up menus provide access to an object's functionality through a right-click action. This menu is displayed at the cursor's current location instead of requiring the user to move the mouse to a menu bar or toolbar. The items on this menu do not need to include all items of functionality, but instead, should be limited to those most commonly used.

 

When possible, avoid using a pop-up menu as the only method for accessing a particular action; however, these menu items do not have to be duplicates of menu items in a drop-down menu.

 

When ordering the menu items in a pop-up menu, the following general guidelines are suggested:

• Primary menu items first: Open, Save, Print.
• Specialized paste menu items: Cut, Copy, Paste.
• Other functional menu items.
• Properties menu item (when present) should be last.
• Groupings should be made with menu separators.

 

Below is an example of a pop-up menu: