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.
> 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?
This can probably be verified during user testing. You should have a
objective for the users to reconfigure a server. Write this down
somewhere :)
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.
>> While exploring GNOME Settings today I saw stuff like this:
>>
>> - In Users and Printers, the options are displayed as labels but when
>> hovering them they turn out to be buttons that you can click to
>> change.
>
> Wow. I just tried this and I found it very surprising and totally
> unexpected behavior, even though I read this first :D
> I really think we should not do this, but use a textbox when we want to
> allow editing a string.
Yeah, it lacks a signifier.
