sajolida:
> 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.
This is about more than making it clear that services have to be
restarted. I explain this below.
>
> [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.
Right, there is duplicate information. But I don't think this is that bad.
The first I call the "status panel" and the other the "configuration
dialog". The status panel should only display the information that is
important / often needed. I implemented this by adding a
"display_status" attribute to the Option class. If this attribute is set
to True, the option will be displayed in the status panel. But currently
I only display the red/green "light", which only makes sense of bools.
If the option type is string or int, it should display a label instead.
I think by the use of the red/green "lights" for bools and labels for
strings and integers it is quite clear that the options are not
configurable in the status panel.
Also, there is the same kind of duplicate information with the red/green
"light" in the service list on the left and the on/off switch in the
status panel.
> - 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.
The server password is of course information that is often needed and
should also be displayed in the status panel. Like I wrote above, I
didn't implement this for strings and ints yet, but will do so if we
decide to keep the status panel.
> - 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.
I think a popup dialog for every option modified would be very annoying.
Maybe a notification (like the ones created with notify-send) would be
less annoying - but I associate those more with notifications from the
system and I think it would be strange to get those from the application
I am currently interacting with. Another option would be displaying a
warning somewhere in the application window. But I think the additional
configuration dialog makes the workflow clear without displaying any
messages.
> 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).
I think B is better than A but I'm not sure if it makes it clear to the
user that:
- After starting the service, he will not be able to modify the options
he sees (unless he stops the service again)
- He will be able to configure the grayed out options once he stopped
the service. Of course, if he pays attention to it, he will notice that
the options gray out while starting the service.
Also, I already gray out the "Automatically start on boot" option while
the persistence is not enabled, which might be confusing.
> 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.
The main reason for thinking up the status panel and configuration
dialog separation was this point of yours:
> What if a service always requires some configuration before being
> started? For example the password of a Mumble server? Would it work
> to display the settings dialog when toggling on if some settings
> are required?
I don't see how this would be solved with either option A or B.
But maybe all of these concerns don't outweigh the more simple design of
your option B, I'm not sure.
> [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).
First I had check boxes, then you said this in your mail from April 21,
so I changed it to switches:
> we can also use a switch for it (as I think
> that check boxes are not recommended anymore in the GNOME 3 guidelines)
Of course, I can change it back again :P
>
> [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 think this is good.
> 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.
I think George suggested more descriptive labels, but maybe I overdid
this. Are tool tips still a thing? I don't recall seeing any in GNOME 3
applications. Maybe I just didn't notice.
>
> 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.
Users would not be able to view this once they added a service. I'm not
sure if hiding an explanation without the option of getting it back is
good design.
