sajolida:
> So, to summarize the different design choices we have:
Thanks for the very helpful summary.
>
> 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.
In the current prototype, the options will only be applied when the
service is (re)started. This allows to simply use text entries whose
values are applied when the service is started. The main reason I want
to change this is that currently it is not clear to the user when the
options will be applied. This is especially problematic if he uses the
persistence feature, configures the service further and restarts Tails
without restarting the service, because then the options will not be
stored and the configuration is lost. This is why I want to use a design
which allows us to apply the options immediately when they are changed.
> 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.
I think this does not apply, because we would apply the changes
immediately. Given this, I think your option A makes sense if we gray
out the options while the service is running.
>
> 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.
I think if we gray out the option and disable the click-functionality
while the service is running, it would be even more confusing without a
signifier. Because then sometimes you can to click on the label to edit
it and sometimes you can't.
Susan and Spencer expressed concern about the unclear state between the
edit action and hitting Enter or focussing anything else. I tried to
address this by creating yet another kind of widget, which is shown in
the attached screenshots. This one also displays an edit-image while in
edit-mode. The user can click on the edit-image, press Enter or focus
anything else - each will apply the change. Pressing Escape will
cancel the edit.
>
> 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).
I think this option would be fine, although it's definitely not the
GNOME way.
> 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.
I implemented a prototype with this option and it looks awful. So I
don't want to follow this further.
>
> 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.
I plan to make a very small user test (about 5 people) on Friday to test
the designs A (without any signifier), my new widget, and B.
>
> 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)?
I already implemented a pop-up to confirm the regeneration of the onion
address. I think this is a
>
> Could people who want a different address create a new service of the
> same type?
I won't support multiple services of the same type in the beginning.
This is a nice feature for future work, but implementing it would
require a lot of work.
Users could remove the previous service and create a new one. But then
they would lose all of their configuration.
> - 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.
ACK
> - 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.
ACK. Do you think a pop-up for confirmation would be sufficient for
those options?
Cheers.
started.%20This%20allows%20to%20simply%20use%20text%20entries%20whose%0A>%20values%20are%20applied%20when%20the%20service%20is%20started.%20The%20main%20reason%20I%20want%0A>%20to%20change%20this%20is%20that%20currently%20it%20is%20not%20clear%20to%20the%20user%20when%20the%0A>%20options%20will%20be%20applied.%20This%20is%20especially%20problematic%20if%20he%20uses%20the%0A>%20persistence%20feature,%20configures%20the%20service%20further%20and%20restarts%20Tails%0A>%20without%20restarting%20the%20service,%20because%20then%20the%20options%20will%20not%20be%0A>%20stored%20and%20the%20configuration%20is%20lost.%20This%20is%20why%20I%20want%20to%20use%20a%20design%0A>%20which%20allows%20us%20to%20apply%20the%20options%20immediately%20when%20they%20are%20changed.%0A>%20%0A>%20%0A>%20I%20think%20this%20does%20not%20apply,%20because%20we%20would%20apply%20the%20changes%0A>%20immediately.%20Given%20this,%20I%20think%20your%20option%20A%20makes%20sense%20if%20we%20gray%0A>%20out%20the%20options%20while%20the%20service%20is%20running.%0A>%20%0A>%20>%20%0A>%20>%20%0A>%20>%20%0A>%20>%20%0A>%20>%20%0A>%20%0A>%20I%20think%20if%20we%20gray%20out%20the%20option%20and%20disable%20the%20click-functionality%0A>%20while%20the%20service%20is%20running,%20it%20would%20be%20even%20more%20confusing%20without%20a%0A>%20signifier.%20Because%20then%20sometimes%20you%20can%20to%20click%20on%20the%20label%20to%20edit%0A>%20it%20and%20sometimes%20you%20can't.%0A>%20%0A>%20Susan%20and%20Spencer%20expressed%20concern%20about%20the%20unclear%20state%20between%20the%0A>%20edit%20action%20and%20hitting%20Enter%20or%20focussing%20anything%20else.%20I%20tried%20to%0A>%20address%20this%20by%20creating%20yet%20another%20kind%20of%20widget,%20which%20is%20shown%20in%0A>%20the%20attached%20screenshots.%20This%20one%20also%20displays%20an%20edit-image%20while%20in%0A>%20edit-mode.%20The%20user%20can%20click%20on%20the%20edit-image,%20press%20Enter%20or%20focus%0A>%20anything%20else%20-%20each%20will%20apply%20the%20change.%20Pressing%20Escape%20will%0A>%20cancel%20the%20edit.%0A>%20%0A>%20>%20%0A>%20>%20B.%20%5BReset%5D%20and%20%5BApply%5D%20buttons%20at%20the%20bottom%20of%20the%20window.%0A>%20>%20%0A>%20>%20%0A>%20>%20%0A>%20>%20%0A>%20>%20%0A>%20>%20%0A>%20%0A>%20I%20think%20this%20option%20would%20be%20fine,%20although%20it's%20definitely%20not%20the%0A>%20GNOME%20way.%0A>%20%0A>%20>%20C.%20One%20edit%20widget%20per%20option,%20with%20in%20place%20edition.%0A>%20>%20%0A>%20>%20%0A>%20>%20%0A>%20>%20%0A>%20>%20%0A>%20>%20%0A>%20>%20%0A>%20%0A>%20I%20implemented%20a%20prototype%20with%20this%20option%20and%20it%20looks%20awful.%20So%20I%0A>%20don't%20want%20to%20follow%20this%20further.%0A>%20%0A>%20>%20%0A>%20>%20D.%20One%20edit%20widget%20per%20option,%20with%20edition%20in%20a%20dialog.%0A>%20>%20%0A>%20>%20%0A>%20>%20%0A>%20>%20%0A>%20>%20%0A>%20>%20So,%20for%20the%20sake%20of%20simplicity%20and%20consistency%20with%20other%20GNOME%0A>%20>%20dialogs,%20I%20would%20be%20interested%20in%20trying%20design%20A.%20I'm%20conscious%20that%0A>%20>%20it%20might%20be%20harder%20to%20discover%20the%20first%20time%20but%20I'm%20interested%20in%0A>%20>%20checking%20this%20with%20facts.%20But%20we%20would%20have%20to%20find%20a%20good%20solution%20for%0A>%20>%20how%20to%20transmit%20that%20options%20cannot%20be%20changed%20while%20the%20service%20is%0A>%20>%20running,%20or%20rather,%20as%20I%20suggested,%20that%20the%20service%20needs%20to%20be%0A>%20>%20restarted%20for%20the%20changes%20to%20apply.%0A>%20>%20%0A>%20>%20Or,%20if%20we%20feel%20less%20adventurous,%20maybe%20we%20should%20go%20for%20design%20B%20with%0A>%20>%20the%20%5BApply%5D%20%5BReset%5D%20buttons%20at%20the%20bottom%20like%20Mac%20OS%20X%20settings.%0A>%20%0A>%20I%20plan%20to%20make%20a%20very%20small%20user%20test%20(about%205%20people)%20on%20Friday%20to%20test%0A>%20the%20designs%20A%20(without%20any%20signifier),%20my%20new%20widget,%20and%20B.%0A>%20%0A>%20>%20%0A>%20>%20Also,%20some%20general%20comments%20that%20might%20help%20reduce%20the%20scope%20of%20the%0A>%20>%20problem%20we%20are%20addressing%20here:%0A>%20>%20%0A>%20>%20-%20I'm%20not%20sure%20we%20need%20to%20allow%20changing%20the%20onion%20address.%20Of%20course%0A>%20>%20%20%20it%20could%20be%20useful%20in%20some%20cases,%20but%20is%20it%20worth%20the%20extra%0A>%20>%20%20%20complication%20and%20the%20risk%20for%20some%20users%20to%20loose%20their%20address%0A>%20>%20%20%20forever%20(unless%20we%20provide%20an%20undo)?%0A>%20I%20already%20implemented%20a%20pop-up%20to%20confirm%20the%20regeneration%20of%20the%20onion%0A>%20address.%20I%20think%20this%20is%20a%0A>%20%0A>%20>%20%0A>%20>%20%20%20Could%20people%20who%20want%20a%20different%20address%20create%20a%20new%20service%20of%20the%0A>%20>%20%20%20same%20type?%0A>%20I%20won't%20support%20multiple%20services%20of%20the%20same%20type%20in%20the%20beginning.%0A>%20This%20is%20a%20nice%20feature%20for%20future%20work,%20but%20implementing%20it%20would%0A>%20require%20a%20lot%20of%20work.%0A>%20Users%20could%20remove%20the%20previous%20service%20and%20create%20a%20new%20one.%20But%20then%0A>%20they%20would%20lose%20all%20of%20their%20configuration.%0A>%20%0A>%20>%20-%20Passwords%20shouldn't%20be%20displayed%20in%20the%20clear.%20We%20might%20have%20to%20use%20a%0A>%20>%20%20%20password%20dialog%20(see%20%22password.png%22%20in%20attachment)%20and%20display%20******%0A>%20>%20%20%20by%20default.%20I%20know%20that%20%22we%22%20use%20automatically%20generated%20passwords%0A>%20>%20%20%20that%20are%20mostly%20fine%20to%20display%20on%20a%20screen%20(unless%20you're%20filmed)%0A>%20>%20%20%20but%20none%20of%20the%20password%20fields%20I%20can%20think%20of%20right%20now%20display%0A>%20>%20%20%20password%20upfront%20and%20that%20might%20surprise,%20scare,%20confuse%20users.%0A>%20ACK%0A>%20%0A>%20>%20-%20What%20Susan%20is%20saying%20about%20forgiveness%20and%20undo%20is%20very%20important%0A>%20>%20%20%20too.%20So%20if%20we%20go%20for%20design%20A%20and%20C%20(D%20also%20but%20a%20bit%20less)%20we%0A>%20>%20%20%20should%20think%20about%20the%20options%20for%20which%20it%20might%20be%20important%20to%20be%0A>%20>%20%20%20more%20forgiving.%20Of%20course,%20it%20makes%20little%20sense%20for%20toggle,%20where%0A>%20>%20%20%20the%20previous%20state%20is%20super%20easy%20to%20reach.%20But%20it's%20not%20same%20for%0A>%20>%20%20%20onion%20addresses%20for%20example.%0A>%20ACK.%20Do%20you%20think%20a%20pop-up%20for%20confirmation%20would%20be%20sufficient%20for%0A>%20those%20options?%0A>%20%0A>%20Cheers.%0A>%20%0A>%20 "Reply to this message")
