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

[Matthew Paul Thomas <mpt myrealbox com>]

Hi Kalle

Thanks for your comments.

Kalle Vahlman wrote on 28/07/08 10:19:
>...
>>    == 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,

Could you elaborate? Do you think that grids of checkboxes are so rare
that they don't need guidelines, perhaps? Nautilus's Properties window
had a grid of checkboxes for permissions until recently. While it
probably wasn't the best possible design, it wasn't awful, and in other
situations it may not be practical to simplify a grid like that the way
it was simplified in Nautilus.

If I dropped the parenthetical exception, I'd also need to drop the
"always" to make it accurate, and that would make the guideline weaker.

>                                                           and the
> latter one shouldn't have them...

Fair enough. Fixed.

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

Do you mean that the sentence should be there but not in parenthesis, or
that it shouldn't be there at all? I think it's quite a reliable list;
try it on a random Gnome application and see. ;-)

>> 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?

No, I'm not going that far. By "more often than usual" I mean that it is
more likely that a boolean option should be presented as radio buttons,
if it is inside an assistant, *than* if it is inside some other type of
window.

"Usually" would mean that for a boolean option presented inside an
assistant, it is considerably more likely that its ideal presentation is
as radio buttons *than* as checkboxes. I don't think that's true, or at
least not true enough to be useful as a guideline.

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

True. And though I didn't look at it at all while writing the
guidelines, Firefox is also littered with bad examples of many of the
others: checkbox labels that end in periods (e.g. Edit > Preferences >
Security > Settings), grouped checkboxes whose labels could be shortened
using an intro label (e.g. Edit > Preferences > Security), checkboxes
that start with "Always" and therefore have ambiguous off states (e.g.
"Always show the tab bar" vs. "Show the tab bar only on Friday nights"),
and checkboxes that start with "Use" and therefore expose jargon for no
apparent benefit (e.g. "Use SSL 3.0", "Use TLS"). None of these are huge
problems, they're just not as understandable as they could be.

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

Where do you see it explained later? This is different from the checkbox
group labels discussed later. The example for this is:

    [/] Play a sound when a message arrives: [Quack    :^]

An example for checkbox group labels might be (though using this example
in the HIGs would be impolitic):

    Warn me if the site I’m visiting is:
    [/] A suspected attack site
    [/] A suspected forgery

This will be more obvious once I add the illustrations. :-)

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

Yeah, it's a bit clumsy. Can you think of any clearer way to express it?
I want to distinguish this case from the case where a label consists
only of a noun or adjective phrase. For example, someone implementing a
Find window shouldn't feel they need to change the non-clause "[ ] Exact
case" to the imperative clause "[ ] Find strings with the same exact
case" or something silly like that.

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

Ok, done.

> 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)

I doubt that's true often enough, or done wrongly often enough, to be
useful as a guideline.

An example of where it wouldn't be true would be in an e-mail program
that finally eliminated the desire for mailing list Reply-To munging.
Whereas in other e-mail programs "Reply to Sender" and "Reply to All"
are toolbar buttons in the main window, in this e-mail program "Reply to
Sender" and "Reply to List" would be checkboxes in the composition
window. So whereas other e-mail programs force you into a decision about
who the reply is best suited for before you've even started writing it
(making it possible but quite difficult to change your mind later), this
e-mail program would give you the entire period of writing the message
to make up your mind.

When you checked or unchecked either of these checkboxes, the e-mail
program would adjust the contents of the To: field accordingly (and vice
versa). That would be a perfectly appropriate example of a checkbox
changing the value of another control.

I recognize that's a theoretical example, though. Do you know of any
real examples in Gnome (past or present) where toggling a checkbox has
*wrongly* changed the value of another control?

>  - Access keys
> 
> Any particular reason for dropping those or just an overlook?

The "Keyboard interaction" chapter already says that "All controls with
labels should have access keys". I don't see any reason that this should
be repeated specially for checkboxes.

Thanks
-- 
Matthew Paul Thomas
http://mpt.net.nz/

---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---