On Tue, 25 Nov 2014 18:48:41 +0100 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
We have been discussing the current usability problems in all modules that manages servers taking this dns-server screenshot as starting point. http://paste.opensuse.org/51547407
We mainly have two problems: - Users expect different effects on running/stopped after changing enabled/disabled (and vice versa). - Sometimes is not so clear when settings should be written to configuration files and when that configuration should be applied to a running server (service reload).
I'll try to summarize a possible solution after listening to QA team and SUSE's UX team. For details check [1]
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"
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 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.
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 New Configuration"
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: 1) 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" )
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?
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. Josef
Cheers.
[1] https://trello.com/c/Xu7BKag3/181-use-case-for-service-start-stop-enable-dis...
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org