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

List:       kde-usability
Subject:    Re: Show/Hide vs Checkbox
From:       Diego Moya <turingt () gmail ! com>
Date:       2005-03-30 18:25:18
Message-ID: 11ee049405033010251d2d4d3c () mail ! gmail ! com
[Download RAW message or body]

On Wed, 30 Mar 2005 19:31:05 +0200, Wilco Greven <greven@kde.org> wrote:
> >
> > Now obviously the menu items don't change place, but it is much much easier
> > to find a constant text and see if the checkbox next to it is checked than
> > it is to read the first word (and Show and Hide look quite similar).
> 
> That's your opinion. I find the current way where the menu action says what's
> going to happen easier.
Are you sure the menu says what's going to happen? How do you know
whether the menu is showing the current state?

This is a frequent problem arising in buttons (and menu entries *are*
a kind of button).  A button that change its label according to state
is always a bad idea, because there is no way to tell whether the
label shows current state or pressing the button will change the state
to the one in the label.

Checkboxes where designed to solve this precise problem. See this page
to analyze the "forces" involved (the solution depends on the intended
meaning):
http://www.fast-consulting.com/GUI%20Design%20Handbook/gdhb_a2d.htm


> Two reasons against having toggle menu items which came out of that
> discussion are:
> - When an item is not checked, nothing indicates that it can be checked.
...unless you provide an empty box when it's not checked, like a
standard checkbox should do. Also the menu text describes the state
that you're going to have if you click on it.


We have two conflicting forces in this case. The first one is the
"toggle state" problem that I just stated. The other is that menu
entries should be actions, not show state. Neither of the proposed
solutions (checkbox, change label) satisfies both requirements.


> My opinion is that the current way of showing a toggle action is the best as
> long as the two problems above exist.

My preferred solution would be to have *both* actions listed, and grey
out the one that is not applicable. As in:

(when the bar is hidden):

-----------------------------------
 Show Search Bar
 .H.i.d.e. .S.e.a.r.c.h. .B.a.r.  <-- disabled
-----------------------------------

(and when the bar is seen):

-----------------------------------
.S.h.o.w. .S.e.a.r.c.h. .B.a.r.  <-- disabled
Hide Search Bar
-----------------------------------

This way
1) the user knows what's going to happen when clicking the menu item, 
2) the user knows that the other entry is disabled because of the current state,
3) and you have the extra benefit that the menu items are always the
same ones (avoiding the uncertainty of a changing interface. Remember
MS Office disappearing menus?)
_______________________________________________
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]