anonym:
> segfault:
>> sajolida:
>>> segfault:
>>> The disadvantages are that:
>>>
>>> - You have duplicate information between the two screens, with one
>>> version describing the state (eg "Persistence Off") and another
>>> changing the setting (eg "Store service configuration and data on the
>>> persistent volume"). In Spencer's design both the state and the
>>> widget the state were the same thing and that's simpler and probably
>>> easier to understand.
>>
>> Right, there is duplicate information. But I don't think this is that bad.
>> The first I call the "status panel" and the other the "configuration
>> dialog". The status panel should only display the information that is
>> important / often needed. I implemented this by adding a
>> "display_status" attribute to the Option class. If this attribute is set
>> to True, the option will be displayed in the status panel. But currently
>> I only display the red/green "light", which only makes sense of bools.
>> If the option type is string or int, it should display a label instead.
>> I think by the use of the red/green "lights" for bools and labels for
>> strings and integers it is quite clear that the options are not
>> configurable in the status panel.
>> Also, there is the same kind of duplicate information with the red/green
>> "light" in the service list on the left and the on/off switch in the
>> status panel.
>
> FWIW, I like the approach you took here, segfault. In most cases users
> will only need what is shown on the status panel, so let's not make it
> harder for them to find what they need by also showing options they may
> not even understand.
Wait. My proposal is not to display everything and the kitchen sink
upfront. My proposal is to show every option is a single place and
merging state and modification. But if we think that some options are
for advanced users only, then we should layer our interface: with some
toggle, some "more options" dialog, or whatever. But this would apply
equally to my proposal (single dialog with "direct manipulation") or
yours (status panel + configuration dialog).
>>> - I have to click Configure to see the password of the Mumble and give
>>> it to my users. The same probably applies to other settings of other
>>> services.
>>
>> The server password is of course information that is often needed and
>> should also be displayed in the status panel. Like I wrote above, I
>> didn't implement this for strings and ints yet, but will do so if we
>> decide to keep the status panel.
>
> Perhaps it's worth making a special case for passwords, i.e. initially
> show it as "***" in the status panel, and only show the password after
> some deliberate action, like a small label saying "Reveal password". Or
> perhaps just show a "copy password to clipboard" button/label?
We just had a similar discussion about the Greeter with Spencer and
Susan :) But here the proper solution would be, I think, different
whether we go for a single dialog or a status panel + a configuration
dialog so I'll refrain from commenting on this for now.
> I also think there should be an option to generate new (safe) passwords
> in the configuration panel, with some button/label next to the setting.
+1
>>> - More design, testing, coding, maintenance, etc.
>>>
>>> Regarding the problem that you were trying to solve: convey to the user
>>> that she needs to restart the service to apply the changes, I'm
>>> confident that this can be solved without loosing the advantages of
>>> having a single screen. For example we could:
>>>
>>> A. Show a dialog saying that the changes will be applied only after
>>> restarting the service, when once of these options is changed.
>>
>> I think a popup dialog for every option modified would be very annoying.
>> Maybe a notification (like the ones created with notify-send) would be
>> less annoying - but I associate those more with notifications from the
>> system and I think it would be strange to get those from the application
>> I am currently interacting with. Another option would be displaying a
>> warning somewhere in the application window. But I think the additional
>> configuration dialog makes the workflow clear without displaying any
>> messages.
>
> I fully agree with you scepticism regarding all solutions for how to
> notify the user of this, so...
>
>>> B. Gray out the controls that require restarting the service while the
>>> service is running. This would force the user to shutdown the
>>> service to change its configuration. I quite like this option as:
>
> ... I think this is what makes most sense, mostly because of what
> follows below:
>
>>> - It could make quite easy to differentiate in the future the
>>> options that require restart and the ones that don't. Even if for
>>> now on you can gray out everything.
>>> - Instead of talking about "reconfiguring and restarting" we would
>>> talk about "stopping, reconfiguring, and starting" which is maybe
>>> a bit slower but might be clearer in terms of mental model. For
>>> example, because it prevents confusion on whether the changes are
>>> applied already or not (with respect to option A).
>
> Perhaps this is what you suggest, but let's make this proposal clear:
> let's KISS and skip supporting changing *any* option while a service is
> running. In other words: let's grey out the "Configure" box while the
> service is started, and enable it again once the service is stopped. A
> label can be shown next to the greyed out button saying: "Services can
> only be configured while stopped".
>
> This will be very easy to explain to users, and simplify implementation
> and reduce the design complexity.
I'm glad your joining me on this one anonym!
>> I think B is better than A but I'm not sure if it makes it clear to the
>> user that:
>>
>> - After starting the service, he will not be able to modify the options
>> he sees (unless he stops the service again)
>
> This is fixed by my proposal: the status panel now only shows
> information, and has no controls except the "Start"/"Stop" toggle, and
> (if stopped) the "Configure" button.
>
>> - He will be able to configure the grayed out options once he stopped
>> the service. Of course, if he pays attention to it, he will notice that
>> the options gray out while starting the service.
>
> This is fixed by my proposal: the configuration dialog is only
> accessible when the service is stopped, and then all options are available.
>
>> Also, I already gray out the "Automatically start on boot" option while
>> the persistence is not enabled, which might be confusing.
>
> IMHO this can also be in the configuration dialog only.
>
>>> Now, putting everything on a single screen doesn't prevent us from
>>> layering this screen, for example putting advanced options in a
>>> toggleable area, but the key idea here is that a single option should be
>>> in a single place. Maybe it would be interesting to list the different
>>> options that we would have for different services in the ones from the
>>> blueprint [2], just to see how big this could get.
>>
>> The main reason for thinking up the status panel and configuration
>> dialog separation was this point of yours:
>>
>>> What if a service always requires some configuration before being
>>> started? For example the password of a Mumble server? Would it work
>>> to display the settings dialog when toggling on if some settings
>>> are required?
>>
>> I don't see how this would be solved with either option A or B.
>
> When adding a service we get the configration dialog, so all options are
> shown there. Add an attribute/tag "mandatory" for such options, and only
> allow finalizing the addition of the service once such options are set
> -- this also makes sense later, when reconfiguring. However, in most
> cases we can generate such things, e.g. for passwords, but I guess there
> might be things we haven't thought about yet.
Right, the same problem would apply to both proposal:
- If we go for the "single dialog" we can prevent switching the service
on until all mandatory options are specified.
- If we go for the "status panel + configuration dialog" we can gray out
the validation button until all mandatory options are specified.
The problem of explaining which options are mandatory will apply to both
proposals and might be solve different in both cases, so I'm not sure
it's worth going in the details now.
>> But maybe all of these concerns don't outweigh the more simple design of
>> your option B, I'm not sure.
>
> So I think we can eat the cake and keep it too, with the above proposal! :)
>
>>> I also prefer the shorter labels (at least for "Persistent",
>>> "Auto-start") which can still have longer labels as tool tips. These
>>> options will be the same for every service so people will get use to
>>> them and shorter labels are easier to scan and recognize.
>>
>> I think George suggested more descriptive labels, but maybe I overdid
>> this. Are tool tips still a thing? I don't recall seeing any in GNOME 3
>> applications. Maybe I just didn't notice.
>
> Personally I find GNOME Settings very uninformative because of the lack
> of a way to get information quickly for each option. I know sajolida
> will hate me, but IMHO, feel free to diverge from GNOME on this point.
>
> What about adding some sort of "Help" indicator (perhaps some stylised
> question mark) that can be place next to some short option label, and
> that shows a pop-up when hovered over? They can even double as links to
> the user docs when available.
>
> If pop-ups are a no-no, what about having some part of the panel
> dedicated to showing the help? We display it when hovering over the
> option's label or control.
I still didn't check the GNOME HIG about popus (someone show do this)
but I couldn't find any with a quick exploration of GNOME Settings. But
I saw different other tricks:
A. Some names of options are short and some are longer (eg "Workspaces
only on primary display"). I think we should be afraid of making labels
a bit long as long as we still try hard to make them as short as possible.
B. Some options have subtitles in gray when needed. See for example the
screenshot in attachment.
C. Some dialogs have "Learn more" or other links to documentation. Which
are rather global to a screen than specific to an option.
I think that use each of these techniques when appropriate will solve a
vast majority of our problems. If some precise problem cannot be solve
by any of these, then only I'd be happy to discuss custom solutions.
