[Please, no CCs to me. I read the list, therefore i must be subscribed.]
Circa 2002-Feb-15 18:18:04 -0800 dixit John Sullivan:
: I realized that there is another parameter to this ambiguity issue. If,
: in the menu, a menu item with an "unchecked checkbox" looks different
: than a standard command-type menu item, then Jim is right that
: checkbox-type menu items are unambiguously checked or unchecked.
:
: The problem is, this is a themeable appearance issue. In some themes
: (and on some platforms, like Macintosh), a "checkable but unchecked"
: menu item looks exactly the same as a "not checkable" menu item.
Then either the theme is broken or the theme is intended for an
audience experienced or intelligent enough to recognize toggle-able
menu items.
Generally, it is necessary to choose a toggleable menu item with an
attached checkbox no more than once (sometimes not at all, depending on
the item's initial state) to discover whether it's checked or not,
independent of whether the actual effect of toggling the menu item is
itself apparent.
In contrast, it's always necessary to choose a menu item with a
polymorphic label at least once to determine that it's a toggle, and it
could take more times if the user doesn't detect that the text has
changed. And if the actual effect of the toggle isn't apparent, then
the ambiguity of "Does the menu label show the current state, or does
it describe the state arrived at by choosing it?" is still a problem.
Polymorphic menu items are simply harder to use and harder to read than
the equivalent menu item with a checkbox. The only situation in which
they are appropriate is when:
(1) The menu item toggles between exactly two states.
(2) Each label for the menu item unambiguously indicates the action
which would be taken when the menu item is chosen and cannot be
confused with a description of the current state.
(3) The effects of choosing the menu item are always immediately and
visibly apparent.
An example of such an acceptable polymorphic menu item might be an item
on a window's titlebar menu that toggles between 'Maximize' and
'Unmaximize', with an accompanying change in the state of the window.
In English, "maximize" (the action) is not easily confused with
"maximized" (the state) and thus fills criterion [2] (other languages
may contain ambiguity here and may not be able to fill this criterion;
that should be considered when designing the menu). Criterion [1] is
fulfilled (except perhaps for ultramodern window managers where there
are four potential states: unmaximized, maximized vertically, maximized
horizontally, and fully maximized; such window managers have other
troubles as well---for example, deciding whether maximizing
horizontally and vertically are orthogonal or not). Because a window
is maximized or unmaximized when the item is chosen, it also fills
criterion [3].
Showing hidden files, on the other hand, fills only criterion [1].
Criterion [2] is not fulfilled in English, since 'show hidden files'
could be a command ("please show hidden files") or a present tense
description of state ("i [the program] am showing hidden files").
Criterion [3] is also not fulfilled, since the window could be
displaying a directory where no hidden files exist.
--
jim knoble | jmknoble pobox com | http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
Attachment:
pgpJGE24S8BWF.pgp
Description: PGP signature