So, to summarize the different design choices we have:
A. GNOME-style widgets with in place edition.
You can see examples of this in Tails: Settings → Users and Settings
→ Printers.
Options are changed by clicking on them with no confirmation by
default: changes are saved when losing focus or pressing
Enter. When needed, we can trigger more elaborate controls when the
option is clicked (drop-down lists, password dialogs, confirmation
dialogs, etc.).
This would look like "hover.png" and "click.png" in attachment (the
pointer is not displayed in "hover.png" but was on "Debian Live
user").
An important difference with the other examples in GNOME is that
here, we decided not to apply any change until the service is
restarted. So if we go for this design, we should maybe always
allow modifying all options (for example, not graying out buttons
while the service is running) but make it clear in a different way
(infobar?) that the service needs to be restarted for the changes to
be applied. We might provide a small [Reset] link somewhere in
addition to that for forgiveness.
Cons: This might be hard to apprehend the first time for the user
as the options lack a signifier that makes it clear that you can
edit them until you pass over them. But I lack previous experience
with users to know how difficult they are to discover (the 1st
second of surprise that some of us had with them might not be a
blocker).
Pros: Reduces the numbers of widgets we have to put on the screen
by layering the interface; the widgets needed to change an option
are only shown when the users tries to change that option.
segfault did some drawing with an additional image as signifier
which looks good:
https://share.riseup.net/#0mHZEa89FfPnIs0RO7N1XA
https://share.riseup.net/#CHWNupfcA-lmMH5nzP0YeA
https://share.riseup.net/#NDjHznpwuMze0XryV8lUBg
If we want to try this design, I would be interested in testing
without the additional image first to see how much of a problem this
really is. Adding back the additional image should be easy and
relatively safe to try later on.
B. [Reset] and [Apply] buttons at the bottom of the window.
Settings are directly editable: strings are displayed in text
fields, options in drop-down lists, etc. The [Reset] and [Apply]
buttons are grayed out until the user changes some of these
settings.
The user has to click [Apply] to apply changes (or [Reset] to reset
them). Starting the service (or closing the program) before
applying changes triggers a confirmation dialog with [Close]
[Reset] and [Apply] buttons.
This would look a bit like this:
https://csl.cs.wisc.edu/sites/default/files/1x_images/MacOSX-4.png
Pros: Makes it more explicit at first sight how to change the
options. More forgiving, at least until [Apply] is confirmed.
Cons: Makes the default state of the dialog look more cluttered
with all the editable widgets displayed upfront. Makes the workflow
of changing a setting more complex ("change → apply → start" instead
of "change → start") and prone to trigger extra confirmation
dialogs (when the service is started before applying the changes).
C. One edit widget per option, with in place edition.
This is what you did so far: each option goes along with, when
relevant, a widget that triggers its edition.
This design makes it easier to gray out these widgets when the
service is running, so that users cannot edit them.
And segfault did some more screenshots:
https://share.riseup.net/#r5nu-iCxHM5sobx2zJBTyQ
https://share.riseup.net/#aX8Jrhb2kkm_ipd3VIbr6w
The edition would be triggered on the same dialog as segfault is
doing here (if I understood correctly, Spencer and Susan expressed
doubts about this).
Pros: Makes it explicit at first sight how to change the
options. Easier to block edition when the service is running and
transmit this to the user.
Cons: More widgets and noise upfront. More action to save after
changing an option.
D. One edit widget per option, with edition in a dialog.
The window would look like design C but when clicking [Edit] the
edition would be done in a small and separate dialog. This might
answer the concerns of Susan.
I bet that this is what's happening when clicking "Edit..." in the
OS X Server screenshot #3.
Pros: Over C, avoid problems with saving.
Cons: More dialogs so probably a bit slower.
So, for the sake of simplicity and consistency with other GNOME
dialogs, I would be interested in trying design A. I'm conscious that
it might be harder to discover the first time but I'm interested in
checking this with facts. But we would have to find a good solution for
how to transmit that options cannot be changed while the service is
running, or rather, as I suggested, that the service needs to be
restarted for the changes to apply.
Or, if we feel less adventurous, maybe we should go for design B with
the [Apply] [Reset] buttons at the bottom like Mac OS X settings.
Also, some general comments that might help reduce the scope of the
problem we are addressing here:
- I'm not sure we need to allow changing the onion address. Of course
it could be useful in some cases, but is it worth the extra
complication and the risk for some users to loose their address
forever (unless we provide an undo)?
Could people who want a different address create a new service of the
same type?
- Passwords shouldn't be displayed in the clear. We might have to use a
password dialog (see "password.png" in attachment) and display ******
by default. I know that "we" use automatically generated passwords
that are mostly fine to display on a screen (unless you're filmed)
but none of the password fields I can think of right now display
password upfront and that might surprise, scare, confuse users.
- What Susan is saying about forgiveness and undo is very important
too. So if we go for design A and C (D also but a bit less) we
should think about the options for which it might be important to be
more forgiving. Of course, it makes little sense for toggle, where
the previous state is super easy to reach. But it's not same for
onion addresses for example.
