Chapter 8. Visual Design

Table of Contents

Color
Palette
Hue, Brightness, Contrast
Window Layout
General
Dialogs
Spacing and Alignment
Text Labels
Spacing and Alignment
Capitalization
Fonts

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 colorblind), 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://www.ximian.com/images/art-devel/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 antialiasing), choose a color that is closest to the hue you need, then darken or lighten as required.

Figure 8.1. The basic GNOME 32-color palette

The basic GNOME 32-color palette

Table 8.1. RGB and hexadecimal values for the basic palette

ColorDescriptionRGBHexColorDescriptionRGBHex
Basic 3D Hilight234 232 227#EAE8E3
Basic 3D Medium186 181 171#BAB5AB
Basic 3D Dark128 125 116#807D74
3D Shadow86 82 72#565248
Green Hilight197 210 200#C5D2C8
Green Medium131 166 127#83A67F
Green Dark93 117 85#5D7555
Green Shadow68 86 50#445632
Red Hilight224 182 175#E0B6AF
Red Medium193 102 90#C1665A
Red Dark136 70 49#884631
Red Shadow102 56 34#663822
Purple Hilight173 167 200#ADA7C8
Purple Medium136 127 163#887FA3
Purple Dark98 91 129#625B81
Purple Shadow73 64 102#494066
Blue Hilight157 184 210#9DB8D2
Blue Medium117 144 174#7590AE
Blue Dark75 105 131#4B6983
Blue Shadow49 78 108#314E6C
Face Skin Hilight239 224 205#EFE0CD
Face Skin Medium224 195 158#E0C39E
Face Skin Dark179 145 105#B39169
Face Skin Shadow130 102 71#826647
Accent Red223 66 30#DF421E
Accent Red Dark153 0 0#990000
Accent Yellow238 214 128#EED680
Accent Yellow Dark209 148 12#D1940C
Accent Green 70 160 70#46A046
Accent Green Dark38 199 38#267726
White255 255 255#ffffff
Black0 0 0#000000

Hue, Brightness, Contrast

Users with vision disorders, such as colorblindess 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 colorblindness. 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 colorblindess and checking legibility of images for colorblind 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.

Figure 8.2. 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 colorblindness would see it
Photo of earth as a user with blue-yellow colorblindness 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 colorblindness 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 checkboxes, text fields, command buttons, and drop-down menus.

Dialogs

When a user is scanning a complex preferences dialog consisting of many labels and corresponding checkboxes, text fields, and combo 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 the section called “Spacing and Positioning Inside Alerts”

Figure 8.3. 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 Figure 8.3, 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 the section called “Frames and Separators” 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.

Figure 8.4. 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 labels immediately precede their associated control in the tab order, so that the access key will focus to or activate the correct control when pressed.

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 option menu.

  • Try to keep elements of the same type left-aligned with each other. For instance, in Figure 8.4, 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 Figure 8.4 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 buildings and paintings for thousands of years.

Technical Details for Proper Layout

Set Border Width for the GtkDialog to 12. Place a GtkVBox containing as many rows as you wish to have categories inside the control area of the GtkDialog, and set the Spacing for the GtkVBox to 18.

In turn, each category should be composed of a GtkVBox with two rows. Set the Spacing to 6.

  • In the top row, place a label for the category header. Make the label bold using the Pango markup

    <span weight="bold">Category Header</span>
    Set the label property Use Markup to Yes, and X Align to 0.0 to left align the label.

  • Place a 2-columned GtkHBox in the lower row of the top-level GtkVBox.

    • In the left column, place a label containing four space characters. This will serve to indent the category contents.

    • In the right column, place a GtkVBox containing a row per control you wish to place in the category. Set the Spacing to 6.

      • For left-side labelled controls such as text boxes, option menus, and many others, place a 2 columned GtkHBox inside the row with a label in the left column and the corresponding control in the right. Set the Spacing on the GtkHBox to 6. Place all labels such as this (for the whole window) in the same GtkSizeGroup (there is currently no way to do this using only Glade, you will have to use code as well). This will align the controls to their right, even between categories, which is important for allowing quick visual scans.

      • For right-side labelled controls such as check boxes and radio buttons, simply place them directly in the row.

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.

Table 8.2. Alignment and spacing for different Text elements

ElementPlacementExample
Large Icons (file browser)Horizontally centered with and (6 pixels, if specification necessary)below large icon
Large icon with text label centred 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 label6 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 checkbox labels6 pixels to the right of and vertically center aligned with radio button
Radio button with text label to its right
Textfield labels6 pixels to the left of and vertically center aligned with textfield control
Textbox with text label to its left
Button labels12 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
Option menu 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.

  • When you use static text to label a control, ensure that the label immediately precedes that control in the Tab order. This will ensure that the access key (underlined character) you assign to the label will move focus to or activate the correct control when pressed.

  • 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.

Table 8.3. 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 combo 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 combo 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

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.