diff --git a/source/img/EditMode.png b/source/img/EditMode.png new file mode 100644 index 0000000..c637e5b Binary files /dev/null and b/source/img/EditMode.png differ diff --git a/source/img/HIG-Settings.png b/source/img/HIG-Settings.png new file mode 100644 index 0000000..0238f48 Binary files /dev/null and b/source/img/HIG-Settings.png differ diff --git a/source/img/PartialEditMode.png b/source/img/PartialEditMode.png new file mode 100644 index 0000000..7a80e96 Binary files /dev/null and b/source/img/PartialEditMode.png differ diff --git a/source/img/TwoLists.png b/source/img/TwoLists.png new file mode 100644 index 0000000..0de5d23 Binary files /dev/null and b/source/img/TwoLists.png differ diff --git a/source/img/ViewMode.png b/source/img/ViewMode.png new file mode 100644 index 0000000..03ff3dc Binary files /dev/null and b/source/img/ViewMode.png differ diff --git a/source/index.rst b/source/index.rst index 4de7eae..5642213 100644 --- a/source/index.rst +++ b/source/index.rst @@ -1,100 +1,100 @@ .. 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 (Desktop Platform) ================================================= .. toctree:: :caption: Contents: :titlesonly: introduction/index layout/index style/index components/index patterns/command/index + patterns/content/index patterns/navigation/index - patterns/iconandtext resources/contribute .. Indices and tables ================== * :ref:`genindex` * :ref:`modindex` * :ref:`search` The Classic KDE Human Interface Guidelines (HIG) offer application designers and developers a set of recommendations for designing and developing user interfaces for QWidget-based, desktop-only applictions. Their aim is to improve the experience for users by making application interfaces more consistent and hence more intuitive and learnable. For applications which are supposed to run on both desktop and mobile systems, consult the [[../KirigamiHIG | Kirigami Human Interface Guidelines (HIG)]] Getting Started --------------- * :doc:`introduction/vision` - The overall vision and principles that guide the design and development of user interfaces for KDE software. * :ref:`Concept` - Creating a project vision, determining the users, and the scenarios of use. * :ref:`Organization` - Guidelines on how an application’s content and functionality are ordered and categorized. * :doc:`introduction/architecture` Architecture of KDE * :ref:`Contribute` Contribute to the HIG]] Behaviour --------- This section contains guidelines for application behaviour. * :ref:`ViewingAndNavigation` Guidelines on controls and patterns to use for viewing, navigating and performing actions on application content. * :ref:`EditingAndManipulation` Guidelines on controls and patterns to use for selection and input. * :ref:`UserAssistance` Guidelines on tooltips, notifications, messages and help. * :ref:`Patterns` Patterns - Guidelines on how to use controls in different combinations to accomplish specific behaviors. Presentation ------------ Presentation deals with the visual design of the user interface. * :ref:`Layout` Guidelines regarding the placement and ordering of onscreen elements. Includes guidance on layout patterns, alignment, size and spacing. * :ref:`Style` Guidelines on the use of colour, icon design and the typography to communicate with a consistent visual vocabulary. * :ref:`Text` Guidelines for the written, language-based elements of the interface. Includes guidelines on wording, capitalization and localization. * :doc:`style/typography` Tools and Resources ------------------- The following tools and resources are offered to help with following these guidelines. * :ref:`ControlsList` A complete listing of all user interface controls and their guidelines in alphabetical order. * :ref:`MockupToolkit` Includes UI controls stencils, color swatches and fonts to help create the visual design your application. * :ref:`About` Learn more about the philosophy behind the KDE HIG. * [http://forum.kde.org/viewforum.php?f=285 Visual Design Group forum] - Ask for help and share your design ideas. Quick index for the new mobile-oriented HIG (work in progress) -------------------------------------------------------------- Drawers & FAB ^^^^^^^^^^^^^ * :ref:`GlobalDrawer` * :ref:`ContextDrawer` * :ref:`FloatingActionButton` * :ref:`QuickContentActions` Navigation ^^^^^^^^^^ * :ref:`ViewsByColumns` * :ref:`ContentsFilter` * :ref:`Views-by-tabs` Editing ^^^^^^^ * :ref:`RearrangeListItems` | Rearrange list's items]] App settings ^^^^^^^^^^^^ * :ref:`VBCtoSettings` | Views-by-columns approach applied to settings]] Cross-apps interactions ----------------------- * :ref:`SharingContents` | Sharing contents to an other app]] Complete app examples --------------------- * App store (to be applied to Muon Mobile) * E-mail client * Media player diff --git a/source/patterns/content/breadcrumb.rst b/source/patterns/content/breadcrumb.rst new file mode 100644 index 0000000..a42c07e --- /dev/null +++ b/source/patterns/content/breadcrumb.rst @@ -0,0 +1,54 @@ +Breadcrumbs +=========== + +Purpose +------- + +The *breadcrumbs* pattern is a navigation aid that helps to keep track +of the location within applications or documents by a) providing +information about the current position within the hierarchy, and b) +offering shortcut links to jump to previous positions without using the +Back button (e.g. home > documents > business). The breadcrumb trail +extends the address bar with (clear) access to subsections. It has the +advantage of distinctness in usage. As a drawback the breadcrumbs +usually needs more space. + +Guidelines +---------- + +Is this the right control +~~~~~~~~~~~~~~~~~~~~~~~~~ + +- Use a breadcrumb trail for orientation and navigation in strictly + hierarchical data, :doc:`n-deep content structures `. + Apply other controls like tags for flat or less organized content (e.g. wizards). +- Make sure the breadcrumbs has only supportive functions. Do not use + it as primary and exclusive navigation pattern. +- Do not use a breadcrumbs to just identify or label the position. +- Do not make the breadcrumb navigation dynamic by adopting the last + user's interactions (known as 'path breadcrumbs'). Breadcrumbs should + show the hierarchy, not the user's history. + +Behavior +~~~~~~~~ + +- Link all breadcrumbs steps to the appropriate page or position + respectively, except the current. +- Add the current position to the breadcrumbs. +- Consider to provide a dropdown list for alternative options on each + level. But always offer one-click access by default. +- Consider to make the breadcrumbs interactive via drag and drop, e.g. + copy/move files by dragging them to a breadcrumb step or to an item + of the dropdown list, apply a sequence of processing steps, etc. + +Appearance +~~~~~~~~~~ + +- Keep the breadcrumbs plain; do not use icons or other controls. +- Place the breadcrumbs above the content control (e.g. file list). + +- Do not place it above the navigation control (e.g. directory + structure) +- Do not integrate it into the tool bar +- Do not place it in an extra tool bar. +- Do not integrate it into the title bar. diff --git a/source/patterns/content/duallist.rst b/source/patterns/content/duallist.rst new file mode 100644 index 0000000..f5b5979 --- /dev/null +++ b/source/patterns/content/duallist.rst @@ -0,0 +1,77 @@ +Duallist +======== + +Purpose +------- + +Multiple selection in lists with more than a few items might become +difficult because selected as well as available items are not visible at +once. As an alternative approach the *dual-list pattern* (also known as +list builder, or paired lists) was introduced. It consists of two +standard list boxes with the option to move items from one list to the +other and back. Dual-lists are useful for extended multiple selection in +general, especially for huge sets of items or in case of elaborate +selections. The trade-off is the rather large amount of space that is +needed to show two adjoined lists. + +Example +------- + +.. image:: /img/TwoLists.png + :alt: twoLists.png + +Guidelines +---------- + +Is this the right control +~~~~~~~~~~~~~~~~~~~~~~~~~ + +- Use a dual-list pattern for multiple selection and in case of large + lists. +- In case of limited screen real estate consider to change the workflow + into repeated selections of smaller lists or by applying a hierarchy + to the data. +- Do not use a dual list to show data primarily. + +Behavior +~~~~~~~~ + +- Make the left list the standard list containing all available + options. The right list holds all currently selected items. +- Place move/remove buttons (right and left arrows) centered and in + between the two lists. +- Disable a button if the respective list is empty. +- Provide drag ‘n drop of items between lists. +- Double click on an item adds it to the current list, or removes it + respectively. +- Allow multiple selection of items within one list. +- If an instance of one item can be repeated (such as a spacer), copy + (rather than move) the item from the available pool of items to the + list of current items. +- If the list of current items can be reordered, place up/down buttons + to the right of the list of current items. Only enable the up/down + buttons when an item is selected and can be moved. Drag and drop may + also be used in addition to reorder the list. +- Do not have blank list items; use meta-options, e.g. (None) instead. +- Place options that represent general options (e.g. All, None) at the + beginning of the list. +- Sort list items in a logical order. Make sure sorting fits + translation. + +Appearance +~~~~~~~~~~ + +- Ensure that the list boxes are of equal height and width. +- Alternate row color (use theme settings). +- Make both list controls large enough that it can show at least four + items at a time without scrolling. +- If the lists appears in a dialog or utility window, consider making + the window and the lists within it resizeable so that the user can + choose how many list items are visible at a time without scrolling. + Each time the user opens this dialog, set its dimensions to those + that the user last resized it to. +- Label both lists view with a descriptive caption to the top. +- Create a buddy relation so access keys are assigned. +- End each list label with a colon. +- Use :doc:`sentence style capitalization ` + for list view items. diff --git a/source/patterns/iconandtext.rst b/source/patterns/content/iconandtext.rst similarity index 100% rename from source/patterns/iconandtext.rst rename to source/patterns/content/iconandtext.rst diff --git a/source/patterns/content/index.rst b/source/patterns/content/index.rst new file mode 100644 index 0000000..1821a28 --- /dev/null +++ b/source/patterns/content/index.rst @@ -0,0 +1,21 @@ +Content patterns +================ + +.. toctree:: + :maxdepth: 1 + :titlesonly: + :hidden: + + breadcrumb + duallist + iconandtext + settings + sliderspin + viewingediting + +- :doc:`breadcrumb` +- :doc:`duallist` +- :doc:`iconandtext` +- :doc:`settings` +- :doc:`sliderspin` +- :doc:`viewingediting` diff --git a/source/patterns/content/settings.rst b/source/patterns/content/settings.rst new file mode 100644 index 0000000..a6abecd --- /dev/null +++ b/source/patterns/content/settings.rst @@ -0,0 +1,119 @@ +Settings +======== + +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. Following +KDE's "Simple by default, powerful when needed" +:doc:`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, for instance, details vs. icon view. 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: Provide enough options for the perfect + customization according individual needs and preferences. But even + though customizability is very important for KDE software, try to + keep your settings dialog as small and simple as possible. Remember: + every option requires more code and more testing! +- 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). + +Layout +~~~~~~ + +- Organize your settings in logical groups. (#1 in the example). +- Split options per group into standard and advanced. Make the standard + easy to use for everyone. (#5) +- Offer several pre-defined profiles or schemes, and let the user + decide what type of configuration should be active. (#3) +- Consider to add access to third-party profiles/schemes via Get Hot + New Stuff! (use the label "Get New [term used for profile in your + case]s"), if available for this group. (#4) +- Show a live preview for visual features. Omit this section if it's + not relevant. +- Provide functions to export/import all settings. (#7) 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. + +Behavior +~~~~~~~~ + +- When the user changes the default switch to a special profile ("User" + or "Current"). This profile cannot be applied unless it is renamed + individually. Access to rename (and delete) is done per context menu. + Indicate user-defined profiles by using italic font for the name. +- Sort your options and groups by importance. +- When a change is applied, the application should adopt it immediately + without the need to restart it. +- Do not change the settings dialog depending on the context. You + should always start with the same landing page regardless of the + application context. +- 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. +- Do not hide options conditionally. Don't make a user guess what + options need to be changed to have other options available. Disable + options instead and hint the user why the options are disabled. + +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 options are easy to understand. +#. Indicate that Advanced options 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. diff --git a/source/patterns/content/sliderspin.rst b/source/patterns/content/sliderspin.rst new file mode 100644 index 0000000..73863b2 --- /dev/null +++ b/source/patterns/content/sliderspin.rst @@ -0,0 +1,46 @@ +Slider and spin box +=================== + +Purpose +------- + +:doc:`Spin boxes ` allow a user to enter a specific +value, and gives users fine control over which value is chosen, +but are slow when moving over large ranges of values. +:doc:`Sliders ` allow for quickly changing values +over long ranges, but make it harder to select very specific values. In +cases where both are necessary, combing the two is sometimes a good +approach. + +Guidelines +---------- + +Is this the right control +~~~~~~~~~~~~~~~~~~~~~~~~~ + +- Use both a slider and spin box when the value is constrained at both + ends, and when there is a large range of values (more than 20 steps) + but precise control over the value is needed nevertheless. +- Consider to use only slider *or* spin box if a well defined workflow + makes the other redundant. + +Behavior +~~~~~~~~ + +- The values of the slider and spin box should be linked so changes to + one are immediately reflect in another. +- Make sure that all requirements from slider and spin box are met. + +Appearance +~~~~~~~~~~ + +- The spin box should be aligned with the long axis of the slider. So + if the slider is horizontal, the spin box should be to the right of + the slider and aligned vertically with the center of the slider. If + the slider is vertical, the spin box should be below the slider and + aligned horizontally with the center of the slider. +- Provide a single label using a text label above it or to the left of + the widgets, using sentence capitalization. Provide an access key in + the label that should give focus directly to the spin box. +- Mark significant values along the length of the slider with text or + tick marks. diff --git a/source/patterns/content/viewingediting.rst b/source/patterns/content/viewingediting.rst new file mode 100644 index 0000000..da5e765 --- /dev/null +++ b/source/patterns/content/viewingediting.rst @@ -0,0 +1,36 @@ +Viewing vs editing +================== + +Purpose +------- + +In most cases information should be presented for viewing not editing. +Presenting input controls to the user when they are not needed creates +unnecessary clutter and distraction, interfering with effective +presentation of the information. + +Guideline +--------- + +.. image:: /img/ViewMode.png + :alt: Viewing + +- Do not use input controls to show information unless there is an + explicit request to edit the information. +- Follow the typography, alignment, and spacing guidelines to layout + information in a way that is easy to understand. +- Provide a clear visual hierarchy (where to look first, where to look + next). The example above uses a large contact photo to anchor the + layout and the contact name is set in large type to direct the users + eye to next piece of information. +- Provide a separate mode for editing the data when requested by the + user (via a button, toolbutton or menu item). + +.. image:: /img/EditMode.png + :alt: Editing + +- Alternatively, in-line editing can be provided to edit a single data + element at a time. + +.. image:: /img/PartialEditMode.png + :alt: Line-in editing