Re: [Usability] RFC: Revision of HIGs "Check Boxes" section

["Kalle Vahlman" <kalle vahlman gmail com>]

2008/7/26 Matthew Paul Thomas <mpt myrealbox com>:
> Hi Calum (and everyone)

Hi!

Some comments below...

[...]
> So for the purpose of discussion on the mailing list, here's my proposed
> revision in plain text.
>
>    = Checkboxes =
>
>    A checkbox is used to control something that can obviously be on
>    or off.
>
>    == Text ==
>
>    A checkbox should always have a label, and (except in the rare
>    case of a grid of checkboxes) the label should always be to the
>    right of the checkbox itself. (In a multi-column listbox, one
>    column may contain the labels for checkboxes in previous
>    columns.)

I don't think the first text in parenthesis is necessary, and the latter
one shouldn't have them...

>    A checkbox label should convey the effect the checkbox has when
>    checked. The effect of the unchecked state should be obvious
>    without any extra text. (If the label contains the word "all",
>    "always", "default", or "only", the unchecked state probably
>    *isn't* obvious.)

This one in parenthesis could go too IMO.

> If it cannot be made obvious by rewording the
>    label, use a pair of radio buttons instead. When deciding this,
>    consider the target audience and situation. For example, in an
>    assistant a pair of radio buttons will be better than a
>    checkbox more often than usual, since people will often be
>    unfamiliar with the choices being offered.

"more often than usual"? You mean "usually", right?

>    The checked state of a checkbox should be understandable as
>    something positive. Never use a checkbox label beginning "Don't"
>    or "Do not", and avoid using a checkbox label beginning "Hide",
>    "Ignore", or similar. Try reversing the effect of the checkbox
>    so the label can be positive.
>
>        Windows Vista guidelines offer "Don't show this message
>        again" as an example of a correctly labelled checkbox.
>        Don't use a checkbox like this in Gnome software,
>        because it would have a negatively-worded label, because
>        it would not be obvious how to turn the message back on
>        later, and because it suggests the message was annoying
>        in the first place. Instead, if a message is truly
>        necessary, present it unobtrusively enough that it
>        doesn't need to be optional.

As a data point, Firefox is littered with these too.

>    Don't begin a checkbox label with "Enable", and be careful if
>    beginning it with "Use". Labels like this are usually
>    unnecessarily indirect, and often introduce a jargon term that
>    people shouldn't need to know. If practical, reword the label
>    to convey what the checked state actually achieves. Don't use a
>    checkbox merely to advertise a feature that should always be
>    turned on anyway.
>
>    A checkbox label should use sentence case, but should not end in
>    a period. (It may end in a colon, if it doubles as the label for
>    a dependent control whose label normally ends in a colon.)

As this special case is explained later, it is probably not needed here...

> The
>    label should be no longer than about ten words, and should not
>    wrap to multiple lines at typical window sizes. If the label is
>    a complete clause, express it as a command (imperative) rather
>    than a description (indicative). For example, not "Sound plays
>    when a message arrives" but instead "Play a sound when a message
>    arrives".

The term "complete clause" is a bit foreign to a non-native speaker
like me. I don't know what would be better here though. The example
is good enough to make the intent clear in any case...

>    Avoid including an explanation or advice inside a checkbox
>    label, and don't give a checkbox a tooltip. If extra information
>    is necessary, present it as a sentence in a smaller font (not in
>    italics) aligned underneath the label. (This time the indicative
>    form is appropriate, with the checkbox as the implied subject.)

Useful note, so lose the parenthesis.

Some useful pointers seem to have been dropped, without reason to my eye:

 - The relation to other controls (no value changes, but can toggle
sensitivity/visibility)
 - Access keys

Any particular reason for dropping those or just an overlook?

-- 
Kalle Vahlman, zuh iki fi
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi