Autore: Alan Data: To: tails-ux Oggetto: Re: [Tails-ux] Results of UX tests on Greeter
Hi,
sajolida <sajolida@???> wrote: > At the beginning of the month, we organized together with Lunar from Tor
> a UX testing session of the last prototype of Tails Greeter, designed by
> Alan and Spencer.
> Thanks for organizing that and for the very nice results presentation!
> As a first note, I wanted to say that the new Greeter is awesome! There
> are surely many little things to improve but it did very well. I was
> also surprised to see how good newcomers do with the GNOME widgets. Many
> of the testers were interacting with Tails and probably GNOME for the
> first time.
> Thanks!
> [1]: Virtual keyboard (bonus).
>
> Nobody was blocked by the default keyboard not being their usual one but
> many did typos. I wonder how would this be for people using non-Latin
> scripts. In case people really can't make it to select their language
> with the mouse of the default keyboard, maybe a virtual keyboard would
> help. That's anyway something we want to integrate in the Greeter to
> protect from keyloggers but that's quite some work.
> I agree we should add a virtual keyboard, and that will help to solve
this issue.
> [2] [6] [11] [12]: Auto-selection according to language (blocker).
>
> Many people either lost time or started with the wrong keyboard because
> of a lack of correlation between the language and the rest. Changing the
> default keyboard and format based on the language would help. We're
> doing this in the current Greeter and that was part of our plans anyway.
> I agree.
> [4]: "Keyboard layout" (easy)
>
> Someone thought that "keyboard" was referring to the type of keyboard
> (USB, BlueTooth) or drivers, etc. Using "Keyboard layout" which is a
> more common phrasing might help.
> I agree.
> [5]: Split keyboard variant (bonus)
>
> The list of different keyboard layouts is very long and people were
> forced to go through it because of [2]. This was sometimes quite long.
> Splitting the selection in two steps: first language, then the variant
> (optional) might help. That's a bonus as the auto-selection should
> already provide something good and that was not preventing people from
> doing their job.
> See other email. I agree it would be a nice bonus.
> [7]: Formats (won't fix)
>
> I was surprised by how well understood was the "Formats" option. The
> calendar icon worked really well. Many people referred to disliking the
> American date formats :)
> I agree there is nothing to fix.
> [8]: Redesign help button (blocker)
>
> Nobody clicked on the help button [?] and the only person who felt like
> he needed help, looked for it and didn't find it. It needs to be redesigned.
> I agree there is a problem. See other thread for discussing a solution.
> [9]: Allow changing timezone in session (later)
>
> Many people were not configuring the time zone in the Greeter, either
> because they were going too fast, didn't care, or were not used to do so
> in the current Greeter. We already have plans for solving this from the
> desktop.
> I agree. We should release both the option in the greeter and
in the session together.
> [10]: Map for time zones (bonus)
>
> Amongst the few people who configured the time zone, most of them
> searched by country name (France) instead of by city name (Paris) or
> time zone name (Eastern Europe). Adding a map would make this easier.
> That's not a blocker since we don't have the backend to handle custom
> time zones anyway.
> Nice bonus, but it should stay a bonus.
> [13]: Doesn't consider saving language settings (won't fix)
>
> Surprisingly, only one person clicked to save the language settings.
> Still, I propose not to change anything as that's probably something
> that people will learn how to do over time.
> Agreed
> [14]: Warning on language settings in cleartext (blocker)
>
> The only person we questioned about saving the language settings thought
> that they were saved encrypted as with everything in Tails. We should
> really add a warning as planned originally.
> Agreed.
> [17]: Improve camouflage wording + screenshot (easy)
>
> First of all, it seemed to be confirmed that the Windows camouflage will
> be removed from Tails Jessie (January 26). Still, if we get it back
> somehow, the way it is presented in the Greeter should make it more
> clear that this is about the visual appearance only (and not the
> networking behavior for example).
> Agreed.
> [18]: Click outside of the dialog closes the dialog (bonus)
>
> One person was very confused about the overlay of the additional
> settings dialog on top of the main window and had a very hard time
> closing it. Clicking outside of the additional settings dialog should
> close it.
> I'm not sure that it is not a nightmare to implement, but let's try.
Else, what about simply adding a "X" close button in the titlebar?
> [19]: "Start Tails" = "Unlock"
>
> Many people were not clicking "Unlock" before clicking "Start Tails"
> when activating the persistent storage. We should make "Start Tails"
> perform the same action as "Unlock" before starting the session.
> Agreed.
> [20]: Info bar about bridge configuration
>
> Everybody we had to configure a bridge was confused about the fact that
> the bridge information was not entered in the Greeter and was worried
> about having made a mistake. We can't really change this now as that's a
> much more complex issue but for the time being we could add an info bar
> in the Greeter saying that the actual configuration will be done later on.
> Agreed.
> [21]: "bridge" → "Tor bridge" (easy)
>
> One technical person thought that "bridge" was referring to the
> networking device (ISO layer 2 bridge) and not "Tor bridge".
> Agreed.
> [22]: "Privacy Settings" → "Additional Software" (easy)
>
> Several people who had to configure an administration password expressed
> that going into "Privacy Settings" was not clear enough, though they
> found their way. I'm proposing to rename this section "Additional Settings".
> Agreed.
> So what's next?
>
> I propose that Alan and Spencer have a look at the rainbow table and
> comment on the solutions I'm proposing. Once we agree on what needs to
> be done we'll create Redmine tickets to solve each one of them.
OK. See other threads for the two problematic issues.
Thanks for organizing and summing up this testing session,