Table of Contents
This section explains some of the basic principles behind the more specific technical guidelines recommended in this document. We believe that these principles are important for all application development.
Remember that the purpose of any software application is to enable some group of people to accomplish a specific set of tasks. So, the first things to establish when designing your application are:
who your users are
what you want to enable them to do
For example, you may be designing an application that will enable engineers (software, electrical, or mechanical) to create diagrams. You may be designing an application that will enable system administrators to configure and monitor a web server. You may be designing an application that will help elementary school students to learn math.
The important thing is that you know your audience, and you understand both their goals and the tasks necessary to achieve those goals. There are a large number of professional interaction designers who write books and teach courses on design methods that can help with this process, many of which are extremely useful. Most of these methods, however, boil down to specific ways of understanding your users, understanding the tasks you want to help them accomplish, and finding ways to support those tasks in your application.
If you are designing an application for use by engineers, or by children, or by system administrators, be sure to create an application that can be used by all engineers, children, or system administrators, including those with disabilities or those who are native speakers of a language different from yours. Be aware of accessibility issues and internationalization and localization issues, many of which are addressed by the guidelines in this document.
Accessibility means enabling people with disabilities of some kind to participate in life's activities: in this case, specifically to use your software. For example:
Color-blind users may not be able to use your application if you rely only on color-coding to distinguish different types of information
Users with hearing impairments may not be able to use your application if you rely on sounds to indicate critical information
Users with limited movement may not be able to use your application if you don't provide keyboard equivalents for commands
Your software should also be usable with voice interfaces, screen readers such as gnopernicus, alternate input devices, and other assistive technologies. The standard GNOME libraries do most of this work for you, but with a little extra effort you can make your application every bit as useful to users who rely on those technologies as to those who don't.
More information on accessibility in GNOME can be found at the GNOME Accessibility Project.
Internationalization is designing software so that it can function in different language environments. Localization is the process of actually translating the messages, labels, and other interface elements of an application into another language.
GNOME has excellent support for both internationalization (also referred to as i18n) and localization (also referred to as L10n). In most cases, simply using standard GNOME APIs for displaying text and messages will allow you or others to localize your application for other locales. For more information on how to make your application localizable, see the Pango project home page (Pango is the GNOME library for rendering internationalized text), the GNOME Translations page, and the GNOME Translation Project page.
Always use words, phrases, and concepts that are familiar to the user rather than terms from the underlying system. Use terms that relate to the user's knowledge of the tasks your application supports. For example, in medicine, the paper folder that contains all information about a specific patient is called a "chart." Hence, a medical application might refer to a patient record that contains the same information as a paper chart as a "patient chart" rather than as a "patient database record."
You can often take advantage of your users' knowledge of the real world by using metaphor— that is, a familiar concept from the outside world— to represent elements within your application. For example:
an image of a file folder suggests a container into which documents can be placed
a waste basket suggests a container into which items can be placed when they are no longer needed
When using metaphors, however, it is important to neither take the metaphor too literally, nor to extend the metaphor beyond its reasonable use. For example, the capacity of a file folder should not be limited to the capacity of a physical file folder, which presumably could contain only a few documents before becoming unwieldy. On the other hand, a waste basket should not be used for anything other than holding discarded files. It should not be used, for example, to eject a removable disk such as a floppy or CD.
Make your application consistent with itself and with other applications, in both its appearance and its behavior. This is one of the most important design principles, and probably the most famous, but it is also frequently ignored. While this document serves as the basis for consistency between GNOME applications, you are encouraged to look at and follow other application's conventions where this document provides no guidelines.
Consistency enables users to apply their existing knowledge of their computing environment and other applications to understanding a new application. This not only allows users to become familiar with new applications more quickly, but also helps create a sense of comfort and trust in the overall environment. Most of the recommendations in the GNOME HI Guidelines are designed to help you create applications that are consistent with the GNOME environment and other GNOME applications.
A word of caution: a mis-applied or incomplete consistency is often worse than inconsistency. If your application includes an Undo menu item for consistency, but it is always disabled because your application does not actually support Undo, this will reduce users' trust in the availability of Undo in other applications on their desktop. Either make your application support Undo, or eliminate the Undo menu item.
Always keep the user informed of what's going on in your application by using appropriate feedback at an appropriate time. The user should never have to guess about the status of the system or of your application. When the user performs an action, provide feedback to indicate that the system has received the input and is operating on it. Feedback can be visual, audio, or both. If the system will take a long time to process the request, provide as much feedback as possible about how lengthy the operation will be. Types of helpful feedback include but are not limited to: cursor changes, animated "throbbers", progress indicators, audio feedback such as a beep, and error messages. Error messages should use simple language, clearly state the problem, and provide solutions or tell the user how to get out of the current situation if possible.
It is critical that feedback be accurate and precise. If you display a determinate progress indicator to display the state of completion of a task and it is inaccurate, the user will lose faith in progress indicators, and they will find the environment less usable. If you display a generic error message that indicates that there is a problem but fails to provide enough information to diagnose or solve the problem, your users will be unable to continue with their task.
Your application should enable the user to concentrate on the task at hand. So, design your application to show only useful and relevant information and interface elements. Every extra piece of information or interface control competes with the truly relevant bits of information and distracts the user from important information. Hence, don't clutter your interface, and don't overload the user with buttons, menu options, icons, or irrelevant information. Instead, use progressive disclosure and other techniques to limit what the user sees at any given moment.
Finally, present your information and interface elements in an aesthetically pleasing manner. A disorganized, cluttered-looking interface with a few elements can be just as distracting as an organized interface with too much information. Make sure that dialog elements are cleanly-aligned, and do not overuse or misuse color or graphics.
Remember that computers exist to serve humans. A user should always feel in control, able to do what they want when they want. This means you should generally avoid modes; users should be able to switch between different tasks (and specifically, different windows) at any time.
The user should also be able to tailor aspects of their environment to fit personal preferences. It is very important, however, to avoid the trap of allowing too much configuration, or allowing the configuration of parameters that most users will not understand or find useful to modify. Wherever possible, inherit visual and behavioral parameters from global preferences and settings such as the current GTK+ theme.
We all make mistakes. Whether we're exploring and learning how to use the system, or we're experts who just hit the wrong key, we are only human. Your application should therefore allow users to quickly undo the results of their actions.
If an action is very dangerous, and there is no way to undo the result, warn the user and ask for confirmation. Only do this in extreme cases, though; if frequently faced with such confirmation messages, users begin to ignore them, making them worse than useless.
In all cases, the user's work is sacrosanct. Nothing your application does should lose or destroy user's work without explicit user action. Among other techniques, this can be achieved by auto-saving backups of documents, and allowing multiple levels of undo.
Wherever possible, allow users to act on objects and data directly, rather than through dialog boxes or explicit commands. For example, it is more intuitive to drag a circle object around in a diagram rather than selecting a "Move" command from a menu while the circle is selected.
See Chapter 10 for more information on direct manipulation.