[yast-devel] GUI for services management
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 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. 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". 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 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. 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. Cheers. [1] https://trello.com/c/Xu7BKag3/181-use-case-for-service-start-stop-enable-dis... -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
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
On 11/26/2014 09:27 AM, Josef Reidinger wrote:
On Tue, 25 Nov 2014 18:48:41 +0100 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
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?
That's exactly the point which started the whole usability discussion. Currently when you configure the server as disabled ("manually" radio button) and you click "ok", the running server is stopped. We got a bug report about it and I agree is unexpected to me. But turns out that is implemented in that way to meet expectations from some users. So the point in (c) is not whether to keep server running with the old configuration (as you can see in (b) that's never an option). The point is whether disabling should mean stopping the currently running service.
[...]
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.
I'd normally agree. But the problem with this approach is that several fields and field combinations has proved to be understood in different ways by different users. Ken's solution was to add extra checks. I think it makes sense even if I usually dislike pop-ups. Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Wed, 26 Nov 2014 13:54:37 +0100 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
On 11/26/2014 09:27 AM, Josef Reidinger wrote:
On Tue, 25 Nov 2014 18:48:41 +0100 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
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?
That's exactly the point which started the whole usability discussion. Currently when you configure the server as disabled ("manually" radio button) and you click "ok", the running server is stopped. We got a bug report about it and I agree is unexpected to me. But turns out that is implemented in that way to meet expectations from some users.
So the point in (c) is not whether to keep server running with the old configuration (as you can see in (b) that's never an option). The point is whether disabling should mean stopping the currently running service.
I am probably not common user. If I uncheck "start server during boot", then I really do not except to stop already running service.
[...]
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.
I'd normally agree. But the problem with this approach is that several fields and field combinations has proved to be understood in different ways by different users. Ken's solution was to add extra checks. I think it makes sense even if I usually dislike pop-ups.
Still I think we maybe just need to separate action buttons ( like start/stop service ) from configuration options ( like start during boot ). This should help with confusion without pop-ups. Just my 2c. Josef
Cheers.
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 11/26/2014 02:03 PM, Josef Reidinger wrote:
On Wed, 26 Nov 2014 13:54:37 +0100 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
On 11/26/2014 09:27 AM, Josef Reidinger wrote:
On Tue, 25 Nov 2014 18:48:41 +0100 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
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?
That's exactly the point which started the whole usability discussion. Currently when you configure the server as disabled ("manually" radio button) and you click "ok", the running server is stopped. We got a bug report about it and I agree is unexpected to me. But turns out that is implemented in that way to meet expectations from some users.
So the point in (c) is not whether to keep server running with the old configuration (as you can see in (b) that's never an option). The point is whether disabling should mean stopping the currently running service.
I am probably not common user. If I uncheck "start server during boot", then I really do not except to stop already running service.
Neither do I. Neither do the QA guys according to https://docs.google.com/spreadsheets/d/1QeVFspHYGMPtEZtkVkOO_WsoEoTNrtIlDvyL... But that was the implemented behaviour. And it was by user request. The good point about Ken's proposal is that it does not only target common user (let's assume for a while that we can consider ourselves as such) but it tries to target all users (even those with a strange mindset that leaded us to this point).
[...]
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.
I'd normally agree. But the problem with this approach is that several fields and field combinations has proved to be understood in different ways by different users. Ken's solution was to add extra checks. I think it makes sense even if I usually dislike pop-ups.
Still I think we maybe just need to separate action buttons ( like start/stop service ) from configuration options ( like start during boot ). This should help with confusion without pop-ups.
Do you mean in a completely different section (with "section" I mean those at the left like "start-up" or "forwarders")? Would it be an option to add them in the same row that other actions like "cancel" or "ok"? -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Wed, 26 Nov 2014 15:20:21 +0100 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
On 11/26/2014 02:03 PM, Josef Reidinger wrote:
On Wed, 26 Nov 2014 13:54:37 +0100 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
On 11/26/2014 09:27 AM, Josef Reidinger wrote:
On Tue, 25 Nov 2014 18:48:41 +0100 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
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?
That's exactly the point which started the whole usability discussion. Currently when you configure the server as disabled ("manually" radio button) and you click "ok", the running server is stopped. We got a bug report about it and I agree is unexpected to me. But turns out that is implemented in that way to meet expectations from some users.
So the point in (c) is not whether to keep server running with the old configuration (as you can see in (b) that's never an option). The point is whether disabling should mean stopping the currently running service.
I am probably not common user. If I uncheck "start server during boot", then I really do not except to stop already running service.
Neither do I. Neither do the QA guys according to https://docs.google.com/spreadsheets/d/1QeVFspHYGMPtEZtkVkOO_WsoEoTNrtIlDvyL...
But that was the implemented behaviour. And it was by user request.
The good point about Ken's proposal is that it does not only target common user (let's assume for a while that we can consider ourselves as such) but it tries to target all users (even those with a strange mindset that leaded us to this point).
[...]
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.
I'd normally agree. But the problem with this approach is that several fields and field combinations has proved to be understood in different ways by different users. Ken's solution was to add extra checks. I think it makes sense even if I usually dislike pop-ups.
Still I think we maybe just need to separate action buttons ( like start/stop service ) from configuration options ( like start during boot ). This should help with confusion without pop-ups.
Do you mean in a completely different section (with "section" I mean those at the left like "start-up" or "forwarders")?
No.
Would it be an option to add them in the same row that other actions like "cancel" or "ok"?
Yes, possible, but better from my POV will be to have it under specific area with buttons under sections on left, which do not change when switching section. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 26.11.2014 15:20, Ancor Gonzalez Sosa wrote:
Neither do I. Neither do the QA guys according to https://docs.google.com/spreadsheets/d/1QeVFspHYGMPtEZtkVkOO_WsoEoTNrtIlDvyL...
But that was the implemented behaviour. And it was by user request.
The good point about Ken's proposal is that it does not only target common user (let's assume for a while that we can consider ourselves as such) but it tries to target all users (even those with a strange mindset that leaded us to this point).
The common workflow should be implemented in way which we expect that logically makes sense. Whenever we can't decide what is the correct decision, we have to ask user. Examples: Trust this GPG key? Install these recommended packages? A common expectation I've seen is that when user configures a service in Yast, but keeps "start at boot" disabled, expects that the service will not start when they close Yast with OK. But these users ALSO expect the service to keep stopped when they configure the service for the first time and SELECT "start at boot". You know why? Because when you are configuring the service, you do not do it at system startup. I myself would have a different expectation - and that's where it all started: different expectations in the very same situation.
I'd normally agree. But the problem with this approach is that several fields and field combinations has proved to be understood in different ways by different users. Ken's solution was to add extra checks. I think it makes sense even if I usually dislike pop-ups.
Still I think we maybe just need to separate action buttons ( like start/stop service ) from configuration options ( like start during boot ). This should help with confusion without pop-ups.
Do you mean in a completely different section (with "section" I mean those at the left like "start-up" or "forwarders")?
Would it be an option to add them in the same row that other actions like "cancel" or "ok"?
We are mixing papas y boniatos here. We are talking about ALL services, they do not need to be configured via Yast module that uses tree widget for navigation. Some use tabs, other use wizard-like workflow. Thx Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader Cloud & Systems Management Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
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 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.
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"
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: 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" )
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 -- Lukas Ocilka, Systems Management (Yast) Team Leader Cloud & Systems Management Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Hello, On Nov 26 18:03 Lukas Ocilka wrote (excerpt):
On 26.11.2014 09:27, Josef Reidinger wrote:
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.
[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.
On Nov 26 18:16 Lukas Ocilka additionally wrote (excerpt):
Whenever we can't decide what is the correct decision, we have to ask user.
Only all those together makes sense from my point of view: Have a simple [Apply] button but when the service does not support a really safe "reload" method (i.e. that neither makes the service temporaryly unavailability nor resets existing connections), then ask the user for confirmation if he wants to disrupt the currently running service to apply the new settings right now. As far as I understand it this means the `apply_settings` method whould have to be able to ask the user if needed. Kind Regards Johannes Meixner -- SUSE LINUX GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 21284 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 28.11.2014 10:32, Johannes Meixner wrote:
On Nov 26 18:16 Lukas Ocilka additionally wrote (excerpt):
Whenever we can't decide what is the correct decision, we have to ask user.
Only all those together makes sense from my point of view:
Have a simple [Apply] button but when the service does not support a really safe "reload" method (i.e. that neither makes the service temporaryly unavailability nor resets existing connections), then ask the user for confirmation if he wants to disrupt the currently running service to apply the new settings right now.
That's a good point but it's actually something completely different. It's a different use case, e.g., something like Samba service to which clients might be connected "right now" and copying files. If we talk about DNS, DHCP or NTP Server, then nobody cares.
As far as I understand it this means the `apply_settings` method whould have to be able to ask the user if needed.
If there is a risk, those Yast modules already ask the admin whether to restart that service or skip it. Bye Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader Cloud & Systems Management Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Hello, On Nov 28 12:46 Lukas Ocilka wrote (excerpt):
On 28.11.2014 10:32, Johannes Meixner wrote:
Have a simple [Apply] button but when the service does not support a really safe "reload" method (i.e. that neither makes the service temporaryly unavailability nor resets existing connections), then ask the user for confirmation if he wants to disrupt the currently running service to apply the new settings right now.
That's a good point but it's actually something completely different.
It's a different use case, e.g., something like Samba service to which clients might be connected "right now" and copying files. If we talk about DNS, DHCP or NTP Server, then nobody cares.
But Ancor Gonzalez Sosa <ancor@suse.de> initially wrote:
usability problems in all modules that manages servers
which I understand that he has all services in mind. Then Ancor Gonzalez Sosah wrote:
taking this dns-server screenshot as starting point
which I understand that DNS is only meant as initial example. If my understanding is right, there is no such thing as "completely different use cases" because all are one same use case "GUI for all modules that manage services". Kind Regards Johannes Meixner -- SUSE LINUX GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 21284 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 11/28/2014 03:23 PM, Johannes Meixner wrote:
Hello,
On Nov 28 12:46 Lukas Ocilka wrote (excerpt):
On 28.11.2014 10:32, Johannes Meixner wrote:
Have a simple [Apply] button but when the service does not support a really safe "reload" method (i.e. that neither makes the service temporaryly unavailability nor resets existing connections), then ask the user for confirmation if he wants to disrupt the currently running service to apply the new settings right now.
That's a good point but it's actually something completely different.
It's a different use case, e.g., something like Samba service to which clients might be connected "right now" and copying files. If we talk about DNS, DHCP or NTP Server, then nobody cares.
But Ancor Gonzalez Sosa <ancor@suse.de> initially wrote:
usability problems in all modules that manages servers
which I understand that he has all services in mind.
Then Ancor Gonzalez Sosah wrote:
taking this dns-server screenshot as starting point
which I understand that DNS is only meant as initial example.
If my understanding is right, there is no such thing as "completely different use cases" because all are one same use case "GUI for all modules that manage services".
Yes, that was my intention. I have summarized all the input (including situations in which reloading is not an option) in the last page of this Google document. Maybe it's easier to discuss if we have something more visual about the changes in the interface, so I included a mockup of the interface with the agreed changes. Keep in mind, nevertheless, that is just a first approach. Maybe (hopefully) the way to separate starting/stopping from the rest will be different in the end. http://goo.gl/Sbe3Ld There are two options. I think most of us prefer option A. The key for success in that approach is an UI that makes the difference between configuration and current status very clear. If we don't achieve that, we will have to implement some variation of option B. Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Hello, On Dec 2 14:43 Ancor Gonzalez Sosa wrote (excerpt):
This reads: ---------------------------------------------------------------------- 3) The most common approach in YaST interfaces is allowing the user to configure everything in the UI without the changes taking effect immediately. When the user clicks the "ok" button, all the changes are applied to the system and the YaST interface is closed. Although that's the usual YaST behavior, it's not mandatory to stick to that approach. ---------------------------------------------------------------------- Personally I am against this usual YaST behavior. The usual YaST behavior is no real (i.e. no bidirectional) communication between user and system. The dialogs might look as if there is such a communication but actually it happens only between the user and the GUI but not between the user and the system simply because nothing is done regarding the system until the whole module is finishing and then it is too late for a bidirectional communication. A consequence is that when something goes wrong while the module is finishing (i.e. while changes are applied to the system), there can be only unfriendly error messages because the user can no longer do anything at this stage. See https://en.opensuse.org/Archive:YaST_Printer_redesign therein in particular the sections - Transaction Semantics For Each "One Setup" - "Just In Time" Configuration - Different Workflow What Actually Happens Kind Regards Johannes Meixner -- SUSE LINUX GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 21284 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 12/02/2014 04:38 PM, Johannes Meixner wrote:
Hello,
On Dec 2 14:43 Ancor Gonzalez Sosa wrote (excerpt):
This reads: ---------------------------------------------------------------------- 3) The most common approach in YaST interfaces is allowing the user to configure everything in the UI without the changes taking effect immediately. When the user clicks the "ok" button, all the changes are applied to the system and the YaST interface is closed. Although that's the usual YaST behavior, it's not mandatory to stick to that approach. ----------------------------------------------------------------------
Personally I am against this usual YaST behavior.
The usual YaST behavior is no real (i.e. no bidirectional) communication between user and system. The dialogs might look as if there is such a communication but actually it happens only between the user and the GUI but not between the user and the system simply because nothing is done regarding the system until the whole module is finishing and then it is too late for a bidirectional communication.
A consequence is that when something goes wrong while the module is finishing (i.e. while changes are applied to the system), there can be only unfriendly error messages because the user can no longer do anything at this stage.
See https://en.opensuse.org/Archive:YaST_Printer_redesign therein in particular the sections - Transaction Semantics For Each "One Setup" - "Just In Time" Configuration - Different Workflow What Actually Happens
I see your point. Let's keep in mind that all YaST modules should be consistent. So before proceeding with the discussion on how to change the behaviour of the modules managing network services, let's ask ourselves: Do we want to change the way YaST interacts with the user and the system in general? That means changing this current behaviour for MOST modules: 1. During startup read all information from the system. 2. Show whatever dialogs are needed to let the user do all his configuration tasks and keep all settings only internally. 3. When finishing write all settings to the system. Whatever is the answer, we cannot change our mind then again in six months from now. There are almost 100 YaST modules out there and even adapting them for small things in which all agree takes a lot of time. I think the current approach is perfect for installation, in which you configure everything before pushing the big red button. But I kind of agree that it has important drawbacks on running system. And that's, IMHO, one of the main problems in YaST development. We are writing modules to fit both installation and configuration of an installed system and I'm not sure to what degree the solutions for both use cases are "compatible". Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 12/04/2014 04:43 PM, Ancor Gonzalez Sosa wrote:
Do we want to change the way YaST interacts with the user and the system in general?
By the way. That question deserves a separated thread with usability experts involved. Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Hello, yes, it should be on a new thread, nevertheless I reply here for now: On Dec 4 16:43 Ancor Gonzalez Sosa wrote (excerpt):
I think the current approach is perfect for installation, in which you configure everything before pushing the big red button. But I kind of agree that it has important drawbacks on running system.
I think you did not yet full understand what I mean with "One Setup" in https://en.opensuse.org/Archive:YaST_Printer_redesign ------------------------------------------------------------------------- "One setup" means the smallest amount of setup actions which lead from one consistent state to another consistent state. "Consistent state" is meant from the user's point of view regarding the particular kind of setup ... and not from a low-level (e.g. filesystem or kernel) point of view. ... Note that it depends entirely on the particular case what exactly "one setup" is according to the above definition. For example: * Add, modify, or delete one print queue is each "one setup" even if there can be several print queues for one printer. * Activate or deactivate one scanner driver is "one setup" even if one scanner driver can be used for serveral scanners. * Add a new harddisk and and do all what is necessary to move for example data from existing /usr/ and /var/ directories to new partitions on the new harddisk is "one setup" for a harddisk management tool. ------------------------------------------------------------------------- Accordingly "a whole system installation" is "one setup" so that the current approach for installation perfectly matches the "one setup" idea. But in the running system there is no such thing as "a whole system installation" and this means many current YaST configuration modules may not match the "one setup" idea. FWIW: The current YaST printer and scanner configuration modules implement the "one setup" idea (since 2008) and - guess what - I did not get any complaint or any comment or any question because their behaviour is different. I assume that for the user it does not at all matter as long as a YaST configuration module works in a reasonable way. Accordingly I think YaST configuration modules can be changed as wished by their individual developers as they like it and when they like it. I only can tell that for me it was very much easier and cleaner to implement the YaST printer and scanner configuration modules according to the "one setup" idea, see https://en.opensuse.org/Archive:YaST_Printer_redesign ---------------------------------------------------------------------- ... it makes the implementation more complicated and therefore results more bugs. For example when a print queue is deleted and a new queue with the same name is set up, the implementation could not just delete it, but must somehow fake in the user interface as if it was already deleted and as if the new one was already set up until the actual deletion and set up happens during "finish" but what should it do when the deletion or set up fails for whatever reason? ---------------------------------------------------------------------- Kind Regards Johannes Meixner -- SUSE LINUX GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 21284 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Hello, inline an addedum to avoid misunderstanding On Dec 4 18:39 Johannes Meixner wrote (excerpt):
I only can tell that for me it was very much easier and cleaner to implement the YaST printer and scanner configuration modules according to the "one setup" idea, see https://en.opensuse.org/Archive:YaST_Printer_redesign ----------------------------------------------------------------------
... the current usual YaST module behavior ...
... it makes the implementation more complicated and therefore results more bugs. For example when a print queue is deleted and a new queue with the same name is set up, the implementation could not just delete it, but must somehow fake in the user interface as if it was already deleted and as if the new one was already set up until the actual deletion and set up happens during "finish" but what should it do when the deletion or set up fails for whatever reason? ----------------------------------------------------------------------
Kind Regards Johannes Meixner -- SUSE LINUX GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 21284 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (4)
-
Ancor Gonzalez Sosa -
Johannes Meixner -
Josef Reidinger -
Lukas Ocilka