Visual design and aesthetics affect user confidence in and comfort with your application. A polished and professional look without excess or oversimplification is not easy to attain. This chapter discusses these high-level, visual aspects of Java look and feel applications:
You can use the theme mechanism to control many of the fundamental attributes of the Java look and feel design, including colors and fonts. You might want to change the colors to match your corporate identity, or you might increase color contrast and font size to enable users with visual impairments to use your application. The theme mechanism enables you to specify alternative colors and fonts across an entire Java look and feel application.
The technical documentation for the class javax.swing.plaf.metal.DefaultMetalTheme is available at the Swing Connection web site here .
If you want to change the color theme of your application, be sure that your interface elements remain visually coherent. The Java look and feel uses a simple color model so that it can run on a variety of platforms and on devices capable of displaying various depths of color. Eight colors are defined for the interface:
Within the primary and secondary color groups in the default theme, there is a gradation from dark (primary 1 and secondary 1) to lighter (primary 2 and secondary 2) to lightest (primary 3 and secondary 3).
The following table summarizes the eight colors defined in the Java look and feel. It provides swatches and values representing each color in the default theme. It also gives details about the roles each color plays in basic drawing, three-dimensional effects, and text.
|Name||Basic Drawing||3D Effects||Text|
| Primary 1
|Active window borders||Shadows of selected items||System text (for example, labels)|
| Primary 2
|Highlighting and selection (for example, of menu titles and menu items); indication of keyboard focus||Shadows (color)|
| Primary 3
|Large colored areas (for example, the active title bar)||Text selection|
| Secondary 1
|Dark border for flush 3D style|
| Secondary 2
|Inactive window borders||Shadows; button mousedown||Dimmed text (for example, inactive menu items or labels)|
| Secondary 3
|Canvas color (that is, normal background color); inactive title bar|
|User text and control text (including items such as menu titles)|
|Highlights||Background for user text entry area|
Unless you are defining a reverse-video theme, maintain a dark-to-light gradation like the one in the default theme so that interface objects are properly rendered. To reproduce three-dimensional effects correctly, make your secondary 1 color darker than secondary 3 (the background color); make secondary 2 (used for highlights) lighter than the background color.
Redefinition of Colors
The simplest modification you can make to the color theme is to redefine the primary colors. For instance, you can substitute greens for the purple-blues used in the default theme, as shown in the following figure.
You can use the same value for more than one of the eight colors--for instance, a high-contrast theme might use only black, white, and grays. The following figure shows a theme that uses the same grays for primary 2 and secondary 2. White functions as primary 3 and secondary 3 as well as in its normal role.
As part of the theme mechanism and parallel to the color model, the Java look and feel provides a default font style model for a consistent look. You can use themes to redefine font typefaces, sizes, and styles in your application. The default Java look and feel theme defines four type styles: the control font, the system font, the user font, and the small font. The actual fonts used vary across platforms.
|Type Style||Default Theme||Uses|
|Control||12-point bold||Buttons, checkboxes, menu titles, and window titles|
|Small||10-point plain||Keyboard shortcuts in menus and tool tips|
|System||12-point plain||Tree views and tool tips|
|User||12-point plain||Text fields and tables|
To ensure consistency, ease of use, and visual appeal, use the supplied default fonts unless there is compelling reason for an application-wide change (such as higher readability). Use the theme mechanism if you do make modifications.
In the default theme, six methods are used to return references to the four type styles. The getControlTextFont, getMenuTextFont, and getWindowTitleFont methods return the control font; getSystemTextFont returns the system font; getUserTextFont returns the user font; and getSubTextFont returns the small font.
All fonts in the Java look and feel are defined in the default Java look and feel theme as Dialog, which maps to a platform-specific font.
This section describes standards for the capitalization of text in the Java look and feel. Text is an important design element and appears throughout your application in such components as command buttons, checkboxes, radio buttons, alert box messages, and labels for groups of interface elements. Strive to be concise and consistent with language.
For all text that appears in the interface elements of your application, follow one of two capitalization conventions: headline capitalization or sentence capitalization. Use headline capitalization for most names, titles, labels, and short text. Use sentence capitalization for lengthy text messages.
Do not capitalize words automatically. You might encounter situations in your interface when capitalization is not appropriate, as in window titles for documents users have named without using capitalization.
Place all text in resource bundles so that localization experts don't have to change your application's source code to accommodate translation.
Most items in your application interface should use headline capitalization, which is the style traditionally used for book titles (and the section titles in this book). Capitalize every word except articles ("a," "an," and "the"), coordinating conjunctions (for example, "and," "or," "but," "so," "yet," and "nor"), and prepositions with fewer than four letters (like "in"). The first and last words are always capitalized, regardless of what they are.
When text is in the form of full sentences, capitalize only the first word of each sentence (unless the text contains proper nouns, proper adjectives, or acronyms that are always capitalized). Avoid the use of long phrases that are not full sentences.
Give careful consideration to the layout of components in your windows and dialog boxes. A clear and consistent layout streamlines the way users move through an application and helps them utilize its features efficiently. The best designs are aesthetically pleasing and easy to understand. They orient components in the direction in which people read them, and they group together logically related components.
When you lay out your components, remember that users might use the mouse, keyboard, or an assistive technology to navigate through them; therefore, use a logical order (for instance, place the most important elements within a dialog box first in reading order).
Use multiples of 6 pixels for perceived spacing between components. If the measurement involves a component edge with a white border, subtract 1 pixel to arrive at the actual measurement between components (because the white border on active components is less visually significant than the dark border). In these cases, you should specify the actual measurement as 1 pixel less--that is, 5 pixels between components within a group and 11 pixels between groups of components.
Note - Exceptions to these spacing guidelines are noted in the relevant component chapters in Part III. For instance, the perceived spacing between toolbar buttons is 3 pixels, whereas the actual spacing is 2 pixels.
In the following figure, a perceived 6-pixel vertical space is actually 5 pixels between checkbox components. The figure also shows how the perceived spacing between inactive objects is preserved. Note that the dimensions of inactive components are the same as active objects, although the white border of active objects is replaced by an invisible 1-pixel border on the bottom and right side of inactive objects.
Insert 5 pixels (6 minus 1) between closely related items such as grouped checkboxes. Insert 11 pixels (12 minus 1) for greater separation between sets of components (such as between a group of radio buttons and a group of checkboxes). Insert 12 pixels between items that don't have the flush 3D border highlight (for instance, text labels, titled borders, and padding at the top and left edges of a pane).
The most effective method of laying out user interface elements is to use a design grid with blank space to set apart logically related sets of components. A grid divides the available space into areas that can help you to arrange and align components in a pleasing layout. Grids make it easy for users to see the logical sequence of tasks and to understand the relationships between sets of components.
The following illustration shows a sample grid that provides standard margins and divides the remaining space into five columns. Horizontal divisions aid in scanning and interpreting the components and sets of related options.
Use the appropriate layout manager to control horizontal space for the variable width of internationalized text strings.
You can use the number and width of components and their associated labels to determine the number of columns in a grid. At the beginning of the design process, vertical divisions are more difficult to set because they depend on the depth of components and sets of components, which are not yet placed.
Developing a grid is an ongoing process. If you know how much space is available, you can start working with the components to determine the most effective use of space. A grid can also help you to determine how much space to allocate to a given set of components. If you can define a grid that will work for a number of layouts, your application will have a more consistent appearance.
For spacing between rows and columns, use multiples of 6 pixels minus 1, to allow for the flush 3D border (see Between-Component Padding and Spacing Guidelines).
Layout of a Simple Dialog Box
First, determine the functional requirements. Then add the components according to the Java look and feel placement and spacing standards. For instance, you must right-align command buttons in dialog boxes at the bottom and separate them vertically from the rest of the components by 17 pixels.
In the following illustration, the most important option--the text field for the search string--has been placed first. Related options are aligned with it along one of the column guides. Spacing between components and groups of components follows the Java look and feel standards.
Use titled borders sparingly: they are best when you must emphasize one group of components or separate one group of components from other components in the same window. Do not use multiple rows and columns of titled borders; they can be distracting and more confusing than simply grouping the elements with a design grid.
Insert 12 pixels between the edges of the panel and the titled border. Insert 12 pixels between the bottom of the title and the top of the first label (as well as between the label and the components) in the panel. Insert 11 pixels between component groups and between the bottom of the last component and the lower border.
A titled border can be created as follows:
myPanel.setBorder(new TitledBorder(new LineBorder
"<< Your Text Here >>"));
Text is an important design element in your layouts. The way you align and lay out text is vital to the appearance and ease of use of your application. The most significant layout issues with respect to text are label orientation and alignment.
Use language that is clear, consistent, and concise throughout your application text. Moreover, ensure that the wording of your labels, component text, and instructions is legible and grammatically correct.
You indicate a label's association with a component when you specify its relative position. Hence, consistency and clarity are essential. In the following figure, the label appears before and at the top of the list in reading order.
In general, orient labels before the component to which they refer, in reading order for the current locale. For instance, in the U.S. locale, place labels above or to the left of the component. Positioning to the left is preferable, since it allows for separation of text and components into discrete columns. This practice helps users read and understand the options.
Between components, alignment of multiple labels becomes an issue. Aligning labels to a left margin can make them easier to scan and read. It also helps to give visual structure to a block of components, particularly if there is no immediate border (such as a window frame) surrounding them. If labels vary greatly in length, the use of right alignment can make it easier to determine the associated component; however, this practice also introduces large areas of negative space, which can be unattractive. The use of concise wording in labels can help to alleviate such difficulties. For an example of right-aligned labels in an applet, see Figure 12.
Avoid the use of titled borders as organizing elements. They add clutter reduce readability, and compound alignment problems by introducing the title as an additional text label. Instead, use design grids and careful alignment of labels to give visual structure to your layouts.
To accommodate differences in languages, decide on the behavior you want to occur during resize operations. Be specific about layout, spacing, and ordering. Use the layout managers to accommodate these differences.
Since the length and height of translated text varies, use layout managers properly to allow for differences in labels.
If used appropriately, animation has great potential to be a useful and attractive part of a user interface. You can use animation to let users know that the system is busy with a task or to draw attention to important events.
Screen readers, which are used by people with visual impairments, do not recognize images that move. Use the accessibleDescription field to describe what is represented by the animation.
Animation is especially useful when you want to communicate that the system is busy. Progress indication shows users the state of an operation; delay indication lets users know that an application or a part of an application is not available until an operation is done.
For example, an application's pointer might change to the wait pointer after the user selects a file and before the file opens. For information on the JFC-supplied pointer shapes available in the Java look and feel, see Table 7.
If you know the estimated length of an operation (for example, if the user is copying files) or the number of operations, use the Java look and feel progress bar. This bar fills from left to right as the operation progresses, as shown in the following figure.
For more on progress bars, see Progress Bars.
Another way to indicate delay is to use animated pointers, which are supported by the Java 2 platform. Instead of just changing to a wait pointer, you can go one step further by animating the pointer image while the system is busy.
Animation is useful when you want to call attention to events. For instance, in a mail application, you might use animation to indicate that new mail has arrived. Another example is a monitoring system that uses animation to alert users when failures occur.
When creating system status animation, consider the target users and their environment. If the animation needs to be visible from across the room, a bolder animation coupled with sound might be just the right thing. On the other hand, that same animation viewed by a user sitting at the workstation would be annoying.
When feasible, let users configure system status animation, so they can adapt their systems to the environment.
||Previous | Next | Contents | Index | Search|
Copyright 1999 Sun Microsystems, Inc. All Rights Reserved.