diff --git a/source/img/Berna.jpg b/source/img/Berna.jpg new file mode 100644 index 0000000..7a312b7 Binary files /dev/null and b/source/img/Berna.jpg differ diff --git a/source/img/Berna_small.jpg b/source/img/Berna_small.jpg new file mode 100644 index 0000000..6e76a2d Binary files /dev/null and b/source/img/Berna_small.jpg differ diff --git a/source/img/Matt.jpg b/source/img/Matt.jpg new file mode 100644 index 0000000..2e6adf2 Binary files /dev/null and b/source/img/Matt.jpg differ diff --git a/source/img/Matt_small.jpg b/source/img/Matt_small.jpg new file mode 100644 index 0000000..797194c Binary files /dev/null and b/source/img/Matt_small.jpg differ diff --git a/source/img/Philip.jpg b/source/img/Philip.jpg new file mode 100644 index 0000000..4431c4b Binary files /dev/null and b/source/img/Philip.jpg differ diff --git a/source/img/Philip_small.jpg b/source/img/Philip_small.jpg new file mode 100644 index 0000000..677eb68 Binary files /dev/null and b/source/img/Philip_small.jpg differ diff --git a/source/img/Santiago.jpg b/source/img/Santiago.jpg new file mode 100644 index 0000000..25f1d80 Binary files /dev/null and b/source/img/Santiago.jpg differ diff --git a/source/img/Santiago_small.jpg b/source/img/Santiago_small.jpg new file mode 100644 index 0000000..d0f5185 Binary files /dev/null and b/source/img/Santiago_small.jpg differ diff --git a/source/img/Susan.jpg b/source/img/Susan.jpg new file mode 100644 index 0000000..f16984e Binary files /dev/null and b/source/img/Susan.jpg differ diff --git a/source/img/Susan_small.jpg b/source/img/Susan_small.jpg new file mode 100644 index 0000000..16b3613 Binary files /dev/null and b/source/img/Susan_small.jpg differ diff --git a/source/introduction/convergence.rst b/source/introduction/convergence.rst index 74e335c..a3a2f64 100644 --- a/source/introduction/convergence.rst +++ b/source/introduction/convergence.rst @@ -1,30 +1,33 @@ 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 +KDE 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 +UIs for screens with different input methods show more controls permanently, whereas UIs for small screens show only the most important controls always, while -showing secondary controls only on demand. +showing secondary controls only on demand. The convergence for these +screens will prefer to show only the most important controls when the +screen has become smaller. Developers and designers must determine which +elements on the screen are the most relevant for use. -Kirigami Components will do some of that adaptation / optimization work +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/personas.rst b/source/introduction/personas.rst index 99092b1..1125166 100644 --- a/source/introduction/personas.rst +++ b/source/introduction/personas.rst @@ -1,137 +1,133 @@ Personas ======== -.. image:: /img/Introduction_KDE4_Vision_personas_all.png - :scale: 50% - :alt: All personas of KDE + Personas are a simple way of grounding your design toward the type of people you consider your software's target user. In your design sessions, you can call out the names of these personas to help you and your team make changes to your software. That way, you can ensure that your design is consistent with KDE visual goals. + + Software that you write will not necessarily satisfy all personas. It should not be the case either that you look to meet every persona's expectations through your software. Instead, focus your efforts into the persona that best meets your target audience and work to strengthen your software toward that KDE-specific audience. + +KDE Personas: Background +------------------------ + +The question "Why should people switch to KDE?" was an important factor +in the creation of our Personas – a crucial aspect if we want to extend +the current user base. The "Technology Adoption Lifecycle" by Rogers +(1962) deals with this question by splitting the overall user base in +groups along a bell curve according to their willingness to adopt new +technology. + +Looking at the "Technology Adoption Lifecycle", you'll find the +following user groups: + +.. image:: /img/Introduction_KDE4_Vision_tal.png + :scale: 30% + :alt: Technology Adoption Lifecycle + +We suggest to move away from the *KDE is for everybody* approach to *KDE +is for the more sophisticated 50% of computer users out there, who +choose it because it perfectly suits their work and that they "want to +have it".* + +Concentrating on this user base rather than everybody has both pragmatic +and motivational reasons: Pragmatically, it will be hard to make KDE a +favourite product for *laggards* and even the *late majority* within the +next five years. Neither cutting away functionality nor hiding all the +complexity behind *Advanced* buttons is an acceptable solution. Second, +creating a desktop for ambitious users better fits the current +motivation in the KDE development base. We don't want to be *simple and +limited*, we want to develop a smart desktop with rich functionality! + +To avoid misunderstandings: KDE will still be an option for educational, +governmental or large enterprise usage – but it won't be the main focus +when developing the default desktop. KDE as a configurable set of tools can +still be adjusted to meet the needs of any other user base. Berna ----- -.. image:: /img/Introduction_KDE4_Vision_personas_1_office.png +.. image:: /img/Berna_small.jpg :scale: 50% :alt: Berna + :align: right -Berna is working as an office clerk in a big insurance. Although a smart -person, she is very unsure when it comes to technology. +Berna works as an office clerk in a big insurance company. Although she is a very smart +person, she is very often unsure how technology can help her. -Berna's major work is to check the details of insured events. She writes +Berna's biggest daily task is to check on the details of insurance claims. She writes reports for her boss suggesting compensation payouts for the cases she -deals with. Berna is a very precise person, and always solves her tasks -accurately. +deals with. Berna is a very detail oriented individual, and always resolves her tasks accurately. -Berna twice lost several hours of work because she didn't understand the -options she was offered. Since then, she has been very careful when -probing new functionality. +Berna lost several hours of work twice because she didn't understand the +options she was offered with technology. Since then, she has been very careful when testing new functionality in the software she uses. She prefers to keep things simple. Matt ---- -.. image:: /img/Introduction_KDE4_Vision_personas_2_student.png +.. image:: /img/Matt_small.jpg :scale: 50% :alt: Matt + :align: right Matt is a geology student in the last year of his undergraduate studies. -For him, technology is meant to take over annoying and repetitive tasks. +For him, technology is meant to simplify annoying and repetitive tasks. For his student research projects, Matt has to do extensive research on -the web, and has to manage pictures of stones and other geologic -material. He gains credits by using his notes to create reports and -presentations. +the web, and has to manage a database of pictures of stones and other geologic materials. He gains credits by using his notes to create reports and presentations. Matt often struggles to keep track of all his notes. He is looking for -an effective routine, so he can concentrate on the contents rather than +an effective routine, so he can concentrate on the content rather than on finding information. Susan ----- -.. image:: /img/Introduction_KDE4_Vision_personas_3_recreational.png +.. image:: /img/Susan_small.jpg :scale: 50% :alt: Susan + :align: right While Susan seldom uses her computer for work, it has become an essential part of her social life. With her computer, she can be -creative and spread this creativity in the world. +creative and spread this creativity to the world. She chats with her friends, shares music, playlists and other media, creates videos and uploads them to her web space, and runs a blog with her own style. She can't imagine a life without her laptop. -Still, she is a fun person and does not want to worry about technical +She is a fun person and does not want to worry about technical details. She expects her machine to work. Santiago -------- -.. image:: /img/Introduction_KDE4_Vision_personas_4_decision.png +.. image:: /img/Santiago_small.jpg :scale: 50% :alt: Santiago + :align: right -Santiago runs a medium-sized business for electric installations. For +Santiago runs a medium-sized electric installations business. For him, technology needs to be comfortable and make him feel smart. -As a manager with engineering background, Santiago's major work is to -negotiate with customers. However, to avoid costs, he administrates the -small network in the company himself, including a file server and +As a manager with an engineering background, Santiago's main task is customer negotiations. However, to avoid costs, he is the administrator for the small network at the company, including a file server and fifteen PCs for his office clerks. -He loves comfort and does not like to dive into manuals or use the -command line to set up the small network. The system has to be reliable -and easy to use, so his employees get along with it. +He loves comfort, does not like to dive into manuals or use the +command line to set up the small network. Santiago relies on the UI to achieve these results. The system has to be reliable and easy to use, so his employees get along with it. Philip ------ -.. image:: /img/Introduction_KDE4_Vision_personas_5_geek.png +.. image:: /img/Philip_small.jpg :scale: 50% :alt: Philip + :align: right -Philip is a high-school student in his last grade. Later, he wants to go -to university to study computer science. He loves the challenge of +Philip is a high-school student in his last year. He wants to go +to college to study computer science. He loves the challenge of making technology do what he wants it to do. -When he was 14, he started to probe different programming languages, and -since then has implemented various different applications he published -under free licenses. He is convinced of Linux and the benefits of free -software. +When he was 14, he tried different programming languages, and +since then has implemented various applications he published +under free licenses. He is convinced that Linux is the way to go and understands the benefits of free software. Philip is fancy about technology and is never discouraged if something -does not work as expected. - - -KDE Personas: Background ------------------------- - -The question "Why should people switch to KDE?" was an important factor -in the creation of our Personas – a crucial aspect if we want to extend -the current user base. The "Technology Adoption Lifecycle" by Rogers -(1962) deals with this question by splitting the overall user base in -groups along a bell curve according to their willingness to adopt new -technology. - -Looking at the "Technology Adoption Lifecycle", you'll find the -following user groups: - -.. image:: /img/Introduction_KDE4_Vision_tal.png - :scale: 50% - :alt: Technology Adoption Lifecycle - -We suggest to move away from the *KDE is for everybody* approach to *KDE -is for the more sophisticated 50% of computer users out there, who -choose it because it perfectly suits their work and that they "want to -have it".* - -Concentrating on this user base rather than everybody has both pragmatic -and motivational reasons: Pragmatically, it will be hard to make KDE a -favourite product for *laggards* and even the *late majority* within the -next five years. Neither cutting away functionality nor hiding all the -complexity behind *Advanced* buttons is an acceptable solution. Second, -creating a desktop for ambitious users better fits the current -motivation in the KDE development base. We don't want to be *simple and -stupid*, we want to develop a smart desktop with rich functionality! - -To avoid misunderstandings: KDE will still be an option for educational, -governmental or large enterprise usage – but it won't be the main focus -when developing the default desktop. KDE as a configurable framework can -still be adjusted to meet the needs of any other user base. +does not work as expected. He feels that as a power user he can fix technical issues himself. diff --git a/source/introduction/research.rst b/source/introduction/research.rst index c3b250c..d791c65 100644 --- a/source/introduction/research.rst +++ b/source/introduction/research.rst @@ -1,88 +1,95 @@ Project User Research Profile ============================= Short summary description of the purpose of the application, who it is for, and what those people can do with it. Purpose ======= **About the Project User Research Template:** The purpose of this template is to provide a place to document an application's user research information for reference during development. Top level items are information everyone in the project should be aware of. Some of the details in the lower sections may take some work and discussion within the project to complete. Who is the application for? --------------------------- - List of types (groups) of users - User groups can be organized based on any type of dimension - Some groups may be broken down in to sub groups (Who is the application *not* for) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Sometimes it is easy to identify who the application is **not** for - This can help keep the scope of the project under control Sample User Profiles ~~~~~~~~~~~~~~~~~~~~ User Profile 1: For each group of users identified (or primary groups, or particularly special groups if many groups are defined), write a description of that user's characteristics based on a real user you know. What kinds of tasks will they complete -------------------------------------- - List of common tasks users will complete - This does not have to be a complete functional specification, but major tasks and specialty tasks should be listed - Include functionality that is planned but not yet implemented to help keep the future in focus (What kinds of functionality will the application *not* support) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - List tasks or functionality the application will not address - Sometimes it is useful to list this unintended functionality to help keep the scope of the application - For example, a certain functionality may not be implemented because it is out of scope with the primary goals of the project, another application with a different focus does it better, or it is an extreme edge case for a user type which is not primary Sample Use Scenarios and Cases ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Use Scenario 1: For each task identified (or major tasks, or particularly special tasks if many tasks are defined), write a description of how that user would accomplish the task *independent* of how they would complete it within the application. Use Case 1: If a use scenario has been implemented, include a matching use case which describes how the task use scenario can be completed in the application. There may be branching or multiple ways to complete the task, and this is a good way to document it. Environment Conditions & Requirements ------------------------------------- - List of environmental conditions for the user or the application to consider - For example, an Internet-capable application would require an Internet connection More Information ---------------- `Short introduction to user personas on Usability.gov`_ `In-depth discussion about creating personas on Boxes and Arrows`_ .. _Short introduction to user personas on Usability.gov: http://www.usability.gov/analyze/personas.html .. _In-depth discussion about creating personas on Boxes and Arrows: http://www.boxesandarrows.com/view/making_personas_more_powerful_details_to_drive_strategic_and_tactical_design +Still Need Help? +---------------- + +CFor more information and help you can find us on +`Matrix `_, +`IRC `_ or +`Telegram `_ \ No newline at end of file diff --git a/source/layout/metrics.rst b/source/layout/metrics.rst index dead397..047695f 100644 --- a/source/layout/metrics.rst +++ b/source/layout/metrics.rst @@ -1,133 +1,132 @@ Metrics and placement ===================== Purpose ------- All controls have a default *height and width* to establish a harmonic overall picture. Nevertheless, size is used to direct users' attention. For instance, a list that captures most of screen’s space points to its central role in the current work flow. And, size can be used to indicate possible interactions. Smaller edits are probably constrained, for instance. Similar to size, the *space* between controls generates a visual impression and supports layout. Space between controls indicates their relatedness. Objects with smaller distances are mentally associated according to the Gestalt theory. *Whitespace* is an important element of design which enables the objects in it to exist at all. The balance between content and whitespace is key to *grouping*. Please read :doc:`units` for more information which and how different units such as px, dpi independent pixels, smallSpacing and largeSpacing are used. Guidelines ---------- Size ~~~~ - If the control appears in a dialog or utility window, consider making the window and the control within it resizeable so that the user can choose how many 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. - Size controls with a minimum of - - - Icon: 16x16px - - Buttons: 72 x 32px - - Line edits, Drop-downs, Combo boxes: ≥80 x 32 px - - Text edits: ≥80 x ≥36 px (text should not exceed 80 characters per + - Icon:16x16px + - Buttons: 72 x 32px + - Line edits, Drop-downs, Combo boxes ≥80 x 32 px + - Text edits: ≥80 x ≥36 px (text should not exceed 80 characters per line) - Checkbox, Radio button including label: ≥80 x 24 px - Group boxes: ≥120 x ≥96 px - Tree view: ≥120 x ≥96 px - List view: ≥80 px (per column) x ≥96 - KDE seeks to support XGA (1024x768px) or WXGA (1280x768px) at least. - Keep in mind that not everyone is provided with a high resolution display. - Avoid to have a large number of controls visible at once, which in turn requires a huge minimal size. - Keep in mind that the available screen area typically also will be shrunk by panels and the window titlebar. Also, user's font might be bigger than yours (e.g. for accessibility reason). - You therefore should ideally preserve ~10% to catch those variables and try to not exceed 920x690px. Space ~~~~~ Qt widgets ^^^^^^^^^^ If you are using Qt widgets you should use one of `Qt's Layout Classes `_, which will take care of laying out and spacing of your controls. QML ^^^ For consistency you should try to use Kirigami and Plasma's smallSpacing and largeSpacing for margins and paddings whenever possible. See :doc:`units` for more details. Use multiples of smallSpacing or largeSpacing, where more spacing is required. .. figure:: /img/Margin.qml.png :alt: Use of base units Use of base units Recommended minimum paddings ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - A smallSpacing padding is the minimum recommended padding inside elements (buttons, drop boxes, text fields, etc.) - An 2 * smallSpacing padding is the minimum recommended padding inside grouping frames (group boxes, tabs, etc.) - Use default spacing of - related items within groups: 2 * smallSpacing - label and item: smallSpacing - related controls with same type (checkboxes / radio buttons): smallSpacing - related controls with different type (checkbox / button): smallSpacing - unrelated controls: ≥ 3 * smallSpacing .. figure:: /img/SpacingPadding.qml.png :alt: Sample spacing Sample spacing - In some cases it may be useful to visually separate groups of related options within one group to facilitate scanning of the dialog. In that case, put a vertical, fixed-size spacer of 18px height between the options. .. figure:: /img/SpacingSeperate.qml.png :alt: Separating groups of related options with a vertical spacer. Separating groups of related options with a vertical spacer. .. hint:: |designicon| It often helps to use a soft grid of 18px (gridUnit), when creating mockups. But only use this as a visual hint, since plasma components and icon size are not multiples of the gridUnit, you won't be able to align everything to the grid. Resize ~~~~~~ - Provide resizing for all primary and mode-less windows. - If form resizing is not provided disable border icons and adjust form style. - Define a minimum size for resizable forms. - Make the content area scrollable if size is too small for all controls; do not scale controls. .. figure:: /img/Resize.qml.png :alt: Give hints how to resize Give hints how to resize diff --git a/source/layout/onehand.rst b/source/layout/onehand.rst index 676f774..2bf4161 100644 --- a/source/layout/onehand.rst +++ b/source/layout/onehand.rst @@ -1,34 +1,32 @@ 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 +one hand in any given situation. This behavior 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. +one hand is resting the bottom end in the palm. Another 15% of people hold them in +the palms with both hands. Both ways to hold a phone make the top of the +screen harder 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. +As shown in the previous examples, the reachable areas of the phone focus on the green areas. -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. +Kirigami's phone components are optimized to favor the center or bottom of the screen for primary interactive elements, while placing secondary elements into drawers which can be opened from up to three different points of the screen and then again favor the bottom area of +the screen. + +Kirigami also features the "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 on a phone, 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/style/elevation.rst b/source/style/elevation.rst index 1210c77..d574113 100644 --- a/source/style/elevation.rst +++ b/source/style/elevation.rst @@ -1,14 +1,21 @@ -Elevation and Shadows -===================== +Depth, Elevation and Shadows +============================ -Shadows should be horizontally-centered, but vertically offset, to -provide the illusion that a light source is over the top of the screen. -The default shadow color should be Shade Black (see :doc:`Breeze Colors `) -with 35% opacity. The default size for window shadows is 64px. Menu & -tooltip shadows are 16px: +Athough in recent years "flat" design has taken over the mobile market, KDE has continued to use shadows as a means to provide depth and elevation to elements on the screen. + +KDE realizes that elevation and depth perception are intrinsic parts of working with computer and mobile interfaces. As you create applications, please be sure to use shadows in the style detailed below. + +Shadows should be horizontally-centered, but vertically offset, to provide the illusion that a light source is over the top of the screen. This would, in general, follow your eye position relative to the screen you are working on. + +The default shadow details should be: + +- Shadow color: Shade Black (see :doc:`Breeze Colors `) +- Shadow opacity: 35% +- Window shadow size: 64px +- Menu & tooltip shadows size: 16px .. image:: /img/Shadows_with_background.png :alt: Example for a shadows of window and menu -Shadows inside apps should use a size of 16px or below, so as not to +REMINDER: Shadows inside apps should use a size of 16px or below, so as not to compete with the window shadows.