Preferences User Interface
Authored by: Jonas
Celebiler, Netscape Client User Interface Group
Date created: 3 March 1998
Date Last Modified:
This document discusses the framework and principles of Communicator's
preferences user interface.
Here are some of the goals that we set for ourselves when designing
the Communicator 4.0 preferences user interface:
These goals translated into some principles we kept in mind when designing
the preferences UI. The next section goes over these principles.
To make it easy for the user to find specific preferences they would be
To make it easy to browse through preferences to discover all the things
you can configure
To provide excellent configurability while still maintaining simplicity
and ease of use:
To not intimidate novice users
By keeping the number of preferences in the UI low (avoiding unnecessary
To have a consistent visual presentation of all the preferences
Principles and Guidelines
Often when a user goes to the preferences they don't know exactly what
they're looking for or where it will be. For example a user might
have a vague notion that s/he needs to change something about their mail
server settings, but not know exactly what the preference would be called
or what category it would fall under. Furthermore, there are likely
preferences which users won't have thought of, but when they see them,
will find useful. Thus it is useful for users to be able to browse
through all the existing preferences, so that they can decide which ones
they want to customize. The preferences framework is therefore designed
so that it is easy to browse around from one preferences panel to another.
Avoid Technical Jargon
We've made a concerted effort in Communicator to present all the preferences
in such a way so that a user who does not know any technical jargon can
understand the options. To do so, we've avoided relying on technical
terms, such as acronyms. Sometimes acronyms are useful, because they
enable a power user to recognize exactly what the option refers to.
However, if an acronym is absolutely necessary, you should also provide
enough descriptive text so that the user can understand the option without
knowing the meaning of the acronym. Similarly, some terms make perfect
sense to users who have had prior exposure to them, but are not understood
by other users. Avoid such terms, or provide enough descriptive text
so that the option can be understood without knowing the term.
Description of the Preferences User Interface Framework
The Preferences Window
The Preferences window consists of four major areas:
Category scrolling list
Message banner (at the top of the dialog)
Preferences panel for the selected category
Each area is described in separate sections below.
Category Scrolling List
Preferences are categorized according to the part of the application
they affect. The list is context sensitive so that when the preferences
window is opened from the application, only those which are relevant to
the application are expanded, while the other categories are collapsed.
The panels corresponding to top level categories contain basic, frequently
accessed preferences. The sub-categories contain more advanced preferences.
The message banner is located above the preferences panel. On the left
is the title of the preference panel being viewed (text is bold). On the
right is the message area (text is right-justified). When the user selects
a category from the list, a short description appears in the message area,
which explains what kind of options are available in that category.
Preferences Panel for the Selected Category
As the user selects a category from the scrolling list, the corresponding
Three buttons have been proposed for the preferences window:
Button order varies across each platform. The buttons are placed in compliance
with each platform's interface guidelines for button order.
OK - save all changes and close the window.
Cancel - do not save any changes and close the window.
Help - open the Preferences Help Window; keep the preferences open.
Q and A
Why Not Tabs?
The number of preferences that exist in the product precludes the use
of tabs, because it would require several rows of tabs. We feel having
multiple rows of tabs offers poor usability, as clicking on a tab in a
new row switches the rows around and disorients the user.
Send feedback to: Jonas Celebiler