[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Show/Hide vs Checkbox
From:       Segedunum <segedunum () actuaria ! co ! uk>
Date:       2005-03-30 22:46:26
Message-ID: 200503302346.35776.segedunum () actuaria ! co ! uk
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wed, 30 Mar 2005 01:18:49, Tim Hutt wrote:
> Just a quick note to say that using menu items that change from (for
> example) 'Show Offline Users' to 'Hide Offline Users' is a poor design. 

Poof. Minefield alert! You have to be a bit careful with this, and there's no 
easy answer.

> Bad examples of this are: Kopete->Settings->First 5 options And:
> Juk->View->First 3 options. 

As others have pointed out, this is down to whether you want to show state or 
an action. I personally don't have anything against checkboxes in menus as it 
can be a valuable indication that something has been selected. It's a 
question of what is what.

In JuK's case the menu entries make sense because they are describing actions 
e.g. Hide Search Bar. If you wanted to use that with a checkbox then you 
would have 'Search Bar' by itself and a checkbox. The disadvantage of this is 
that you are not describing what is going to happen, or what it does i.e. 
showing the search bar is an action. The disadvantage of the doing, verb menu 
approach is that you are changing the text (not always a good idea) and a 
user can click on it and can possibly have no visual feedback whatsoever that 
anything has changed other than the changed menu text. People actually learn 
text for menu entries. If they look at it and the icon, menu entry and text 
look the same apart from one word then they'll think it's the same.

If you're changing the state of the application (or inferring an action), and 
that change will have no immediate visual feedback for the user then use 
check boxes - if they make sense. If you're performing an action on 
something, like the application itself, and that action will have immediate 
user feedback (e.g. search bar disappears) then use the verb option. That's 
why check boxes make sense for actions in dialogues. However, with menu 
entries (most of the time) visual feedback is nearly always the case so the 
verb option is preferred. If you're changing state or performing an action 
that doesn't have any immediate feedback then it is generally put in a 
configuration dialogue somewhere or it's a toggle button on the toolbar.

Wordwrap is a checkbox option in KMail on the Options menu, with sometimes no 
visual feedback that it is on (text might not be currently wrappable). This 
makes sense there, but should it be in a configuration dialogue? Possibly, as 
it should be configured on by default and configured along with the number of 
characters. However, you may want to simply override it for one particular 
e-mail ;). A lot of checkboxes in KMail also use 3D icons rather than 
checkboxes, which is even more confusing. I'm not picking on KMail per se, 
but it's just what I'm using at the moment.

Oh, and another thing. The checkbox in KDE with Plastik (might be different 
for different themes though) is a cross and not a check. This is bad as a 
cross can sometimes be inferred that something is wrong. Doesn't feel 
natural.

I find all this fascinating to be honest, as there's no easy answer. If Apple 
are taking the action route, what do their UI guidelines say?

Cheers,

David

[Attachment #5 (application/pgp-signature)]

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability


[prev in list] [next in list] [prev in thread] [next in thread]