Git commit 73c5e9c6197f34d54edde4baf98448c47955cd10 by Fabian Riethmayer. Committed on 10/09/2018 at 10:27. Pushed by fabianr into branch 'master'. Revise HIGs for Clarity Summary: Added clarifying language to the HIG. Sorry about the images. Reviewers: ngraham, fabianr Reviewed By: ngraham, fabianr Subscribers: zzag, ngraham, fabianr, abetts Tags: #vdg, #kde_human_interface_guidelines Differential Revision: https://phabricator.kde.org/D14985 A +- -- source/img/Berna.jpg A +- -- source/img/Berna_small.jpg A +- -- source/img/Matt.jpg A +- -- source/img/Matt_small.jpg A +- -- source/img/Philip.jpg A +- -- source/img/Philip_small.jpg A +- -- source/img/Santiago.jpg A +- -- source/img/Santiago_small.jpg A +- -- source/img/Susan.jpg A +- -- source/img/Susan_small.jpg M +8 -5 source/introduction/convergence.rst M +70 -74 source/introduction/personas.rst M +7 -0 source/introduction/research.rst M +4 -5 source/layout/metrics.rst M +11 -13 source/layout/onehand.rst M +15 -8 source/style/elevation.rst https://commits.kde.org/websites/hig-kde-org/73c5e9c6197f34d54edde4baf98448= c47955cd10 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/conv= ergence.rst index 74e335c..a3a2f64 100644 --- a/source/introduction/convergence.rst +++ b/source/introduction/convergence.rst @@ -2,8 +2,8 @@ Optimized convergence =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = 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 @@ -21,10 +21,13 @@ 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 permanentl= y, 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/persona= s.rst index 99092b1..1125166 100644 --- a/source/introduction/personas.rst +++ b/source/introduction/personas.rst @@ -1,137 +1,133 @@ Personas =3D=3D=3D=3D=3D=3D=3D=3D = -.. 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 p= eople you consider your software's target user. In your design sessions, yo= u can call out the names of these personas to help you and your team make c= hanges to your software. That way, you can ensure that your design is consi= stent with KDE visual goals. + = + Software that you write will not necessarily satisfy all personas. It s= hould not be the case either that you look to meet every persona's expectat= ions through your software. Instead, focus your efforts into the persona th= at best meets your target audience and work to strengthen your software tow= ard 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 =E2=80=93 a crucial aspect if we want to e= xtend +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 =E2=80=93 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 resolve= s 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 car= eful when testing new functionality in the software she uses. She prefers t= o 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 geol= ogic materials. He gains credits by using his notes to create reports and p= resentations. = 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 custo= mer 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 ach= ieve these results. The system has to be reliable and easy to use, so his e= mployees 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 under= stands 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 =E2=80=93 a crucial aspect if we want to e= xtend -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 =E2=80=93 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 techni= cal issues himself. diff --git a/source/introduction/research.rst b/source/introduction/researc= h.rst index c3b250c..d791c65 100644 --- a/source/introduction/research.rst +++ b/source/introduction/research.rst @@ -86,3 +86,10 @@ More Information .. _Short introduction to user personas on Usability.gov: http://www.usabi= lity.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_driv= e_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 @@ -34,11 +34,10 @@ Size 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: =E2=89=A580 x 32 px - - Text edits: =E2=89=A580 x =E2=89=A536 px (text should not exceed 80 = characters per + - Icon:16x16px + - Buttons: 72 x 32px + - Line edits, Drop-downs, Combo boxes =E2=89=A580 x 32 px + - Text edits: =E2=89=A580 x =E2=89=A536 px (text should not exceed 80 c= haracters per line) - Checkbox, Radio button including label: =E2=89=A580 x 24 px - Group boxes: =E2=89=A5120 x =E2=89=A596 px 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 @@ -2,11 +2,11 @@ One-handed use =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = 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 = @@ -18,16 +18,14 @@ screen hard to reach. 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 eleme= nts into drawers which can be opened from up to three different points of t= he screen and then again favor the bottom area of +the screen. + +Kirigami also features the "overscroll" feature, which allows you pull dow= n the top part of the screen in case you have to reach e.g. the topmost ite= ms of a list. + +When using Kirigami on a phone, make sure that often-used controls are nev= er placed at the top of the screen, and also avoid the screen corners in ge= neral. = .. _research: http://www.uxmatters.com/mt/archives/2013/02/how-do-users-re= ally-hold-mobile-devices.php .. _UXmatters: http://www.uxmatters.com/mt/archives/2013/02/how-do-users-r= eally-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 -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +Depth, Elevation and Shadows +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D = -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, KD= E 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 wo= rking with computer and mobile interfaces. As you create applications, plea= se 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 worki= ng 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 no= t to compete with the window shadows.