| Java >
Guidelines Home Page > Java Look and Feel Design Guidelines >
Part II: Fundamental Java Application Design >
5: Application Graphics
In a cross-platform delivery environment, you need to ensure that the visual components of your application reproduce legibly and aesthetically on all your target systems. You do not have control over which platforms will be used to run your software or what display capabilities users might have.
Online graphics consist of the visual representations of JFC components in the Java look and feel, which are drawn for you by the toolkit, and application graphics such as icons and splash screens, which you supply.
Use themes to control the colors of Java look and feel components--for instance, to provide support for display devices with minimal available colors (fewer than 16 colors).
You need to supply icons, button graphics, pictures and logos for splash screens and About boxes. Since these graphics might be displayed on a number of different platforms and configurations, you must develop a strategy for ensuring a high quality of appearance. In addition, you need to ensure that your graphics are meaningful to color-blind users. Strategies for addressing color blindness are similar to those used for handling limited display colors.
Use color only as a secondary means of representing important information. Make use of other characteristics (shape, texture, size, or intensity contrast) that do not require color vision or a color monitor.
The number of colors available on a system is determined by the bit depth, which is the number of bits of information used to represent a single pixel on the monitor. The lowest number of bits used for modern desktop color monitors is usually 8 bits (256 colors); 16 bits provide for thousands of colors (65,536, to be exact); and 24 bits, common on newer systems, provide for millions of colors (16,777,216). The specific colors available on a system are determined by the way in which the target platform allocates colors. Available colors might differ from application to application.
Designers sometimes use predefined color palettes when producing images. For example, some web designers work within a set of 216 "web-safe" colors. These colors reproduce in many web browsers without dithering (as long as the system is capable of displaying at least 256 colors). Dithering occurs when a system or application attempts to simulate an unavailable color by using a pattern of two or more colors from the system palette. The main drawback of dithering is the striped (moiré) patterns that can result.
Outside web browsers, available colors are not so predictable. Individual platforms have different standard colors or deal with palettes in a dynamic way. The web-safe colors might dither when running in a standalone application, or even in an applet within a browser that usually does not dither these colors. Since the colors available to a Java application can differ each time it is run, especially across platforms, you cannot always avoid dithering in your images.
Identify and understand the way that your target platforms handle colors at different bit depths. To achieve your desired effect, test your graphics on all target platforms at depths of 8 bits (that is, 256 colors).
GIF is the common format for application graphics in the Java look and feel. GIF files tend to be smaller on disk and in memory than JPEG files. A GIF file includes a color table (or palette) of up to 256 colors. The number of colors in the table and the complexity of the image are two factors that affect the size of the graphic file.
On 8-bit systems, some of the colors specified in a GIF file will be unavailable if they are not part of the system's current color palette. These unavailable colors will be dithered by the system. On 16-bit and 24-bit systems, more colors are available and different sets of colors can be used in different GIF files. Each GIF image, however, is still restricted to a set of 256 colors.
JPEG graphics are generally better suited for photographs than for the more symbolic style of icons, button graphics, and corporate type and logos. JPEG graphics use a compression algorithm that yields varying image quality depending on the compression setting, whereas GIF graphics use lossless compression that preserves the appearance of the original 8-bit image.
At monitor depths greater than 8 bits, most concerns about how any particular color reproduces become less significant. Any system capable of displaying thousands (16 bits) or millions (24 bits) of colors can find a color very close to, or exactly the same as, each value defined in a given image. Newer systems typically display a minimum of thousands of colors. Since each system renders colors slightly differently, different monitors and different platforms might display the same color differently, however. For instance, a given color in one GIF file might look different to the eye from one system to another.
Many older monitors or systems still display only 256 colors. For users with these systems, it might be advantageous to use colors known to exist in the system palette of the target platforms. Most platforms include a small set of "reserved" colors that are always available. Unfortunately, these reserved colors are often not useful for visual design purposes or for interface elements because they are highly saturated (the overpowering hues one might expect to find in a basic box of crayons). Furthermore, there is little overlap between the reserved color sets of different platforms, so reserved colors are not guaranteed to reproduce without dithering across platforms.
Select colors that do not overwhelm the content of your application or distract users from their tasks. Stay away from saturated hues. For the sake of visual appeal and ease of use, choose groups of muted tones for your interface elements.
Since there is no lowest-common-denominator solution for choosing common colors across platforms (or even colors that are guaranteed to reproduce on a single platform), some of the colors in your application graphics will dither when running in 8-bit color. The best strategy is to design images that dither gracefully, as described in the following section.
Images with fine color detail often reproduce better on 8-bit systems than those images that are mapped to a predefined palette (such as the web-safe palette) and use large areas of solid colors. Dithering is less noticeable in small areas, and, for isolated pixels of a given color, dithering simply becomes color substitution. Often colors in the system palette can provide a fair-to-good match with those specified in a GIF file. The overall effect of color substitution in small areas can be preferable to the dithering patterns produced for single colors, or to the limited number of colors resulting from pre-mapping to a given color palette.
There are no absolutely safe cross-platform colors. Areas of solid color often dither, producing distracting patterns. One effective way to avoid coarse dithering patterns is to "pre-dither" your artwork intentionally. This approach minimizes obvious patterned dithering on 8-bit systems while still permitting very pleasing effects on systems capable of displaying more than 256 colors.Figure 43 Adding a Pattern to Avoid Coarse Dithering Patterns
The plain graphic in the preceding table, which uses a large area of a single web-safe color, dithers badly on Microsoft Windows and CDE. A gradient effect is added to the original graphic to add some visual interest; this produces a banding effect on Mac OS. Adding the dithered pattern along with the gradient produces good results on all three platforms with 8-bit color. In 16-bit and 24-bit color, the graphic reproduction is very close to, or exactly the same as, the originals.
|Java Look and Feel Design Guidelines, second edition.
Copyright 2001. Sun Microsystems, Inc. All Rights Reserved.