Lähettäjä: sajolida Päiväys: Vastaanottaja: Tails user experience & user interface design, George Kadianakis, anonym Aihe: Re: [Tails-ux] Tails Server GUI Design
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.
This would be:
1. I turn the service off through the switch.
2. I change some options.
3. I turn the service on through the command line.
Then the problem is to know what happens to the options I changed in
step 2, right? I think these changes should be applied, as if I had
turned the service on through the switch. Now if the command line allows
passing conflicting options when starting the service (let's say a
different password), then these options should any be kept in sync in
the GUI anyway, no?
So I understand that keeping a GUI and a CLI in sync makes
implementation more complicated, but I don't see how this affect a
design more than other one. But I probably missed something.