Spencer:
>>>
>>> sajolida:
>>> [4]: "Keyboard layout"
>>>
>>> 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.
>
> More than layout happens here it seems. I am all for using a common
> name in short while refining logic to find a more suitable label.
>
> Being presented with a list of languages should remove any presumption
> that 'Keyboard' referred to the type. I think we can do better than what
> we tested but it is a slippery slope to curate experiences to every
> level of cognition.
My point here is that we tried to be creative by using "Keyboard
language" and then "Keyboard" while other OS (for example OS X [1] and
Windows) consistently use "Keyboard layout". But the point raised by
this use is that "keyboard" is not specific enough as it could also mean
"keyboard hardware". So I'm really in favor of using the industry
standard for this one which can't hurt.
[1]:
https://support.apple.com/en-us/HT202038
[2]:
http://windows.microsoft.com/en-us/windows/change-keyboard-layout#1TC=windows-7
> We need more tests :)
I won't do any myself :)
>>> [5]: Split keyboard variant
>>>
>>> The list of different keyboard layouts is very long and people were
>>> forced to go through it
>>
>> Lunar:
>> split the selection with two dropdown: Region and then City.
>>
>> This could also be a solution for language selection.
>
> Will explore.
>
>>>
>>> [7]: Formats
>>>
>>> Many people referred to disliking the
>>> American date formats :)
>>>
>
> I think you mean US (MDY), since Central and South America use the same
> format structure as most of Europe. In Canada, all three formats are
> used :)
Yes, sorry people used "American" to mean "US". They refer to MDY.
> If tested in half of the world your finding will be reproducable :)
>
> DMY it is then, yeah? Only in conversation is DMY often broken;
> reading is working and as far as I can tell Tails doesn't talk.
>
>>> [8]: Redesign help button
>>>
>>> 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.
>
> It needs tested with more people. One person isn't a reasonable sample
> size.
First, regarding methodology: we're not doing statistics here and we
don't need statistically reasonable sample sizes to detect problems and
propose solutions. Otherwise we'll never get there :) UX testing is more
about opening your eyes to things that you didn't see before than doing
stats. Counting the occurrences of a problem can be relevant to
prioritize them.
In this particular case, of course, we're discussing whether the help
button is visible enough and that's very subjective to this person, he
could have bad sight, be slightly colorblind, etc. But to me who saw him
do this interaction this was clearly a blocker: he expressed the need
for a help button, looked for it 1 or 2 seconds but couldn't find it. So
I guess this will happen to more people looking for it and to ever more
people who are not deliberately looking for it.
But I also don't think that's a big deal and I won't argue more.
>>> [9]: Allow changing timezone in session
>>>
>>> Many people were not configuring the time zone in the Greeter ...
>>> We already have plans for solving this from the desktop.
>
> Will you point me to this?
That's a very old project that need some C++ code :(
https://labs.riseup.net/code/issues/6284
>>> [17]: Improve camouflage wording + screenshot
>>>
>>> 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).
>
> 'Desktop Camouflage' resolves this :) We can add more themes, making
> 'Windows Camouflage' more clear in this layered context. Obviously
> there will be a list of one but let's be future proof with this and open
> the door for Mac and Ubuntu (or whatever) to be built by some awesome
> future contributor.
>
>>> [18]: Click outside of the dialog closes the dialog
>>>
>>> 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.
>
> By itslef, this is the worst functionality ever (iOS, like many other
> things, functions like this), as disoverability is a wild presumption :(
>
> However, if this is one of many ways to exit a dialog (say, in addition
> to a 'Close X'), this is okay :)
We already have the "Cancel" button but she didn't see it. Language was
probably a major issue here as well I reckon.
>>> [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.
>
> Will you point me to the issue?
You worked on this one yourself:
https://tails.boum.org/blueprint/network_connection
To summarize, I think that additional Tor configuration should be
proposed when choosing the network as the user might either:
- not be able to make this decision before knowing to which network
to connect and how it behaves (captive portals).
- want to switch from direct Tor to bridges after failures.
>>> 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.
>
> Okay :) The only things that stand out [4] and [8] need more testing.
I'm not going to do more testing myself. I proposal a solution for [4]
and I'm fine with leaving [8] as it is right now if none of you wants to
work on making it more visible.
> We should do a second test and see what overlaps. The only issue I see
> is the freeze date in <2weeeks :(
I'm not sure it's realistic to be ready for the freeze in two weeks, and
it's not mandatory: the current Greeter works fine in Tails Jessie,
though is even a bit more ugly :)
We could instead aim at releasing the new Greeter in 2.2 (March 8).
> I can organize this for early this coming week and have sharable results
> by the end of the week; let me know. I would need your notes on how you
> ran the session so as to most closely reproduce it. Otherwise, I have a
> guide I use.
If you want to do more tests that's fine with me though I don't think
it's necessary. Here are the guidelines I used:
https://tails.boum.org/contribute/how/user_interface/testing/
If you are working alone, I recommend doing a screencast of the desktop
while the user performs the test, so you don't have to worry about
taking notes while doing the tests.
>> intrigeri
>> In passing, I wonder how the UX looks like after a non-Latin keyboard
>> layout, that requires a specific input method, has been *successfully*
>> selected (IBus support in the new Greeter?).
>
> Me too :) If anyone can create this, please share some images.
