Re: [Tails-ux] Tails Server GUI Design

Delete this message

Reply to this message
Author: Susan
Date:  
To: Tails user experience & user interface design
Subject: Re: [Tails-ux] Tails Server GUI Design
Like Spencer, I don't like to rely on the user to click elsewhere to apply a change, because it isn't obvious what the state is between the edit action and the not-obvious next required action.

I've seen prolonged and serious problems with turning on and off edit modes in testing, however, when the mode affects multiple fields or sections of a big UI. Users seem to really want to click on things directly to edit them, and they forget to save when the save button is not adjacent to the thing they are editing.

In MacOS control panels, for example, (when unlocked) all fields are editable. Two buttons take care of most situations: [Cancel] [OK]

I'm also concerned about changing forms where there are important existing values without providing a Reset or Cancel option. (Sometimes also providing Undo or Use Last Values would be helpful, for network configs, because the consequences of not being able to get back to a working network are awful.)

In cases when you might not want to close the dialog on [OK], some configuration dialogs use:
 [Close]  [Reset]                             [Apply]


When someone just closes the dialog, the system should ask the user whether to save changes or not, to make state explicit.

Have you already considered changing the button from "Edit" to "Save" during editing? That might be a good way to go when there is just one thing to change.

In this example, though, there are at least 4 things that can change. For that reason, I think one of the action-button approaches at the dialog box level would be best here. No explicit mode change to make it editable but forgiveness afterward.

Susan

On Jun 17, 2016, at 2:54 PM, Spencer <spencerone@???> wrote:

> Hi,
>
>> segfault:
>> screenshots
>
> Thanks !!!
>
> Each string has a different button at the end; feels strange.
>
> An 'Edit' button for the entire dialog might be more suitable, then you can avoid the ambiguousness of clicking elsewhere to accept and save the change, and the clutter of many types of buttons stacked to the right, at least on the service dialog default check & go state.
>
> Wordlife,
> Spencer
>
>
>
> _______________________________________________
> Tails-ux mailing list
> Tails-ux@???
> https://mailman.boum.org/listinfo/tails-ux
>
>