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

[Heiko Tietze]

Thanks for the review, sounds reasonable. But I'm wondering if we really
need the legacy (factory) reset button (#6 in the mockup) since the preview
offers access to several factory settings. Despite the ugly gear icon which
is not intuitive. Objections to against removing it?

2016-02-01 14:28 GMT+01:00 Thomas Pfeiffer <thomas.pfeiffer at kde.org>:

> 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)
>
>
> _______________________________________________
> kde-guidelines mailing list
> kde-guidelines at kde.org
> https://mail.kde.org/mailman/listinfo/kde-guidelines
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-guidelines/attachments/20160201/d70d54f5/attachment.html>