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
