On 26.11.2014 09:27, Josef Reidinger wrote:
1) Change the
UI for enabling/disabling. We don't need a box with
radio buttons. It would it better to have a single checkbox.
[X] Start DNS server when booting
Yes, make perfect sense. Maybe better is "Start DNS server during boot"
Whatever the text, using a check-box for a boolean operation (on/off) is
the only logical solution.
2) Remove the
"reload" button in its current form
3) Add a button [Apply current settings] which works exactly like "ok"
but without quitting. Initially disabled. Enabled once the user has
Well, it is more tricky as sometimes is hard to know if you need
"reload" or if you need "restart". For some changes is enough to
SIGHUP, but for some changes real restart is needed including temporary
unavailability of service or reset of existing connections.
From serious bussiness point of view it is huge difference. And for
"Apply" it is not clear for me what is effects.
[Apply] is a good idea. Whether service needs to be restarted, reloaded
or stopped & started again should be hidden behind the module API. It
would just provide `apply_settings` method without any details.
4) Use pop-ups
to ask the user about their intentions when saving
changes or running the server. A subtle but important detail - the
goal of the pop-ups is exposing functionality and offering options,
not warning about something that some users can perceive as problems
(and others don't).
4.a) User changed any configuration and clicked on "Start Server Now".
Show dialog with "changes are pending" message and two options:
"Cancel" and "Save Settings and Start Server Now".
I think we need consider what is 99% case. I think usually people want
to save settings and start server to try it. I think we should prevent
all unnecessary steps. I prefer if we want to support such case to have
button reset, then reload old configuration and if someone need to
start server with old settings, then "Reset" + "Start Server".
If it helps to prevent confusion then call button "Start Server with
Frankly I did not like that solution much at the beginning but as I have
talked with several guys and seen several opinions, we have to make some
assumptions what a normally-logical behavior might be and let the user
decide on corner cases.
This would, at the end, work in your 99% cases and we would ask the user
in the remaining 5% ;)
If we do not want to solve these inconsistencies (such as re/starting a
server without saving changes), we should remove such possibility from
On the other hand, we should not over-engineer anything.
changed any configuration and clicked "ok" or "apply":
First of all, save settings to configuration files.
Next step depends on current situation:
a) Server is not running
Ask the user if they would like to start the server now
Why? let consider cases:
1) user want to start server with new settings => "Start" as I write
2) user want to just store configuration => "OK" ( or maybe call it
"Write Configuration" )
Different users want different things from the very same UI.
Sometimes users expect server to be running when it was running when
they entered Yast, but sometimes they expect it to be stopped when they
selected not to start at boot. Some users expect the server to be
stopped. Strange, but this workflow solves both or even more.
is running and “start when booting” is marked
Reload the server
c) Server is running and “start when booting” is not marked
Ask the user if they would like to stop the server now.
If they decide to keep it running, reload the server.
Why? If server running then simply reload it. Or do you think it is
common use case to run old server and wait with reload to next boot?
Here probably depends on the fact whether user selected the service to
be stopped (in this Yast run), but that seems to be too complicated and
too hard-to-guess behavior.
Anyway, Josef's proposal is not bad.
What do you
think? I'd say it makes a lot of sense. But I'm not sure
how the reloading of setting is currently managed in most cases and if
somebody could complain about the settings being "immediately"
effective on already running services.
For me problem is mostly that visually screen is separated to "lazy"
config and action buttons on bottom, but part of action buttons like
start/stop is in "lazy" part. I think only visual separation helps to
make explicit what is action button and what is lazy configuration.
As you may guess from my comments I do not prefer to ask user to
something unless it is really critical like that computer will explode
or if beer getting warm.
Me neither, depends on how often this will happen. And I don't think
these pop-ups would be seen so often.
Diagram with "the most probable path" and some expectations on
probability might help to understand better.
Thanks for taking care
Lukas Ocilka, Systems Management (Yast) Team Leader
Cloud & Systems Management Department, SUSE Linux
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org