diff --git a/source/img/HoldPhones_Figure-2.png b/source/img/HoldPhones_Figure-2.png new file mode 100644 index 0000000..b682774 Binary files /dev/null and b/source/img/HoldPhones_Figure-2.png differ diff --git a/source/img/HoldPhones_Figure-4.png b/source/img/HoldPhones_Figure-4.png new file mode 100644 index 0000000..3dc8c7e Binary files /dev/null and b/source/img/HoldPhones_Figure-4.png differ diff --git a/source/img/Switch-theme.jpeg b/source/img/Switch-theme.jpeg new file mode 100644 index 0000000..a663cb3 Binary files /dev/null and b/source/img/Switch-theme.jpeg differ diff --git a/source/index.rst b/source/index.rst index 5642213..b9c4f33 100644 --- a/source/index.rst +++ b/source/index.rst @@ -1,100 +1,101 @@ .. 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 + resources/about 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/introduction/convergence.rst b/source/introduction/convergence.rst new file mode 100644 index 0000000..74e335c --- /dev/null +++ b/source/introduction/convergence.rst @@ -0,0 +1,30 @@ +Optimized convergence +===================== + +Kirigami is made with convergent applications in mind. "Convergent" for +us means that one instance of an application can adapt its user +interface (UI) depending on the context, most importantly depending on + +- Primary input method (for now "pointing device + keyboard" vs. touch, + in the future possibly also simple directional inputs like TV + remotes, game controllers, in-vehicle controls, ...) +- Physical screen size (for now phone vs. tablet vs. laptop/desktop + screen, in the future possibly also TV screens, smart watches, ...) +- Screen orientation / aspect ratio (mostly portrait vs. landscape) + +Kirigami is not about simple "responsive" user interfaces, though (i.e. +those which just adapt their layout a bit), but really optimized ones. +For example, "pointing device + keyboard" UIs should use +mouse-over/hover effects to reveal inline controls, whereas touch UIs +should use touch gestures. + +When navigating through hierarchies, portrait mode mode shows only one +column/page at a time, whereas landscape shows multiple ones. + +UIs for bigger screens show more controls permanently, whereas UIs for +small screens show only the most important controls always, while +showing secondary controls only on demand. + +Kirigami Components will do some of that adaptation / optimization work +for you, but be prepared to also manually adapt your user interface for +different devices. diff --git a/source/introduction/index.rst b/source/introduction/index.rst index 59b8311..c088617 100644 --- a/source/introduction/index.rst +++ b/source/introduction/index.rst @@ -1,12 +1,14 @@ Intoduction =========== .. toctree:: :titlesonly: :hidden: vision architecture + convergence * :doc:`vision` * :doc:`architecture` +* :doc:`convergence` diff --git a/source/layout/index.rst b/source/layout/index.rst index eb14709..1c7a84b 100644 --- a/source/layout/index.rst +++ b/source/layout/index.rst @@ -1,17 +1,19 @@ Layout ====== .. toctree:: :maxdepth: 1 :caption: Contents: :titlesonly: :hidden: units metrics alignment + onehand * :doc:`units` * :doc:`metrics` * :doc:`alignment` +* :doc:`onehand` diff --git a/source/layout/onehand.rst b/source/layout/onehand.rst new file mode 100644 index 0000000..676f774 --- /dev/null +++ b/source/layout/onehand.rst @@ -0,0 +1,34 @@ +One-handed use +============== + +According to `research`_, about half of users use their phone with just +one hand in a given situation. This limits the areas they can +comfortably reach with their thumb. The safest way to hold a phone in +one hand is resting the bottom end in the palm. Another 15% hold them in +the palms of both hands. Both ways to hold a phone make the top of the +screen hard to reach. + +.. figure:: /img/HoldPhones_Figure-2.png + + Reachability of screen regions in one-handed use. |br| + *Source:* `UXmatters`_ + +.. figure:: /img/HoldPhones_Figure-4.png + + Reachability of screen regions in two-thumbed use. |br| + *Source:* `UXmatters`_ + +Kirigami's phone components are therefore optimized to favor the center +or bottom of the screen for primary interactive elements, while putting +secondary elements into drawers which can be opened from up to three +different points of the screen and then again favor the lower parts of +the screen. It also has an "overscroll" feature, which allows you pull +down the top part of the screen in case you have to reach e.g. the +topmost items of a list. + +When using Kirigami, make sure that often-used controls are never placed +at the top of the screen, and also avoid the screen corners in general. + +.. _research: http://www.uxmatters.com/mt/archives/2013/02/how-do-users-really-hold-mobile-devices.php +.. _UXmatters: http://www.uxmatters.com/mt/archives/2013/02/how-do-users-really-hold-mobile-devices.php + diff --git a/source/patterns/content/help.rst b/source/patterns/content/help.rst new file mode 100644 index 0000000..8d50565 --- /dev/null +++ b/source/patterns/content/help.rst @@ -0,0 +1,35 @@ +Help system +=========== + +Purpose +------- + +The *help system* should be used as a secondary mechanism to support +users’ complete and better understanding of tasks — the primary +mechanism should be the user interface itself. Users consult the help +system only if they can't accomplish a task with the UI. + +Examples +-------- + +Guidelines +---------- + +Try to make Help unnecessary in the first place: + +- Make common tasks easy to discover and perform. +- Provide clear main instructions as well as concise control labels + that are goal- and task-oriented. +- Provide supplemental instructions and explanations where needed. +- Avoid problems by using controls constrained to valid choices, + providing suitable default values, handling all input formats, and + preventing errors. +- Write error messages that provide a clear solution or action for the + user to take. +- Usually, the help system is activated by F1 respectively Ctrl+F1 for + context sensitive information and via menu. + +Implementation +-------------- + +- http://www.kde.org/support/ diff --git a/source/patterns/content/index.rst b/source/patterns/content/index.rst index 1821a28..db22ebf 100644 --- a/source/patterns/content/index.rst +++ b/source/patterns/content/index.rst @@ -1,21 +1,23 @@ Content patterns ================ .. toctree:: :maxdepth: 1 :titlesonly: :hidden: breadcrumb duallist iconandtext + help settings sliderspin viewingediting - :doc:`breadcrumb` - :doc:`duallist` - :doc:`iconandtext` +- :doc:`help` - :doc:`settings` - :doc:`sliderspin` - :doc:`viewingediting` diff --git a/source/resources/about.rst b/source/resources/about.rst new file mode 100644 index 0000000..3736c2c --- /dev/null +++ b/source/resources/about.rst @@ -0,0 +1,145 @@ +About +===== + +Human interface guidelines (HIG) are software development documents that +offer application developers a set of recommendations. Their aim is to +improve the experience for users by making application interfaces more +consistent and hence more intuitive and learnable. + +The quality and acceptance of a guideline depends to a large extent on +its set-up. A good structure guarantees quick access to the information +the reader looks for. Additional, links to the rationales behind the +guideline as well as alternative solutions are helpful. A HIG should not +only include widgets and their appearance but also core usability goals, +generic design specifications, and user demands. To manage all these +aspects we have chosen to adopt the +“\ `Universal Model of a User Interface`_\ ” by Bob Baxley (2003) as basis +for the new KDE HIG. This model has been slightly adjusted to account for +more recent approaches to visual design guidelines. + +The central aim of KDE HIG is to create a consistent experience across +the software compilation. This means to apply the same visual design and +user experience as well as consistent access and predictable behavior of +common elements in the interface – from simple ones such as buttons and +icons up to more complex constructions, such as dialog boxes. + +The model consists of three tiers, each of which is made up of three +layers: + +#. Structure + + Structure contains concept, design vision and principles, task + flow and organization. It should answer question like: What + constitutes KDE software?, Who is the user of KDE software?, and + Where do we want to go in future? + + #. Design Vision and Principles + + There are almost always multiple solutions to any given user + interface problem. Consistency in the choice of solutions and, + ultimately, the experience of the user, is guided by a Design + Vision. As such, the design vision is aspirational by + definition; it is a high level description of the desired user + experience in not just one application, but across multiple KDE + applications and the KDE workspace. A set of Design Principles + are derived from the design vision as a means to provide more + specific guidance on how to achieve that desired user + experience. + + #. Conceptual Model + + The conceptual model is the most fundamental aspect of the + interface, describing the relationship between the interface + and the outside world. The purpose of the conceptual model is + to draw on the user’s past experiences so they can readily + understand basic operations and accurately predict + functionality. + + #. Organizational Model + + The organizational model describes how the system’s content and + functionality are ordered and categorized. Also known as the + information architecture, the organizational model encompasses + both the classification scheme as well as the model of + association, hierarchy versus index for example. + +#. Behaviour + + Behaviour includes viewing and navigation, editing and + manipulation and user assistance. All elements of the Behaviour + layer must satisfy the Design Principles. This layer is more like + ‘traditional’ guidelines, addressing questions like: How should a + button behave in case of…?, or What widget do I have to use for a + selection of one out of a few items? + All HIGs assume that the controls referenced in the following + "Implementation" sections are used. Therefore they only contain + guidelines for aspects which can be changed by the developer, to + keep them as concise as possible. + If you feel your application needs something which the referenced + standard KDE or Qt widget does not provide, do not create you own + custom replacement, because it might violate best practice which + is implemented in the standard widget. Instead, ask the KDE HIG + team for advice on how to solve your specific problem. + + #. Viewing and Navigation + + The Viewing and Navigation layer encompasses the wide variety + of behaviors and operations that allow users to navigate the + interface and affect its presentation. + + #. Editing and Manipulation + + The Editing and Manipulation layer contains the behaviors that + result in permanent changes to user’s stored information. … + Behaviors in this layer can often be recognized by the + following traits: they result in permanent, stored changes; + they require an implicit or explicit save operation; and they + typically require validation of the input data. + + #. User Assistance + + Interface elements that inform users of the application’s + activity and status, as well as elements dedicated to user + education, are all contained in the User Assistance layer. This + includes online help, error alerts, and status alerts. + +#. Presentation + + Presentation deals with visual design of the user interface - + layout, style and text. It’s all about the appearance of the + application including the platform style’s margins and spacing, + colours, fonts, icon designs, etc. These questions primarily + concern designers, developers, translators and the promotion team. + + #. Layout + + The various design decisions governing the placement , ordering + ans spacing of onscreen elements are expressed in the Layout + layer. In addition to providing an ordered visual flow, the + Layout layer also supports the Behavior tier by arranging + elements in a manner that helps communicate behavior, + importance, and usage. + + #. Style + + The Style layer is concerned with emotion, tone, and visual + vocabulary. Because it is the most visible and concrete aspect + of an interface, it typically accounts for people’s first + impression of a product. Style is influenced by the use of + color, the design of icons throughout the interface and the use + of typography. All elements of the Style layer must satisfy the + Design Principles. This allows the style to change as necessary + while still preserving the user experience secured by the + Design Principles. + + #. Text + + Contained within the Text layer are all the written, + language-based elements of the interface. This includes the + labels used to represent the organizational model, the names of + the input and navigational controls contained in the Viewing + and Navigation layer, and the alert messages and help text used + by the User Assistance layer. + +.. _Universal Model of a User Interface: http://www.baxleydesign.com/pdfs/dux03_baxleyUIModel.pdf + diff --git a/source/style/index.rst b/source/style/index.rst index 7c013c8..300ac2a 100644 --- a/source/style/index.rst +++ b/source/style/index.rst @@ -1,21 +1,23 @@ Style ===== .. toctree:: :caption: Contents: :titlesonly: :hidden: elevation icon imagery + theme typography writing/index The Style layer is concerned with emotion, tone, and visual vocabulary. Because it is the most visible and concrete aspect of an interface, it typically accounts for people’s first impression of a product. Style is influenced by the use of color,the design of icons throughout the interface and the use of typography. Elements of style support Organization, Viewing and Navigation, Editing and Manipulation and User Assistance. * :doc:`elevation` * :doc:`icon` * :doc:`imagery` +* :doc:`theme` * :doc:`typography` * :doc:`writing/index` diff --git a/source/style/theme.rst b/source/style/theme.rst new file mode 100644 index 0000000..5bab77f --- /dev/null +++ b/source/style/theme.rst @@ -0,0 +1,26 @@ +Theme +===== + +Application specific theme +-------------------------- + +- Only set a custom color scheme, never set a custom widget theme. +- It's recommended to use the global color theme. + +If your application focuses on visual content, e.g. creating or working +with images or videos, you might switch the app to a dark color theme +corresponding to the global color theme. e.g. switch from *Breeze* to +*Breeze Dark*, but don't switch from "Oxygen" to "Breeze Dark" + +Provide the option for the user to disable switching to the app specific +color theme and use the global color theme instead. You can offer an +option for the user to switch to any of the other installed color +themes. + +Place the option to switch theme in Settings > Designs. + +.. figure:: /img/Switch-theme.jpeg + :alt: kritas theme switcher + :scale: 50% + + Kritas theme switcher. diff --git a/source/style/writing/contraction.rst b/source/style/writing/contraction.rst new file mode 100644 index 0000000..5838252 --- /dev/null +++ b/source/style/writing/contraction.rst @@ -0,0 +1,31 @@ +Contractions +============ + +Short version +------------- + +Instead of: + +don't, won't, it's, can't, there's, ... + +...use: + +do not, will not, it is, cannot, there is, ... + +Longer version +-------------- + +In general, contractions (such as the examples above) should not be used +when writing user-interface strings, for two main reasons: + +- contractions are avoided in formal writing +- they make English text harder to understand for non-native readers + (and although `KDE has great translation teams`_, the original + English string is used if no translation exists) + +For further discussion on this issue, in general, see the following blog +post: `Don't Use Contractions?`_ + +.. _KDE has great translation teams: http://l10n.kde.org/ +.. _Don't Use Contractions?: http://www.businesswritingblog.com/business_writing/2006/04/dont_use_contra.html + diff --git a/source/style/writing/index.rst b/source/style/writing/index.rst index b06611e..11f9c94 100644 --- a/source/style/writing/index.rst +++ b/source/style/writing/index.rst @@ -1,20 +1,22 @@ Writing ======= .. toctree:: :titlesonly: :hidden: wording capitalization + contraction labels static localization Text includes all the written, language-based elements of the interface. This includes the labels used to represent the organizational model, the names of the input and navigational controls contained for Viewing and Navigation, and the alert messages and help text used for User Assistance. * :doc:`wording` * :doc:`capitalization` +* :doc:`contraction` * :doc:`labels` * :doc:`static` * :doc:`localization`