Martin Schmidkunz write:

Hi!

Thanks for all your comments!

Concerning hide/show behaviour: There is already a basic overview concept created by Robert Lihm (gagarin.suse.de): On hover the basic actions (edit/delete) are shown and then executed on click. I didn`t use this mock up because it was too complex for my skills (e.g. it used three different style sheets) I will add it to the style guide in the next days.

@Josef, Bubli: after experiencing Robert`s mock up, what are your impressions now?

Robert mock is better. Why? Because mouse over just show actions. Problem of your mock is that after mouse over page start changing, moving etc. And it is stressing ( because it looks like "action" ) because you just move mouse over. So I think that in general mouse over is good for hide/show which doesn't move anything on screen. If you need to show more details etc I prefer click to show and click to hide.

Concerning the term "repository": OK, let`s stick with it (although my stomach aches a little bit, but at least we are consistent with other Novell products and avoid another major time consuming discussion)

Explaining "Priorities": An icon would be one solution, but it would break with the rest of the current webYaST concept. The other idea would be to add a simple line of text like "If packages are available in more repositories, the one with the highest priority will be preferred." in a smaller font below the term "Priority".

Spinbox: Spinbox would be a good idea nonetheless I suggest to give the user a hint about min/max values and meaning of values (0 highest, 99 lowest)

Maybe so big range is confusing for target customer...maybe we should reduce options to small subset like always preferred (0), prefered (25), default (50), use when better is not present (75), latest chance (99). And I think we should use names for states, because number doesn't say behavior of that number. If you have priority and names for priority states you can easy understand. Numbers is good when you want exact data and it is important like age or date of birth. I think target user need maximum five states (but I think that 3 should be also enough). And if you still want to use numbers I prefer slider over spinbox especially if we have range.

Enable/disable: Why not use a check box? The reason is that check box has a relative small target hit area compared to a button. Secondly combined with explanatory status text a labelled button seem to be more easy to understand.

"Keep downloaded packages" Is this really something for the GUI? Compared with the settings level in other module this seems quite complex to me.

agree. And if we still want to use it I think better name is one which say why user should enable this checkbox like "Save bandwitch for reinstalling from this repo"

Josef

Cu,

Martin

* Ladislav Slezak lslezak@suse.cz [Feb 22. 2010 15:37]:

Or (IHMO better way) the exact number can be completely hidden.

This is definitely the preferred solution.

Repo priority is always a relative criteria, absolute numbers have no meaning.

Ideally, there would be a 'sort by priority' view combined with e.g. drag-and-drop to move repositories up and down.

Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)

No, the current webYaST concept means that icons should be handled with care. One idea for a style guide text would be: "Do not use just an icon to display an action as icons are often perceived in a different way by different users. That means that just displaying an icon makes it more difficult for the user to get the meaning of an action. To avoid confusion and ease the use of webYaST always use an icon and some explanatory text." [http://en.opensuse.org/YaST/Web/Docu/Style_Guide/Generic_Layout]

Concerning help: Currently there is no explicit "help" concept in webYaST. One reason is that usability studies showed that users often find "Help" quite unhelpful and the other reason is that it is our aim to create an UI which is so simple and self-explanatory that "Help" becomes superflous. If you want to give the user detailled information about a setting use either prefilled input fields or a short explanatory text below the settings label. Do not use "help" icons, pop ups or similar stuff. These will breake the otherwise clear and easy webYaST layout and the ease of it`s user experience. Try to make the wording of a setting as easy and self-descriptive as possible.

[http://en.opensuse.org/YaST/Web/Help]

What do you think?

Cu,

Martin

On 22.02.2010, at 16:44, Katarina Machalkova wrote:

...

Explaining "Priorities": An icon would be one solution, but it would break with the rest of the current webYaST concept.

Shall I read it as "current webYaST concept doesn't allow icons"? Where is this defined?

fB.

\\\ Katarina Machalkova \\\__o YaST developer __\\\'/_ & hedgehog painter

---------------------------------------------------------------- Martin Schmidkunz User Experience Specialist martin.schmidkunz@novell.com +49 (0) 911 740 53-346 ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -----------------------------------------------------------------

Novell, Inc. Novell® Making IT Work As One™

*lol* E.g. "Help" in assistants is skipped in the GNOME human interface guidelines (http://library.gnome.org/devel/hig-book/stable/windows-assistant.html.de ) and "always help" is skipped in the Windows Guidlines as well. So I guess it makes sense to use common sense: "Use help where it is appropriate." Which means, Johannes, you were 100% right with your request :-)

However for webYaST our aim is different: here we want to allow the user to make some basic settings and this can be done so simple that a detailed help is not needed.

Cu,

Martin

---------------------------------------------------------------- Martin Schmidkunz User Experience Specialist martin.schmidkunz@novell.com +49 (0) 911 740 53-346 ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -----------------------------------------------------------------

Novell, Inc. Novell® Making IT Work As One™

On Tuesday 23 of February 2010 15:05:07 Katarina Machalkova wrote:

...

Concerning help: Currently there is no explicit "help" concept in webYaST. One reason is that usability studies

Which usability studies? [citation needed]

...

showed that users often find "Help" quite unhelpful

But that's not the fault of the users! Why should the users be punished for the fact that hackers are unable to write proper help by being given no help at all?

There is nothing wrong with the effort to create UI that is simple and self- explanatory. But - there are concepts you can't do away with and yet you can't make them self-explanatory no matter how hard you try.

I'm not sure how solution should look like, but here I agree with Katarina. The fact that some help texts are bad does not mean the concept of help is useless in general. And even with most self-explanatory UI we are able to make, we'll run into problems some times. Example: webyast administrator, where UI itself can't explain which 'administrator' is being configured.

j

Bullseye! Katarina is absolutely on target. Traditional yast help consists of texts like "Press the Apply button to perform the changes." No kidding, such UI descriptions are absolutely unnecessary.

A big reason for why in the GTK plugin I chose to get rid of the side help-bar (remember that?) and "hide" the help text into its own button (which now all the UIs do) was the unhelpfulness of the help texts.

A help button that pops up the appropriate manual section however, detailing the use cases and explaining some technical details about the FTP server that opensuse ships with, and others is absolutely welcome.

Tooltips might be useful here and there too (like in the users tool to say that only alphanumeric characters may be used for the user name), but I would try not to over-do those and implement it another way when possible (they're annoying because you feel you must press them in order to avoid any mis-step).

Cheers, Ricardo

Ter, 2010-02-23 às 15:05 +0100, Katarina Machalkova escreveu:

...

Concerning help: Currently there is no explicit "help" concept in webYaST. One reason is that usability studies

Which usability studies? [citation needed]

...

showed that users often find "Help" quite unhelpful

But that's not the fault of the users! Why should the users be punished for the fact that hackers are unable to write proper help by being given no help at all?

...

and the other reason is that it is our aim to create an UI which is so simple and self-explanatory that "Help" becomes superflous.

There is nothing wrong with the effort to create UI that is simple and self- explanatory. But - there are concepts you can't do away with and yet you can't make them self-explanatory no matter how hard you try.

Taking the recent 'wontfix-ed' example - what if I don't know what a DNS server is? Do I have to open a separate tab in browser and google for it? Shouldn't the application/website I'm using provide me with all the information I need instead?

...

If you want to give the user detailled information about a setting use either prefilled input fields or a short explanatory text below the settings label.

"detailed information" and "short explanatory text" contradict each other. You either have detailed info and your text is no longer short, or the text is short and the info is not detailed anymore.

LiveJournal (a popular blogging site) uses '?' icons adjacent to the form fields which are not self-explanatory. Our very own SLMS web frontend does the same (LJ icons link to FAQ which then open in separate window, SLMS shows the explanation in icon tooltip).

Not only those two concepts show the help when the user wants to be helped, but it looks somehow pretty as well.

But obviously, my concept of "pretty", "cool" and "helpful" is entirely different from those of the rest of the (normal) world

sB.

Hello,

On Feb 23 15:05 Katarina Machalkova wrote (shortened):

...

There is nothing wrong with the effort to create UI that is simple and self- explanatory. But - there are concepts you can't do away with and yet you can't make them self-explanatory no matter how hard you try.

Taking the recent 'wontfix-ed' example - what if I don't know what a DNS server is?

I don't know what "the recent 'wontfix-ed' example" is.

Sorry, forgot to link the reference[1], assuming that everyone knows what I'm talking about ;-) This was about bug #580938, which complains that "DNS tab of network configuration is too technical"

i.e. I was not referring to configuration of bind, dnsmasq & friends, but to the dialog that configures 'nameserver' entries in one's /etc/resolv.conf. Quite essential piece of configuration, if one doesn't use DHCP that would distribute this info.

Without some helpful hints that would explain the terms (what nameserver are, what search domains are, why do I need them, can keep these fields blank) there's hardly some way to make this very page "less technical".

fB.

[1] http://bugzilla.novell.com/show_bug.cgi?id=580938

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Dne 23.2.2010 17:30, Johannes Meixner napsal(a):

Hello,

On Feb 23 16:41 Katarina Machalkova wrote (shortened):

...

This was about bug #580938, which complains that "DNS tab of network configuration is too technical"

i.e. I was not referring to configuration of bind, dnsmasq & friends, but to the dialog that configures 'nameserver' entries in one's /etc/resolv.conf.

A perfect example for my previous mail.

I fully agree that "DNS" is too technical for this setup task (i.e. a normal end-user wants to set up his workstation in a DHCP-less network).

On the one hand the "ultimate goal" is that network setup on an end-user workstation works without help text.

Fully-understandable and self-explanatory UI is the goal. But sometimes, there are situations where adding more information will only confuse the great self-explanatory UI...

On the other hand "ultimate changes everywhere" are needed to get there - here in particular changes in Mac OS and Windows which use the same technical term and thereby define a word which is actually meaningless for most normal end-users but they must have learned like a performing animal to react appropriately when they spot this word on the screen.

...and that's why we have to be prepared for those cases where UI just cannot be self-explanatory. Of course, if users read the help text assigned to one/some of the not-exactly-100%-self-explanatory widget, they will have to remember it and probably not use it again, so having that piece of information on the screen is not needed anymore.

Having a help text is a fallback, but we definitely need this fallback to be defined as we can never 100% guarantee that there will never be such a case when it is needed. Of course, we have to invest more time into defining self-explanatory UI.

Bye Lukas

Thanks for the example, Karl. I agree with you, that "enable" in every option is an overkill. Nonetheless from a usability perspective I think it is necessary to show the user the current status additionally.

Cu,

Martin

On 26.02.2010, at 09:07, Karl Eichwalder wrote:

"Martin Schmidkunz" Martin.Schmidkunz@gmx.de writes:

...

The results show that it is more usable for webYaST to provide additional text providing the current status of a setting.

This reminds me. YaST dialogs are often rather chatty. For example, the word "Enable" in option labels is superfluous. Instead of

[ ] Enable Hot Sunny Weather

you better simply say:

[ ] Hot Sunny Weather

IMO, that especially true, if the title of such an option list comes with a group title featuring the "Enable" word, too:

Enable Fine Weather

[ ] Hot Sunny Weather [ ] With Wind Now and Then etc.

"Enable" in the group title might be ok, but repeating it with every option is overkill.

-- Karl Eichwalder R&D / Documentation

SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org

---------------------------------------------------------------- Martin Schmidkunz User Experience Specialist martin.schmidkunz@novell.com +49 (0) 911 740 53-346 ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -----------------------------------------------------------------

Novell, Inc. Novell® Making IT Work As One™