On 26.11.2014 09:27, Josef Reidinger wrote:
- 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.
Remove the "reload" button in its current form
Add a button [Apply current settings] which works exactly like "ok"
but without quitting. Initially disabled. Enabled once the user has changed something.
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 send 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.
- 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 New Configuration"
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 the UI.
On the other hand, we should not over-engineer anything.
4.b) User 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:
- user want to start server with new settings => "Start" as I write
above 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.
b) Server 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