segfault:
> sajolida:
>> segfault:
>>> sajolida:
>>>> segfault:
>>>>> 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.
>
> I also understand that point. And I think maybe in English it is more
> obvious that a "service" is served by a "server". But I did the tests in
> German and used the terms "Server" and "Dienst", which are the terms
> usually used IMO. These terms were confusing for the non-technical users
> because they didn't know the meaning and didn't know that the "Dienst"
> is run by the server. Maybe I should just have used the English terms -
> then it would be more obvious that 'service' has something to do with
> the server, but non-technical german users would still not get the meaning.
Good point! Then I think we should have a closer look at all your
translatable strings and see if we could use a single term in all places
and if it works in the languages we know best.
>>>>> - 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)?
>
> I'll try this. Users could still be wondering why the button is grayed
> out and how they can get the information they are looking for. This
> whole thing would be no problem if starting the service wouldn't take so
> long :/
Graying out some widgets until it's available is a very common pattern
so we should look at people usually solve the problem of communicating
what needs to be done to activate these widgets (and also, sometimes
there is not information and that's fine). Maybe a solution would be to
use a tooltip. I'm offline so I can't check the GNOME HIG but there are
still some tooltips in the GNOME we have in Tails, see attachment.
I also still wonder about how we could get "(requires Persistence)" out
of the main display, though it's not a big deal, it would unclutter the
default display and could provide the information only when relevant.
Maybe a tooltip on Autostart would work here as well.
I also thought about using Responsible Disclosure: only display
Autostart when persistence is enabled. Knowing that an Autostart option
exists for people who don't have persistence is probably not a strong
incentive enough to create a persistence. So displaying this option to
everybody might not be really helpful.
Sorry for bring up new ideas and feel free to discard them as it's no
big deal (just itching me!).
>>>>> - 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".
>
> Again, this would be problematic in German. Actually, I know no
> frequently used german word for "button". I think just using the english
> term would be what you see most frequently, but again I'm not sure if
> non-technical users would understand what it means.
Could you look at what Microsoft and Apple documentations use to
translate "GUI button" and "keyboard key" in German?
