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

[Heiko Tietze]

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. 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.
* 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!
* Respect the privacy of the users: Always use an opt-in, never an opt-out for 
those options.
=== 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. 
* 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.
=== 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
=== Example ===
(Mockup from http://i.imgur.com/cpGQBBY.png  with caption of the markups)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-guidelines/attachments/20160131/059870b9/attachment.sig>