sajolida:
> segfault:
>> sajolida:
>>> segfault:
>>>> I think both anonym's suggestion of graying out the "configure" button
>>>> and the current design solve the problems we would have if we used only
>>>> a single panel. anonym confirmed that he didn't actually test the
>>>> prototype before writing the mail and didn't know the problems he
>>>> addressed are already solved in the current design.
>>>>
>>>> So currently I see the following proposals:
>>>>
>>>> 1. Use a single panel with either;
>>>>
>>>> A. Somehow make it clear to the user that he needs to restart the
>>>> service after changing options
>>>>
>>>> -or-
>>>>
>>>> B. Gray out the options which require restart if the service is running
>>>
>>> If we go for a single dialog I think we should go for B and make options
>>> read-only when the service is started. I proposed A to have some
>>> alternative to B but I never really believed in it :)
>>>
>>>> 2. Use the separate status panel and configuration dialogue with either:
>>>>
>>>> C. Name the ok button "Accept and Restart Service" and do exactly that
>>>> when it's clicked.
>>>>
>>>> D. Gray out the "configure" button in the status panel while the
>>>> service is running.
>>>>
>>>> I would be glad if we could decide on this soon, so I can continue
>>>> working on this and implement all the functionality needed for initial
>>>> usability tests.
>>>>
>>>> Some of the sarah's ideas would make A less awkward, but I would still
>>>> prefer 2. because of the arguments I made in my previous mail.
>>>>
>>>> I prefer C over D - they solve the same problems, but I think D will
>>>> provide slightly better UX, because users will be able to look at the
>>>> configuration panel and change the controls while the service is
>>>> running, only having to restart it to apply the changes.
>>>
>>> I would still go for the single dialog (B) which still has the
>>> advantages of:
>>>
>>> 1. Less design and less code.
>>
>> This is true, but it's not that much more design and code.
>
> I'm not saying this is a very strong argument, but it definitely is an
> argument in favor of the single dialog.
>
>>> 2. One option lives in one place where the user can both see its state
>>> and change it.
>>
>> Users would of course also see the option's state in the config dialog.
>
> Understood.
>
>> And I think as long as the configure button is visible on the same
>> screen, clicking it would be the obvious action if the user wants to
>> change an option. So no risk of "Wtf I see the option but why can't I
>> change it?!"-like situations IMO.
>
> I don't think it would be a big deal either.
>
>>> I'm not sure whether after the recent discussions there are still clear
>>> disadvantages to this proposal (but of course I'm partial). But hey, I'm
>>> not going to be pissed of or whatever if you decide to go for the
>>> configuration dialog :)
>>
>> Really, I'm not that convinced (anymore) of the config dialog and I
>> don't want to make this decision on my own.
>
> 10 days have passed since your last message on this topic and nobody
> else gave more opinion. So... you could ask anonym on the chat if you
> wanted, since he was defensing the config dialog. And otherwise make
> whatever decision your feel better at ease. You'll do user testing
> anyway later on so you'll validate your decision with actual data.
I went with removing the status panel and config dialog and using a
single config panel, like you suggested. When I have cleaned this up
some more, I will send another round of screenshots and links to test it.
But now that I implemented the persistence feature, I see another
problem with this approach:
The options are only applied when the service is enabled. If the user
checks the persistence checkbox and restarts Tails without starting the
service, the service will not be persistent.
In contrast, the config dialog would apply the options when it is closed
via the "Apply and restart service" button, so there would be no
confusion of whether the options are already applied or not.
Now the only option I see to fix this in the config panel is by applying
the options immediately when they are changed. This would work for some
options, but then there is a problem with options which take a string
and write it to a config file, for example the server password. I can't
parse and rewrite the config file on each character changed in the
password text entry.
Do you have any idea how I could fix this?
>
>> Currently I think the main argument I have left is that with B it might
>> be not immediately clear to the user what he has to do to enable the
>> grayed out options. Additionally confusing might be the fact that we are
>> also using graying out to disable options while prerequisite options are
>> not set. So maybe more risk of the "Wtf do I have to do to change this
>> option?!" situation. But then again, if they start the service by
>> clicking the switch in the first place, it's likely they notice that
>> this causes the graying out. So I don't think this is very important.
>
> I'm not sure what you mean by "we are also using graying out to disable
> options while prerequisite options are not set". Can you give an example?
I mean we gray out the autostart option if the persistence option is not
checked.
> This can probably be verified during user testing. You should have a
> objective for the users to reconfigure a server. Write this down
> somewhere :)
Right, I will make a "configure the service to automatically start on
boot" objective (if I can implement the autostart feature in time for
the user tests).
> Note that a similar problem would apply to the Configure button with the
> config dialog. People would also have to understand that they have to
> stop the service to get the Configure button back.
Not in the config dialog which I implemented before. The configure
button was always enabled but the service was restarted if the config
dialog was closed via the "Apply and restart service" button.
Cheers
