Mailinglist Archive: opensuse-ux (89 mails)

[Johannes Meixner <jsmeix@xxxxxxx>]

Hello,

sorry, a very long answer:

On May 24 22:27 Martin Schmidkunz wrote (shortened):
> I don't know how to show semantics regarding user input via UI.

This is a perfectly valuable answer because it makes clear
that there is an issue which needs to be addressed.


> Example:
> a) for one kind of input values the user is free to choose
>   what he likes because any choice would work
> b) for other kind of input values the user is not free to choose
>   what he likes because only the right choice would work
> 
> 
> >Is there a solution how to show this kind of semantics regarding
> >user input via the UI?
> 
> An obvious method is to show the user an example of accepted input (e.g. like
> you have it on an online form where you have the entry field Birthday [
> ] and then in brackets (e.g. 04/24/1980).
> An other method would be to check in the code and show a pop-up or a warning
> when the user makes some sensless or faulty input.
> An other method would be to add some explanatory text (I know that you don`t
> like this answer, Johannes :-))
> For example in the case of the password you will be asked:
> Please set a password [         ]
> or
> Please enter you root password [         ]

It seems you mixed up syntax checks (show the user an example
of accepted input / show a pop-up when faulty input)
with user info about semantics (password example).

To make it 100% clear:

1) The currently usual terse password input dialog:
Password: [        ]

2) Password input only with snytax hint:
Password: [        ] (letters,numbers,and -_=.,;:)

3) Password input only with semantics hint:
3a) Set a new password: [        ] Repeat it: [        ]
3b) Enter your password: [        ]

4) Password input with snytax and semantics hints:
4a) Set a new password: [        ] (letters,numbers,and -_=.,;:)
             Repeat it: [        ] (to check that there is no typo)
4b) Enter your password: [        ] (letters,numbers,and -_=.,;:)

Note that "(to check that there is no typo)" is also a semantics hint.
I think it does not matter if "(...)" is a snytax or a semantics hint.
I think any user would understand that "(...)" is a hint and from
the content of the hint it is clear if it is about snytax or semantics.


I am perfectly happy with explanatory text directly where
the input has to be made (i.e. directly in the dialogs).
E.g. I would like to have it as in example 4a/b.

I am not happy with a design guideline to have only trese info
in the dialogs and move all "what is really interesting" to
help texts which are known that nobody reads them ;-)

Seriously: If an interesting info is only in the help text,
even experienced users may miss this interesting part and
therefore work based upon their own assumptions which leads
often to wrong settings if the stuff is not 100% trivial
and obvious (below there is an example).
Later, when it doesn't work, the user might re-try it and then
he might read the help text but then it is already too late
because the user's first try had failed.


> 2) Printer specific option settings:
> 
> Resolution: Combo box with values 300dpi, 600dpi, 1200dpi
> Media Size:
> Please choose your media size: Combo box [A4, A5, Letter, Legal]
> Note: If you choose a paper size that is not available in your
> printer, you prints will be faulty.

You really mean we poor programmers are allowed to show such a
useful text directly to the user directly in the dialog where
a particular option is set?
You mean that we are really allowed to show useful information
directly in the dialog as text so that the dialog can contain
more than only clickable but meaningless graphical stuff and
that users may have to read (caution: "reading involves thinking!")
something?
Unbelievable!
;-))


> >In the YaST printer config we have two checkboxes
> > [ ] Share Printer
> > [ ] Do Local Filtering
> >where the first one is of type a) but the second one is type b)
> >but there is nothing in the UI which indicates this difference
> >and this difference is no longer obvious to any normal user.
> 
> Again I would suggest some explanatory text.
> I know that this is not a creative answer, but I really thought some times
> about that issue, but I couldn`t figure out other solutions than those
> mentioned above.

I prefer very much a clean and simple solution "show explanatory
text" instead of an overengineered sohisticated creative thingy
(I cannot call the latter a "solution ;-)


> But maybe anybody else has some good ideas about that?

Of course if there is a clean and simple graphical UI solution...


> >On May 23, 07 17:18:47 +0200, Johannes Meixner wrote:
> > >Unfortunately (up to now) my experience with user experience
> > >experts is that the texts in the dialogs must be very short.
> 
> This is true for users which are very experienced.
> The lesser the user experience is, the more does he need some
> guidance (text, wizards, whatever)

No.
The above "Share Printer / Do Local Filtering" example went
wrong for a very experienced user.
We have good reasonable defaults for both settings.
The unexperienced user leaves them (hopefully) as they are
and this results for 90% a correct setting.
The experienced user needs some interesting hint here because
he thinks about the stuff and the longer he thinks the more
likely he comes to the idea that because of his experience
he should change the default which results for 90% an
incorrect setting ;-)

By the way:
Some time ago there was a usability test regarding printer
setup with YaST (set up a supported locally connected printer)
and all users were successful but the experienced users needed
longer (aka. "get lost in the various 'experts' sub-dialogs" ;-)
than the unexperienced users.


> Am 23.05.2007, 19:24 Uhr, schrieb Juergen Weigert <jw@xxxxxxx>:
> >But: If interfaces for two different tasks end up to be confusingly similar,
> >we are responsable for resolving such confusion. Breaking the usual 'design
> >rules' is among the options. I'd rather annoy the user with unexpected
> >dialog elements than let him go down a wrong road.
> 
> Please try any other solution first before breaking consistency :-)
> The programms like the YaST are already inconsistent enough.
> Which is actually one of the next items on our list :-)

I think one must very carefully distinguish what is meant with
consistency. 
I think consistency should mean that things which have the same
meaning (i.e. same semantics) should look the same on the UI.
But I think consistency should not force that for each piece of
software (e.g. for each YaST module) its particular UI should
look like the UI of all others.

I think currently we discuss much too much only regarding the
surface (e.g. make the look of all UIs the same or make the
look "nicer" - whatever this means) or regarding trivial things
like syntax.

I think we must discuss much more with the semantics in mind.

If some existing UI design from another piece of software
fits perfectly regarding the syntax but does not fit regarding
the semantics (i.e. regarding the meaning behind the scenes),
there must be a difference in the UI of both pieces of software
because otherwise a same UI design in both pieces of software
would mislead the poor user instead of helping him to see
that there is actually a difference.

If I remember correctly there is a perfect example regarding
such kind of bad syntax-only-oriented desing:

The password dialog when logging in into Windows 95/98:

If I remember correctly the dialog is always the same like:
  User: [        ]
  Password: [        ]

But if the user value doesn't exist on the system, a new user
is created with the password value as his new password.

>From the syntax point of view the UI is perfectly o.k. for both
cases but from the semantics point of view it is catastrophic
because the usual way when a new user is created is when there
is a typo when someone enters his user name and then he works
without any notification as a new user in a new environment
and runs into problems like "where are all my old files",
"why does my desktop icons are all gone", ...


By the way:

The syntax versus semantics stuff is perfectly implemented
for light switches versus fire alarm buttons.

It doesn't matter at all if a light switch is actually
an on/off switch or only a pushbutton which toggles
the lights on/off or if a fire alarm button is a real switch
or a pushbutton or whatever else it is - i.e. the syntax
it totally irrelevant here.

Only the semantics is of interest here:
Never ever have an obvious red frame around a light switch
but always have an obvious red frame around a fire alarm button.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex
-- 
To unsubscribe, e-mail: opensuse-ux+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-ux+help@xxxxxxxxxxxx