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.
- 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 firstname.lastname@example.org:
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