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

[Matthew Paul Thomas <mpt myrealbox com>]

Kalle Vahlman wrote on 30/07/08 13:39:
> 
> 2008/7/29 Matthew Paul Thomas <mpt myrealbox com>:
>...
>> Kalle Vahlman wrote on 28/07/08 10:19:
>...
>>>>    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.

Fair enough. Rewritten as:

    A checkbox should always have a label, and the label should
    always be to the right of the checkbox itself. The only
    exception is a multi-row grid of checkboxes, where each row and
    column should have a label but the individual checkboxes should
    not. In a multi-column listbox, text in one column may function
    as the label for a checkbox in a previous column.

>...
>>>>    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.)
>...
> I'm wary of banning specific words, specially very common words like
> "all". For example,

I'm not *banning* words. "Probably isn't obvious" is merely a gentle
shove. :-)

> "[ ] 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).

Do you have a real example of this? It's hard to tell whether your
artificial example would be obvious, because I don't know what "foo" and
"bars" are.

I've just gone looking through the applications I have installed at the
moment, and these are the first three examples I've found of checkboxes
using the word "all".

1.  Inkscape's "Export Bitmap" window has a checkbox:

        [ ] Hide all except selected

    This would be clearer as a pair of radio buttons:

        Show: (*) Whole image  ( ) Selection only

2.  Blam's "Preferences" window has a checkbox:

        [/] Automatically refresh all channels every [__15] minute

    This would be clearer as a pair of radio buttons:

        Update channels: (*) Every [__15] minutes  ( ) Manually

3.  AbiWord's "Preferences" window has a checkbox:

        [/] Automatically load all plugins found

    I have no idea what happens when I uncheck it, or why I'd want to.
    Again, radio buttons would make this more understandable.

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

I think it's important enough to include, but not important enough to be
outside parentheses.

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

Ok. Changed "more often than usual" to "more often than elsewhere".

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

Actually since my previous message, I've come across two problems of
this type in Gnome:

*   Until recently, the "Layouts" tab of the "Keyboard Preferences"
    window used checkboxes for selecting the default layout. Checking
    one checkbox unchecked the previous one. It should have used, and
    now does use, radio buttons instead.

*   In Gnumeric's "Format Cells" dialog, checking the "Superscript"
    checkbox unchecks the "Subscript" checkbox if it is checked, and
    vice versa.

The latter example is interesting, because it's copying the behavior of
the equivalent dialog in Microsoft Excel (and other Microsoft Office
applications). The Windows Vista UX guidelines allow this behavior
explicitly <http://msdn.microsoft.com/en-us/library/aa511452.aspx>:

    Correct:

    Effects  ------------------------------------------
     (*) No strikethrough       (*) No effect
     ( ) Strikethrough          ( ) Shadow or outline
     ( ) Double strikethrough       : : Shadow
                                    : : Outline
     (*) No super or subscript  ( ) Emboss
     ( ) Superscript            ( ) Engrave
     ( ) Subscript

    In this example, the use of radio buttons is accurate, but
    creates unnecessary complexity.

    Better:

    Effects  ------------------------------------------
     [/] Strikethrough         [ ] Shadow
     [ ] Double strikethrough  [ ] Outline
     [ ] Superscript           [ ] Emboss
     [ ] Subscript             [ ] Engrave

    In this example, the use of check boxes is simpler and allows
    users to focus on selecting the desired options instead of on
    their complex relationship.

    *Important: Apply this guideline only in extremely rare
    circumstances*, when showing the dependencies adds significant
    complexity without adding clarity. In the previous example, it
    is unlikely that users would attempt to choose both superscript
    and subscript, and if they did, it would be easy to understand
    that they were exclusive options.

Microsoft might have had a point here, except that they're making the
first example artificially complex. The same set of constraints could
more simply be presented like this:

      Position:         Strikethrough:
      (*) Normal        (*) None
      ( ) Superscript   ( ) Single
      ( ) Subscript     ( ) Double
                      __________________
    Special effects: [None            :^]

where the "Special effects" menu would include "Emboss", "Engrave",
"Outline", "Shadow", and "Outline and Shadow" options.

That's what I meant in my original message by "The Windows Vista
guidelines ... [making] unwarranted special exceptions for poor
uses of checkboxes ... in Microsoft Office". I don't think it's a common
enough problem to include a specific "don't do what Microsoft says here"
warning, though, since Microsoft Office and Gnumeric are the only
programs I've ever seen with this design. (Even Openoffice.org manages
without such checkbox chicanery.)

Instead, however, I've addded a simple warning that checkboxes shouldn't
be mutually exclusive. That would cover both the former problem in
Keyboard Preferences and the current problem in Gnumeric, and it would
do this more obviously than a vague guideline about checkboxes not
"affect[ing] the values of any other controls".

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

Yep, that too. Another example is an "Automatic" checkbox next to a
slider for volume, brightness, zoom level, etc: checking it should make
the slider insensitive, *and* change the slider's value to convey what
the automatically chosen setting is.

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

Changed to:

    Clicking a checkbox, or its label, toggles its state. Changing
    its state may also change the sensitivity, and occasionally the
    value, of other controls.

    Don’t make checkboxes mutually exclusive. Represent mutually
    exclusive options using radio buttons or an option menu
    instead.

    Don’t open a dialog when a checkbox is checked. If a checkbox
    turns on something that demands further configuration, and it
    is not possible for that configuration to have a sensible
    default, instead of a checkbox use a button to open a dialog
    for configuring and confirming the function.

>...
> Anyway, nice work! :)

Thanks! And thanks again for your feedback.

I'll include an updated patch in replying to Calum.

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

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