Susan:
>> A dialog would be a way to avoid both of these action-visibility issues.
Segfaut:
Do you mean a dialog that opens when you click on the option you want to
change? Or do you mean using a separate dialog for editing all the options?
Susan: I meant a Save/Don't Save dialog. But an editing dialog could work too and might be more straightforward.
S
---------//------older
> On Jun 23, 2016, at 6:38 PM, segfault <segfault@???> wrote:
>
> 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 implemented this and I like it. See the screenshot.
>
>>>
>>> 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.
>
> I guess this is true. But I'm not sure how we could achieve this. Maybe
> we could add another "Cancel" icon next to the "Apply" one and make them
> actual buttons? I could try implementing this, but I guess it would be
> quite some work (it would be buttons inside a button and I would have to
> redirect the click event to the inner buttons somehow - I'm not even
> sure if this is possible with GTK). See the other screenshot for how
> this would look like.
>
>>>
>>> A dialog would be a way to avoid both of these action-visibility issues.
>
> Do you mean a dialog that opens when you click on the option you want to
> change? Or do you mean using a separate dialog for editing all the options?
>
>>>
>>> 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.
>
> At some time we might support multiple services of the same type. I
> think this would also be the best solution for having multiple
> configurations.
>
>>>
>>> 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.
>
> The welcome message is read/written directly from/to the mumble config
> file. It supports HTML, but you don't have to use HTML tags (but you
> won't be able to use font formatting or line breaks without HTML). I
> don't plan to put more work into the welcome-message option, because I
> think it is actually not that important.
>
>>>
>>> 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.
>>>
>>>> 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.
>>>
>>> "Are You Sure?" is helpful to get people to pause and then know _when_ it is
>>> they are committing.
>>>
>>> "Change config to XYZ?" is helpful to get people to know _what_ it is they are
>>> committing to.
>>>
>>> Neither of those helps people recover if their first choice does not work.
>>>
>>> Layering:
>>>
>>> I agree that "Advanced" may be problematic, but I think it's good to layer deep,
>>> seldom-needed knobs and levers sometimes just to get them out of the UI for most
>>> people, who can easily become overwhelmed and scared away by seeing lots of
>>> choices that they don't understand. Maybe some kind of "More Options" label
>>> would be helpful to use for this purpose.
>>>
>>> Layering can also provide more room for explanations, which helps people learn
>>> and make more confident decisions.
>>>
>>> Layering can be as simple as show/hide drawer or something like that, so the
>>> user has control of it. I agree that UIs should help people learn when they want
>>> to know more.
>>>
>>> Susan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Tails-ux mailing list
>>> Tails-ux@???
>>> https://mailman.boum.org/listinfo/tails-ux
> <editable-with-apply-icon.png>
> <editable-with-apply-and-cancel.png>
> _______________________________________________
> Tails-ux mailing list
> Tails-ux@???
> https://mailman.boum.org/listinfo/tails-ux
