Three Simple Tips for Interface Design You Should Know
The GNOME Human Interface Guidelines (HIG) have always been a controversial topic among fans and third-party developers. Claus Schwarm shows you why the HIG is important and some subtle ways in how to utilize the HIG in simple but not always obvious ways.
When the GNOME projects’ members started to work on version 2 of the GNOME desktop environment, no change produced as much aversion, displeasure, and anger as the Human Interface Guidelines (HIG). Still today, some complain about the current direction of GNOME.
There is no such thing as a perfect guideline—at least, not when written by humans. Mistakes happen. The interpretation of usability principles may lead to wrong or inappropriate conclusions—inappropriate because development is done in special circumstances, carried by volunteers and enthusiasts.
However, very fundamental ideas of the HIG don’t need to be discussed in the light of usability principles, alone. In fact, such a discussion may be misleading: Many people seem to confuse the word “usability” with “being used to”, and thus argue for whatever they already know. But you can’t conclude from one observation to the general rule. It’s a classic failure in human thinking.
The HIG is not just a collection of usability principles, it’s also a sort of unofficial standard. It’s sufficient to accept them as such. Just like many states in the world decided to drive on the left side—which is obviously wrong when you’re from a state with right-side driving—, this is not a question of wrong or right, or good or bad. The central question is whether everybody drives on the same side in a particular country.
A pragmatic approach to the GNOME HIG is thus: who cares whether it’s left or right? Right or wrong? When in Rome, do as the Romans do.
GNOME’s interface toolkit, GTK+, and all of its numerous language bindings imposes nearly no restrictions on the interface design. And with freedom comes diversity. The GNOME HIG may serve as a way of coordinated efforts; a tool to avoid unnecessary diversity. It’s a friendly and useful meeting point, worth revisiting every few months. The following three simple recommendations aim to provide a basic starting point for developers and interface designers.
(1) Get your Window Types Straight
GNOME’s Human Interface Guidelines distinguish two types of windows: primary and secondary windows. Primary windows are the main windows, those that hold the contents a user cares about.
There are quite different kinds of primary windows: for example, gEdit and Mozilla Firefox use a single interface with tabs inside, Inkscape uses a single window interface with multiple instances, and GIMP uses a multiple window interface. Which type of primary window you should use depends on what audience you’d like to serve. The choice is rather specific to your situation.
Less specific is the design of secondary windows. They do not present content that is central to the users. All applications have lots of secondary windows except maybe the most simple ones. Here, most application developers can improve their interface design easily, and without much hassle.
Often, all secondary windows are called dialogs. This is convenient but a little bit misleading: the GNOME HIG uses the word in a specific way. It differentiates five types of secondary windows:
Mixing these types, or rather, their design elements, is a common error that leads to unnecessary work and ends up creating confusing interfaces and confused users, even if they wouldn’t admit that.
What are these design elements? Common to all secondary windows is a certain window type, and buttons for interacting with the window at their bottom. Common is also the question whether they have window titles, show up in the window list of the panel, and whether they use a certain layout for the text. However, depending on the window at hand, these elements are used differently or not at all.
|Type||Window Title||Primary Text||Panel List|
The above table makes is easier to spot the basic differences between these types. For example, the design of utility windows and dialogs could be called a reference for secondary windows. Alerts, and progress windows seem to differ from the reference.
A utility window layout is usually used for windows which display document or application properties or preferences. GNOME’s default editor gedit, for example, has several utility windows: “Edit > Preferences”, “Tools > Document Statistics”, or “Help > About”. A dialog window, on the other hand, is needed by the user to complete a certain task. Again, gedit has several examples: “File > Open”, “File > Save”, “File > Print”, or “Search > Find”.
Utility and also dialog windows are usually not meaningful to the user without the parent window. Thus, there’s no need to display them in the panel list of windows. They are also usually requested by the users; their appearance is no surprise. Thus, they usually do not need deeper explanation; there’s no need for a primary and secondary text. It’s sufficient to use a window title.
These assumptions break for the other two important window types: Alerts and Progress Windows.
Usually, a user doesn’t request (or want) any of them. An alert is obviously alerting him/her that something important has happened. From the user’s perspective, this is a surprise. It requires an explanation. Thus, primary and secondary text make sure that a user understands what happened. For a similar reason, progress windows are not wanted by a user either: Users expect that everything happens immediately. The need to wait for the computer is a distraction. Again, a primary and secondary text makes sure the users understand what’s happening.
But there is a slight difference between alerts and progress windows, namely how users react about them. An alert is usually read and closed fairly immediately. There’s no need to use a window title or make it appear in the panel list of windows. Both elements would be distractions for something that will exist for only a few seconds, anyway.
But the best reaction about a progress window is to do something different. There’s no way around to speed up the actions. Thus, progress windows do appear in the panel list and they do have a window title. Users must be able to identify them if they decide to care about a different task while waiting.
The remaining window type mentioned by the HIG is “Assistants.” It’s the most simple type: there’s not much to learn about it—just try to prevent using it by all means. If, after careful consideration, you see no other way than using an assistant, GTK+ 2.10 and higher will provide a simple widget for it.
The first four window types in the HIG can thus be separated by the role of the user: Is he/she active and the window was requested? Or is he/she passive and the software needs to display the window? In the first case, you will need a utility window or a dialog, in the latter case an alert or a progress window.
Mixing these types may lead to a confusing user interface. When mixing an alert and a utility window, you will just repeat information. This may look like this:
A more complicated case is to mix a utility window and a progress window. This may lead to an unusual combination of buttons in the window, confusing the user and letting him/her lose control. A good candidate for such a mix is a search dialog: People need to enter information before the search is started, and it may last a few seconds.
There are two simple ways out of such a situation: First, you can turn the single window into two windows: the first being a usual utility window which is shown until the users selects an appropriate option. Then, hide the window from the view, and show a usual progress window until the requested action is finished. Another option is shown by GNOME’s default search utility available under “Places > Search for files…”. Here, the default action is changed during a search while a small icon indicates ongoing activity.
(2) Order Buttons and Label them Appropriately
With the notable exception of toolboxes, all secondary windows should have at least one button. All button labels should use an imperative verb describing what it will do when clicked. The button with the suggested (or affirmative) action should be in the lower-right corner. This is probably the most discussed recommendation of the HIG.
Again, it’s not relevant whether it’s good or bad, wrong or right, or right or left: When in Rome, do as the Romans do.
However, users running HIG compliant applications under GNOME probably noted that it’s usually a snap to get rid of windows, in general. It takes nearly no mental effort. One reason may the above rule: Your “muscle memory” is used to the fact that the most appropriate action is always in the right corner. Funny enough as it seems to be unaffected by the fact that the window is mostly somewhere else on the monitor screen.
Car drivers who are used to a manual transmission know a similar effect: After the initial training, they don’t need to think about switching gears, anymore. The movement is prepared without your consciousness being involved. Getting used to a affirmative button in the lower right corner is even more simple.
But that’s not all. The rule also helps developers: If you have trouble finding the affirmative action for a certain secondary window, you probably need to step back a second and think about your window design again. You have probably made a mistake, and didn’t respect the first tip mentioned above.
If, for example, the developers of the above “Create thumbnails” dialog would have used the affirmative-action trick, they would have noted that something’s wrong: First, you certainly don’t call a dialog to close it right away. You want to do something, first. The button order “Stop”, “Close”, and “Start” would have made more sense. Next, the affirmative action is “Create”, not “Start”. With the affirmative action in the lower right corner, the developers could have saved their time including an extra element which explains users what to do: “Click Start to begin.”
Additionally, they could have made the Enter key trigger that button—a general recommendation for all alerts, dialogs, or assistants with an affirmative button for continuing. The only exception to the rule is when hitting the enter key by mistake would cause a lot of damage: Think “Erase Disk”.
Why does it matter how buttons are labeled? Using verbs helps you as a developer to formulate the question correctly. This is also useful for developers without English as their native language. Even native speakers have proven in the past that it’s easy to formulate sentences which are easy to be misunderstood. However, a verb makes using a dialog more easy. In contrast, see the following screenshot where the meaning of the answer depends on a single (hidden) word in the dialog text:
You can probably guess the hidden word. But are you sure, it wasn’t “Cancel?”
(3) Layout with Spacing and Alignment
Screen real-estate is scarce and developers like to put many functions into an application. As a result, an increasing amount of elements share a more or less fixed amount of pixels. It’s getting crowded. To separate distinct elements, developers add even more elements, and thus more visual noise to a window layout.
In contrast, the GNOME HIG recommends to use a multitude of 6 pixels for layout. For example, use a 12 pixel wide border in a secondary window. In Glade, this is done by using a 6 pixel border for the window, and a 6 pixel border for the inner content. With buttons labeled as discussed above, the result may look similar to the following dialog window:
It’s a simple construction. The usual separator between the lower buttons and the content is disabled as recommended by the GNOME HIG. One thing becomes immediately obvious: The design is not yet relaxing. However, it exemplifies some principles of laying out utility windows and dialogs.
The layout uses a vertical box with 3 rows to layout the inner contents. The spacing is set to 12 pixels so each part is visually distinct. A frame is used in every row, with its borders set to “none” and its label set to be bold. Of course, it’s also necessary to add the borders around the final buttons.
Within each frame, an alignment helps to layout the inner contents. Use 12 pixels for the left padding, and maybe 6 pixels for the top padding. That’s it, basically. Try to align the inner contents to the left and to the right, if possible. For instance, this could be done to the combo box that is used to select the units.
Overall, it’s a really simple design. It copies the “Export to bitmap” dialog used in Inkscape 0.42. Here’s, how it looks:
No interactive element was removed. Everything’s still there. Applying basic HIG design recommendations is thus possible without removing functionality, and the necessary effort is not even overly demanding. However, it improves overview for users—probably not just for those living in Rome.
Following these simple three recommendations will not make an application easy to use, or usable. They may help you to get started on making your applications more usable or easy-to-use, though. However, they certainly do no harm, unless you consider it your personal goal to make a platform such as Microsoft Windows more consistent and successful.
The GNOME HIG offers a lot of advice in making applications more usable. Some of them are useful in all situations—for example, you probably like to remove all computer jargon in your application, a hard to reach goal. Some may need a second thought whether other considerations are more important in a certain situation. Applications designed for professionals—people who work all day long with a certain application—probably need to take special care about efficiency as well.
When in doubt about the usability of a certain design, the GNOME usability mailing list is always there to help. There’s also an IRC channel #usability on irc.gnome.org to ask, although it doesn’t appear to be very active. It’s not a failure to get help from designers. This is maybe the most important recommendation of the GNOME HIG.