mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2024-12-18 12:14:42 -05:00
421 lines
10 KiB
ReStructuredText
421 lines
10 KiB
ReStructuredText
==============
|
||
Usability & UX
|
||
==============
|
||
|
||
|
||
Software that is too complicated to use, is often unused. Because we
|
||
want as many people as possible to benefit from its unique security
|
||
properties, the usability and user experience of Qubes OS is an utmost
|
||
priority!
|
||
|
||
We ask anyone developing for Qubes OS to please read through this guide
|
||
to better understand the user experience we strive to achieve. We also
|
||
ask them to review :doc:`our visual style guide </developer/general/visual-style-guide>`
|
||
for other design related information.
|
||
|
||
|
||
----
|
||
|
||
|
||
Easy To Use
|
||
-----------
|
||
|
||
|
||
An ideal user experience is friendly, and it beckons a new user to
|
||
explore the interface. In this process, they can naturally discover how
|
||
to use the software. Below are some guidelines that will help you design
|
||
a user interface that accomplishes this goal.
|
||
|
||
.. important::
|
||
Interfaces Should Not
|
||
|
||
|
||
- Require extensive configuration before a user can *begin* doing
|
||
things
|
||
|
||
- Make it possible to break provided features or actions in
|
||
unrecoverable ways
|
||
|
||
- Perform actions which compromise security and data
|
||
|
||
- Overwhelm the user with too much information and cognitive load
|
||
|
||
|
||
|
||
Perhaps the most common cause of mistakes is complexity. If there is a
|
||
configuration setting that will significantly affect the user’s
|
||
experience, choose a safe and smart default then tuck this setting in an
|
||
``Advanced Settings`` panel.
|
||
|
||
.. important::
|
||
Interfaces Should
|
||
|
||
|
||
- Make it easy to discover features and available actions
|
||
|
||
- Provide some understanding of what discovered features do
|
||
|
||
- Offer the ability to easily undo mistakes
|
||
|
||
- Choose intelligent defaults for settings
|
||
|
||
|
||
|
||
In making software easy to use, it is crucial to be mindful of
|
||
`cognitive load <https://en.wikipedia.org/wiki/Cognitive_load>`__ which
|
||
dictates that *“humans are generally able to hold only seven +/- two units of information in short-term memory.”* Making sure your interfaces
|
||
don’t pass this short-term memory limit is perhaps the most important
|
||
factor in helping a user feel comfortable instead of overwhelmed.
|
||
|
||
|
||
----
|
||
|
||
|
||
Easy to Understand
|
||
------------------
|
||
|
||
|
||
There will always be the need to communicate things to users. In these
|
||
cases, an interface should aim to make this information easy to
|
||
understand. The following are simple guides to help achieve this - none
|
||
of these are absolute maxims!
|
||
|
||
.. important::
|
||
Avoid Acronyms
|
||
|
||
|
||
Acronyms are compact and make good names for command line tools. They do
|
||
not make graphical user interfaces more intuitive for non-technical
|
||
users. Until one learns an acronym’s meaning, it is gibberish. Avoid
|
||
acronyms in your interfaces whenever possible!
|
||
|
||
- ``DVM`` - Disposable Virtual Machine
|
||
|
||
- ``GUID`` - Global Unique Identifier
|
||
|
||
- ``PID`` - Process Identification Number
|
||
|
||
- ``NetVM`` - Networking Virtual Machine
|
||
|
||
|
||
|
||
Despite this rule, some acronyms like ``USB`` are widely used and
|
||
understood due to being in common use for over a decade. It is good to
|
||
use these acronyms when the full words like ``Universal Serial Bus`` are
|
||
more likely to confuse users.
|
||
|
||
.. important::
|
||
Use Simple Words
|
||
|
||
|
||
Use the minimum amount of words needed to be descriptive, but also
|
||
informative. Go with common words that are as widely understood.
|
||
Sometimes, inventing a word such as ``Qube`` to describe a
|
||
``virtual machine`` makes the life of the user much easier.
|
||
|
||
- Use ``Disposable Qube`` instead of ``DVM`` or
|
||
``Disposable Virtual Machine``
|
||
|
||
- Use ``interface`` instead of ``GUI`` or ``Graphical User Interface``
|
||
|
||
- Use ``application number`` instead of ``PID`` or
|
||
``Process Identification Number``
|
||
|
||
- Use ``Networking`` or ``Networking Qube`` instead of ``NetVM`` given
|
||
context
|
||
|
||
|
||
|
||
|
||
----
|
||
|
||
|
||
.. important::
|
||
Avoid Technical Words
|
||
|
||
|
||
Technical words are usually more accurate, but they often *only* make
|
||
sense to technical users and are confusing and unhelpful to
|
||
non-technical users. Examples of technical words that might show up in
|
||
Qubes OS are:
|
||
|
||
- ``root.img``
|
||
|
||
- ``savefile``
|
||
|
||
- ``qrexec-daemon``
|
||
|
||
|
||
|
||
These are all terms that have at some point showed up in users’
|
||
notification messages. Each term is very specific, but requires the user
|
||
to understand virtualization to interpret.
|
||
|
||
.. important::
|
||
Use Common Concepts
|
||
|
||
|
||
Large amounts of the global population have been using computers for one
|
||
or two decades and have formed some mental models of how things work.
|
||
Leveraging these mental models are a huge gain.
|
||
|
||
- Use ``disk space`` instead of ``root.img``, since while not quite
|
||
accurate, it makes contextual sense
|
||
|
||
- Use ``saving`` instead of ``savefile`` as the former is the action
|
||
trying to be completed
|
||
|
||
- Use ``Qubes`` instead of ``qrexec-daemon`` as it gives better context
|
||
on what is happening
|
||
|
||
|
||
|
||
These words are more abstract and user relevant- they help a user
|
||
understand what is happening based on already known concepts (disk
|
||
space) or start to form a mental model of something new (Qubes).
|
||
|
||
|
||
----
|
||
|
||
|
||
.. important::
|
||
Avoid Inconsistencies
|
||
|
||
|
||
It is easy to start abbreviating (or making acronyms) of long terms like
|
||
``Disposable Virtual Machine`` depending on where the term shows up in
|
||
an interface.
|
||
|
||
- ``DVM``
|
||
|
||
- ``DispVM``
|
||
|
||
- ``DisposableVM``
|
||
|
||
|
||
|
||
This variation in terms can cause new users to question or second guess
|
||
what the three different variations mean, which can lead to inaction or
|
||
mistakes.
|
||
|
||
.. important::
|
||
Make Things Consistent
|
||
|
||
|
||
Always strive to keep things consistent in the interfaces as well as
|
||
documentation and other materials.
|
||
|
||
- Use ``Disposable Qube`` at all times as it meets other criteria as
|
||
well.
|
||
|
||
|
||
|
||
By using the same term throughout an interface, a user can create a
|
||
mental model and relationship with that term allowing them to feel
|
||
empowered.
|
||
|
||
|
||
----
|
||
|
||
|
||
.. important::
|
||
Avoid Duplicate Words
|
||
|
||
|
||
It is easy to add words like ``Domain`` before items in a list or menu
|
||
in an attempt to be descriptive, such as:
|
||
|
||
.. code:: bash
|
||
|
||
Menu
|
||
- Domain: work
|
||
- Domain: banking
|
||
- Domain: personal
|
||
|
||
|
||
|
||
The repeated use of the word ``Domain`` requires a user to read it for
|
||
each item in the list, which makes extra work for the eye in parsing out
|
||
the relevant word like ``work, banking, or personal``. This also affects
|
||
horizontal space on fixed width lines.
|
||
|
||
.. important::
|
||
Create Groups & Categories
|
||
|
||
|
||
It is more efficient to group things under headings instead as this
|
||
allows the eye to easily scan the uniqueness of the items. (As per our
|
||
previous example:)
|
||
|
||
.. code:: bash
|
||
|
||
Domains
|
||
- Work
|
||
- Banking
|
||
- Personal
|
||
|
||
|
||
|
||
|
||
----
|
||
|
||
|
||
Easy To Complete
|
||
----------------
|
||
|
||
|
||
Lastly, expected (and unexpected) situations often require user actions
|
||
or input. Make resolving these occurences as easy as possible to
|
||
complete the action.
|
||
|
||
.. important::
|
||
Don’t Leave Users Stranded
|
||
|
||
|
||
Consider the following notifications:
|
||
|
||
- ``The disk space of your Qube "Work" is full``
|
||
|
||
- ``There was an error saving Qube "Personal"``
|
||
|
||
|
||
|
||
Instead of displaying solvable errors like these and neglecting to
|
||
provide a fix:
|
||
|
||
.. important::
|
||
Offer Actionable Solutions
|
||
|
||
|
||
Error messages and limits such as those in the previous example can be
|
||
greatly improved by adding buttons or links to helpful information.
|
||
|
||
- Add a button to ``Increase Disk Space``
|
||
|
||
- Add a link to a documentation page called
|
||
``Troubleshoot saving data``
|
||
|
||
|
||
|
||
In adhering to these principles, you’ll make undesirable situations more
|
||
manageable for users instead of feeling stranded.
|
||
|
||
|
||
----
|
||
|
||
|
||
.. important::
|
||
Minimize Repetitive Steps
|
||
|
||
|
||
There are many cases where a user wants to perform an action on more
|
||
than one file or folder. However in order to do the action, the user
|
||
must repeat certain steps such as:
|
||
|
||
1. Click on ``Open File`` from a menu or button
|
||
|
||
2. Navigate through file system
|
||
|
||
|
||
|
||
- Click Folder One
|
||
|
||
- Click Folder Two
|
||
|
||
- Click Folder Three
|
||
|
||
- Click Folder Four
|
||
|
||
|
||
|
||
3. Select proper file
|
||
|
||
4. Complete task on file
|
||
|
||
|
||
|
||
|
||
|
||
That subtle act of clicking through a file system can prove to be
|
||
significant if a user needs to open more than a couple files in the same
|
||
directory. We can alleviate some of the work by changing the process:
|
||
|
||
1. Click on ``Open File`` from a menu or button
|
||
|
||
2. Remember last open folder/file system
|
||
|
||
3. Select proper file
|
||
|
||
4. Complete task
|
||
|
||
|
||
|
||
Clearly, cutting out something as simple as navigating through the file
|
||
system can save a user quite a bit of time. Alternatively, adding a
|
||
button or menu item like ``Open Multiple Files`` might be even better,
|
||
because remembering and using relevant hotkeys is often something only
|
||
power users know how to do!
|
||
|
||
|
||
----
|
||
|
||
|
||
GNOME, KDE, and Xfce
|
||
--------------------
|
||
|
||
|
||
The desktop GUIs that QubesOS versions 1 - 4.1 offer are
|
||
`KDE <https://kde.org>`__ and `Xfce <https://xfce.org>`__. We are
|
||
currently migrating towards using `GNOME <https://www.gnome.org>`__. We
|
||
know some people prefer KDE, but we believe Gnome is easier to use for
|
||
average non-technical users. Xfce will always be supported, and
|
||
technical users will always have the choice to use KDE or other desktop
|
||
environments.
|
||
|
||
This change means you should use `GTK <https://gtk.org/>`__ rather than
|
||
Qt for new GUIs.
|
||
|
||
All three of these mentioned desktop environments have their own `human interface guidelines <https://en.wikipedia.org/wiki/Human_interface_guidelines>`__,
|
||
and we suggest you familiarize yourself with the platform you developing
|
||
for.
|
||
|
||
- `GNOME Human Interface Guidelines <https://developer.gnome.org/hig/>`__
|
||
|
||
- `KDE HIG <https://hig.kde.org/>`__
|
||
|
||
- `Xfce UI Guidlines <https://wiki.xfce.org/dev/hig/general>`__
|
||
|
||
|
||
|
||
|
||
----
|
||
|
||
|
||
Further Learning & Inspiration
|
||
------------------------------
|
||
|
||
|
||
Learning to make well designing intuitive interfaces and software is
|
||
specialized skillset that can take years to cultivate, but if you are
|
||
interested in furthering your understanding, we suggest the following
|
||
resources:
|
||
|
||
- `Learn Design Principles <https://web.archive.org/web/20180101172357/http://learndesignprinciples.com/>`__
|
||
by Melissa Mandelbaum
|
||
|
||
- `Usability in Free Software <https://jancborchardt.net/usability-in-free-software>`__ by
|
||
Jan C. Borchardt
|
||
|
||
- `Superheroes & Villains in Design <https://vimeo.com/70030549>`__ by
|
||
Aral Balkan
|
||
|
||
- `First Rule of Usability? Don’t Listen to Users <https://www.nngroup.com/articles/first-rule-of-usability-dont-listen-to-users/>`__
|
||
by Jakob Nielsen
|
||
|
||
- `10 Usability Heuristics for User Interface Design <https://www.nngroup.com/articles/ten-usability-heuristics/>`__
|
||
by Jakob Nielsen
|
||
|
||
- `Hack Design <https://hackdesign.org/>`__ - online learning program
|
||
|
||
|