This chapter discusses designing user interfaces and includes:
Developing a menu structure
Creating windows
Designing controls within windows
Designing for user interaction
Developing an object-oriented interface
The menu structure uses a standard set of menu-bar items that leads to predefined pull-down menus. Choices in pull-down menus are categorized by the type of action they represent.
For more information, see the Menu Guidelines reference page.
The window menu provides choices that let the user change the size and location of the window and gain access to functions and settings specific to the window manager or workspace.
For more information, see the Window Menu reference page.
Table 10-1 describes the standard menu-bar items.
Table 10-1. Description of Menu-Bar Items
| Menu | Description |
|---|---|
| File | Contains choices that let the user identify a file to be used by the application or perform actions with the data it contains or represents. For example, the Open choice allows a user to choose a file to be invoked by the application; the Print choice allows the user to print the data the application contains. Generally, actions included in this menu are those that display, transfer, or store the information associated with the application. |
| Edit | Contains choices typically used when editing, such as Cut and Paste. |
| View | Contains choices that affect the arrangement and presentation of the view in the window such as Sort and Change View. |
| Options | Contains choices that enable the user to customize an application. |
| Help | Contains choices that let a user refer to the online help available for the various parts of the interface. It can also provide access to an online tutorial for a product or operating system. |
The following sections discuss:
Choosing the parts of a window
Displaying secondary windows in the correct location
Choosing between modeless and modal secondary windows
Conserving screen space
The following principles address choosing the parts of a window:
Provide a status area that displays the status of a running process so that the user can have that information in the window. For example, a window that displays a printer queue might have a status area to show when the queue is ready, stopped, or processing jobs.
Provide an information area where the user can view general information about the window or elements within the window. Examples of what the information area could display are:
A brief description of the element that the cursor is on, for example, descriptions of the menu items as the user navigates through them
The position of the cursor, for example, Row 2, Column 3 when in a text-entry field
Messages that the user might not want in an information message, for example, No misspelled words found
For more information, see the Information and Message Areas (Area) and Status Area (Area) reference pages.
Display secondary windows in the best possible location for the user. In some cases, this means that you need to let the user specify a default location for a particular secondary window, for example, a Find dialog window. The following principles address where to place a secondary window:
If the user does not need to see the information in the existing window, display the secondary window centered on top of the existing window. Do not cover up the title bar or menu bar.
This keeps the windows from spreading unnecessarily over the entire screen. The user should be able to see the context from which the secondary window came and also to use the menu bar to access other secondary windows if needed.
If the user needs to see the information in the primary window, display the secondary window so that it does not cover the existing window.
In many cases, you need to position the secondary window so that it does not cover any part of the primary window. You can calculate the best location by beginning to the right of the primary window and moving the secondary window in a clockwise direction around the existing window until you find enough available screen space to display the secondary window. Do not cover up the title bar of the primary window. The user should be able to see the context from which the secondary window came.
If the secondary window contains information about a particular element within a window, display the secondary window so that it does not cover the following:
Any portion of the element
Any portion of an important related element, such as a label for the element that the secondary window is related to
The title bar or menu bar of the window that contains the particular element
The user should be able to see the context from which the secondary window came.
For more information, see the Secondary Window reference page.
Modeless secondary windows let the user continue to work in the existing window from which the secondary window was opened. Modeless secondary windows are more flexible than modal windows because users have greater control in the interface when they can interact with many windows.
Modal secondary windows prevent the user from continuing to work in the existing window from which the secondary window was opened. Use modal windows only when absolutely necessary, for example when a communications program is downloading a file that cannot be modified until the download has completed. Even though users cannot interact with elements within the existing window, they should still be able to interact with the existing window itself.
As an alternative to providing modal secondary windows, use a modeless secondary window and make some of the choices in the primary window unavailable.
For more information, see the Secondary Window reference page.
The following principles address conserving screen space:
Leave between one–eighth and one–half inch between the window contents and the window border.
Plan grids for the known information in the windows.
A grid allows you to create visually appealing windows that accurately reflect the intended hierarchy. You can design a grid system to accommodate any size, shape, or quantity of information.
Grids promote consistency, allowing the user to anticipate placement of information from window to window.
Use group boxes or separators to separate groups of related controls. For example, you can use group boxes or separators to show that several radio buttons belong together in one group.
Use group boxes judiciously. Although using group boxes effectively groups related controls together, group boxes provide visual clutter that can distract the user, especially when you use group boxes within other group boxes. Using separators and the design layout guidelines in this book can help minimize the use of group boxes.
Use standard typography.
Coherent typography presents a more cohesive, organized presentation of the information and makes it easier for the user to read. For example, use a bold font for headings and a light font for labels.
Line up similar elements and separate groups by placing a single colored line under the heading or by increasing the space between groups. Use indents to show sublevel information rather than nested group boxes. This saves screen space and keeps the windows organized.
Design positive and negative space within the interface.
In every composition there is positive and negative space. Positive space is the space taken up by elements such as icons and controls. Negative space is the space around the positive space. Software designers often think of this negative space as ‘extra’ space. Although organizational techniques such as grid systems can help you compose a design that uses space economically, do not completely eliminate negative space because this space creates visual ‘breathing room’ and enhances readability.
The following sections discuss:
Aligning controls
Sizing controls
Grouping controls
Placing and sizing push buttons
Providing dialog and action choices
Designing icons
Using ellipses
Creating new controls
When related controls are displayed next to one another within a window, align them into rows and columns. The following principles address aligning controls:
Align controls horizontally with the baseline of the text or graphic.
Align controls vertically with the most distinguishing features of the control. For example, align radio buttons and check boxes such that the radio button graphic or check box graphic is in alignment. To align text, use the left edge of the text in each control if the text is left-justified.
Right align the labels with the left edge of the text-entry fields in cases where there are several text-entry fields. This makes it easier for the user to see which label goes with which field.
For more information, see the Label and Text-Entry Field (Control) reference pages.
The following principles address sizing controls:
If the user can change the size of a window, size any controls that can be scrolled so that more of the control's contents are visible. Examples of controls that support scrolling are text-entry fields, list boxes, and containers.
Size other controls when the user would expect the size to change or when it would be useful for accomplishing a particular task. For example, users might expect sliders to be sized larger when a window is made larger because it lets them set slider values more accurately. When sizing controls, remember to keep the controls' sizes in proportion to text size.
There should be a minimum size for each control if controls are sized in a window. The minimum size should not be so small that it is useless to the user. When the window is sized smaller than the minimum control size, the control will be clipped. If clipping makes the application unusable, the window can display a message stating that the user should increase the window display size.
When displaying graphics, bit maps, or icons, do not automatically resize the image so that the aspect ratio is incorrect. This results in unpredictable and often unreadable images.
Group and label controls within a window appropriately. Examples of controls that belong in a group are:
Related radio buttons
Push buttons at the bottom of a window
Check boxes that have a common purpose
When grouping controls, separate individual groups from one another in the window. Some ways to separate the groups are to use:
Blank window space
Separator lines
Group boxes
The following principles address placing and sizing push buttons:
Place push buttons that affect the entire window at the bottom of the window horizontally.
Align push buttons on the left side of the window when the window is much wider than the area occupied by the push buttons. Place the push buttons so that there is the same amount of space between each push button.
Align push buttons on both sides of the window (with equal amounts of space between each button) when the window is about the same size as the area occupied by the push buttons.
In rare circumstances, placing all the buttons on one horizontal line causes the window to be wider than necessary to display all the elements in the window. In extreme cases, provide the user with two rows of buttons instead of making the window wider than is necessary.
See the Push Button (Predefined) reference page for the correct ordering of the push buttons from left to right.
Place push buttons that affect a particular control or group of controls within the window to the right of the control or group of controls. Align the push buttons vertically. If there are too many buttons to fit beside the affected controls, place the push buttons horizontally below the controls and visually separate the controls and their associated push buttons from the other controls in the window.
Design all push buttons that are in a horizontal row to have the same height and all push buttons that are in a vertical column to have the same width.
Design push buttons to be consistent in size, whenever possible. Consider the longest label necessary and make the buttons conform to that size. If it is not possible to make all of the push buttons the same size, size the push buttons relative to the length of their labels.
For more information, see the Push Button (Control) and Push Button (Predefined) reference pages.
Provide a dialog choice when the user must supply additional parameters through a secondary window before a process begins. Provide an action choice when the user's action begins immediately after the user activates the choice.
For example, when a user chooses the Print choice, it can be either a dialog choice or an action choice. A dialog choice asks for additional information such as page orientation, number of copies, and printer name. An action choice prints the document immediately, possibly displaying a secondary window to show an in-progress message.
Icons are a prominent visual aspect of the interface and are what many people think of when they think of a graphical user interface. When you design your icon set, be aware that users need to work within a larger set — the operating environment. Do not consider icons as ‘advertisements ’ for the interface. Design icons as functional, integrated parts of the visual hierarchy of the interface.
The following principles address icon design:
Design your icons to work together as a family by using the same style for each icon and by conveying a consistent language of images throughout your icons.
A family of icons builds on knowledge the user acquires when encountering different icons in the set.
Do not design any icon that stands out from the rest of the icons, unless it is necessary for user understanding.
An icon stands out if its use of color, style, or shape are different than those around it. This would be considered an anomaly and should be employed only where there is a genuine necessity. Color and font resources should never be hard coded.
Limit the number of details shown in the icon.
For most interfaces, there are between 70 and 90 pixels in which to display icon information. Because of the limited space, the amount of information that you can convey is also limited. Any extraneous details detract from your intended message.
Design icons to be clear and readily understood.
Strive to create icons that are easily recognized and memorable. One way to achieve this is to base your designs on metaphors from the user's environment and to create icons that are consistent with those metaphors.
Simplify and refine the icon design to reduce clutter or visual noise in the overall interface image.
Visual noise is annoying and distracts the user from important visual information. If visual noise occurs in the interface, the user must sift through the noise to find information. It is difficult to use an icon to convey a complex message because icons are small and are often created from simple shapes such as squares or rectangles. To convey your basic message clearly, limit details and simplify information when possible.
Incorporate multicultural considerations in your icon design. For more information about international guidelines, see Chapter 11, “International Design Guidelines”.
The following principles address when to use an ellipsis (...) after a choice label.
A choice should have an ellipsis when the choice will not be carried out immediately and a secondary window will be presented to the user to further clarify the choice before the process begins.
A choice should not have an ellipsis when the choice is carried out immediately after the user activates it, regardless of whether or not a secondary window is opened. Never display an ellipsis on a choice when activating it will not display a secondary window.
User interactions take many forms and the interface often provides feedback or cues as users select or manipulate interface elements. The following sections discuss feedback and cues. See also Chapter 9, “Visual Presentation Principles” for more information on presentation principles.
Consider user interactions as part of an ongoing dialog between the user and the interface. Often, when people converse, the listener provides feedback to the user to indicate that the message is being received. Feedback is the application's return of a dialog (or other cue) to the user's input.
As in dialogs between people, users appreciate feedback in dialogs with the interface to help them understand what information the system has received. Therefore, design your interface to provide feedback that is subtle but consistent.
Also, provide transitions to help users follow the results of their interactions. Think of transitions as providing a ‘storytelling’ aspect in the interface. In other words, use transitions to help users understand the flow from one step to the next. Transitions should be noticeable but subtle so that they are helpful to less experienced users and do not annoy experienced users.
An example of a subtle transition is graduated boxes (sometimes called zoom boxes or nested boxes) that appear when the user closes a window. They tell the user that the view has been closed and the data put away. If the window simply disappears, the user might think that the information had been deleted.
As with static elements, all the visual variables can play a role in communicating interaction cues and transitions, including size, shape, movement, and color. However, interactive cues and transitions can incorporate an additional important visual interface concept: movement. Users react instinctively to movement. For example, when a printer icon displays paper ejecting from the printer, the user knows that the print job was successfully spooled. Therefore, movement is one of the most powerful visual variables. To maintain that potency, use movement sparingly and only where absolutely necessary.
Unlike feedback, a cue may alert the user unexpectedly, for example, when a printer jam occurs.
Because graphical user interfaces are still mainly visual, visual cues are numerous. When designing a new visual cue or set of visual cues, avoid conflicts with preexisting cues. As with any type of cue, efficiency of a visual cue depends on its timing. Carefully choose when to display or remove a cue in relation to user action. You can intensify the effect of certain visual cues by combining them with appropriate audible cues.
For example, if a printer runs out of paper during printing, the audible cue attracts user attention while the blinking sheet of paper on the printer icon informs the user of the nature of the problem. The interface can indicate a paper jam by another visual cue, such as the paper on the printer icon changing color or shade.
For more information on cues, refer to Chapter 4, “Audible and Visual Interface Cues”.
The concept of basing an interface on objects is a step toward the goal of a user-centered design. Object-oriented interface design employs real-world metaphors to help users understand and use the functions in your application. The types of objects and the interactions required depend on the tasks to be performed. For example, a highway construction worker may need a map object with a topographical view; a secretary is more likely to need a telephone directory.
While some objects are specific to an application or task, other objects have a wider range. For example, the construction worker and the secretary may both need a calendar object. In an object-oriented environment, various objects can work together. Users can choose the objects they need and group those that are customized for the tasks they want to perform.
You can classify objects according to the functions they perform. The Motif user interface classifies objects as follows:
Container objects
Data objects
Device objects
Composite objects
Many objects are capable of containing other objects. Before classifying an object as a container, take the user's perspective and determine what its primary use will be. A wastebasket object can contain other objects. Its containment behavior, however, is both temporary and secondary to its main purpose of disposing unwanted objects and data. The user is more likely to regard it as a device than a container.
A folder, on the other hand, does little to its contents other than contain them. A folder may have views that allow a user to see the contents, but the folder does not transform the contents. Therefore, a folder is generally a container.
When an object is dragged to a container that can hold it, the default result of the drop operation should be to move the source object into the container, removing it from its former location.
You can think of most objects as containing data. A data object is one that exists to allow direct access to information, either to be displayed or edited. A folder usually contains data in the form of its objects but its main purpose is containment. A note object, however, is meant to convey information and would therefore be a data object.
Device objects provide an interaction path between a user's objects (or data) and the functions that the user may want to perform on those elements. For example, a printer object can allow the user to print without menus, using only direct manipulation techniques such as dragging and dropping an object to the printer.
The default behavior for a device object should usually be to place a copy of the source object into the device or into a queue for the device, prompt the user for additional information, perform the specified operation on the copy of the source, and, unless the device is a drive, delete the copy. Exceptions include devices such as wastebaskets and shredders, which are intended to allow the user to discard data or objects, and which should allow the source to be moved instead of copied.
A composite object is an object that is made up of other objects. It can easily be decomposed; that is, its control objects can be moved, copied, or deleted. It is distinguished from a simple object, which cannot be decomposed and is not made up of other objects. A composite object is composed of simple objects.
Use the following suggestions and your understanding of objects along with the user's tasks, expectations, and needs to decide when to use a simple or composite object:
Use a simple object when:
The user does not often need to decompose the object into its constituent parts.
The number of composed views necessary to support a task is not so large as to be unmanageable. Six to eight views is a recommended maximum. For more information, see the View reference page.
Each composed view will be perceived as a sensible view derived from the function and nature of the object.
Each view presents the object's information as a whole or as filtered subsets.
The user perceives the object as a single indivisible object, and not as a container or collection of many objects (for example, a report object rather than an investment portfolio object).
Use a composite or container object when:
Information elements are not clearly related when presented to the user.
There are clearly defined boundaries between the information elements that suggest separate logical simple objects.
The information elements are not derivations of a simple object.
The application relies heavily on containment or collection behavior; for example, the application refers to a folder that contains many different objects.
The user will need to decompose the object and access (or manipulate) individual objects or the composite (or container) object.
The following principles address the differences between application-oriented and object-oriented interface design.
The main element of an application-oriented interface is the application itself. The user first starts the application, then calls files into the application to accomplish a task. The user must be aware of which application is running at any given time, which type of files the application supports, and how the operating system organizes data into files, directories, and storage media.
The tasks performed in an application-oriented environment generally have a rigid stricture; the user must complete steps in a predefined order from start to finish before going to another task. An application-oriented environment is best suited for users who do a small number of tasks repetitively. The application-oriented menu structure supports this type of interface.
The application-oriented menu structure uses a standard set of menu-bar items that contain predefined pull-down menus. Choices in the pull-down menus are categorized by the type of action they represent as shown in Table 10-2.
Table 10-2. Application-Oriented Pull-Down Menus
| Menu | Description |
|---|---|
| File | Contains choices that let the user call a file into the application or perform a set of actions on the file (or parts of it). |
| Selected | Contains choices that are determined by the scope of the actions they represent. Place choices that apply to selected objects or data in the view, but are not typical editing choices, in this menu. |
| Edit | Contains choices typically used when editing, such as Cut and Paste. |
| View | Contains choices that affect the arrangement and presentation of the view in the window, such as Sort and Change View. |
| Help | Contains choices that let the user refer to online help available for the various parts of the application. |
Object-oriented interfaces focus on the user's objects. The user decides what object to work with, then chooses actions to apply to the object, either by using menus or by direct manipulation. The user is not required to know what application is being used to work with the objects at any given time.
In an object-oriented environment, the user can decide how to structure tasks. In most cases, the user can choose the steps to be performed. The objects that need to be supplied should work together and with objects supplied by other applications. The object-oriented menu structure supports this type of interface.
The object-oriented menu structure sorts choices into various menus, based on the objects or elements to which the choices apply. To satisfy the user's expectations and to make choices easy to find, be aware of the scope of each choice and place the choice in the appropriate menu. Table 10-3 describes standard object-oriented menu choices.
Table 10-3. Object-Oriented Pull-Down Menus
| Menu | Description |
|---|---|
| Object | Contains choices that affect the object whose view is in the window in which the menu appears. The Object menu also lets the user open additional windows that contain other views of the object. The same set of choices should also be available from the object's pop-up menu. |
| View | Contains choices that affect the way the object is presented in the current view and that let the user switch to a different view of the object within the same window. This menu allows the user to customize the view by sorting, filtering, or changing the format of its contents, or by changing the presentation of the menu-bar item. |
| Selected | Contains choices that affect the objects or data that are currently selected in the window or that affect the selection state of the contained objects. The contents of the Selected menu must change dynamically to reflect those choices that are appropriate to all members of the selected set. |
| Help | Contains choices that let the user refer to online help for various parts of the application. |
In an object-oriented user interface, applications no longer become the primary interface to the user. Instead, users work directly with objects, organizing and classifying them to suit their tasks. Views replace applications as the means of accessing or modifying information. For example, a newly installed spreadsheet processor would be accessible as a new view for every existing spreadsheet object.
There are three types of views: composed view, contents view, and properties view.
A composed view shows an object's data in presentation (or final output) form. For example, a composed view for a word-processor document shows the formatted output as seen on a printer or previewer. Composed views usually apply to data objects.
A contents view shows the contents of an object. For example, a contents view for a word-processor document shows the list of files that make it up. Contents views usually apply to container objects, such as in folders.
You can display contents views with various interpretations, including iconified views and detailed views. Do not be overly concerned about which category a particular view falls into. Instead, create views that convey information in a form that is meaningful to users.
A properties view displays information about the characteristics or attributes of an object and optionally provides a way for the user to change them. For example, in a properties view for an object such as a document, the user could change the font, type size, or color of the document. A properties view should be provided for every type of object.