Re: [Tails-ux] Greeter revamp: new prototype

Delete this message

Reply to this message
Author: sajolida
Date:  
To: Tails user experience & user interface design
New-Topics: [Tails-ux] Tails Terminology [was: Greeter revamp: new prototype]
Subject: Re: [Tails-ux] Greeter revamp: new prototype
Alan:
> I published a 2nd version of the prototype. Check it!
>
>     http://repo.or.cz/tails-greeter-prototype.git


First of all, a bit of congratulations. The prototype is great! I'm
convinced we have a very strong proposal, the best we've ever had, and
being able to interact with it is super cool. I can't wait to see people
use it!

Then a bit of context: I couldn't spend a lot of time testing and
following this thread closely myself because I was swamped with other
writing work this week (and also didn't have a spare laptop to test it
when I could).

> It's intended to solve the more urgent problems, and to be, with minor
> modification if needed, the tested version for next week.


I have some more that are think were not discussed yet.

For the test session itself, I'm a bit worried about having too many
placeholders. Like the one on "Configure Encrypted Storage". Every time
people will be presented with a placeholder it will bring them out
mentally of a pure usage experience that we want to create for the
tests; probably require interaction with us to clarify what's going on
etc. So I'd try to limit them to the bare minimum.

For example:

- "Configure Encrypted Storage". I think this will not happened before
the first release of this new Greeter, so what about not displaying it
for the time being? I suspect that when we will have the code read to
put this in place, it will anyway be worth conducting user testing of
this change to the Greeter (at least if we move all the persistence
settings in the Greeter).
- "Take a Tour". Same thing: this will not happened before the first
release and we should test this separately once we get there as it's
going to be big. Adjust the intro sentence accordingly.
- "Help" buttons. These I'm not sure and maybe we can leave them. I
think it can be interested to see if people use them. In case they use
them, they've already decided to break the pure usage experience to seek
for help. Maybe we can explain what they need to know when they click
such buttons.
- "Restart" button. Is this going to work when I do the tests?

Then I could nitpicking on a bunch of terminology and phrasing issues
but maybe you discussed them already so I don't know how to proceed. I
could either:

I think I'll raise some of the terminology issues here, submit patches
for the typos and phrasing, and wait and see on others :)

As a general rule, please refrain from changing or remixing terms or
feature names that we are using elsewhere (for example in the doc); at
least without checking with others outside of your threads. Because we
want to use consistent terminology everywhere, and partial changes
(unless well justified) are going to be problematic because changing
terminology only in one place, would affect many other (documentation,
possibly user support, other interfaces, etc.).

1. "Keyboard Language" is an uncommon concept. GNOME talks about
"layout" in the system settings. So I'd say "Keyboard Layout" (or
"Keyboard" only if you prefer).

2. "Save XXX Changes" maybe I'd rather say "Save XXX Settings" as what
we are saving here are the settings and not the changes. Especially when
used with a *checkbox* which describes a *state* (and not a *change*).

3. "Administrative Account". Here you're changing the way we're calling
this everywhere else in the doc ("administration password") which is
unconsistent. Also, I think that "account" here is misleading because
people don't interact with different accounts here (as is "account =
login + password") and use this password through sudo and other access
granting mechanisms which I don't associate with an "account". And
regarding "administrative" vs "administration" I'm not convinced the
change is worth it but maybe I missed some discussion.

4. "Encrypted Storage". when discussing this terminology again earlier
this sprint we settled on saying "Persistent Storage" and, in some
relevant places "Encrypted Persistent Storage". We didn't feel ready to
drop the terminology "persistence" which is all over the place. In the
case of the Greeter I propose to call this section "Persistent Storage".
People who already have it set up should know it's encrypted. For people
who don't we can still label the configure button as "Configure
Encrypted Persistent Storage".

5. "Network Connection / Direct". I'm afraid people might think this is
"direct" in opposition to "Tor" (which could be "indirect" in some
mental models). But I'm ready to wait and see if this is indeed
problematic. Also note that we're currently calling this "Network
configuration", see the doc.