--===============1838355744==
Content-Type: multipart/signed;
  boundary="nextPart16863742.5Mht8TpDPp";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart16863742.5Mht8TpDPp
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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.=20

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

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

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

In JuK's case the menu entries make sense because they are describing actio=
ns=20
e.g. Hide Search Bar. If you wanted to use that with a checkbox then you=20
would have 'Search Bar' by itself and a checkbox. The disadvantage of this =
is=20
that you are not describing what is going to happen, or what it does i.e.=20
showing the search bar is an action. The disadvantage of the doing, verb me=
nu=20
approach is that you are changing the text (not always a good idea) and a=20
user can click on it and can possibly have no visual feedback whatsoever th=
at=20
anything has changed other than the changed menu text. People actually lear=
n=20
text for menu entries. If they look at it and the icon, menu entry and text=
=20
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), a=
nd=20
that change will have no immediate visual feedback for the user then use=20
check boxes - if they make sense. If you're performing an action on=20
something, like the application itself, and that action will have immediate=
=20
user feedback (e.g. search bar disappears) then use the verb option. That's=
=20
why check boxes make sense for actions in dialogues. However, with menu=20
entries (most of the time) visual feedback is nearly always the case so the=
=20
verb option is preferred. If you're changing state or performing an action=
=20
that doesn't have any immediate feedback then it is generally put in a=20
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=20
visual feedback that it is on (text might not be currently wrappable). This=
=20
makes sense there, but should it be in a configuration dialogue? Possibly, =
as=20
it should be configured on by default and configured along with the number =
of=20
characters. However, you may want to simply override it for one particular=
=20
e-mail ;). A lot of checkboxes in KMail also use 3D icons rather than=20
checkboxes, which is even more confusing. I'm not picking on KMail per se,=
=20
but it's just what I'm using at the moment.

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

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

Cheers,

David

--nextPart16863742.5Mht8TpDPp
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCSyxLT5O050VJ4KURAuV0AJkBNEgkZkW/cmtoW9keEOuSC/chgQCZAYgx
ueqCUpBEXYPlgn/5Y4ai45w=
=cf+D
-----END PGP SIGNATURE-----

--nextPart16863742.5Mht8TpDPp--

--===============1838355744==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1838355744==--