Re: [Tails-ux] Tails Server GUI Design

segfault:
> Finally, the next prototype is ready :)

\o/

> I also append some screenshots.

That's cool!

> In contrast to the previous design, now the configuration is only
> displayed via the "Configure" button or when adding a new service. This
> way the user is required to click the "Accept and Restart Service"
> button to apply the configuration, making it clear that the service will
> be restarted. A disadvantage is that some options could actually be
> changed without restarting the service (and others only require to
> reload the Tor service), which would not be possible with the new
> design. Maybe I could add those to the "status panel" (the one which
> displays the status of the options and contains the configure button,
> see screenshot 4).

A strength of Spencer's design THREE [1] was to have all the controls in
the same screen. I understand that you wanted to make it more clear that
the service had to be restarted for the changes to be effective but I'm
not sure that the benefits of this change outweigh the disadvantages.

[1]:
https://labs.riseup.net/code/attachments/download/1317/tails.server.gui.alt.png

The disadvantages are that:

- You have duplicate information between the two screens, with one
version describing the state (eg "Persistence Off") and another
changing the setting (eg "Store service configuration and data on the
persistent volume"). In Spencer's design both the state and the
widget the state were the same thing and that's simpler and probably
easier to understand.
- I have to click Configure to see the password of the Mumble and give
it to my users. The same probably applies to other settings of other
services.
- More design, testing, coding, maintenance, etc.

Regarding the problem that you were trying to solve: convey to the user
that she needs to restart the service to apply the changes, I'm
confident that this can be solved without loosing the advantages of
having a single screen. For example we could:

A. Show a dialog saying that the changes will be applied only after
restarting the service, when once of these options is changed.

B. Gray out the controls that require restarting the service while the
service is running. This would force the user to shutdown the
service to change its configuration. I quite like this option as:

   - It could make quite easy to differentiate in the future the
     options that require restart and the ones that don't. Even if for
     now on you can gray out everything.
   - Instead of talking about "reconfiguring and restarting" we would
     talk about "stopping, reconfiguring, and starting" which is maybe
     a bit slower but might be clearer in terms of mental model. For
     example, because it prevents confusion on whether the changes are
     applied already or not (with respect to option A).

Now, putting everything on a single screen doesn't prevent us from
layering this screen, for example putting advanced options in a
toggleable area, but the key idea here is that a single option should be
in a single place. Maybe it would be interesting to list the different
options that we would have for different services in the ones from the
blueprint [2], just to see how big this could get.

[2]: https://tails.boum.org/blueprint/tails_server/#index1h2

Also, Spencer had check boxes for "Persistent", "Auto-start", and "Allow
LAN" and you replaced them with On/Off switches. From the GNOME HIG [3],
I would also say that check boxes are more appropriate (and more
discrete on the screen).

[3]: https://developer.gnome.org/hig/stable/switches.html.en

Quoting the HIG:

« When the control does not turn a function on or off, or when a
function does not clearly have an on/off nature, a check box is a more
appropriate option. For example, an alarm might be controlled using a
switch, since it can be turned on or off. However, a check box is a
better choice for an option to repeat that alarm on a daily basis, since
alarm repetition is a configuration option, rather than starting or
stopping a particular piece of functionality. »

So I'd say that turning each service on and off should be done through a
switch but that each of "Persistent", "Auto-start", and "Allow LAN"
should be check boxes. What do you think?

I also prefer the shorter labels (at least for "Persistent",
"Auto-start") which can still have longer labels as tool tips. These
options will be the same for every service so people will get use to
them and shorter labels are easier to scan and recognize.

Maybe I wouldn't be so strict with options that are specific for a given
service and in such cases, more descriptive labels might be better.

And finally, as a note for the future, maybe we can do something smart
with the empty screen with "Add a service", maybe explaining what Tails
Server is all about.