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

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

2008/7/29 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?

That, and the fact that there is no further mention about grids of checkboxes
later in the guide. So I think it's better to either drop it
completely (as they _are_
a very special use case) or to explain further how the labels should be arranged
in that case. Now it just leaves the reader wondering.

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

That's true.

Perhaps the two special cases should be mentioned together? Like so:

"A checkbox should always have a label, and the label should always
 be to the right of the checkbox itself. Exceptions to this are checkboxes
 in a multi-column listbox, where one column may contain the labels for
 checkboxes in previous columns, and grids of checkboxes where the
 labels are common for whole rows and columns."

though I guess they still are "to the right" if they are in the next colum
so it's not really an exception... The problem for me was the "dangling"
mention of the grids without explanation of what it would be useful for
and how it should be handled, that's all..

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

I'm wary of banning specific words, specially very common words like "all".
For example,

"[ ] Apply foo to all selected bars"

in a dialog with selectable items is very obvious (although you could just
drop the "all" there of course).

At least the parenthesis should be removed here too, if not the whole
sentence ;)

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

Ah right, I read the sentence to mean the latter case. Maybe replace
"usual" with "in other contexes" or "other type of windows" to make
the meaning more obvious?

>>>    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:
[snip example]

I stand corrected.

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

Indeed :)

>>> 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.
[snip example]
> 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?

Right, now that I thought it a bit further checkboxes *should* change values
of other controls if the option they toggle limits the range of valid values
to some other control...

The sensitivity part I'd like to see though, since the statement

  "Don't perform any action *other than* toggling the state"

seems to me like ruling out effects to other controls. I suppose it is
self-evident
that the option (and its effects on other contols) the checkbox controls should
also be applied in an instant-apply situation, but still..

Maybe "Don't perform any action *other than* toggling the state and applying
the option if the option is instant-applyable" or something...

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

Right, sorry for not checking since I thought this might be the case...

Anyway, nice work! :)

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