title: Tails Greeter Design Rationale
What is This?
This document serves as an explanation of the rationale behind the proposed Greeter design related to tails#8230 (closed). This document will grow over time, so please feel free to agree with, object to, or request anything.
- What is This?
- History of this document
- Implementation phases
- Proposed design for the 1st screen
- Upcoming settings
History of this document
This document is the result of a process that took more than one year:
- Spring 2014: discussion on the greeter with NUMA people
- Summer 2014: mockups implementing the results of these discussions
- Winter 2014: test of these mockups and changes proposals by 2 designers
- Spring to Summer 2015: redesign of the 1st screen and flow
- 2017: reconsider some decisions after discovering unexpected, problematic impact
Please take this into account when you comment on current proposals. Improvements are more than welcome but yet another complete redesign is not, unless you have a very strong point.
After working on a prototype and doing UX testing with some folks at NUMA, we arrived at the idea of having two main experience flows:
- Guided Configuration: A wizard to guide new users
- Self-guided Configuration: A quick setup for veteran users
The result of this step can be found in this NUMA flow.
The implementation and release of this is scheduled in three phases. The intention is to make progress that can be delivered as soon as things become reality:
PHASE 1: Redesign the Greeter's 1st screen. We then have similar functionality to the current Greeter but more clearly presented.
PHASE 2: Add a wizard to guide beginners ("Discover: Guided Configuration")
PHASE 3: Merge the persistence creation/configuration into the Greeter
We are proposing this because we have been debating a lot on the first screen(s) and we have reached something that is worth being tested and implemented. There is still work needed on the Guided Configuration wizard.
Proposed design for the 1st screen
We refined this on the tails-ux mailing list to arrive at the following concrete proposal for the 1st screen. Below in this document we explain every designation.
Design a greeter dialog that:
- Accommodates for one-click access to localization and persistence options
- Accommodates for fast access to other advanced options
- Has a simple and easy to understand interface for both new and advanced users
- Uses as much tested data from previous design iterations as possible
- Is up-to-date with GNOME 3.14 guidelines
A single welcome and settings screen, which is always displayed, that acts as a "Check & Go" screen, as well as a hub for editing settings.full size bitmap source
Current condition:full size bitmap
UX for specific options
Language & Region
The language section is always visible. When a language is saved (in cleartext), it is automatically filled in with saved options.
When a line is clicked, a popover (https://developer.gnome.org/hig/stable/popovers.html.en) opens with an explanation of the option and the controls to change its value.
As the values change their new value will replace the previous value in each respective location.
It is clear that the "Language" section can/should be saved, but not yet weather the "Settings" section can/should be saved.
UI when "Save Language Changes" is checked:
- On a new Tails installation the check box is unchecked by default.
- When the user switches languages the check box is checked, then a warning is displayed.
- The next time Tails starts the language preferences that were saved unencrypted are detected and the box is automatically checked.
- When the user switches languages by unchecking the box to remove the saved preferences, a notification is displayed saying that the options were safely deleted.
See the dedicated page about the Formats setting.
Explanation of this design
Content Structure Types
Which content structure type is most appropriate for the Greeter?
- Step-by-step: Guided walkthrough
- Show/Hide: Hidden off-screen or behind on-screen element
- Openface: Full display
With the Step-by-step flow already established as the most appropriate guided configuration structure, the designation made was that the Show/Hide structure most appropriately accommodates the two end-of-spectrum use cases (noob and veteran). However, this does not align with the GNOME HIG or provide feedback to the user which options are selected (when diverging from defaults). We thus chose to:
- Add a "+" button to add a customizable setting, as commonly found in GNOME lists
- Only display privacy settings that diverge from defaults
Options Available On The 1st Screen
The hypothesis is that a good design should allow people to teach themselves.
With this said, it seems appropriate to educate people of varying technical levels of understanding what options are available to them and what importance these options hold in regard to the intended function.
In our situation, this is most effectively accomplished by displaying all settings groups upfront. However, in order not lose the beginners, the privacy settings are hidden when they doesn't diverge from defaults.
Start Tails Button Location
Where should the ‘Start Tails’ button be located?
- Top of Greeter
- Bottom of Greeter
- Greeter Frame
- Greeter Canvas
- Button in an Action Bar
- Button Isolated
This is really a few things, but the designation was made that the most appropriate location for the ‘Start Tails’ button is above the Greeter canvas as part of an Action Bar. Although placing the ‘Start Tails’ button at the bottom of the Greeter follows the flow logic of configuring the session settings and then starting Tails, the most occurrent use cases are 1) using Tails with default settings, and 2) using Tails with saved custom settings, therefore, it seems most appropriate to have the ‘Start Tails’ button ordered before the settings. Placing the ‘Start Tails’ button in the Greeter frame instead of the canvas is an attempt to lessen the number of elements on the canvas. Using an Action Bar aligns with GNOME HIG and provides a place for other buttons.
Section order and labels
How should the settings section be ordered?
- Alphabetical: Language, Settings, Storage
- Importance: Storage, Language, Settings
- Logical: Language, Storage, Settings
An order such as alphabetical is much less helpful than ordering by importance or by logical steps. On top of that, to setup storage, one should select the appropriate language first to be able to read or write. Thus the choice of the Language, Storage, then Settings order.
Should the settings sections be labeled with either two or three labels?
The designation was made that having three sections with three labels was the most appropriate approach given the high need for conceptual clarity, especially for new users. Three sections with two labels (grouping all of the settings together under ‘Settings’), although more minimal, became too ambiguous and didn’t emphasize/isolate the ‘Language’ section enough.
Should icons accompany the Section or Line-item labels, none, or both?
- Line Item
Given the context of the settings list, the designation was made that icons should only accompany the labels of the line-items. Aside from the visual conflict that arises between the Section and Line-item label icons when placed so close together, Tails, as well as many other operating systems, currently uses colored and monochromatic icons to accompany line items for almost every list, and displays no icon for section labels.
Should icons accompany button labels?
The designation was made that icons should not accompany button labels. In addition to the proposed 'Start Tails', 'Play', and 'Computer' icons not being as precise as they could be in regard to the communication of their function, there is great difficulty involved in effectively transforming 'Restart', 'Tour', and 'Start Tails' into iconic and accurate representations of their concepts.
Should the Greeter have the option to be closed/restarted?
- No Close/Restart
Since there are multiple boot modes to choose from for Tails, the designation was made that a ‘Restart’ button located in the Action Bar of the Greeter would accommodate a user’s preference to go back and boot into failsafe mode.
The following new settings are planned or discussed: