Table of Contents
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 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.
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
Table 8.1. 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 |
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).
![]() | ![]() | ![]() |
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.
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.
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”
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.
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.
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.
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.
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.
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
Element | Placement | Example |
---|---|---|
Large Icons (file browser) | Horizontally centered with and (6 pixels, if specification necessary)below large icon | ![]() |
Small icons (toolbar) | Vertically centered with and (6 pixels, if specification necessary) to the right of small icons | ![]() |
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 | ![]() |
Radio button and checkbox labels | 6 pixels to the right of and vertically center aligned with radio button | ![]() |
Textfield labels | 6 pixels to the left of and vertically center aligned with textfield control | ![]() |
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 | ![]() |
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 | ![]() |
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.
Two styles of capitalization are used in GNOME user interface elements:
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 ...
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 |
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.