Susan:
>> Spencer said:
>> I see a downside to this approach: In the other approach, where the user
>> clicks on the label to edit it, "special" edit modes like for the
>> password or the onion address can be triggered by this click on the
>> label. I think with this approach we would need additional buttons for
>> those options. The icons you use for this look really nice, but I'm not
>> sure if they are self-explanatory enough - I prefer buttons with text.
>
> Buttons / icons with text work best in testing. And not just a little better but
> overwhelmingly better. Text localizes better too, especially in the case of
> icons, which are often not universally meaningful.
>
> I would like to see the edit icon turn into a Save icon while the field is
> editable in the design Segfault showed. Not more buttons, but a button swap.
>
> I don't think ESC will be a good only choice for canceling an edit. Not enough
> people know about it. It's a hidden control for non-programmers.
>
> A dialog would be a way to avoid both of these action-visibility issues.
>
> I also wonder if it would be safer to save one or two configurations so that
> people can use different ones as they wish without having to reenter them, and
> so that a known-working config could be returned to if the experimental new
> config does not work.
>
> On the downside, you then might have a text file somewhere with a history event
> you don't want.
> Maybe this is just impossible because of the way Tails works?
> A temp file then maybe for the session?
>
> Do you have to write HTML to make a welcome message, or does the system just tag
> it for you? That displayed incomplete text with markup seems distracting without
> being informative enough.
>
> Lunar said:
>> It's unclear to me what happens if a user click on the “Cancel” button.
>> Will the settings still be saved somewhere?
>>
>> Is there another label than “Cancel” that could describe the action
>> better? “Edit again”?
>
> "Save" or "Don't Save" often work well together. Would "Don't Save" be accurate?
>
> Particular labels are better than generics (OK/Cancel/Submit). I think Cancel
> the Edit is what "Cancel" means here, but it wouldn't hurt to be more specific.
Segfault's "Cancel" button is meant to say "Close this dialog and go
back to editing without restarting the service": it's neither saving the
changes for real, neither discarding the previous edition.
So maybe the labels could be:
Left Button:
- [Close] (as [Cancel] might be interpreted as cancelling the
previous edit).
- [Cancel] which is the most usual. The user is not going to loose
the previous edition work anyway. That's the behavior of [Cancel]
in the attached screenshot from Synaptic: it goes back to the
previous window without loosing the previous edition work.
- [Edit Again], as Lunar suggested but I find the phrasing unusual
- [Edit Configuration] which avoid "Again".
Right Button:
- [Restart Service]
- [Save & Restart Service] to put emphasis on the fact that this is
the button that saves the changes.
>> In case you go on with such a confirmation dialog, would it make sense
>> to have the option to review changes that are going to be performed?
>
> It's a great idea to review changed configs before applying when more than one
> thing is saved.
>
> Preventing errors and allowing people to recover from errors easily are the
> principles to keep in mind, whatever mechanism may be used. When the
> consequences of failure are severe you need even more prevention and more cure.
> Anything that helps people recover from a non-working state would be good here.
I also like this idea. With this design, segfault, how hard would it be
to add a summary of the changes in this confirmation dialog (like
Synaptic does)?
