diff --git a/source/index.rst b/source/index.rst index ccc62f9..19e0dbd 100644 --- a/source/index.rst +++ b/source/index.rst @@ -1,47 +1,86 @@ .. KDE HIG documentation master file, created by sphinx-quickstart on Tue Feb 6 13:29:47 2018. You can adapt this file completely to your liking, but it should at least contain the root `toctree` directive. KDE Human Interface Guidelines ============================== .. toctree:: - :caption: Contents: - :titlesonly: + :hidden: introduction/index layout/index style/index components/index patterns/command/index patterns/content/index patterns/navigation/index resources/about resources/contribute resources/glossary .. Indices and tables ================== * :ref:`genindex` * :ref:`modindex` * :ref:`search` -The KDE Human Interface Guidelines (HIG) offer application designers and developers -a set of recommendations for designing and developing user interfaces for mobile, -desktop, convergent applications and workspace widgets. Their aim is to improve the -experience for users by making application and widget interfaces more consistent -and hence more intuitive and learnable. +The KDE Human Interface Guidelines (HIG) offer designers and developers a set of recommendations for producing beautiful, usable, and consistent user interfaces +for convergent desktop and mobile applications and workspace widgets. Their aim +is to improve the experience for users by making application and widget +interfaces more consistent and hence more intuitive and learnable. .. figure:: /img/HIGDesignVisionFullBleed.png :scale: 50 % :alt: Different DPIs on desktop and mobile ''Simple by default, powerful when needed.'' -KDE encourages developing and designing for customization, while providing good -default settings. Integrating into other desktop environments is also a virtue, -but ultimately we aim for perfection within our own Plasma desktop environment -with the default themes and settings. This aim should not be compromised. + +Design Vision +------------- +KDE's design vision focuses on two attributes of KDE software that connect its +future to its history: + +- **Simple by default** - Simple and inviting. KDE software is pleasant + to experience and easy to use. +- **Powerful when needed** - Power and flexibility. KDE software allows + users to be effortlessly creative and efficiently productive. + +Design Principles +----------------- +The following design principles are used in support of the Design Vision. + +- **Simple by default** + + - *Make it easy to focus on what matters.* - Remove or minimize elements + not crucial to the primary or main task. Use spacing to keep things + organized. Use color to draw attention. Reveal additional information or + optional functions only when needed. + - *I know how to do that!* - Make things easier to learn by reusing design + patterns from other applications. Other applications that use good design + are a precedent to follow. + - *Do the heavy lifting for me.* - Make complex tasks simple. Make novices + feel like experts. Create ways in which your users can naturally feel + empowered by your software. + +- **Powerful when needed** + + - *Solve a problem.* - Identify and make very clear to the user what need is + addressed and how. + - *Always in control.* - It should always be clear what can be done, what is + currently happening, and what has just happened. The user should never + feel at the mercy of the tool. Give the user the final say. + - *Be flexible.* - Provide sensible defaults but consider optional + functionality and customization options that do not interfere with the + primary task. + +.. note:: + Note: KDE encourages developing and designing for customization, while + providing good default settings. Integrating into other desktop environments + is also a virtue, but ultimately we aim for perfection within our own Plasma + desktop environment with the default themes and settings. This aim should + not be compromised. diff --git a/source/introduction/index.rst b/source/introduction/index.rst index 78794d6..35c43ba 100644 --- a/source/introduction/index.rst +++ b/source/introduction/index.rst @@ -1,25 +1,23 @@ Introduction ============ .. toctree:: :titlesonly: :hidden: - vision architecture convergence devicetypes responsive concept personas research -* :doc:`vision` * :doc:`architecture` * :doc:`convergence` * :doc:`devicetypes` * :doc:`responsive` * :doc:`concept` * :doc:`personas` * :doc:`research` diff --git a/source/introduction/vision.rst b/source/introduction/vision.rst deleted file mode 100644 index 3e4f04d..0000000 --- a/source/introduction/vision.rst +++ /dev/null @@ -1,49 +0,0 @@ -Design Vision and Principles -============================ - -.. figure:: /img/HIGDesignVisionFullBleed.png - :scale: 50 % - :alt: Different DPIs on desktop and mobile - - ''Simple by default, powerful when needed.'' - - -Design is driven at the highest level by a vision. We rely on a set of design principles to fulfill that design vision. These principles guide all aspects of the user interface design. - -Design Vision -------------- -The design vision focuses on two attributes of KDE software that connect its past to its future. - -- ''Simple by default'' - Simple and inviting. KDE software is pleasant - to experience and easy to use. -- ''Powerful when needed'' - Power and flexibility. KDE software allows - users to be effortlessly creative and efficiently productive. - -Design Principles ------------------ -The following design principles are used in support of the Design Vision. - -- Simple by default - - - *Make it easy to focus on what matters.* - Remove or minimize - elements not crucial to the primary or main task. Use spacing to - keep things organized. Use color to draw attention. Reveal - additional information or optional functions when needed, later in - the presentation. - - *I know how to do that!* - Make things easier to learn by reusing - design patterns from other applications. Other applications that - use good design are a precedent to follow. - - *Do the heavy lifting for me.* - Make complex tasks simple. Make - novices feel like experts. Create ways in which your users can - naturally feel empowered by your software. - -- Powerful when needed - - - *Solve a problem.* - Identify and make very clear to the user what - need is addressed and how. - - *Always in control.* - It should always be clear what can be done, - what is happening and what happened. The user should never feel at - the mercy of the tool. Give the user the final say. - - *Be flexible.* - Provide sensible defaults but consider optional - functionality or customizations that do not interfere with the - primary task. diff --git a/source/patterns/content/settings.rst b/source/patterns/content/settings.rst index f719160..90a64d9 100644 --- a/source/patterns/content/settings.rst +++ b/source/patterns/content/settings.rst @@ -1,117 +1,117 @@ Settings ======== A *settings page* provides the ability to customize how an application or Plasma widget should behave. It is intended for settings that are persistent but not changed very frequently. Following KDE's "Simple by -default, powerful when needed" :doc:`design mantra `, +default, powerful when needed" :doc:`design mantra <../../index>`, settings are split into common and advanced groups. Advanced settings are not important to most users but essential for some, and therefore can't be removed. Those settings are hidden by default to reduce the mental overhead of using the settings page, but with easy access. When to use ----------- - Use the settings page to display settings that are persistent but not accessed or changed very frequently. The toolbar or the main menu (and optionally context menus) are more appropriate places for settings that are frequently accessed and changed, such as icon view style or sort order. - Do not use settings pages to change the properties of a selected item. Instead, use a properties dialog or a contextual editing panel. - Do not use the settings page for potentially dangerous developer settings like the name of an SQL table. Instead, use configuration files or separate dialogs. How to use ---------- - **Simple by default**: Define smart and polite defaults so that your target :doc:`personas ` don't have to alter them at all. - **Powerful when needed**: Provide enough settings for the perfect customization according individual needs and preferences. But even though customizability is very important for KDE software, try to keep your settings page as small and simple as possible. Remember: every option requires more code and more testing, and makes the settings page slower to use. - Respect the privacy of the users: Always use opt-in, never an opt-out model for features that transmit potentially private data (e.g. usage statistics). See KDE's `Telemetry Policy `_ for details. Implementation -------------- - For a desktop app, put your settings page inside a dialog window and do not allow it to have a vertical or horizontal scrollbar because all of the content will not fit. Instead, separate your controls into more groups and make use of :doc:`tabbed views `. This does not apply to scrollbars within inline tables and grid views, which are acceptable. - On mobile, use a full-screen view for your settings page. Vertical scrolling is acceptable. - Lay out your settings page according to the :doc:`alignment ` guidelines. The overall layout should appear to be centered, with with section labels on the left side, and controls on the right. Tables and grid views are the exception, and should span the window width. - Organize your settings into logical groups, with more important groups appearing higher up on the page. Separate the groups with whitespace or put them into different tabs of a :doc:`tabbed view ` (if appropriate). Try to avoid the use of group boxes to distinguish sections. (#1 in the example) - Separate common and advanced settings into different groups. If necessary, hide the advanced settings behind a collapsible group box. Make the standard settings comprehensible and easy to use. (#5) - Consider adding access to third-party add-ons via Get Hot New Stuff!, if available for this group. Use the label "Get New [term used for add-on content]s" (#4) - When a change is applied, the application should adopt it immediately without the need to restart it. - Do not change the settings page depending on the context. It should always start with the same landing page regardless of the application context. - Do not use a wizard to change settings. Only use a wizard if a group of settings are all interrelated and must be edited all at once, e.g. setting up an email account. - If some of the program's settings are only applicable in certain contexts, do not hide the inapplicable ones. Instead, disable them and hint to the user why they're disabled. **Exception:** it is acceptable to hide settings for non-existent hardware. For example, it's okay to hide the touchpad configuration when no touchpad is present. Mockup ~~~~~~ .. image:: /img/HIG-Settings.png :alt: HIG-Settings.png #. Access groups via sidebar. #. The preview has to be on the top of the content area. #. Offer a good number of pre-defined profiles/schmes to let the user choose one out of different factory settings. Anchor the profiles so that users can have more space for the area below using the horizontal splitter. Cut long captions with ellipsis and show the full name in a tooltip. (Remark 1: The mockup has very large splitters. The implementation should be visually less obtrusive.) (Remark 2: The profile selection replaces the former "reset (to default)" function.) #. Allow users to add more profiles via Get Hot New Stuff (GHNS). Organize the setting in a way that GHNS access is per group and not global. #. Provide access to the most relevant settings at the Standard section. Make sure that these settings are easy to understand. #. Indicate that Advanced settings are available but keep this section collapsed by default. Use a descriptive label so that it reflects the functionality. #. Allow users to export the current settings to a file that can be easily imported on any other machine. #. Allow to Apply the current settings to the application without closing the dialog. #. Provide access to functions for user-defined profiles per context menu and standard shortcuts. #. Scroll the whole area of options but neither the preview not the profiles, if necessary.