syntax versus semantics in UI
Hello, I have a general question if there exist solutions how to show semantics regarding user input via UI. I know how to show syntax regarding user input via UI, e.g.: - show several checkboxes for several binary (on/off) values which can be set "on" or "off" independent of each other - show radio buttons for several binary (on/off) values where only one of them can be "on" - show a list of predefined values if only this values are correct input - show a text input field for an arbitrary input value I don't know how to show semantics regarding user input via UI. 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? Simple real-world examples are: 1) Password input: A password is an arbitrary input value so that a text input field is shown in the UI. But the semantics is different if - a new password is to be set => case a) above - the system asks the user for his password => case b) above 2) Printer specific option settings: Specify the printing resolution versus specify the media size: Both values can be choosen from a list of possible values e.g. Resolution: 300dpi, 600dpi, 1200dpi (the supported resolutions of the printer driver) Media Size: A4, A5, Letter, Legal (the supported media sizes of the printer driver) The syntax is the same for resolution and media size but the semantics is different because - any choice of the resolution works => case a) above - only the media size which is actually in the printer works => case b) above You might think that this is no UX/UI problem at all because it is obvious for any normal user if the semantics is of type a) or b). This is true for my simple examples above but in general it isn't, see this snippet from a mail: --------------------------------------------------------------
Why did you acitvate the filtering when you want to set up a raw queue? Filtering is exactly the opposite of "raw". ... Reading this setting in the YAST module, I thought it was more a choice: do you want the filtering done on the server side or on the client side.
It is a choice but it is not a choice where you are free to select whatever you like - it is a choice where you must choose the right setting which works in your particular environment. -------------------------------------------------------------- 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. 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@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
On May 23, 07 10:52:44 +0200, Johannes Meixner wrote:
Hello,
I have a general question if there exist solutions how to show semantics regarding user input via UI.
I know how to show syntax regarding user input via UI, e.g.: - show several checkboxes for several binary (on/off) values which can be set "on" or "off" independent of each other - show radio buttons for several binary (on/off) values where only one of them can be "on" - show a list of predefined values if only this values are correct input - show a text input field for an arbitrary input value
I don't know how to show semantics regarding user input via UI. 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?
Simple real-world examples are:
1) Password input: A password is an arbitrary input value so that a text input field is shown in the UI. But the semantics is different if - a new password is to be set => case a) above - the system asks the user for his password => case b) above
Here semantics must be made clear from the context. E.g. "You are about to change the password for account foobar." vs. "To log in as foobar, please enter password."
2) Printer specific option settings: Specify the printing resolution versus specify the media size: Both values can be choosen from a list of possible values e.g. Resolution: 300dpi, 600dpi, 1200dpi (the supported resolutions of the printer driver) Media Size: A4, A5, Letter, Legal (the supported media sizes of the printer driver) The syntax is the same for resolution and media size but the semantics is different because - any choice of the resolution works => case a) above - only the media size which is actually in the printer works => case b) above
Technically, the semantic difference can be described in terms of consistency between internal model and real world: The system is in an inconsistent state, if e.g. Letter is chosen from the list while some other format (e.g. A4) is loaded in the tray. Choice of printer resolution does not affect consistency as the real-world will automatically addapt to the internal model. It must be made clear that the UI requests information about the real world, to update its internal model. "The printer did not inform Cups which paper size is loaded. - Choose the size if you know what is loaded. - [Klick here] to print a test page indicating the sizes. - If the wrong size is chosen here, your page may not fit on the page, or the printer may ask for different paper before printing."
You might think that this is no UX/UI problem at all because it is obvious for any normal user if the semantics is of type a) or b).
In the printer example, we already have a negative user expirence when the UI has to ask the user details about the system. One would assume that the system tells the user which paper is loaded, not vice versa. So, I agree with you, it is most definitly a user experience issue. Although the classic usability guidelines cannot do much about it. I could think of technical solutions, to detect and catch any inconsistencies at a different point in time.
This is true for my simple examples above but in general it isn't, see this snippet from a mail: --------------------------------------------------------------
Why did you acitvate the filtering when you want to set up a raw queue? Filtering is exactly the opposite of "raw". ... Reading this setting in the YAST module, I thought it was more a choice: do you want the filtering done on the server side or on the client side.
It is a choice but it is not a choice where you are free to select whatever you like - it is a choice where you must choose the right setting which works in your particular environment. --------------------------------------------------------------
In this case, the user misunderstood the dialog. He thought he could make a free choice, but, the system was asking to provide information it could not autmatically detect. It is best to keep in mind the different worlds that we have to deal here. I) User's view of the world. II) System model in software. III) Real Hardware World. These worlds are sometimes poorly connected to each other. cheers, Jw. -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de wide open suse_/ _---|____________\/ \ | 0911 74053-508 (tm)__/ (____/ /\ (/) | __________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) "Oral agreements are worth about as much as the paper they are written on." -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
Hello, On May 23 16:58 Juergen Weigert wrote (shortened):
Here semantics must be made clear from the context. E.g. "You are about to change the password for account foobar." vs. "To log in as foobar, please enter password." ... "The printer did not inform Cups which paper size is loaded. - Choose the size if you know what is loaded. - [Klick here] to print a test page indicating the sizes. - If the wrong size is chosen here, your page may not fit on the page, or the printer may ask for different paper before printing."
I fully agree with explanatory texts in the dialogs. Unfortunately (up to now) my experience with user experience experts is that the texts in the dialogs must be very short. 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@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
On May 23, 07 17:18:47 +0200, Johannes Meixner wrote:
I fully agree with explanatory texts in the dialogs.
Unfortunately (up to now) my experience with user experience experts is that the texts in the dialogs must be very short.
I humbly disagree. Brevity is important for a most streamlined workflow. Yes. 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. IANAL - IANAUE :-) cheers, Jw. -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de wide open suse_/ _---|____________\/ \ | 0911 74053-508 (tm)__/ (____/ /\ (/) | __________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) "Oral agreements are worth about as much as the paper they are written on." -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
Hello, On May 23 19:24 Juergen Weigert wrote (shortened):
IANAUE
I am looking forward to a comment from a user experience expert. 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@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
Hi, thanks for kicking my butt, Johannes :-) I am sorry, but I find it rather difficult to keep up with my participation on the UX-list in these days which were quite busy. But I don`t write this email for complaining, so I will just participate in this discussion: I don't know how to show semantics regarding user input via UI. 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 [ ] 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 might think that this is no UX/UI problem at all because it is obvious for any normal user if the semantics is of type a) or b).
No, I also think, that it is an UX/UI problem. And I find it an interesting challenge :-)
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. But maybe anybody else has some good ideas about that?
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) Am 23.05.2007, 19:24 Uhr, schrieb Juergen Weigert <jw@suse.de>:
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 :-) Enjoy, 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. SUSE® Linux Enterprise 10 Your Linux is ready http://www.novell.com/linux -- To unsubscribe, e-mail: opensuse-ux+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
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@suse.de>:
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@opensuse.org For additional commands, e-mail: opensuse-ux+help@opensuse.org
participants (3)
-
Johannes Meixner -
Juergen Weigert -
Martin Schmidkunz