Ticket: #5464

Rationale

tails-greeter works fine, and its code in not that bad anymore, so on this side it's now feasible to add features (e.g. ticket #5421, ticket #5479).

However, the greeter UI is difficult to use, and adding more options in the current state of things would only make things worse usability-wise.

So, we have to improve the greeter UI to make it more ergonomic and easier to use.

Design

Clarify specification

It would help a lot to clarify some areas of the greeter specification. This may involve revisiting a few past decisions:

Do we still want the first screen to look like a Windows (NT4) login screen?
Do we still want a second screen for options? Or another way to show it?
Do we want the look to depend on whether the Windows theme was opted-in?
How much do we want to optimize for first-time users?

Usability study

Draft several User eXperience (and layout) options
Make them testable
Make an usability study:
- catch testers (Tails users and/or newbies)
- make them test, see what they do and ask them what they think

We may want to ask input from UX experts, and/or pay one to run the usability study.

References

http://design.canonical.com/2013/08/usability-testing-how-do-we-design-effective-tasks/

Prototypes

Some proposals to test!

Goals

My goals for the interface was:

read in "natural" order: top to bottom
no hidden windows/options
easy to adapt to right-to-left languages RTL
inspired/similar to GNOME3 "system preferences"

Screenshots

Please test the script below, which lets you try the user experience!

The greeter started from DVD:

The greeter started from USB with persistence:

The greeter started from USB with persistence once language selected:

The greeter once the administration password option clicked:

The greeter once the keyboard option clicked:

The greeter once the windows camouflage option clicked:

How to test

Download everything in mockups, or better clone the git, go to the directory and:

$ ./mockup.py [-v <variant>] [-p]

Dependencies: gtk3, python gobject introspection (basically debian wheezy)

Questions

I'd like to hear about:

your overall impression?
should keyboard selectable independently from locale in one click?
your navigation experience?
where should the locales box be?

(Note that some answers were sent on tails-dev already.)

Remarks (add yours!)

add a symbol if option was visited/activated
activation of presets in persistence: when?

Resources

Related tickets

Moving stuff out of the greeter: ticket #5501

Past discussions

Past work

feature/single_toggle_button branch in tails-greeter repo

UI / UX documentation

GNOME's studies on the subject

Feedback

This is feedback about the current greeter.

Report #1

User interface is confusing.

The combination of "green/red icons + the check mark + pushed button" is really hard to grasp.

How about a big push button labeled "Persistence", maybe with an icon?

The current behaviour for "More options?" is also problematic... How about having a "More options" button at the bottom, near the "Login" button? Ideally, this would require a "Back" button on the "Administration password" scren, but even without it, I think the result will be easier to understand/use.

How about using checkmark boxes or Yes/No radial dials, or not use them at all? Entering a password into a box means it's enabled, and leaving it empty implies you don't wish to use the feature. The text in my example here is a bit big though:

Report #2

A few impressions after the publication of the screenshots. Great job by the way!

The buttons ON/OFF are sometime confusing, as it's hard to know if it reflects the actual configuration, or the ability to modify this configuration, i.e. if the option is actually activated or if clicking on this button will toggle this option ON. I hope I'm clear enough :)

Please also keep in mind that some use small screens, and can get blocked if the cannot see the validation button.

Last point, as I will have to use Tails-greeter at each boot, I would like to be able to handle it easily with the keyboard, to save a lot of time.

That said, thanks a lot for the great job!

Report #3

Indeed, this is a great polishing of the user interface, at least in terms of appearance. I failed to download anything from the mockups page though so be aware that this opinion is based on the screenshots only

I do have some corrections and suggestions though, from the screenshot it is apparent that it allows to choose "Portugues" (with a eacute) as a region/locale, which is not! It is a river and neighborhood in Porto Rico. "Portugues" (with a ecirc) is the correct word for Portuguese in Portuguese.

Now as for if "Should keyboard selectable independently from locale in one click?", I would say yes as I use it in the current greeter. I do this for two reason: First in case my tails session gets owned the attacker will perhaps not know from which country I am though I am aware in that situation I probably have far worse problems as far as de-anonimization goes. And second, I am fluent in English, and I prefer to see the menus and the documentation in English (as are more complete). Having to scroll down to get the Portugal keyboard in the current greeter is quite annoying though and I often wonder why are the other languages more obscure keyboards (like without dead keys and etc) before the more default options. Perhaps ordering alphabetically by languages and after all the defaults keyboards then again the lesser keyboards in this new greeter? (btw why is Portuguese absent from the locales screenshots?)

A last, but most important imho suggestion: no matter how ergonomic you can make the greeter it will always have some usability problems, but there is a way to minimize this! There is already a todo ticket for choosing language at installation time ( see: ticket #5501) but then if someone got hold of your tails she/he could see from where you are and what language you speak. Now, if a new feature in the greeter was implemented - "Greeter Password" (pass-phrase would be overkill in this case as usability is preferred) - language, locale, but also camouflage, read only options for persistence, keyboards and other options to come in the greeter, could be defined at installation time and accessed at boot time with a few keystrokes from universal keys in keyboards. Or perhaps you have two greeter configurations and could setup two passwords.. If you think this feature could be useful perhaps you could revamp the greeter with this in mind for a future version? ;)

Okay that's its :) the overall opinion of the greeter from the screenshots is that you made an amazing job :-) congratulations and thanks :-)

Report #4

The clean, fresh design is nice!
Is "English" preselected? Hopefully the "English" language option is preselected so the most common use case doesn't require an additional click.

Maybe a little checkmark to the left of the current language could indicate this. This would let the user know they can skip past this step without clicking anything more if we have already selected the most common option.
The on/off rocker switch example is confusing. As others have mentioned, 'off' or 'on' could be interpreted as either the current state or is the action to be taken when clicked. A possible alternative would be to use radio buttons and add one more option "Default theme" that is the prechecked radio option. I would rename the entire panel so just "Camoflage" or "Theme" instead of specifically "Windows Camoflage". Doing both of these (using radios and renaming the panel) would also allow for adding another theme like OS X by just adding a new radio option.
I might rename "Bridges" to "Tor Bridges" for clarity even on a user's first use.

Otherwise looks great.

Possible roadmaps

done Decide what DM and language / UI toolkit we will use for the greeter in Wheezy
done Adapt following plans accordingly
Gather more input from people who have strong opinions about the t-g UX: the idea is to encourage work on the greeter by bringing early positive input rather than late negative feedback. This should happen in the dedicated thread.
Clarify specifications (see the Design section above)
1. research a bit the pending questions
2. raise these topics for discussion among Tails developers
Implement plan A or plan B
Update documentation
Send software and documentation for translation on tails-l10n

Plan A - incremental UI changes

The idea is to draft a new possible version first, and then we can decide whether we want to ship it right away, or create other options and benchmark them through a full-blown usability study. Alan committed to lots of things in this plan, but not to any deadline.

Ask for ideas
Propose one or several prototypes
Next thing to do: make some testing happen by various kinds of users
Extract something useful from the result
Implement the chosen proposal in a dedicated branch of the greeter repo

Plan B - full UI rewrite with usability study

Design and sketch prototypes
Organize a usability study
Implement the winner idea