segfault:
> I'm currently working on the Tails Server (presumably also in this
> year's Google Summer of Code) and I created an initial design of the
> GUI. You can pull it from my gitlab repository [1] or take a look at the
> attached screenshot.
Yeah! Sorry it took me so long to answer. I was locked up with intrigeri
doing accounting...
> Please provide feedback on the redmine ticket [2].
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. On the other hand, discussing
over email will make it more likely to drop George or anonym from the
loop...
I'm offline right now so I'm missing Spencer's screenshot as well. My
comments only take into account your Glade prototype.
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/.
2. From the Tweak Tool screenshot maybe you can reuse the placement of
the description which is smaller, gray, and below the label.
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.
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).
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.
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.
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.
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.
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?
- Toggling persistence might require restarting the service.
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)?
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.
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 :)
Keep up with the good work!
