Meta: I'm realizing now that George was probably not put in copy while
discussing the UI on tails-ux [1] and now we're discussing many UX
issues on tails-dev without putting tails-ux in copy. All my comments
probably make more sense on tails-ux so I'm moving there with George
still in copy.
[1]:
https://mailman.boum.org/pipermail/tails-ux/
segfault:
> George Kadianakis:
>> segfault <segfault@???> writes:
>>
>> [...]
>>
>> I gave your iso a try! The application seems to work pretty well!
>
> Thanks for testing it!
Same here this morning and I was really impressed by the state of
things!!! I didn't read George comments before doing my testing (so
duplicated comments are really duplicates).
>> Here are some nitpicking comments. Feel free to ignore comments that involve
>> parts you have not yet implemented.
>>
>> - When Mumble starts it just says "Online". There is no indication on how to
>> use it, what's the onion address, or how you connect to it.
>>
>> - Why is the reset button available only for Gobby?
>>
>> - Mumble has no options? Not even port or onion address like Gobby?
>
> That should not happen. Seems like you discovered a bug. But I can't
> reproduce it in the current version. :/
I didn't get that bug.
>> - OTOH, Gobby provides useful information when it starts, like the onion
>> address and the port.
>>
>> However, in both cases I was actually not sure how to test or use the
>> service. I wonder if it would make sense to have a small paragraph for each
>> type of service pointing to resources on the internet, or a small guide on
>> how your friends can connect to you... (hm, localization issues?)
>
> I plan to relay on the documentation for this (the question mark).
This also relates to the mental model issue I wrote you about in private
the other day. I feel like we need to make it more explicit somehow how
these services need to be used.
You have the "Connection Information" field which is a good start but I
feel like we need something more. Maybe we should differentiate and
treat better the three different areas of the right pane:
1. General information, service status, On/Off button
2. Service settings
3. Connection Information
Because right now for example the connection information look like a
setting while it's instead a summary of read-only information that are
themselves extracted from the settings (Onion Address, Password).
Hypothesis:
- The connection information could be displayed only once the service is
started (right now I get "None" before the service is set up and that's
useless and confusing).
- Maybe it could be displayed at the bottom and be a bit more verbose,
like George suggested, it could be:
"To connect to this service, use:"
- Application: Mumble (included in Tails)
- Address: pecdctvzgspqtlif.onion
- Port: 64738
- Password: ***********
If the application is not included in Tails we would display something
different and tell which software package to install; but I don't think
we have valid examples right now.
I hope this could be added without making the window too clumsy.
Otherwise maybe have a button "Learn how to connect to your service"
with a popup with this information and an explicit link to the
documentation.
>> - In Gobby, is the server password securely auto-generated? Can we make this
>> more obvious maybe? Or maybe can we have an opt-in "auto-generate" button
>> that generates a password only if the user wants?
>
> In both Mumble and Gobby the server password is a 20 character random
> string. We could implement a button to generate a new (secure) password,
> but I kinda like the secure default. Do you think explaining this in the
> documentation would be acceptable?
>
>> Or maybe the current auto-generate by default approach is best for UI. Not sure.
>>
>> BTW, did you write the password generation routine yourself or is it a
>> module? You don't have one that uses readable words instead of random base64?
>
> I use Python's random module:
> import random; import string;
> ''.join(random.SystemRandom().choice(string.ascii_letters +
> string.digits) for _ in range(20))
>
> I kinda expect users to copy-paste the `Connection Info` (including
> onion address and password). But I think you're right and it wouldn't
> hurt to use something more readable. I did a quick search and didn't
> find any Python module in Debian that provides such a function. Do you
> know one?
I'm more and more doubtful about whether we should provide password
generation at all (sorry), or at least not by default.
I understand that the intent here is to provide strong passwords by
default. But unfortunately, people are not used to manage such random
passwords and I'm wondering whether it will lead to more troubles than
benefits. We (übergeeks) have quite different ways of dealing with
passwords and secure communications than what I expect to be (or would
like to be) the average Tails user. I'll miss personas here to make my
point!
Such passwords take for granted that people will send them over the
Internet through secure channels. I think that proposing this by default
can be problematic depending on the password culture of the user. For
example, some security practices teach you to never send a password (in
clear text) over the Internet. Another reasonable practice that I see
around me is to have weaker passwords but that people can memorize and
share only in person or written temporarily on pieces of paper.
People might also not (yet) be clear about what a secure channel is
appropriate for sending such passwords. Is sending emails through GMail
and HTTPS all-right?
People receiving these passwords will have to store them somewhere and
if they are not used to use a password manager they might do something
much worse than using a weak but memorable password.
And if they are used to use a password manager, then they can use the
password generation tools from there. Which will have more features than
the one we can provide here (diceware!). This is what I would be
personally and having the password generation directly in Tails Server
wouldn't bring me much benefit as I'll probably want to generate more
readable passwords for example.
On the other hand, providing a traditional blank password field wouldn't
question the usual password management of people. They might equally
prefer shared memorable passwords or already be using a password manager
that can generate random passwords.
Of course, I would love to teach people to use password managers and
always different random passwords but I don't think that Tails Server is
the place to do this.
Also, password shouldn't be displayed in clear text by default. That's
another reason to let the user choose their own password: it will be
easier for them to find out what it is.
>> - When Gobby is offline, the "Connection info" says "None". Maybe it should say
>> "Service has not been started" or sth?
>
> A status message is already displayed above, in the status line. The
> onion address is also "None" if the service was not started yet. I don't
> know if it makes sense to set them both to status messages instead.
+1 I think it shouldn't be displayed until the service is started
(because there's no real "connection" to get "information" about yet).
Some more comments in no particular order:
1. Regarding the terminology "server" vs "service". The application is
called "Tails Server" but then we always talk about "services". I don't
think it's bad as such but I wonder how it will be understood by users.
Maybe you could ask some questions like this at the end of your testing
session, during the debriefing:
- What does the word "service" means to you?
- What does the word "server" means to you?
- Why is the application called "Tails Server"?
2. Related to that, in the connection information, different client
applications use different terminology and we should help people
understand this. For example Mumble talks about "Server" and "Address"
and Gobby asks for the "Host Name". Maybe we could display, for example
for Gobby, one of:
" - Address: pecdctvzgspqtlif.onion (host name)"
" - Address / Host Name: pecdctvzgspqtlif.onion"
" - Host Name: pecdctvzgspqtlif.onion"
3. When first starting the application, both the [Add Service] and [+]
buttons do the same thing. You're also missing a sentence as placeholder
for the empty left pane. I propose we solve both issues at once by
removing the "Add Service" button and writing instead something like:
« Tails Server allows you to create online services to which other
people can connect through Tor. For example, you can create a Mumble
service to organize group calls.
Click '+' to create a new service. »
We could even have a little monochrome schematics of a Tails Server and
several clients connecting to it. If you want that I can volunteer to
draw it :)
Maybe add a link to the documentation of Tails Server in general here.
See
https://developer.gnome.org/hig/stable/empty-placeholder.html.en
also reads "If there are controls that allow items to be added, it can
be appropriate to highlight them using a suggested style while the
list/grid is empty." which is, I understand, the button with a blue
background. Maybe it's worth trying...
4. Still when first starting the application, the [-] button active but
does nothing. Why not deactivate it?
5. We could maybe find something different to translate the dependency
between "Autostart" and "Persistence", to avoid always displaying
"(requires Persistence)". What about:
- Putting "Autostart" in the same line as "Persistent".
- When "Autostart" is clicked while disabled, display a popup reading:
« You can automatically start a service when starting Tails only if
the service is made persistent first.
[Cancel] [Make Persistent] »
This would both clean the main window and provide more information about
the relationship between the two options.
6. I'm still not convinced by the usefulness of the [Reset] button for
the onion address:
- What would be the user scenario for changing the onion address of a
service which already has user data, for example, a Gobby service for
which several documents have been written already?
- What's the advantage of changing the onion address of a service with
no user data, for example to organize a Mumble call with different
people, instead of removing and creating a new service?
- Isn't it always better to recreate a new service that to reuse one?
Could it be problematic that people change the onion address instead of
creating a new service in certain scenarios?
If we keep this option, I'd like to rephrase the dialog. Also, the new
onion address is not generated until the service is restarted which is
not clear (I expected a new address immediately which is what I
requested by clicking on the button).
7. I like the status spinner and little status sentence! Still, I don't
understand why it says "Connecting to Tor" while my Tails is already
connected to Tor :) Maybe we should say "Registering onion address" or
"Configuring service" instead or something that would make a more
explicit reference to the service itself.
8. In the Mumble client, how should I check the server's certificate?
I know that you are working on an upstream patch to display the
fingerprint of the server in this dialog but we're probably missing this
information in the "Connection Information" from Tails Server.
9. I like the edition widgets. And the fact that they are disabled when
the service is running seems pretty clear.
10. When adding a new service, I wonder about the workflow. Sometimes
people explore and try stuff just to see what it does, and we should
allow and support this; especially for something like Tails Server that
might end up having many different services with obscure meanings. Right
now when I add a new service I have:
i. The list of services with the name of the service and a very
short description.
ii. The service is created with the status "Installing". Maybe if I
was only exploring I would feel like things were going too fast
and instead expected to get more info about the service before
modifying my Tails. Would it be hard to move the installation at
the beginning of the first launch? Still, it's a minor issue :)
Maybe we could still start `apt update` in the background!
11. Maybe to support this exploration and learning even better we could
make the question mark button, the one that links to the user
documentation, even more explicit. Maybe "Learn more about Mumble..."?
12. Why say "Virtual Port"? Isn't "Port" enough? In Mumble client at
least the field is called "Port" only and we should match this.
13. In Gobby, "Autosave Interval: 30", 30 what? You missing a unit here.
14. In Gobby again, the client asks for the "Host Name" and the port is
not needed by default. So I propose we simplify the connection
information not to mention the port; unless it's not the one by default
but I'm not sure in which user scenario this would make sense.
15. When trying to stop one of the services, the spinner and the status
"Stopping..." went on for more than a minute so I thought they got stuck
and restarted the service instead (and it worked).
16. When removing a service, could we propose a backup of the service?
I'm thinking of Gobby here for example, where there is no way of
accessing the internal documents (outside from the clients). Maybe we
could create an archive of the configuration, the onion service key, and
the data of the service as a backup? I felt that this could be a cheap
way of being forgiving when people remove a service but maybe this would
duplicate a possible future backup tool in Tails.
I'm attaching a few screenshots that might help others understand what
we're talking about.
