Re: [Tails-ux] Tails Server GUI Design

Lunar:
> segfault:
>> segfault:
>>> sajolida:
>>>> A strength of Spencer's design THREE [1] was to have all the controls in
>>>> the same screen. I understand that you wanted to make it more clear that
>>>> the service had to be restarted for the changes to be effective but I'm
>>>> not sure that the benefits of this change outweigh the disadvantages.
>>>
>>> This is about more than making it clear that services have to be
>>> restarted.
>>
>> Another problem we would have if we dropped the configuration dialog
>> came to my mind:
>> Currently, the service status indicator and the on/off switch are
>> automatically set if the service starts or stops. So if the service runs
>> into an error or is stopped or started via the command line, the GUI
>> still displays the correct state. (I implemented this by listening to
>> systemd unit signals via dbus.)
>>
>> Now with your proposal B, we would have to apply the options when the
>> on/off switch is clicked. But since there are other ways to start the
>> service, for example via the CLI, this could lead to an incorrect state
>> in the GUI, where the options don't display their correct state.
>> This might be a bit far-fetched and maybe the user can't expect the GUI
>> to be in a consistent state if he mixes it's use with the CLI - but this
>> issue would not exist with the configuration dialog.
>
> Feels there's a potential usability trap here. I think it's important
> to distinguish between the desired state and the current state. If the
> application crashed and can't be restarted automatically, this is a
> different state than not wanting the application to run.
>
> I think both the data model and the interface should reflect this
> distinction.

Thanks for the input :)

But I'm not sure if I get what you mean. I didn't implement service
failure handling yet. I think turning the switch off automatically and
somehow notifying the user that the service ran into an error would be
nice behavior. Would you agree to this, or do you think the switch
should stay in the "on" state?

The error notification could be realized with a label with something
like "Service error" (or maybe more descriptive) and warning triangle.
Additionally a desktop notification could be send.