[kde-guidelines] HIG pattern about simple vs. advanced settings

[Thomas Pfeiffer]

I like!
Inline some alternative wording suggestions and minor edits:

On Sonntag, 31. Januar 2016 15:36:34 CET Heiko Tietze wrote:
> After a request on the KDE forums (https://forum.kde.org/viewtopic.php?
> f=285&t=130573), Fabian drafted a guideline for simple vs. advanced settings
> that actually recapitulates what we had in mind for the KCMs.
> 
> HIG/Patterns
> ** [[Projects/Usability/HIG/SettingsPattern|Settings]] - Provide setting in
> both simple as well as advanced configurations.
> 
> HIG/SettingsPattern
> == Purpose ==
> 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.
> KDE aims to be highly configurable on the one hand but also to be simple for
> beginners. 
> Therefore the settings are split into simple vs. advanced.

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.
> 
> == Guidelines ==
> === 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
> different views (for instance details vs. icon view). Use a toolbar or
> context menu for those options.

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: Even so KDE is all about options, try to keep your
> settings as small and simple as possible. Remember: every option requires
> more code and more testing!

Even though customizability is very important for KDE software, try to keep 
your settings dialog as small and simple as possible.

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

Always use opt-in, never an opt-out model for features that transmit 
potentially private data (e.g. usage statistics).

> === Behavior ===
> * 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.

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 as straightforward as possible; let the user 
just confirm when data are being overwritten.

> * Consider to add access to third-party configurations via Get Hot New
> Stuff!. * 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.
> * When a change is applied, the application should adopt immediately without
> the need to restart.

* When a change is applied, the application should adopt it immediately 
without the need to restart it.

> === Appearance ===
> * Organized your settings in logical groups.
> * Sort your options and groups by importance.
> * If you have more then one group of options think about providing a search
> field to help the user finding a certain option
> * Do not be context aware. You should always start with the same landing
> page regardless of the application context.

Do not change the settings dialog depending on the context. You should always 
start with the same landing page regardless of the application context.

> === Example ===
> (Mockup from http://i.imgur.com/cpGQBBY.png  with caption of the markups)