# Visual Design

Visual design is not just about making your application look pretty. Good visual design is about communication. A well-designed application will make it easy for the user to understand the information that is being presented, and show them clearly how they can interact with that information. If you can achieve all that, your application will look good to the user, even if it doesn't have any fancy graphics or spinning logos!

## Color

Color is a good tool for communicating information in a user interface. For example, it can be used to:

- strengthen a desktop's look and feel by enhancing a theme

- accent a dynamic alert in a system management application

- emphasize an element in a long list to expedite scanning

- add aesthetically pleasing details to an icon

However, color should always be regarded as a useful addition to your design, not as a necessity. Never depend upon colors alone to display important information, and keep in mind that if colors cannot be perceived correctly (for example, the user has an 8-bit system, or is color-blind), your application should still be usable.

### Palette

A 32-color palette has been developed for the GNOME desktop. The palette may be downloaded from http://developer.gnome.org/projects/gup/images/ximian-palette. To use it in The GIMP, save it to your `~/.gimp_1.2/palettes` folder, and restart The GIMP. A single, consistently-used palette helps give a unified look and feel to the desktop while minimizing visual distractions. If you need a color that is darker or lighter than the colors in this basic palette (e.g., for anti-aliasing), choose a color that is closest to the hue you need, then darken or lighten as required.

#### The basic GNOME 32-color palette

The basic GNOME 32-color palette

### RGB and hexadecimal values for the basic palette

Color | Description | RGB | Hex | Color | Description | RGB | Hex
| Basic 3D Hilight | 234 232 227 | #EAE8E3 |  | Basic 3D Medium | 186 181 171 | #BAB5AB
| Basic 3D Dark | 128 125 116 | #807D74 |  | 3D Shadow | 86 82 72 | #565248
| Green Hilight | 197 210 200 | #C5D2C8 |  | Green Medium | 131 166 127 | #83A67F
| Green Dark | 93 117 85 | #5D7555 |  | Green Shadow | 68 86 50 | #445632
| Red Hilight | 224 182 175 | #E0B6AF |  | Red Medium | 193 102 90 | #C1665A
| Red Dark | 136 70 49 | #884631 |  | Red Shadow | 102 56 34 | #663822
| Purple Hilight | 173 167 200 | #ADA7C8 |  | Purple Medium | 136 127 163 | #887FA3
| Purple Dark | 98 91 129 | #625B81 |  | Purple Shadow | 73 64 102 | #494066
| Blue Hilight | 157 184 210 | #9DB8D2 |  | Blue Medium | 117 144 174 | #7590AE
| Blue Dark | 75 105 131 | #4B6983 |  | Blue Shadow | 49 78 108 | #314E6C
| Face Skin Hilight | 239 224 205 | #EFE0CD |  | Face Skin Medium | 224 195 158 | #E0C39E
| Face Skin Dark | 179 145 105 | #B39169 |  | Face Skin Shadow | 130 102 71 | #826647
| Accent Red | 223 66 30 | #DF421E |  | Accent Red Dark | 153 0 0 | #990000
| Accent Yellow | 238 214 128 | #EED680 |  | Accent Yellow Dark | 209 148 12 | #D1940C
| Accent Green | 70 160 70 | #46A046 |  | Accent Green Dark | 38 199 38 | #267726
| White | 255 255 255 | #ffffff |  | Black | 0 0 0 | #000000

### Hue, Brightness, Contrast

Users with vision disorders, such as color-blindness or low vision, require alternatives to default settings. A good user interface anticipates these needs by providing customizable preferences and support for accessible themes. Even better is an application that is already configured with carefully-chosen color and contrast defaults.

An estimated 11% of the world population has some sort of color-blindness. Those affected typically have trouble distinguishing between certain hues such as red and green (deuteranopia or protanopia), or blue and yellow (tritanopia). Therefore it is necessary to allow the user to customize colors in any part of your application that conveys important information. This means that your application must effectively convey information using just the colors from any theme that the user chooses.

A useful tool for reviewing information about color-blindness and checking legibility of images for color-blind users is Vischeck, an online tool that simulates the way an image or a website might appear to a user who has deuteranopia, protanopia, or tritanopia.

#### How the earth looks to a user with normal color vision (left), deuteranopia (middle), and tritanopia (right). (Images from http://www.vischeck.com).

Photo of earth as a normally-sighted user would see it | Photo of earth as a user with red-green color-blindness would see it | Photo of earth as a user with blue-yellow color-blindness would see it

Other users have more problems with contrast levels rather than hue on their screen. Some users require a high level of contrast between background and foreground colors, such as black on white, white on black, or some other high-contrast combination. Others can experience discomfort unless they use low-contrast settings, such as gray text on a lighter gray background.

You can meet these needs by ensuring your application supports the accessible GNOME themes (found in the gnome-themes module in cvs), which include high and low contrast themes, and large print themes. This means you must supply default and large sizes of high-, low- and regular-contrast icon sets with your application.

### Guidelines

- Use the GNOME color palette. If you need a darker or lighter shade, start from one of the colors from the palette and darken or lighten as needed.

- Do not use color as the only means to distinguish items of information. All such information should be provided by at least one other method, such as shape, position or textual description.

- Ensure your application is not dependent on a particular theme. Test it with different themes, especially high and low contrast accessibility themes, which use fewer colors, to ensure your application respects the settings. For example, all text should appear in the foreground color against the background color specified in the chosen theme.

- Select colors carefully. When they need to be recognizably different, select the light colors from orange, yellow, green or blue-green, and darker colors from blue, violet, purple or red, as most people affected by color-blindness already see blue, violet, purple and red as darker than normal.

## Window Layout

### General

Placement of visual components in an application is important because relationships between elements are indicated by their positions. This is called "layout" in interface design.

A clean layout is crucial to creating a smooth visual flow of information for the user. This section describes the proper component placement and spacing to use in GNOME applications. The major components discussed will be labels, icons, radio buttons and check boxes, text fields, command buttons, and drop-down menus.

### Dialogs

When a user is scanning a complex preferences dialog consisting of many labels and corresponding check boxes, text fields, and drop-down combination boxes, it is easy to see how she can quickly become hindered by poor layout in the visual design. For information on laying out Alerts, see alert-spacing

#### Improved window layout

Initial layout with poor alignment and limited use of white space | Improved layout with fewer alignment points, frames removed to relieve clutter, and clearer grouping with use of white space

In improved-layout-figure, the dialog on the left presents labels which are not left-aligned. The user's eye is not given a proper anchor to scan the dialog quickly.

As the labels are all similar in length, they should be left-aligned. Now the user has a firm left margin to anchor the eye and scan the list of items vertically more easily. If most of the labels in a group greatly differ in length, right-align them instead, so that the controls do not end up too far away from their corresponding labels.

Using frames with visible borders to separate groups within a window is deprecated. Use spacing and bold headers instead. This is more effective because there are fewer gratuitous lines to distract the user from the main content in the window. See controls-frames for more details.

Try to keep components consonant with each other in terms of size and alignment. This is particularly important within a group of controls, so that the user's ability to quickly scan information is not sacrificed. Minimize as much as possible the need for the user's eye to jump around when scanning a layout.

#### Layout specifications

Improved layout with fewer alignment points, frames removed to relieve clutter, and clearer grouping with use of white space

### Guidelines

- Leave a 12-pixel border between the edge of the window and the nearest controls.

- Leave a 12-pixel horizontal gap between a control and its label. (The gap may be bigger for other controls in the same group, due to differences in the lengths of the labels.)

- Labels must be concise and make sense when taken out of context. Otherwise, users relying on screenreaders or similar assistive technologies will not always be able to immediately understand the relationship between a control and those surrounding it.

- Assign access keys to all editable controls. Ensure that using the access key focuses its associated control.

### Spacing and Alignment

Provide adequate space between controls and groups of controls. This white space will make it easier for the user to find the information they need.

### Guidelines

- As a basic rule of thumb, leave space between user interface components in increments of 6 pixels, going up as the relationship between related elements becomes more distant. For example, between icon labels and associated graphics within an icon, 6 pixels are adequate. Between labels and associated components, leave 12 horizontal pixels. For vertical spacing between groups of components, 18 pixels is adequate. A general padding of 12 pixels is recommended between the contents of a dialog window and the window borders.

- Break long lists of choices into smaller groups. For lists of less than about eight items, use radio buttons or check boxes. For longer lists, use a list control or drop-down list.

- Try to keep elements of the same type left-aligned with each other. For instance, in layout-callouts-figure, the group titles (General and Actions) are left-aligned and justified with each other.

- Indent group members 12 pixels to denote hierarchy and association.

- Minimize the number of alignment points in your window. An alignment point is an imaginary vertical or horizontal line through your window that touches the edge of one or more labels or controls in the window.

- Right-justification within groups or the overall window (as indicated by the line labelled "justification" in layout-callouts-figure is pleasing to the eye, but not crucial.

- Lay out components left-to-right, top-to-bottom. Generally, the first element the user is meant to encounter should be in the top-left, and the last in the bottom right. Keep in mind that when localized for non-western locales, interfaces may be reversed so that they read from right to left.

- Using "white" or blank spacing and indentation to delineate groups is cleaner and preferable to using graphical separators such as frames.

- Align controls in your layout exactly. The eye is very sensitive to aligned and unaligned objects. If nothing lines up with anything else in a window, it will be very hard for the user to scan the contents and find the information he wants. Two things that almost line up, but not quite, are equally distracting.

- Be consistent. Use the same spacing, alignment, and component sizes in all dialogs appearing in your application. The OK and Cancel buttons, for example, should all appear exactly 12 vertical and horizontal pixels from the lower right corner of every dialog window.

- Ensure that light and dark areas as well as spacing are equally distributed around the window. Keep in mind that every control or group of controls in your window has a visual "weight," depending on its overall size, color, and how much white space it includes. Darker, larger areas are "heavier," while paler, smaller areas are "lighter."

- Do not design windows that are more than 50% longer in one dimension than in the other. People are more comfortable looking at windows and dialogs whose dimensions stay within the golden ratio (about 1.6 to 1), a ratio that artists and architects have used to create aesthetically-pleasing paintings and buildings for thousands of years.

## Text Labels

To a user with normal vision, textual output provides the majority of the information and feedback in most applications. To a visually-impaired user who may not be able to see or understand any additional graphical output, clear textual output is critical. You must therefore choose and position text carefully on the screen, and leave the choice of fonts and sizes to the user, to ensure that all users are able to use your application effectively.

### Spacing and Alignment

Use spacing and alignment of text uniformly throughout your application. A basic rule of thumb is to put space between user interface components in increments of 6 pixels, going up as the relationship between related elements becomes more distant.

### Alignment and spacing for different Text elements

Element | Placement | Example
Large Icons (file browser) | Horizontally centered with and (6 pixels, if specification necessary)below large icon | Large icon with text label centered below
Small icons (toolbar) | Vertically centered with and (6 pixels, if specification necessary) to the right of small icons | Small icon with text label to the right
List control label | 6 pixels above and horizontally left aligned with list control or 12 pixels to the left of and horizontally top aligned with list control | List control with text label horizontally aligned above
Radio button and check box labels | 6 pixels to the right of and vertically center aligned with radio button | Radio button with text label to its right
Text field labels | 6 pixels to the left of and vertically center aligned with textfield control | Textbox with text label to its left
Button labels | 12 pixels of padding to either side of centered text (and any accompanying graphic). If appearing in a group of buttons, longest button label sets button size, center all other button labels and accompanying graphics in same-sized buttons | Buttons with centered text
Other component labels (e.g., spin boxes, text fields | 12 pixels between the longest text label and its associated component, all other text labels in component grouping left aligned with the longest label. All labels vertically center aligned with associated components | Drop-down list with label to its left

### Guidelines

- If the label precedes the control it is labelling, end the label with a colon. For example, Email: to label a text field into which the user should type their email address. This helps identify it as a control's label rather than an independent item of text. Some assistive technology screen review utilities may also use the presence of a colon to identify text as a control label.

- Ensure that a label with a mnemonic is associated with the control it labels.

- Left-align components and labels, unless all the labels in a group have very different lengths. If they do, right-align the labels instead, to ensure that no controls end up too far away from their corresponding labels.

- Choose label names carefully. Label objects with names that make sense when taken out of context. Users relying on screenreaders or similar assistive technologies will not always be able to immediately understand the relationship between a control and those surrounding it.

- Be consistent with label usage and semantics. For example, if you use the same label in different windows, it will help if it means the same thing in both windows. Equally, don't use labels that are spelled differently but sound the same, e.g., "Read" and "Red", as this could be confusing for users relying on screenreaders.

- Don't use the same label more than once in the same window. This makes life difficult for users relying on tools like magnifiers or screen readers, which cannot always convey surrounding context to the user.

- Do not hard-code font styles and sizes. The user should be able to adjust all sizes and typefaces.

- Do not use more than two or three different fonts and sizes in your application, and choose visually distinct rather than similar-looking fonts in one window. Too many font sizes and styles will make the interface look cluttered and unprofessional, and be harder to read. In general, always use fonts from the current theme, and specify relative rather than absolute sizes.

- Do not use graphical backdrops or "watermarks" behind text, other than those specified by the user's chosen theme. These interfere with the contrast between the text and its background. This can cause difficulty for users with visual impairments, who will therefore normally choose themes that always use plain backdrops.

### Capitalization

Two styles of capitalization are used in GNOME user interface elements:

Header capitalization

- Capitalize all words in the element, with the following exceptions:

  - Articles: a, an, the.

  - Conjunctions: and, but, for, not, so, yet ...

  - Prepositions of three or fewer letters: at, for, by, in, to ...

Sentence capitalization

- Capitalize the first letter of the first word, and any other words normally capitalized in sentences, such as application names.

The following table indicates the capitalization style to use for each type of user interface element.

### Capitalization Style Guidelines for User Interface Elements

Element | Style
Check box labels | Sentence
Command button labels | Header
Column heading labels | Header
Desktop background object labels | Header
Dialog messages | Sentence
Drop-down combination box labels | Sentence
Drop-down list box labels | Sentence
Field labels | Sentence
Filenames | Sentence
Graphic equivalent text: for example, Alt text on web pages | Sentence
Group box or frame labels | Header
Items in drop-down combination boxes, drop-down list boxes, and list boxes | Sentence
List box labels | Sentence
Menu items | Header
Menu items in applications | Header
Menu titles in applications | Header
Radio button labels | Sentence
Slider labels | Sentence
Spin box labels | Sentence
Tabbed section titles | Header
Text box labels | Sentence
Titlebar labels | Header
Toolbar button labels | Header
Tooltips | Sentence
Webpage titles and navigational elements | Header

#### Capitalization guidelines for other languages

Languages other than English may have different rules about capitalization. For example, Swedish has no concept of Header capitalization. Contact the GNOME Translation Project if you are in doubt about how to capitalize labels in a particular language.

## Fonts

Only use the fonts that the user has specified in their theme, and in sizes relative to the default size specified in their theme. This will ensure maximum legibility and accessibility for all users.

Do not mix more than two or three font sizes and styles (underlined, bold, italicized) in one window, as this will look unprofessional and distract the user from the information being conveyed.

Provide alternatives to WYSIWYG where applicable. Some users may need to print text in a small font but edit in a larger screen font, for example. Possible alternatives include displaying all text in the same font and size (both of which are chosen by the user); a "wrap-to-window" option that allows you to read all the text in a window without scrolling horizontally; a single column view that shows the window's contents in a single column even if they will be printed in multiple columns; and a text-only view, where graphics are shown as placeholders or text descriptions.