sajolida:
> segfault:
>> I did a second batch of user tests, again with five participants.
>>
>> I changed a few things before these tests:
>>
>> - Use the "clickable labels" I implemented and wrote about before. I
>> will append screenshots of this again. In the previous tests I simply
>> used textboxes for the editable options, which were grayed out while the
>> service was running. Because they were grayed out, they could not be
>> selected, which was a problem for some users, who wanted to copy the
>> strings. With the clickable labels, the users are able to select and
>> copy them, because they turn into normal labels while the service is
>> running.
>>
>> - Only display the onion address and connection information once the
>> service has started
>>
>> - 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.
> 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.
>
>> 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.
>
>> 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.
> 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.
>> - 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.
>> - 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?
> Would this work? What do you need to display in the Status line?
>
>> - 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.
>> - 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:
>
> - [Close] [Copy] with [Copy] not closing the window.
> - [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.
> 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).
>> 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.
> 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
>
>> - 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.
