From kde-usability Wed Mar 30 18:25:18 2005 From: Diego Moya Date: Wed, 30 Mar 2005 18:25:18 +0000 To: kde-usability Subject: Re: Show/Hide vs Checkbox Message-Id: <11ee049405033010251d2d4d3c () mail ! gmail ! com> X-MARC-Message: https://marc.info/?l=kde-usability&m=111220715631242 On Wed, 30 Mar 2005 19:31:05 +0200, Wilco Greven 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