Plasma/Active/Development/ActiveHIG/Settings

From KDE Community Wiki
Revision as of 18:36, 31 December 2011 by Colomar (talk | contribs) (Wording changes)

Configuration Dialogs in Plasma Active

Configuration dialogs are used to configure options of

  • Applications
  • Functionality shared between applications (e.g. web browsing settings, multimedia settings)
  • System components (e.g. locale, hardware options, power profiles)

What to Put in Configuration Dialogs

Configuration dialogs are not the solution for everything. Use them only for settings that

  • Are relevant to the target user of your application or system component
  • Have different optimal values for different users. If there is one value that works best for (almost) all users, do not provide a settings option
  • Need only be changed very rarely. If an option needs to be changed depending on the task performed, put it in the interface for the task instead of a configuration dialog.

Access to Configuration Dialogs

  • All configuration dialogs can be accessed by opening the general Configuration Shell ("Settings") and selecting the entry.
  • Application-specific dialogs can also be accessed from the application using a button or menu entry. Opening the dialog from the application opens the configuration shell in a new window with the corresponding module selected
  • Shared application settings can also be accessed from each application that they affect

Instant Apply

Changes are applied instantly. There is no "Apply" button. If possible in any way, avoid application-specific settings that need the application to be restarted in order to take effect. If it is technically not possible to apply changes without restarting the application, do the following:

  • As soon as any changes are made in the dialog, display the message "Restart [Application name] for the changes to take effect" below the settings. In the case of shared settings, the message reads "Restart [Application type, e.g. "Multimedia"] applications for the changes to take effect
  • If all changes which cannot be applied immediately are reverted to the value they had when the dialog was opened, the message is removed

Dialog Layout

Each configuration dialog has the following elements:

  • The title
  • A short description of the dialog's purpose (if helpful)
  • The list of options

Title

Choose the title like this:

  • For application specific configuration dialogs, the title is the application's name.
  • For shared application settings and system components, choose a simple term describing the kind of settings (e.g. "Multimedia", "Emoticons", "Personal Information", "Time and Date", "Power Management")

Short Description

The short description should not be longer than one sentence or a short comma-separated list of terms. Do not start with "Settings for..." or "Configure", as this implied by the fact that it's a Settings module. Example "Date Format, Currency, Metrics and other locale-specific settings" for "Locale").

If the title is already fully self-explanatory, omit the short description

List of Options

  • Use sub-headlines to group related options. Sub-headlines are left-aligned
  • Order settings within each group and the groups themselves by relevance, from most relevant to least relevant
  • Display the option labels right-aligned and the configuration widgets left-aligned.
  • Keep the labels short. Labels must never be more than one line long.
  • If users may need further explanation for an option, put a question mark icon next to the label. When clicked, display a tooltip containing the explanation.

Keep all options of one kind within one screen, without scrolling. If your options do not fit on one screen, you probably have too many options. Mobile users usually do not want to fiddle with lots of detailed options. Think again which options are really useful / absolutely necessary.

Configuration widgets

Use the following widgets in configuration dialogs:

  • For turning things on and off, i.e. starting or stopping (sub-)processes or activating or deactivating hardware features(e.g. "Activate GPS", "Enable Service XYZ"), use a sliding switch to prevent accidental switching
  • For other yes/no options (e.g. "Skip run-together words" or "Delete cache when closing browser") which don't initiate an action like starting or stopping a process when switched, use a checkbox as they are easier to switch
  • To select one out of three to five options, use radio buttons if enough space is available
  • To select one of many options, use a [selection widget]
  • Use edit boxes to enter text or numbers with undefined range
  • To adjust numbers within a defined range (e.g. 1-10), use a number wheel
  • Use buttons to execute actions like clearing a cache or re-initiating a database. If the action is irreversible with potential loss of important data, ask for confirmation before executing the action