[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    [websites/hig-kde-org] source: Revise HIGs for Clarity
From:       Fabian Riethmayer <null () kde ! org>
Date:       2018-09-10 10:27:37
Message-ID: E1fzJPt-00065w-Bw () code ! kde ! org
[Download RAW message or body]

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/73c5e9c6197f34d54edde4baf98448c47955cd10

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
@@ -2,8 +2,8 @@ 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
@@ -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 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
@@ -86,3 +86,10 @@ More Information
 .. _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 <https://matrix.to/#/#kde_vdg:matrix.org>`_, 
+`IRC <irc://chat.freenode.net/kde-vdg>`_ or 
+`Telegram <https://telegram.me/vdgmainroom>`_
\ 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: ≥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
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
 ==============
 
 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 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 <color>`)
-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 <color>`)
+- 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.


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic