Purpose
Provide user-customizable options how an application should behave. The settings are intended for options that are not accessed frequently and are persitent.

General recommendations
- Keep your settings as small and simple as possible!
- Define smart and polite defaults
- Group your settings, if you have more then 7
- You should only have one settings page/dialog. It shouldn't be context aware, but always show the same content regardless of the application context

Grouping
Group related settings in groups up to 7 options. If you have more then 7 groups add another level of grouping. Try not to have more then 3 levels of grouping.
Sort your options and groups by importance.

For 2 levels of grouping use the List - Detail pattern
For 3 levels of grouping use the List - Details - Tabs pattern

Advanced options
Advanced options, are options that are not important to most users, you can set sensible defaults for them, but can't remove them, because they are essential to some users.
Place theses option in a separate section in their group. This section is not shown by default, but only expanded after clicking on a button. Try to use a descriptive title for the button, only use "Advanced options" for labeling if you cant find anything better.

Wizard
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.
Don't use a wizard to edit options.


Related Links / Settings in other HIGs
- https://msdn.microsoft.com/en-us/hh770544
- http://www.google.com/design/spec/patte ... ings.html#
- https://developer.apple.com/library/mac ... ences.html
- http://elementary.io/docs/human-interfa ... #concision

Great start! Wanted to do this myself but didn't find the time. Some questions and ideas:

At the purpose section it's not clear that you are talking about applications, and not Plasma. Simple to add. The advice to keep settings simple could be read as in terms of the storage, like only two xml levels. Furthermore it is typical for KDE to let the user configure the hell out of every software. Maybe we should cover this vision here too.

I stumbled over "It shouldn't be context aware" misreading the "don't". Maybe change like "Have always the same landing page..." or the like. The grouping stuff sounds over-complex to me. You define two different types of settings? And 7 could be too low for checkboxes only (which would be a checkbox group, although). What we really need are examples.

Regarding the advanced stuff we decided to go with the KCM design in this thread, didn't we? Then it's only one layout with a scrollarea. Grouping is done via sidebar icons. No tabs. Placement of controls can be in up to three columns. There should always be a preview (this might be too much, but I would want to have the Apply button enabled).

Something new: I changed my environment recently once again back from Intel graphics to nvidia. Installing the OS is a piece of cake but when it comes to app configuration that takes a lot of time. I'd request an import/export function for every application, perhaps with some options to select what to export. For instance, KMail has something similar but terrible implemented and not working for me.
* Always provide functions to export/import all settings. 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 be straightforward as much as possible, let the user just confirm when data are being overwritten.

I'd also define where data are stored, ~/.config/<app> or ~/.kde5/<app> or ~/.config/kde/app/<app>/. Sometimes I want to purge an installation and it's easier when all pieces are at the same place (Krusader has two or three files spread around several directories).

* Purpose
The settings provide user-customizable options how an application or plasma (KCM) should behave. The settings are intended for options that are not accessed frequently and are persitent.


* 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. If you need help to define the defaults ask: viewforum.php?f=285

- Powerful when needed
Even so KDE is all about options, try to keep your settings as small and simple as posible. Don't provide options that can be determine without user interaction.
Remember: every option requieres more code and more testing!

- Respect the privacy of the users
Always use an opt-in, never an opt-out for those options.

- Provide functions to export/import all settings. 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 be straightforward as much as possible, let the user just confirm when data are being overwritten.

- Try to provide a preview area if possible

- When a change is applied, the application should change immediately to reflect the change. No restarting should be requiered.


* Grouping
- Group your settings, if you have more then 11
For presentation, group related settings in groups with up to 11 options. Placement of options can be in up to three columns.

- Scructure your groups:
If you have more then 7 groups add another level of grouping. Try not to have more then 3 levels of grouping.

- Sort your options and groups by importance.

- If you have more then 1 group of options think about providing a search field to help the user finding a certain option

For an example KCM: https://community.kde.org/File:Systemse ... 3-ht-2.png


* Naviagtional patterns
- Don't be context aware. You should always start with the same landing page regardless of the application context

- For 2 levels of grouping use the List - Detail pattern
see https://techbase.kde.org/Projects/Usabi ... onPatterns

- For 3 levels of grouping use the Breadcrumb - List - Details (whats the correct name ?)
(TODO needs to be added to the navigation patterns in the HIG)
see https://community.kde.org/KDE_Visual_De ... pplication for details and mockups


* Advanced options
Advanced options, are options that are not important to most users, you can set sensible defaults for them, but can't remove them, because they are essential to some users.
Hide advanced options by default, but provide a button to slide open them. Try to use a descriptive title for the button, only use "Advanced options" for labeling if you cant find anything better.

* Wizard
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.
Don't use a wizard to edit options.

* GHNS
TODO

Related Links / Settings in other HIGs
- see initial post -


Glossary?
Should we add a glossary to explain the terms used?
- settings
- options
- controls
- ... ?

I like the combination of general recommendations with our vision. But Powerful when needed is rather to have options to configure the hell out of an application, hidden behind the standard settings that are simple by default.

"Try to provide a preview area if possible": I'd be more demanding here. "Always provide a preview with the option to select one out of a couple of predefined settings. If the preview makes no sense you should provide at least those predefined settings to allow the user to switch between alternatives."

I scribbled the idea once again but this time with a more generic content - and with markups.

1) Access to the groups is done with the sidebar. Use icons with labels for the selection.
2) The preview has to be on the top of the content area. Anchor the preview so that users can have more space for the area below using the horizontal splitter (Remark: The mockup has very large splitters. Should be visually less obtrusive.)
3) Allow users to add more predefined settings to the preview selection via Get Hot New Stuff (GHNS). (Remark: Not sure if this should be a link or something else. In the previous examples we had +/- buttons.)
4) Provide access to the most relevant settings at the Standard section. Make sure that these options are easy to understand.
5) Indicate that Advanced options are available but do not open those on demand only.
9) Scroll the whole area of options but not the preview, if necessary.
6) Settings have to offer Reset to switch back to factory settings (Remark: We could remove this since the preview itself is kind of reset)
7) Allow users to export the current settings to a file that can be easily imported on any other machine (Remark: Icons only here to avoid a button wall. Without Reset we could change it back to textual captions).
\8) Allow to Apply the current settings to the application without closing the dialog.

Missing: Better description of the preview-selector. What is shown when the selection is tweaked? (E.g. Breeze colors but red outlines). Also there has to be a confirmation when changes were made. Furthermore, we should define resize behavior. I would make the dialog non-resizable, if possible. If not the content defines the minimum, meaning no right anchors, no stretching or the like.

Glossary: Options/Setting, Preview-Selector, Group, ...

Not much discussion here, so I went forward to the next QA step - verification at the mailing list. In order to have a coherent wiki style I edited the text a little bit and extended the purpose part, removed "Don't provide options that can be determine without user interaction." (it's a triple negation, right? *g*), rephrased the text at some places, removed the 11 items per group since we have a potentially large scroll area and the organization should be based on logical information, and removed the list/breadcrumb pattern because this guideline is a pattern on its own. If those changes do not make sense don't hesitate to insult me on the mailing list.

https://mail.kde.org/pipermail/kde-guid ... 00895.html