segfault:
> sajolida:
>> segfault:
>>> - Display the connection information on click in a separate window
>>
>> Why didn't you use a button for this? I mean replace "Click to display"
>> with a button labeled [Connection Information]?
>
> I used a clickable label, because it blends in well with the other
> clickable labels. A button wouldn't need a label on the left. But now
> that I'm going to use the edit mode instead of the clickable labels
> anyway, I think I can also use a button for this.
You can try and see how it looks.
>> Does "Info" work well? Would "Information" or "Details" work better?
>
> I didn't test this. But I don't think that anyone wouldn't get what
> "Info" means.
Sure, sorry :)
>>> This time I did the tests with less skilled users (the first tests were
>>> mainly with IT students). The feedback was less positive, the average
>>> SUS score was only 60.5/100 (it was 83 in the first tests). They also
>>> had a lot more problems and needed more time to solve the tasks (average
>>> of 16 minutes).
>>
>> Ouch! Choosing the testers well is very important.
>
> Sure. But I wrote to you in private weeks ago that the participants will
> probably be IT students. I'm glad I did some more tests with other users
> too, because I think it's valueable to know about this difference in
> user experience, so we can work on improving it for less experienced users.
I didn't meant to criticize your recruiting and I was surprised myself
by the big difference between the two groups.
To answer Spencer, the point here I think is to recruit users that would
be good user representatives of what you want to test. In the case of
Tails Server, I think it makes sense to consider that the people who
will dig into Tails Server will be slightly more technical than "the
average Tails user". For example, if you want to organize a group call
between 5 people, it's likely that the person who feels the most
technical will be the one to set up the server. But still, we shouldn't
consider Tails Server as for advanced users only.
So actually, I think we learned a lot by testing first with IT students
and then with non-IT students as for example it helped understanding
better the mental model problem (client-server) which was problematic
only with the second group.
>>> The main problems discovered:
>>>
>>> - 4/5 had at least some problems with the client-server concept, i.e.
>>> they didn't understand that they are hosting a server on their machine
>>> and have to connect to this server with a client application. And they
>>> tried to modify the server config in the client, especially during step
>>> 6. "Configure the Mumble service so that it will automatically start
>>> after a reboot of the system".
>>> - This is what sajolida (and others?) already expected. I'm not sure
>>> what we can do about this. sajolida suggested showing a schematic of the
>>> concept in the placeholder in Tails Server. Maybe we can also display a
>>> line "You can connect to this server with 'Mumble'", and maybe open the
>>> application on click on the application name.
>>
>> Did you ask what "server" and "service" meant to them?
>
> Some were confused by these terms. I think we should use "server"
> instead of "service" in the GUI.
You could try to do this change, but I also understand what Spencer says
about the fact that a "service" is run by a "server", and using only
"server" might be problematic in some places. A good check would be to
try and see if any sentence of label becomes very weird.
>> Another idea could be to avoid using "Mumble" only in Tails Server and
>> prefer using "Mumble server". For example in the left pane and the title
>> of the service. Maybe it will help people differentiate between the
>> "server" and the "client". Then maybe it will become inconsistent and
>> confusing to use both "server" and "service".
>
> I agree.
\o/
>>> - When asked to modify the options, 4/5 needed at least 1 minute to
>>> figure out that they had to stop the service before they can edit the
>>> options.
>>> - I think I will use the edit mode we discussed instead of the
>>> clickable labels, which will hopefully make it more obvious how to edit
>>> the options.
>>
>> Ok.
>>
>>> - 2/5 tried editing the password in the "Connection Information" window,
>>> after they were not able to edit it in the config panel. I think this
>>> would be solved when we solve the problem that the user's don't know how
>>> to edit the options.
>>
>> When I proposed to display a dialog when people try to edit the grayed
>> out option you rightly said that this would be to invasive and annoying.
>> Then what about an InfoBar or something message in the same window that
>> would be less invasive? With "Stop the service to be able to edit its
>> settings" or something like this.
>
> We could do something like this if we don't want to use the edit mode.
> With the edit mode, the service wouldn't need to be stopped before
> editing, but only when applying the changes.
Ah, ok!
>>> - 3/5 needed some time to see the on-switch to actually start the
>>> service after installing it
>>> - I don't know how we can make this more obvious. I think putting
>>> on-switches in the top-right corner is standard in GNOME. And I don't
>>> see any other position where it would be more noticeable without looking
>>> awkward.
>>
>> Now I realize that the "Status" info is not aligned with the [On/Off]
>> switch which is also indicating the status. Maybe merging all this in
>> one line would help. The line could be structured like this:
>>
>> - Status: [On/Off] (Spinner) (Additional status info...)
>
> Ok, I will try this. You would leave out the red / green "light" then?
Good question... To which extend the red / green light only duplicates
the state of the on / off button? Would removing the red / green light
be problematic in some cases, for example when starting the service?
Would it be enough to have only the on / off switch and say that:
- when the switch is turned on, we try to start the service and
feedback about the progress in the status.
- if the service fails to start we changed back the switch to off?
>>> - 2/5 were looking for the address and other connection information
>>> before the service had finished starting. They didn't find it, because
>>> the address and the connection info only get populated after the service
>>> was started.
>>> - Maybe we could show them with a hint "Not available until service
>>> started"
>>
>> If you decide to go for a [Connection Information] button, then you
>> could display it only when the info is available.
>
> This is what I'm doing right now. The connection information line is
> only visible when the info is available. This didn't prevent users from
> looking for it.
I understand better now. Then maybe the "Connection Information" button
could be grayed out while the information is not available (instead of
being completely hidden)?
>>> - 3/5 were confused how to close the "Connection Information" window
>>> - Apparently it was a bad idea of mine to name the buttons "Copy" and
>>> "Don't Copy". I think I will rename "Don't Copy" to "Close" and make the
>>> "Copy" button not automatically close the window.
>>
>> You could either have:
>>
>> a. [Close] [Copy] with [Copy] not closing the window.
>> b. [Copy] and have people close the dialog from a top-right
>> [x] button (I see that you don't have any right now).
>
> Right. I'm not sure which I prefer.
>
>>> - 2/5 pressed the '+' key on their keyboard instead of the '+' button
>>> after reading "Click '+' to create a new service" in the placeholder
>>
>> My bad. The placeholder should read "Click the '+' button to create a
>> new service".
>
> Not sure if this would work better. Especially in other languages, where
> "button" and "key" could be the same term.
I don't know of any such language. I'm not saying they don't exist but I
would be surprised if there was no way of differentiating between "GUI
button" and "Keyboard key".
>> We could also, as suggested by the GNOME HIG, make the [+]
>> button blue ("suggested") when there are no services configured.
>
> I tried doing this with the GTK SUGGESTED_ACTION style class. But it's
> not supported for GtkToolButton, only normal buttons - so it seems like
> this is not used for tool buttons. It's also not how "Printers", "Online
> Accounts", etc. do it. But if we decide to do it anyway, I could of
> course try to imitate the modifications done by the SUGGESTED_ACTION
> style class (i.e. the blue color).
Thanks for trying, and let's forget about this then :)
>>> Problems in Mumble:
>>> - None of the users verified the certificate
>>> - 1/5 saw the SHA-1 sum in the connection info, but didn't find it in
>>> Mumble
>>> - anonym's Mumble patch will make this a lot easier, because it will
>>> display the fingerprint directly in the warning message
>>>
>>> - 1/5 saw the SHA-1 sum in Mumble, but not in the connection info
>>> - I'm not sure how to prevent this. We could display the fingerprint
>>> directly in the config panel.
>>>
>>> - 1/5 thought the warning was caused wrong connection data
>>> - The others didn't care at all
>>>
>>> - 4/5 were not sure if they could choose the "Label" field in the "Add
>>> Server" form themselves or had to fill in the correct value. One was
>>> stuck for a long time on this, because he thought the certificate
>>> warning was caused by the wrong value in the "Label" or "Username" field.
>>
>> I also thought this would be a problem but maybe I didn't mention it and
>> wanted to see if it would be show up during the tests.
>>
>> Maybe a workaround for us would be to have this as an editable field in
>> Tails Server with a placeholder "My Mumble server" or something like
>> this and then give it in the connection information.
>
> We could use a placeholder like this in the connection information, but
> I don't think we should provide an editable field for this in Tails
> Server. The user has to copy/paste this string anyway, so he can just
> edit it in the Mumble form.
Ok, and from a technical point of view it doesn't make sense to provide
this as an editable field in Tails Server since it doesn't match any
real setting of the server. Then what about displaying in the connection
information only: "Label: A name of your choice"?
>> The real solution
>> would be to fix this in Mumble client... Maybe by removing it all the
>> way and using instead the IP address or onion address to display it in
>> the list of servers (with an option to rename it on the fly there).
>
> ACK
Do you feel like reporting an upstream UX bug? :)
>>> - 3/5 were confused that there is no "password" field in the "Add
>>> Server" form
>>
>> I also thought about this. That would also have to be fixed in Mumble
>> client upstream. If I understand correctly, all servers have a password
>> so why not ask for it together with all the other information?
>
> Not all servers have a password. With the default config there is no
> password. So I guess a password field would be confusing for users
> connecting to a server without a password.
Ah, I didn't know that!
