sajolida:
> I will leave the final decision up to you, but I find comments on
> Redmine harder to follow and track than over email where it's easier to
> quote, do subthreads if needed, and have more people reading. Then I
> prefer summing up results only in Redmine to prevent diluting the next
> actions in the middle of the discussions.
I think you're right. For me the main argument is that we will reach
more people with the mailing list. So let's keep the discussion on the
mailing list and sum up results on the Redmine ticket.
> I'm offline right now so I'm missing Spencer's screenshot as well. My
> comments only take into account your Glade prototype.
Spencer's design differs quite a lot from my initial one and anonym and
myself already said that we find it superior, so I think you should take
a look at it :)
Sadly, most of your comments are not applicable to Spencer's design.
>
> 1. In GNOME, switches are often on the right of their label (like in
> Settings → Power or Settings → Universal Access) but also sometimes,
> more rarely though, on the left of their label as you did (like in Tweak
> Tool → Extensions). In the case of Tweak Tool, each label come with a
> small description (like in your case) and more buttons (Settings, Remove).
>
> So my first reaction was to think that switches should be on the right,
> but now that I see Tweak Tool you're probably fine. Maybe it would be
> worth checking the GNOME HIG https://developer.gnome.org/hig/stable/.
>
If we go with Spencer's design, there won't be a list with switches
anymore like the one in Tweak Tool → Extensions. Spencer already put the
switch on the right in his proposal three, which I like best.
> 2. From the Tweak Tool screenshot maybe you can reuse the placement of
> the description which is smaller, gray, and below the label.
Yes, that would look better. Again, Spencer already did something
similar in his proposal :)
> 3. I wonder whether we could do without the "more" expander as we
> already have another layer of interface with the "settings" button. Then
> we could:
> - Always display the onion address. People will definitely need it to
> use the service so hiding it forces everybody to go through "more"
> (and defeats the purpose of "more" as a way of layering the
> interface for more advanced users).
>
> - Always display the settings button like Tweak Tool does. Maybe
> we can also use the gear logo which is quite common in GNOME,
> though I dislike buttons without a label.
>
> - Move "Autostart" and "Allow LAN" to the settings. This could make
> it easier to solve George's concern regarding the meaning of "Allow
> LAN" since we could give it a bit more space.
I think all of these propositions are already solved well in Spencer's
design :)
There is no "more" expander anymore and I think it provides enough space
to show all the settings at once, so we can get rid of the "settings"
button too.
> 4. I also wonder whether the "Persistent" option deserves to be always
> shown. I think it should be off by default to follow our usual practive
> of "not saving anything by default". But then I expect that many people
> will want to use it or will be interested in its status so that would be
> an argument in favor of displaying it in the main window. But if we
> display it in the settings, then all settings are in a single window,
> out of the overview, and we can also use a switch for it (as I think
> that check boxes are not recommended anymore in the GNOME 3 guidelines).
Also superfluous if we only show all settings or none as in Spencer's
design.
> 5. The settings button could then open a dialog with:
>
> - Some generic options ("Autostart", "Allow connections from local
> network", "Persistent", etc.)
>
> - Some options that are specific to the service (and might be defined
> in whatever plugin mechanism we design to specify a new service).
>
> As a consequence, I don't really like the idea of anonym to "have all
> connection info *and* all options/settings shown in the frame exposed by
> clicking the "More" expander". I'm in favor of a single settings button
> and something that looks more like Tweak Tool → Extensions.
I skip this one because too, because it does not apply to Spencer's design.
> 6. For "Allow LAN" do we want to display the local IP address? Otherwise
> people would have to find it out somewhere else before being able to use
> it. Displaying it might also clarify what it is about.
That's a good idea! I will include this in the next version of the
prototype.
> 7. Regarding toggling "Persistent" on and off. To simplify things, and
> as anonym pointed out, I would:
>
> - Prevent switching it off if the service is started already.
>
> - Maybe allow switching it on if the service is started already as
> suggested by George. But maybe it's good enough to keep this as a
> future improvement.
>
> - Propose to erase all data related to the service when switching off.
> This is a problem we have with persistence features in general,
> see #8447. But since we're designing something new here, let's not
> duplicate this problem elsewhere.
I spent some time thinking about anonym's comment on this one. I tried
it with the mumble server and at least with this one it worked perfectly
if I simply moved the config file to the persistence storage when making
it persistent and removing the link and moving the config file back in
place when removing the persistence, without ever restarting the service.
By the way, I think at least copying the files to the persistence
storage and mounting the persistent directory should also be implemented
in the current persistence assistant. This would remove the necessitiy
of a reboot before the persistence is applied. I witnessed multiple
times that users forgot this reboot while setting up a new Tails device
and they lost they're newly created mail address and PGP keys because
they were not stored persistently.
But I see that this replacement of config files might cause problems
with other services, so I agree that disabling the persistence switch
while the service is running would be the safest and easiest way.
> 8. I'm not 100% convinced by the onion address in the text box but I
> understand your arguments and I'm fine trying it this way.
>
> 9. As George pointed out, "Autostart" only makes sense if the service is
> persistent already. This should be translated in the interface.
Agreed. I will try to come up with something addressing this in the new
version of the prototype.
> 10. Also, I feel like we need to clarify what is the workflow of
> configuring and starting a service. Especially since here we have an
> on/off toggle that can be manipulated independently of the settings button:
>
> - As anonym pointed out, some settings would require restarting the
> service.
>
> - 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 think with Spencer's design we could open a dialog when a new service
is set up with the + sign.
> - Toggling persistence might require restarting the service.
Like you suggested above, this could be solved by disabling the
persistence switch while the service is running.
> Do you think you could implement some prototype for this workflow in
> Glade in your next iteration (as it might change the layout if we find
> big issues in the workflow)?
Will do.
> Maybe in the back end we need to know for each setting if it is required
> on start and if it requires restarting the service if changed.
Indeed, I think we should create a "RequiresRestart" attribute in the
TailsOptions class. All options which have this set to True would then
be disabled in the GUI (and refuse modification through the CLI) while
the service is running.
> Now I'm wondering whether this design and the design of the
> current persistence assistant should be consistent or unified
> somehow (as they are both proposing opt-in persistence features). But
> that sounds scary and out-of-scope for now. Maybe your design can later
> on inspire some improvements to the current persistent assistant :)
I took a look at the code of the current persistence feature and was
scared so much that I scrapped my plan of implementing the mounting of
non-directory files through persistence.conf, although that feature
would come in very handy for the Tails Server.
Thanks a lot for the comprehensive input! Please keep it up, this way we
will get a really user-friendly interface :)
