<div dir="ltr">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?</div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-01 14:28 GMT+01:00 Thomas Pfeiffer <span dir="ltr"><<a href="mailto:thomas.pfeiffer@kde.org" target="_blank">thomas.pfeiffer@kde.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I like!<br>
Inline some alternative wording suggestions and minor edits:<br>
<span class=""><br>
On Sonntag, 31. Januar 2016 15:36:34 CET Heiko Tietze wrote:<br>
> After a request on the KDE forums (<a href="https://forum.kde.org/viewtopic.php" rel="noreferrer" target="_blank">https://forum.kde.org/viewtopic.php</a>?<br>
> f=285&t=130573), Fabian drafted a guideline for simple vs. advanced settings<br>
> that actually recapitulates what we had in mind for the KCMs.<br>
><br>
> HIG/Patterns<br>
> ** [[Projects/Usability/HIG/SettingsPattern|Settings]] - Provide setting in<br>
> both simple as well as advanced configurations.<br>
><br>
> HIG/SettingsPattern<br>
> == Purpose ==<br>
> The settings dialog provides user-customizable options how an application or<br>
> plasma (KCM) should behave. The dialog is intended for options that are not<br>
> accessed frequently and are persitent.<br>
> KDE aims to be highly configurable on the one hand but also to be simple for<br>
> beginners.<br>
> Therefore the settings are split into simple vs. advanced.<br>
<br>
</span>Following KDE's "Simple by default, powerful when needed" design mantra,<br>
settings are split into simple vs. advanced ones.<br>
<span class=""><br>
> Advanced settings are options that are not important to most users but<br>
> essential for some, and can't removed therefore. Those options are hidden<br>
> by default, but with an easy access in order to improve learnability.<br>
><br>
> == Guidelines ==<br>
> === Is this the right control ===<br>
> * Use this pattern for all settings that are relevant to change for users.<br>
> * Do not use the settings dialog for frequently accessed properties like<br>
> different views (for instance details vs. icon view). Use a toolbar or<br>
> context menu for those options.<br>
<br>
</span>Use the toolbar or main menu (and optionally context menu) for these options.<br>
<span class=""><br>
> * Do not use the settings dialog for rarely changed or developer options<br>
> like the sql table name. Use extra configuration files or dialogs for those<br>
> options. === General recommendations ===<br>
> * Simple by default: Define smart and polite defaults. Set the defaults in a<br>
> way that most users don't have to alter them at all.<br>
> * Powerful when needed: Even so KDE is all about options, try to keep your<br>
> settings as small and simple as possible. Remember: every option requires<br>
> more code and more testing!<br>
<br>
</span>Even though customizability is very important for KDE software, try to keep<br>
your settings dialog as small and simple as possible.<br>
<span class=""><br>
> * Respect the privacy of the users: Always use an opt-in, never an opt-out<br>
> for those options.<br>
<br>
</span>Always use opt-in, never an opt-out model for features that transmit<br>
potentially private data (e.g. usage statistics).<br>
<span class=""><br>
> === Behavior ===<br>
> * Provide functions to export/import all settings. If splitting the options<br>
> into app related (such as colors, fonts, etc.) and account related (for<br>
> instance personal settings, mail accounts..) make sense, let the user decide<br>
> what to export. Import has to be straightforward as much as possible; let<br>
> the user just confirm when data are being overwritten.<br>
<br>
Provide functions to export/import all settings. If splitting the options<br>
</span>into app-related (such as colors, fonts, etc.) and account-related (for<br>
instance personal settings, mail accounts...) make sense, let the user decide<br>
what to export. Import has to as straightforward as possible; let the user<br>
<span class="">just confirm when data are being overwritten.<br>
<br>
> * Consider to add access to third-party configurations via Get Hot New<br>
> Stuff!. * Do not use a wizard to edit options. Only use a wizard to set<br>
> options if actually a group of options all have to be edited at once, eg<br>
> creating an account or a first run wizard.<br>
> * When a change is applied, the application should adopt immediately without<br>
> the need to restart.<br>
<br>
</span>* When a change is applied, the application should adopt it immediately<br>
without the need to restart it.<br>
<span class=""><br>
> === Appearance ===<br>
> * Organized your settings in logical groups.<br>
> * Sort your options and groups by importance.<br>
> * If you have more then one group of options think about providing a search<br>
> field to help the user finding a certain option<br>
> * Do not be context aware. You should always start with the same landing<br>
</span>> page regardless of the application context.<br>
<br>
Do not change the settings dialog depending on the context. You should always<br>
start with the same landing page regardless of the application context.<br>
<span class=""><br>
> === Example ===<br>
> (Mockup from <a href="http://i.imgur.com/cpGQBBY.png" rel="noreferrer" target="_blank">http://i.imgur.com/cpGQBBY.png</a>  with caption of the markups)<br>
<br>
<br>
</span>_______________________________________________<br>
kde-guidelines mailing list<br>
<a href="mailto:kde-guidelines@kde.org">kde-guidelines@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-guidelines" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/kde-guidelines</a><br>
</blockquote></div><br></div>