On 28.4.2015 12:55, Ancor Gonzalez Sosa wrote:

...

...

The first page of the document is unchanged, so you can skip it if you already know the problem.

Cheers.

[1] https://docs.google.com/document/d/1TQO-bdqagSOUssGqJsf3eEeMDh2w40BujdOFP9-t...

Hi, for me option A looks better, we just need better wording. Maybe "State" and "Service" instead of start-up?

From my POV, the current state of a service and start-up are related, so I'd expect them on the same screen. On the other hand, both options A and B seem to be too complicated for the first (and even second) sight.

Additionally, option B have them one one screen, but they are separated by LDAP and Firewall settings. Reconsidering these screens ~ maybe LDAP and Firewall do not belong there at all. They aren't actually related to service (status) at all. Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On 28.4.2015 22:50, Christian Boltz wrote:

I don't know much about bind, but I'm slightly surprised about the "[ ] LDAP Support Active" option - why is this option on the same tab as the start now/on boot settings?

I'd guess "LDAP Support Active" is a config option for bind, and therefore should be on another tab (maybe "Basic Options"?)

It's a generic Bind option to store records in LDAP. Well, we could label then checkbox "Store DNS Records in LDAP" then, that's true. But we didn't have any "general options" and for that reason, we just put it next to firewall and named service.

To sum it up - I'd take option B with the "LDAP Support Active" option moved to another tab. And I'd propose to use _exactly_ that screen for all services.

I'd actually move LDAP + Firewall to some other tab as services start/enable belong to each other from my POV.

If you think option B has too much on one page, move the firewall settings to a separate "Firewall" tab. That's still better than option A ;-) (and if a service needs multiple independent ports (for example, 80 and 443 for Apache), you even have some room for more checkboxes)

This is not needed. There will always be just one checkbox for all ports at once. Yast always enables a service defined in /etc/sysconfig/SuSEfirewall2.d/services/ instead of opening/closing ports in firewall. See http://kobliha-suse.blogspot.cz/2008/06/firewall-services-defined-by-package... (sorry for the advert). Bye Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On 04/29/2015 11:19 AM, Kenneth Wimer wrote:

Hi all,

I'm on the list now, so no more need to put me in CC...sorry for that, I know that it gets annoying :-(

I think that in general we need to differentiate between the main functions of the UI (starting and stopping services during run-time and configuring the starting and stopping services at boot.) and the various options around those functions.

I agree the module is typically used for 2 use cases: controlling the status (which includes firewall and all that) and configuring the service. I'm not so sure, nevertheless, that the first one deserves to be called primary. I guess some users see the module just as a configuration tool and use the services YaST module or even command line to start/stop and enable/disable. That's what I would expect from server's sysadmins. I guess some users only run the module once in a while to start/stop the service without tweaking the configuration. That's what I would expect in computers that are actually not servers, but can need the service active for a particular purpose during a particular time frame. I also can imagine we everything in between, as usual with YaST.

It seems (correct me if I am wrong, this is just a guess) that the firewall option was added to this UI to accommodate the primary use-case, or most common user path: starting service and then unblocking the port for the service to actually work.

Most likely, yes.

The rest of the UI however, seems like a toolkit of functions and all their possible options and related functions. The first question I would ask would be: Do we want to make a UI which makes it easy for a user to accomplish the primary and secondary use-cases or do we want to present a toolkit with all possible functions and options.

Mixing these options means more work over the long-run...building a UI that is a toolkit for all possible functions and options AND adding bits here and there to represent the most common user paths. I guess it all comes down to out target users, and I'd assume that we currently have little or no solid information on them.

Actually we don't have that information, but even though it makes sense to me to group all the things related to the so-called "primary" use case into one initial screen.

I won't go into the details about LDAP or such because I think we need to answer these bigger questions first.

Those were my 2 cents.

On 29/04/15 08:30, Lukas Ocilka wrote:

...

On 28.4.2015 22:50, Christian Boltz wrote:

...

I don't know much about bind, but I'm slightly surprised about the "[ ] LDAP Support Active" option - why is this option on the same tab as the start now/on boot settings?

I'd guess "LDAP Support Active" is a config option for bind, and therefore should be on another tab (maybe "Basic Options"?) It's a generic Bind option to store records in LDAP. Well, we could label then checkbox "Store DNS Records in LDAP" then, that's true.

But we didn't have any "general options" and for that reason, we just put it next to firewall and named service.

...

To sum it up - I'd take option B with the "LDAP Support Active" option moved to another tab. And I'd propose to use _exactly_ that screen for all services. I'd actually move LDAP + Firewall to some other tab as services start/enable belong to each other from my POV.

...

If you think option B has too much on one page, move the firewall settings to a separate "Firewall" tab. That's still better than option A ;-) (and if a service needs multiple independent ports (for example, 80 and 443 for Apache), you even have some room for more checkboxes) This is not needed. There will always be just one checkbox for all ports at once. Yast always enables a service defined in /etc/sysconfig/SuSEfirewall2.d/services/ instead of opening/closing ports in firewall. See http://kobliha-suse.blogspot.cz/2008/06/firewall-services-defined-by-package...

(sorry for the advert).

Bye Lukas

-- 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 05/02/2015 11:38 AM, Christian Boltz wrote:

Hello,

after the discussion we just had at the YaST workshop, here's my proposal ("written" in GIMP ;-) - see the attached screenshot.

I removed two things: - the "[ ] LDAP support active" checkbox - should go to another screen - After saving the config "( ) stop the service" - that's an unrealistic usecase IMHO (if you want to stop the service, you typically don't care about the config ;-)

The second change also means that we can replace the radio buttons with a checkbox [x] Reload/restart the service after saving settings which should be enabled by default.

This gives us enough space to keep the firewall settings on the same page - but if you really, really want, you can also move it to another page.

And actually looks much closer to the original proposal I was trying to implement[1] (discussed in this thread[2]). [1] https://docs.google.com/drawings/d/1cVv4FY4tWRLAnMG96Cdfvw8asTNpzhFUdKn4TEq8... [2] http://lists.opensuse.org/yast-devel/2015-04/msg00007.html -- 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 05/04/2015 10:21 AM, Lukas Ocilka wrote:

On 2.5.2015 11:38, Christian Boltz wrote:

...

Hello,

after the discussion we just had at the YaST workshop, here's my proposal ("written" in GIMP ;-) - see the attached screenshot.

I removed two things: - the "[ ] LDAP support active" checkbox - should go to another screen - After saving the config "( ) stop the service" - that's an unrealistic usecase IMHO (if you want to stop the service, you typically don't care about the config ;-)

The second change also means that we can replace the radio buttons with a checkbox [x] Reload/restart the service after saving settings which should be enabled by default.

This gives us enough space to keep the firewall settings on the same page - but if you really, really want, you can also move it to another page.

I like the proposal.

- Start/Stop and Enable/Disable are on the same screen - Even save, but do not exit - is there

What is still a bit weir is

"Currently" which is IMO "Current status" or something similar

I have a different issue (but maybe it can be solved by wording): If a service is running now and I want it to be stopped when the module finishes, how will I do it? It sounds like the only way is to stop the service and then finish the module, but it cannot be achieved via setting the check boxes... Jiri

...

Oh, and don't forget to re-add the LDAP checkbox somewhere ;-)

Yes, that's the problem, where to put it? Alone? If we create another screen, LDAP check-box would be there alone. So, maybe also move firewall there too? On the other hand, moving firewall elsewhere would move it also from the obvious place where I'd expect it.

To fix that problem, we might need to always check whether the service would be reachable (firewall stopped or port opened) before saving the configuration and maybe asking user to confirm that?

BTW, side note: Firewall is disabled doesn't help the user to understand that they can't open a port in disabled firewall. Just changing the label to be more informative might help. Yes, I know it's a generic thing in CWM.

Thx for your ideas Lukas

-- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.com Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.com -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Hello, Am Montag, 4. Mai 2015 schrieb Jiri Srain:

On 05/04/2015 10:21 AM, Lukas Ocilka wrote:

...

On 2.5.2015 11:38, Christian Boltz wrote:

...

after the discussion we just had at the YaST workshop, here's my proposal ("written" in GIMP ;-) - see the attached screenshot.

...

I like the proposal.

:-)

...

- Start/Stop and Enable/Disable are on the same screen - Even save, but do not exit - is there

What is still a bit weir is

"Currently" which is IMO "Current status" or something similar

I was too lazy to push around letters in GIMP - but if this is the only problem in my proposal, I'm more than happy ;-)

I have a different issue (but maybe it can be solved by wording): If a service is running now and I want it to be stopped when the module finishes, how will I do it? It sounds like the only way is to stop the service and then finish the module, but it cannot be achieved via setting the check boxes...

See Josef's mail - this is possible by clicking "stop now" - and I'd really be interested why you want to stop a service after changing its config. (This somehow reminds me to one of my commit messages for AppArmor - "now that function xy was fixed, drop it" ;-) I'd guess this is a rare usecase, and by moving the support for it to the "stop now" button I was able to make the dialog much more usable and easier to understand.

...

...

Oh, and don't forget to re-add the LDAP checkbox somewhere ;-)

Yes, that's the problem, where to put it? Alone? If we create another screen, LDAP check-box would be there alone. So, maybe also move firewall there too? On the other hand, moving firewall elsewhere would move it also from the obvious place where I'd expect it.

Please keep the firewall settings on the start now/on boot page - it makes most sense there. And yes, the LDAP checkbox might end up on a separate page with nothing else. This doesn't hurt IMHO because it's a totally different setting. IIRC the "basic options" page is already crowded - otherwise this would have been a possible place for the LDAP checkbox.

...

To fix that problem, we might need to always check whether the service would be reachable (firewall stopped or port opened) before saving the configuration and maybe asking user to confirm that?

Good question ;-) Basically it's a good idea, but there might also be people who set up a nameserver just for usage from localhost, and those people would be annoyed by the confirmation popup.

...

BTW, side note: Firewall is disabled doesn't help the user to understand that they can't open a port in disabled firewall. Just changing the label to be more informative might help.

Indeed. Regards, Christian Boltz -- Das Ziel des Trolls ist [...] der Gegenseite genug Seil zu reichen, damit sie sich selbst in aller Öffentlichkeit erhängen kann. [Fefe in http://blog.fefe.de/?ts=b3558afe] -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On 05/13/2015 09:31 AM, Ancor Gonzalez Sosa wrote:

On 05/09/2015 01:06 AM, Christian Boltz wrote:

...

Hello,

Am Montag, 4. Mai 2015 schrieb Jiri Srain:

...

On 05/04/2015 10:21 AM, Lukas Ocilka wrote:

...

On 2.5.2015 11:38, Christian Boltz wrote:

What is still a bit weir is

"Currently" which is IMO "Current status" or something similar

I was too lazy to push around letters in GIMP - but if this is the only problem in my proposal, I'm more than happy ;-)

"Current status" would be ok (much better than "currently" which was just a temporary solution). But the problem is that this has been exactly the confusing point to some users. We need something more explicit meaning "Status (currently and after saving settings)".

Remember one of the many manifestations of the original problem: some people expected that enabling the service at boot would mean that the service is running after pressing "ok" (even if it's currently stopped). They seem to got confused even though the old UI also had the buttons for starting/stopping just in the same tab.

I believe (or hope) it can be fixed with the proper labels, but I'm not creative enough.

So, who can help me with the labels of the widgets and the help messages? Here you are the ones in the current prototype: http://paste.opensuse.org/22250719 Keep in mind that the labels should be self-explanatory with no room for doubts or ambiguity and the help... well, the help text should be useful :-) 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, Am Donnerstag, 14. Mai 2015 schrieb Ancor Gonzalez Sosa:

On 05/13/2015 09:31 AM, Ancor Gonzalez Sosa wrote: ...

...

"Current status" would be ok (much better than "currently" which was just a temporary solution). But the problem is that this has been exactly the confusing point to some users. We need something more explicit meaning "Status (currently and after saving settings)".

I think "Current status" is enough - especially in combination with greying out "reload the service after saving settings" if current status is "stopped". An alternative would be: Instead of greying out the "Reload the service after saving" for stopped services, change it to "Start the service after saving settings" (with the checkbox _not_ ticked by default) - but I'm not sure if having a totally different label and checkbox default depending on the current status is a good idea or if it introduces confusion. (The problem with this approach is that we would need to change the label and the checkbox status when someone clicks "Start now" / "Stop now".)

...

I believe (or hope) it can be fixed with the proper labels, but I'm not creative enough.

So, who can help me with the labels of the widgets and the help messages? Here you are the ones in the current prototype: http://paste.opensuse.org/22250719

Looks good :-) Maybe a minor addition for the "Start service during boot" help text: ... to disable the service. _This only affects starting the service on boot, but_ does not affect the current status... Regards, Christian Boltz -- Ich springe so oft aus dem Fenster, daß ich ein schnurloses Telefon habe. [Ratti in suse-linux] -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

On 14.5.2015 16:54, Ancor Gonzalez Sosa wrote:

On 05/02/2015 11:38 AM, Christian Boltz wrote:

...

Oh, and don't forget to re-add the LDAP checkbox somewhere ;-)

My first option (already in the prototype) was adding a "LDAP Support" tab for it containing only the LDAP checkbox.

The tab looked quite empty and Josef suggested then to move the checkbox to some of the already existing tabs. So I did this[1]: http://paste.opensuse.org/80519760

I like how it looks now. It's a basic option.

Aesthetically it's quite ok. But I don't like it because I assume that "LDAP support active" affects all the settings, like forwarders, ACLs and all that. If that checkbox only affects to the so-called basic options, I'm fine. If not, I prefer the almost empty tab rather than this "beautiful" but wrongly grouped one.

Opinions?

In fact, LDAP support is only for resource records - zones, nothing else. So maybe it actually belongs to DNS Zones tab?

[1] By the way, I also swapped the order of the table and the add/modify frame. I dunno if we have a style guide about it, but to me it looks nicer and more intuitive with the table first and the form below.

Well, Add/Change are grouped by a frame and Delete is not? That actually looks strange. Our style guide says something else: Add/Delete/Change (or similar) below the table. Change opens up a pop-up with OK/Cancel buttons. Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader SLE Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org