HIG about Simple vs. Advanced Settings

Recently the question was asked in the KDE forums how we handle advanced settings. While there is neither a best practice nor a common approach in KDE software, we actually discussed a similar concept in respect to the Plasma control modules (KCM).

The updated organization of KCMs was implemented by the developers, the community decided about the basic layout, and a couple of proposals were done [1, 2]. So why don't generalize this idea and write a guideline?

The following guideline proposal not only recapitulates what we considered for the KCM but also introduces some new ideas. There is first of all the import/export function. The use case for this function is a system backup where you may want to store application settings too. While installing software is a piece of cake you waste much time to get back your previous look and feel as well as the known behavior. The import/export function should affect all aspects of the application. In contrast, the GHNS! feature is applied locally to the selected "group", which could be a minor usability flaw. Also controversially discussed is the workflow how to add user-defined settings. The idea is to implement it similar to the current color KCM. When the user modifies properties of an existing preset, e.g. "Breeze", the changes are applied to the preset "Current". In order to keep the customization it has to be renamed, e.g. "My Breeze". The advantage - and probably big challenge for developers - is to provide not only one single factory setting. Simplicity does not mean to have no choice.

Before we now start to create examples we would like to get your agreement - or rejection. So what do you think?


The settings dialog provides user-customizable options how an application or plasma (KCM) should behave. The dialog is intended for options that are not accessed frequently and are persitent. Following KDE's "Simple by default, powerful when needed" design mantra, settings are split into simple vs. advanced ones. Advanced settings are options that are not important to most users but essential for some, and can't removed therefore. Those options are hidden by default, but with an easy access in order to improve learnability.

Is this the right control

  • Use this pattern for all settings that are relevant to change for users.
  • Do not use the settings dialog for frequently accessed properties like, for instance, details vs. icon view. Use the toolbar or main menu (and optionally context menu) for these options.
  • Do not use the settings dialog for rarely changed or developer options like the sql table name. Use extra configuration files or dialogs for those options.

General recommendations

  • Simple by default: Define smart and polite defaults. Set the defaults in a way that most users don't have to alter them at all.
  • Powerful when needed: Provide enough options for the perfect customization according individual needs and preferences. But even though customizability is very important for KDE software, try to keep your settings dialog as small and simple as possible. Remember: every option requires more code and more testing!
  • Respect the privacy of the users: Always use opt-in, never an opt-out model for features that transmit potentially private data (e.g. usage statistics).


  • Organize your settings in logical groups. (#1 in the example).
  • Split options per group into standard and advanced. Make the standard easy to use for everyone. (#5)
  • Offer several presets and let the user decide what type of configuration should be active. (#3)
  • Consider to add access to third-party presets via Get Hot New Stuff! (GHNS), if available for this group. (#4)
  • Show a live preview for visual features. Omit this section if it's not relevant.
  • Provide functions to export/import all settings. (#7) If splitting the options into app-related (such as colors, fonts, etc.) and account-related (for instance personal settings, mail accounts...) make sense, let the user decide what to export. Import has to as straightforward as possible; let the user just confirm when data are being overwritten.


  • When the user changes the default switch to a special preset ("User" or "Current"). This preset cannot be applied unless it is renamed individually. Access to rename (and delete) is done per context menu. Indicate user defined presets by using italic font for the name.
  • Sort your options and groups by importance.
  • When a change is applied, the application should adopt it immediately without the need to restart it.
  • Do not change the settings dialog depending on the context. You should always start with the same landing page regardless of the application context.
  • Do not use a wizard to edit options. Only use a wizard to set options if actually a group of options all have to be edited at once, eg creating an account or a first run wizard.


1) Access groups via sidebar.
2) The preview has to be on the top of the content area.
3) Offer a good number of presets to let the user choose one out of different factory settings. Anchor the presets so that users can have more space for the area below using the horizontal splitter. Cut long captions with ellipsis and show the full name in a tooltip.
(Remark 1: The mockup has very large splitters. The implementation should be visually less obtrusive.)
(Remark 2: The preset selection replaces the former "reset (to default)" function.)
4) Allow users to add more presets via Get Hot New Stuff (GHNS). Organize the setting in a way that GHNS access is per group and not global.
5) Provide access to the most relevant settings at the Standard section. Make sure that these options are easy to understand.
6) Indicate that Advanced options are available but keep this section collapsed by default.
7) Allow users to export the current settings to a file that can be easily imported on any other machine.
8) Allow to Apply the current settings to the application without closing the dialog.
9) Provide access to functions for user-defined presets per context menu and standard shortcuts.
10) Scroll the whole area of options but neither the preview not the presets, if necessary.

* ^todo


I am trying, here, to come up with a way of saying this nicely, and failing, so... this whole thing is in severe danger of falling into the beginner/advanced fallacy. This issue keeps surfacing when people want to produce more streamlined options dialogues, and always ends up in a situation where people either fail completely to come up with a sensible definition of what constitutes an "advanced" user, or where the dialogue simply becomes more difficult to find your way around than it was before, or, more commonly, both.

Really, i applaud the idea, wholeheartedly, to make settings dialogues more pleasant to use, but please, please do not call options "advanced". The direct implication is that the user who do not click that button is somehow a simpleton. In short, some /very/ large corporations have spent a very considerable amount of effort trying to get this stuff to work (see the Personalised menus in Office as an example, though that's only one of many), and they have not been able to sort it. I'm sure that we're all more than happy to just say that these large corporations are terrible and just don't know what they're doing, but the amount of resources expended on this are considerable, and i think there's a certain amount of hubris if we are now saying that we somehow have found out how to do what they have failed to do.

The whole thing was discussed at some length here, in relation to System Settings, but the discussion applies to this situation as well: http://blog.tenstral.net/2012/02/kde-system-settings-usability.html

Honestly, i hope it can be worked through, but... yeah, i just worry about this, because of the basic fallacy in defining the beginner/expert split. It's not that /some/ things are not clearly one or the other, it is simply that the grey area is gigantic.

By Dan Leinir Turthra Jensen at Mon, 02/08/2016 - 17:48

Thanks for your reply. I think it's fair to express concerns.
Regarding the terminology I think we could easily call the collapsed section "Details" or "more". What we likely all agree is
a) a good number of configuration switches is desirable,
b) easy access to all features as well for the average user, and
c) having a consistent layout.
The idea is to not only apply this approach for system settings (that have been reorganized, by the way) but also for other KDE applications. With the preset feature you get access to not only one set of good options. Switching from preset A to B affects the advanced settings reducing the need to go into details.
If we take our vision of "simple by default and powerful when needed" seriously then it has to be covered accordingly.

By htietze at Tue, 02/09/2016 - 08:42

I would suggest to use a descriptive title for the button, e.g. something like

  • "Cypher details" for an new key in KGpg
  • "Connection details" when configuring TLS/SSL settings in KMail
  • "Sensitivity", for hardware threshold in a mouse KCM
  • ...

That way it is easier to find an option, too.

By fabianr at Tue, 02/09/2016 - 11:24

Please no "More". As it is then like secondary/obsolete settings that people don't want to look because "there is more".

Same thing is with "Details". It should be more accurate information about the setting itself. Like if you make a backup script to sync two directories, then the "Details" would explain the backup script what it is doing.

By Juurikas at Wed, 02/10/2016 - 22:16

Okay, that makes sense. So I'll change

6) Indicate that advanced options are available but keep this section collapsed by default. Use a descriptive label so that it reflects the functionality.

And the mockup label could be shown as to indicate that it is a variable.

By htietze at Thu, 02/11/2016 - 08:57