Over two years ago, on 10 May 2006 at 15:45, Calum Benson wrote:
On 10 May 2006, at 15:39, Matthew Paul Thomas wrote:
I'd like to revise this section to fix all these issues. Is that ok?
["These issues" are listed in
<http://mail.gnome.org/archives/usability/2006-May/msg00060.html>.]
These all sound fine to me. Some of them probably apply to (at
least)
the radio buttons section too, so feel free to fix those while you're
at it :)
...
So, I finally got around to doing this. :-) I got annoyed by advising
against the same mistakes repeatedly in Bugzilla and mailing lists, so
my revision concentrates heavily on those common mistakes and what
to do
instead. The Windows Vista guidelines also do this, but much more
verbosely, and they also make unwarranted special exceptions for poor
uses of checkboxes in Windows Vista and in Microsoft Office. (For this
reason, I include an explicit warning for the benefit of developers
who
may be coming from Windows.) The Apple HIGs aren't particularly useful
for checkboxes at all -- they contain few guidelines except for
layout.
My patch is incomplete, because it is missing illustrations. It is
also
rather noisy, because I have taken the opportunity to rename "check
box"
to "checkbox" throughout.
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.)
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.) 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.
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.
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.) 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”.
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.)
Even better, try shortening the explanation or advice enough
that it can be used as the label itself, replacing the existing
one.
If necessary, a group of related checkboxes may have an extra
label introducing them. This label should be in sentence case,
and end with a colon. Avoid repeating the first word in several
checkboxes in a group; instead, include this word in the label
for the group.
In help text or support materials, refer to a checkbox as a
“box” that someone may “check” or “clear”.
== Layout ==
Arrange a group of checkboxes in a single column, unless a
horizontal or multi-column arrangement suits the window much
better. If there is a label for the group as a whole, place it
either above the group, or to the left of the first checkbox,
depending on the layout of the rest of the window.
Avoid presenting more than about eight checkboxes as a single
group. If this is unavoidable, or if the number of checkboxes is
dynamic (for example, a list of plug-ins), present them in a
scrollable list box.
== Behavior ==
Clicking a checkbox, or its label, toggles its state. Don’t
perform any action *other than* toggling the state; for example,
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.
For example, a backup function might have “Backup is off.” text,
followed by a “Turn On Backup…” button that opens a secondary
dialog. Once the configuration is complete, the text might
change to summarize the configuration, and the single button
might be replaced by “Settings…” and “Turn Off Backup” buttons.
== Mixed-state checkboxes ==
When a checkbox represents a property that is turned on for some
parts of the current selection, but off for other parts, the
checkbox should appear in its mixed state. For example, where
multiple files are selected in Nautilus, an emblem that has been
applied only to some of the selected files is represented by a
mixed-state checkbox in the Properties window.
Clicking a mixed-state checkbox cycles between the mixed state,
the fully checked state, the unchecked state, and back to the
mixed state (restoring the original values), in that order.
Don’t use a mixed-state checkbox for any other purpose. For a
property that normally has three possible states, use three
radio buttons or an option menu instead.
If this revision is acceptable, please let me know what I need to do
to
generate a proper ChangeLog entry etc.
Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/
---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)---
Index: C/hig-ch-toolbars.xml
===================================================================
--- C/hig-ch-toolbars.xml (revision 551)
+++ C/hig-ch-toolbars.xml (working copy)
@@ -152,7 +152,7 @@
</listitem>
- <listitem><para>If your application has a single toolbar,
allow the user to turn it on or off with a
<menuchoice><guimenu>View</guimenu><guimenuitem>Toolbar</
guimenuitem></menuchoice> check box menu item.</para></listitem>
+ <listitem><para>If your application has a single toolbar,
allow the user to turn it on or off with a
<menuchoice><guimenu>View</guimenu><guimenuitem>Toolbar</
guimenuitem></menuchoice> checkbox menu item.</para></listitem>
<listitem><para>If your application has two or three toolbars,
allow the user to turn them on or off individually by placing a menu
item for each one on the application's <guimenu>View</guimenu>
menu. For example, <guimenuitem>Main Toolbar</guimenuitem>,
<guimenuitem>Drawing Toolbar</guimenuitem>, <guimenuitem>Formatting
Toolbar</guimenuitem>. Place the items together in a single group on
the menu, with <guimenuitem>Main Toolbar</guimenuitem> first (if
your application has one), followed by the others in alphabetical
order.</para></listitem>
Index: C/hig-ch-menus.xml
===================================================================
--- C/hig-ch-menus.xml (revision 551)
+++ C/hig-ch-menus.xml (working copy)
@@ -199,7 +199,7 @@
<listitem><para>Order items within a group logically,
numerically, in task order or by expected frequency of use, as
appropriate.</para></listitem>
- <listitem><para>Only place one type of menu item in each group
— <link linkend="menu-item-type-command">command</link>, <link
linkend="menu-item-type-mutable">mutable</link>, <link linkend="menu-
item-type-check">check box</link> or <link linkend="menu-item-type-
radio">radio button</link>. For example, do not place commands
(such as <menuchoice><guimenu>View</guimenu><guimenuitem>Reload</
guimenuitem></menuchoice>) and settings (such as.
<menuchoice><guimenu>View</guimenu><guimenuitem>Toolbar</
guimenuitem></menuchoice>) in the same group.</para></listitem>
+ <listitem><para>Only place one type of menu item in each group
— <link linkend="menu-item-type-command">command</link>, <link
linkend="menu-item-type-mutable">mutable</link>, <link linkend="menu-
item-type-check">checkbox</link> or <link linkend="menu-item-type-
radio">radio button</link>. For example, do not place commands
(such as <menuchoice><guimenu>View</guimenu><guimenuitem>Reload</
guimenuitem></menuchoice>) and settings (such as.
<menuchoice><guimenu>View</guimenu><guimenuitem>Toolbar</
guimenuitem></menuchoice>) in the same group.</para></listitem>
</itemizedlist>
</sect2>
@@ -247,27 +247,27 @@
<itemizedlist><title>Guidelines</title>
<listitem><para>If your mutable menu items are <link linkend="menu-
item-type-command">command items</link>, and you have sufficient
space on your menu, consider providing two adjacent menu items for
the commands instead. Then make the items sensitive or insensitive
as the situation demands. This also makes it easier for the user to
tell when different shortcuts are available for each of the
commands, for example <keycombo><keycap>Ctrl</keycap><keycap>R</
keycap></keycombo> for <guimenuitem>Reload</guimenuitem>, and
<keycap>Esc</keycap> for <guimenuitem>Stop</guimenuitem>.</para></
listitem>
- <listitem><para>Do not use mutable menu items to toggle a two-
state setting (for example, <guimenuitem>Show Toolbar</guimenuitem>
and <guimenuitem>Hide Toolbar</guimenuitem>). Present such items as
a single <link linkend="menu-item-type-check">check box item</link>
instead.</para></listitem>
+ <listitem><para>Do not use mutable menu items to toggle a two-
state setting (for example, <guimenuitem>Show Toolbar</guimenuitem>
and <guimenuitem>Hide Toolbar</guimenuitem>). Present such items as
a single <link linkend="menu-item-type-check">checkbox item</link>
instead.</para></listitem>
</itemizedlist>
</sect3>
<sect3 id="menu-item-type-check">
<title>Checkbox Items</title>
- <figure id="checkbox-items-figure"><title>A group of check box
items on a menu</title>
+ <figure id="checkbox-items-figure"><title>A group of checkbox
items on a menu</title>
<mediaobject>
<imageobject><imagedata fileref="images/menus-checkbox-
group.png" format="PNG" width="231" depth="112"/></imageobject>
<imageobject><imagedata fileref="images/menus-checkbox-
group.eps" format="EPS"/></imageobject>
- <textobject><phrase>Screenshot of group on a View menu
containing four check box items: Main Toolbar, Side Pane, Location
Bar and Status Bar</phrase></textobject>
+ <textobject><phrase>Screenshot of group on a View menu
containing four checkbox items: Main Toolbar, Side Pane, Location
Bar and Status Bar</phrase></textobject>
</mediaobject>
</figure>
- <para>A check box menu item shows the current state of a two-
state setting, and allows the user to toggle it by selecting the
menu item.</para>
+ <para>A checkbox menu item shows the current state of a two-
state setting, and allows the user to toggle it by selecting the
menu item.</para>
<itemizedlist><title>Guidelines</title>
- <listitem><para>Use a check box menu item only when it is
obvious from the label what the set and unset states mean. This
usually means that the two states are logical or natural opposites,
such as "on" and "off". If this is not the
case, use two <link linkend="menu-item-type-radio">radio button
items</link> instead.</para></listitem>
- <listitem><para>Never change the label of a check box menu item
in response to the user selecting the item.</para></listitem>
+ <listitem><para>Use a checkbox menu item only when it is
obvious from the label what the set and unset states mean. This
usually means that the two states are logical or natural opposites,
such as "on" and "off". If this is not the
case, use two <link linkend="menu-item-type-radio">radio button
items</link> instead.</para></listitem>
+ <listitem><para>Never change the label of a checkbox menu item
in response to the user selecting the item.</para></listitem>
</itemizedlist>
@@ -287,7 +287,7 @@
<itemizedlist>
- <listitem><para>If you need to offer a choice of two mutually-
exclusive settings to the user, use a group of two radio button
items instead of a single check box menu item if the settings are
not clearly opposites. For example, represent <guimenuitem>View as
Icons</guimenuitem> and <guimenu>View as List</guimenu> as two radio
button items.</para></listitem>
+ <listitem><para>If you need to offer a choice of two mutually-
exclusive settings to the user, use a group of two radio button
items instead of a single checkbox menu item if the settings are not
clearly opposites. For example, represent <guimenuitem>View as
Icons</guimenuitem> and <guimenu>View as List</guimenu> as two radio
button items.</para></listitem>
<listitem><para>Never change the label of a radio button menu
item in response to the user selecting or deselecting the item.</
para></listitem>
@@ -301,8 +301,8 @@
including:
* Confusing menu items acting as radio buttons in a group with menu
- items acting as check boxes.
- * Ambiguous names for check box/toggle menu items which make it
+ items acting as checkboxes.
+ * Ambiguous names for checkbox/toggle menu items which make it
difficult to establish the current system state by looking at
the menu.
</remark>
@@ -910,14 +910,14 @@
<row>
<entry><guimenuitem><accel>T</accel>oolbar</guimenuitem></
entry>
<entry>None</entry>
- <entry>Shows or hides the application's toolbar. This is a
<link linkend="menu-item-type-check">check box menu item</link>.
Include this item in every application that has a single toolbar.
See <xref linkend="toolbars-controlling-display"/> for information
on how to deal with multiple toolbars.</entry>
+ <entry>Shows or hides the application's toolbar. This is a
<link linkend="menu-item-type-check">checkbox menu item</link>.
Include this item in every application that has a single toolbar.
See <xref linkend="toolbars-controlling-display"/> for information
on how to deal with multiple toolbars.</entry>
</row>
<!-- Suggest removing this for now, see bug #????
<row>
<entry><guimenuitem><accel>S</accel>tatusbar</guimenuitem></entry>
<entry>None</entry>
- <entry>Shows or hides the application's statusbar. This is a
<link linkend="menu-item-type-check">check box menu item</link>.
Include this item in every application that has a statusbar.</entry>
+ <entry>Shows or hides the application's statusbar. This is a
<link linkend="menu-item-type-check">checkbox menu item</link>.
Include this item in every application that has a statusbar.</entry>
</row>
-->
Index: C/hig-ch-input.xml
===================================================================
--- C/hig-ch-input.xml (revision 551)
+++ C/hig-ch-input.xml (working copy)
@@ -435,7 +435,7 @@
<listitem><para>Use a logical keyboard navigation order. When
navigating around a window with the Tab key, keyboard focus should
move between controls in a predictable order. In Western locales,
this is normally left to right and top to bottom.</para></listitem>
- <listitem><para>Ensure correct tab order for controls whose
enabled state is dependent on check box, radio button or toggle
button state. When such a button is selected, all its dependent
controls should be enabled, and all the dependent controls of any
other button in the group should be disabled. When the user selects
a check box, radio button or toggle button that has dependent
controls, do not automatically give focus to the first dependent
control, but instead leave the focus on the button.
+ <listitem><para>Ensure correct tab order for controls whose
enabled state is dependent on checkbox, radio button or toggle
button state. When such a button is selected, all its dependent
controls should be enabled, and all the dependent controls of any
other button in the group should be disabled. When the user selects
a checkbox, radio button or toggle button that has dependent
controls, do not automatically give focus to the first dependent
control, but instead leave the focus on the button.
<!-- See <xref linkend="keynav-examples"/>.--></para></listitem>
@@ -1019,7 +1019,7 @@
</row>
<row>
<entry><keysym>Space</keysym></entry>
- <entry>Toggle selected state of focused check box, radio button,
or toggle button</entry>
+ <entry>Toggle selected state of focused checkbox, radio button,
or toggle button</entry>
</row>
<row>
<entry><keysym>Return</keysym></entry>
Index: C/hig-ch-controls.xml
===================================================================
--- C/hig-ch-controls.xml (revision 551)
+++ C/hig-ch-controls.xml (working copy)
@@ -47,7 +47,7 @@
able to use later, even if it is not available right now.</para>
<figure>
- <title>Two check boxes: sensitive (top) and insensitive
(bottom)</title>
+ <title>Two checkboxes: sensitive (top) and insensitive
(bottom)</title>
<mediaobject>
<imageobject>
@@ -61,7 +61,7 @@
<textobject>
<phrase>Screenshot showing the visual appearance of
sensitive and
- insensitive check box controls</phrase>
+ insensitive checkboxes</phrase>
</textobject>
</mediaobject>
</figure>
@@ -667,194 +667,185 @@
completed.</para>
</sect1>
- <sect1 id="controls-check-boxes">
- <title>Check Boxes</title>
-
- <para>Check boxes are used to show or change a setting. Its two
states,
- set and unset, are shown by the presence or absence of a
checkmark in the
- labelled box.</para>
-
- <figure>
- <title>A typical group of check boxes</title>
-
- <mediaobject>
- <imageobject>
- <imagedata depth="140" fileref="images/controls-check-
boxes.png"
- format="PNG" width="143" />
- </imageobject>
-
- <imageobject>
- <imagedata fileref="images/controls-check-boxes.eps"
format="EPS" />
- </imageobject>
-
- <textobject>
- <phrase>A typical group of five check boxes in a dialog</
phrase>
- </textobject>
- </mediaobject>
- </figure>
-
- <!-- CB-Fig: callouts. -->
-
- <itemizedlist>
- <title>Guidelines</title>
-
- <listitem>
- <para>Do not initiate an action when the user clicks a
check box.
- However, if used in an instant-apply <link linkend="windows-
utility">property
- or preference window</link>, update the setting represented
by the
- check box immediately.</para>
- </listitem>
-
- <listitem>
- <para>Clicking a check box should not affect the values of
any other
- controls. It may sensitize, insensitize, hide or show other
controls,
- however.</para>
- </listitem>
-
- <listitem>
- <para>If toggling a check box affects the sensitivity of
other
- controls, place the check box immediately above or to the
left of the
- controls that it affects. This helps to indicate that the
controls are
- dependent on the state of the check box.<!--FIXME: pic
required)--></para>
- </listitem>
-
- <listitem>
- <para>Use <link linkend="layout-capitalization">sentence
- capitalization</link> for check box labels, for example
- <guilabel>Use custom font</guilabel>.</para>
- </listitem>
-
- <listitem>
- <para>Label check boxes to clearly indicate the effects of
both their
- checked and unchecked states, for example, <guilabel>Show
icons in
- menus</guilabel>. Where this proves difficult, consider
using two
- radio buttons instead so both states can be given labels.
For example:</para>
-
- <figure>
- <title>Ambiguous check box (top), radio buttons work
better in this
- case (bottom)</title>
-
- <mediaobject>
- <imageobject>
- <imagedata depth="70"
- fileref="images/controls-check-box-ambiguous.png"
format="PNG"
- width="279" />
- </imageobject>
-
- <imageobject>
- <imagedata fileref="images/controls-check-box-
ambiguous.eps"
- format="EPS" />
- </imageobject>
-
- <textobject>
- <phrase>Two images: one showing a single check box
ambiguously
- labelled "Progress bar in left of
statusbar", the other
- making the choice explicit with radio buttons labelled
- "Left" and "Right" under the
heading "Status
- bar progress indicator position:"</phrase>
- </textobject>
- </mediaobject>
- </figure>
-
- <para>The single check box in this example is ambiguous, as
it is not
- clear where the "progress indicator" will go if
the box is
- unchecked. Two radio buttons are better in this case, as
they make the
- options clear.</para>
- </listitem>
-
- <!-- CB-Fig: Again, callouts, shorten caption. The callouts
should include other bullet points as well (e.g., access keys). The
referring bullet item is badly phrased. Perhaps make this the one
check box images for the bullets, with different callouts for
different bullet points. -->
-
- <listitem>
- <para>Provide an access key in all check box labels that
allows the
- user to set or unset the check box directly from the
keyboard.</para>
- </listitem>
-
- <listitem>
- <para>If the check box represents a setting in a multiple
selection
- that is set for some objects in the selection and unset for
others,
- show the check box in its mixed state. For example:</para>
-
- <figure>
- <title>Check boxes (right) showing properties for a
multiple
- selection of files in Nautilus (left)</title>
-
- <mediaobject>
- <imageobject>
- <imagedata depth="170"
- fileref="images/controls-check-boxes-mixed.png"
format="PNG"
- width="223" />
- </imageobject>
-
- <imageobject>
- <imagedata fileref="images/controls-check-boxes-
mixed.eps"
- format="EPS" />
- </imageobject>
-
- <textobject>
- <phrase>Check boxes showing the Hidden, Readable and
Writeable
- states of two selected files in Nautilus. Both files
are hidden,
- neither are writeable, but one is readable. The
Readable check
- box is therefore shown in its mixed state.</phrase>
- </textobject>
- </mediaobject>
- </figure>
-
- <para>In this example, both selected files are hidden
(since their
- filenames start with "."), and the emblems on
their icons show
- that neither file is writeable, but one is readable. The
- <guilabel>Readable</guilabel> check box is therefore shown
in its
- mixed state. <remark>At time of writing, the exact visual
appearance
- of a mixed state check box in gtk was undecided</remark>.</
para>
-
- <para>When a check box is in its mixed state:</para>
-
- <itemizedlist>
- <listitem>
- <para>clicking the box once should check the box,
applying that
- setting (when confirmed) to all the selected objects</
para>
- </listitem>
-
- <listitem>
- <para>clicking the box a second time should uncheck the
box,
- removing that setting (when confirmed) to all the
selected objects</para>
- </listitem>
-
- <listitem>
- <para>clicking the box a third time should return the
box to its
- mixed state, restoring each selected object's
original value
- for that setting (when confirmed)</para>
- </listitem>
- </itemizedlist>
-
- <!-- CB-Ed: Mixed state check boxes are a polemic-ridden
issue. Data to back this up? -->
- </listitem>
-
- <listitem>
- <para>Label a group of check boxes with a descriptive
heading above or
- to the left of the group.</para>
- </listitem>
-
- <listitem>
- <para>Use a frame around the group if necessary, but
remember that
- blank space often works just as well and results in a less
- visually-cluttered dialog.</para>
- </listitem>
-
- <listitem>
- <para>Do not place more than about eight check boxes under
the same
- group heading. If you need more than eight, try to use
blank space,
- heading labels or frames to divide them into smaller groups.
- Otherwise, consider using a check box list instead— but you
probably
- also need to think about how to simplify your user
interface.</para>
- </listitem>
-
- <listitem>
- <para>Try to align groups of check boxes vertically rather
than
- horizontally, as this makes them easier to scan visually. Use
- horizontal or rectangular alignments only if they greatly
improve the
- layout of the window.</para>
- </listitem>
- </itemizedlist>
+ <sect1 id="controls-checkboxes">
+ <title>Checkboxes</title>
+ <para>
+ A checkbox is used to control something that can obviously be
on or off.
+ </para>
+ <sect2>
+ <title>Text</title>
+ <para>
+ 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.)
+ </para>
+ <para>
+ 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
+ <quote>all</quote>, <quote>always</quote>,
+ <quote>default</quote>, or <quote>only</quote>,
+ the unchecked state probably <emphasis>isn’t</
emphasis> obvious.)
+ If it cannot be made obvious by rewording the label, use a
pair of
+ <link linkend="controls-radio-buttons">radio buttons</link>
instead.
+ When deciding this, consider the target audience and
situation.
+ For example, in an <link linkend="windows-
assistant">assistant</link>
+ 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.
+ </para>
+ <para>
+ The checked state of a checkbox should be understandable as
something
+ positive.
+ Never use a checkbox label beginning
+ <quote>Don’t</quote> or <quote>Do not</quote>,
+ and avoid using a checkbox label beginning
+ <quote>Hide</quote>, <quote>Ignore</quote>, or similar.
+ Try reversing the effect of the checkbox so the label can
be positive.
+ </para>
+ <caution class="windows">
+ Windows Vista guidelines offer
+ <guilabel>Don't show this message again</guilabel>
+ 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.
+ <!-- See also <xref linkend="alerts-confirmation"></xref>.
-->
+ </caution>
+ <para>
+ Don’t begin a checkbox label with <quote>Enable</
quote>,
+ and be careful if beginning it with <quote>Use</quote>.
+ 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.
+ </para>
+ <para>
+ A checkbox label should use sentence
+ <link linkend="layout-capitalization">case</link>, 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.)
+ 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).
+ <mediaobject>
+ <textobject>
+ For example, not
+ <guilabel>Sound plays when a message arrives</guilabel>
but instead
+ <guilabel>Play a sound when a message arrives</guilabel>.
+ </textobject>
+ </mediaobject>
+ </para>
+ <para>
+ 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.)
+ Even better, try shortening the explanation or advice
enough that it
+ can be used as the label itself, replacing the existing one.
+ </para>
+ <para>
+ If necessary, a group of related checkboxes may have an
extra label
+ introducing them.
+ This label should be in sentence case, and end with a colon.
+ Avoid repeating the first word in several checkboxes in a
group;
+ instead, include this word in the label for the group.
+ </para>
+ <para>
+ In help text or support materials, refer to a checkbox as a
+ <quote>box</quote> that someone may <quote>check</quote> or
+ <quote>clear</quote>.
+ </para>
+ </sect2>
+ <sect2>
+ <title>Layout</title>
+ <para>
+ Arrange a group of checkboxes in a single column, unless a
horizontal
+ or multi-column arrangement suits the window much better.
+ If there is a label for the group as a whole, place it
either above
+ the group, or to the left of the first checkbox, depending
on the
+ layout of the rest of the window.
+ </para>
+ <para>
+ Avoid presenting more than about eight checkboxes as a
single group.
+ If this is unavoidable, or if the number of checkboxes is
dynamic
+ (for example, a list of plug-ins), present them in a
scrollable
+ <link linkend="controls-lists">list box</link>.
+ </para>
+ </sect2>
+ <sect2>
+ <title>Behavior</title>
+ <para>
+ Clicking a checkbox, or its label, toggles its state.
+ Don’t perform any action <emphasis>other than</
emphasis>
+ toggling the state;
+ for example, 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
+ <link linkend="controls-buttons">button</link> to open a
dialog for
+ configuring and confirming the function.
+ </para>
+ <para>
+ <mediaobject>
+ <textobject>
+ For example, a backup function might have
+ <guilabel>Backup is off.</guilabel> text, followed by a
+ <guilabel>Turn On Backup…</guilabel> button
+ that opens a secondary dialog.
+ Once the configuration is complete, the text might
change to
+ summarize the configuration, and the single button
might be
+ replaced by <guilabel>Settings…</guilabel> and
+ <guilabel>Turn Off Backup</guilabel> buttons.
+ </textobject>
+ </mediaobject>
+ </para>
+ </sect2>
+ <sect2>
+ <title>Mixed-state checkboxes</title>
+ <para>
+ When a checkbox represents a property that is turned on for
some parts
+ of the current selection, but off for other parts,
+ the checkbox should appear in its mixed state.
+ For example, where multiple files are selected in Nautilus,
+ an emblem that has been applied only to some of the
selected files
+ is represented by a mixed-state checkbox in the Properties
window.
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="images/controls-check-boxes-
mixed.png" />
+ </imageobject>
+ <imageobject>
+ <imagedata fileref="images/controls-check-boxes-
mixed.eps" />
+ </imageobject>
+ </mediaobject>
+ </para>
+ <para>
+ Clicking a mixed-state checkbox cycles between the mixed
state,
+ the fully checked state,
+ the unchecked state,
+ and back to the mixed state (restoring the original values),
+ in that order.
+ </para>
+ <para>
+ Don’t use a mixed-state checkbox for any other purpose.
+ For a property that normally has three possible states,
+ use three radio buttons or an
+ <link linkend="controls-option-menus">option menu</link>
instead.
+ </para>
+ </sect2>
</sect1>
<sect1 id="controls-radio-buttons">
@@ -862,7 +853,7 @@
<para>Radio buttons are used in groups to select from a mutually
exclusive
set of options. Only one radio button within a group may be set
at any one
- time. As with check boxes, do not use radio buttons to initiate
actions.</para>
+ time. As with checkboxes, do not use radio buttons to initiate
actions.</para>
<figure>
<title>A typical group of radio buttons</title>
@@ -889,7 +880,7 @@
<listitem>
<para>Only use radio buttons in groups of at least two,
never use a
single radio button on its own. To represent a single
setting, use a
- check box or two radio buttons, one for each state.</para>
+ checkbox or two radio buttons, one for each state.</para>
</listitem>
<listitem>
@@ -1039,7 +1030,7 @@
<para>Do not use groups of toggle buttons in dialogs unless
space
constraints force you to do so, or you need to provide
consistency
with a toolbar in your application. <link
- linkend="controls-check-boxes">Check boxes</link> or <link
+ linkend="controls-checkboxes">Checkboxes</link> or <link
linkend="controls-radio-buttons">radio buttons</link> are
usually
preferable, as they allow more descriptive labels and are less
easily-confused with other types of control.</para>
@@ -1058,7 +1049,7 @@
<listitem>
<para>Label a group of toggle buttons with a descriptive
heading above
- or to the left of the group, as you would with a group of
check boxes
+ or to the left of the group, as you would with a group of
checkboxes
or radio buttons.</para>
</listitem>
@@ -1132,7 +1123,7 @@
<remark>At time of writing, the exact visual appearance of
mixed state
toggle buttons was undecided. A mixed state toggle button
should
- behave exactly as a mixed state check box or radio button,
depending
+ behave exactly as a mixed-state checkbox or radio button,
depending
on whether the toggle button choices are independent or
mutually
exclusive, respectively.</remark>
</listitem>
@@ -1463,7 +1454,7 @@
<listitem>
<para>Do not use lists with less than about five items,
unless the
number of items may increase over time. Use <link
- linkend="controls-check-boxes">check boxes</link>, <link
+ linkend="controls-checkboxes">checkboxes</link>, <link
linkend="controls-radio-buttons">radio buttons</link> or an
<link
linkend="controls-option-menus">drop-down list</link> if
there are fewer
items.</para>
@@ -1497,11 +1488,11 @@
</listitem>
<listitem>
- <para>Consider using a check box list for multiple-
selection lists, as
+ <para>Consider using a checkbox list for multiple-selection
lists, as
these make it more obvious that multiple selection is
possible:</para>
<figure>
- <title>A simple check box list</title>
+ <title>A simple checkbox list</title>
<mediaobject>
<imageobject>
@@ -1517,7 +1508,7 @@
<textobject>
<phrase>Picture of list control with two columns. The
first
- column consists of check boxes showing whether or not
the
+ column consists of checkboxes showing whether or not
the
corresponding item in the second column is selected
for further
action.</phrase>
</textobject>
@@ -1689,11 +1680,11 @@
</listitem>
<listitem>
- <para>Consider using a check box tree for multiple-
selection trees, as
+ <para>Consider using a checkbox tree for multiple-selection
trees, as
these make it more obvious that multiple selection is
possible:</para>
<figure>
- <title>A simple check box tree</title>
+ <title>A simple checkbox tree</title>
<mediaobject>
<imageobject>
@@ -1709,7 +1700,7 @@
<textobject>
<phrase>Picture of tree control with two columns. The
first
- column consists of check boxes showing whether or not
the
+ column consists of checkboxes showing whether or not
the
corresponding item in the second column is selected
for further
action.</phrase>
</textobject>
Index: C/images/controls-check-box-ambiguous.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = image/png
Index: C/images/controls-check-boxes.png
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = image/png
Index: C/hig-ch-layout.xml
===================================================================
--- C/hig-ch-layout.xml (revision 551)
+++ C/hig-ch-layout.xml (working copy)
@@ -389,14 +389,14 @@
<para>Placement of visual components in an application is
important because relationships between elements are indicated by
their positions. This is called "layout" in interface
design.</para>
- <para>A clean layout is crucial to creating a smooth visual
flow of information for the user. This section describes the proper
component placement and spacing to use in GNOME applications. The
major components discussed will be labels, icons, radio buttons and
check boxes, text fields, command buttons, and drop-down menus.</para>
+ <para>A clean layout is crucial to creating a smooth visual
flow of information for the user. This section describes the proper
component placement and spacing to use in GNOME applications. The
major components discussed will be labels, icons, radio buttons and
checkboxes, text fields, command buttons, and drop-down menus.</para>
</sect2>
<sect2 id="layout-dialogs">
<title>Dialogs</title>
- <para>When a user is scanning a complex preferences dialog
consisting of many labels and corresponding check boxes, text
fields, and drop-down combination boxes, it is easy to see how she
can quickly become hindered by poor layout in the visual design. For
information on laying out Alerts, see <xref linkend="alert-spacing"/
></para>
+ <para>When a user is scanning a complex preferences dialog
consisting of many labels and corresponding checkboxes, text fields,
and drop-down combination boxes, it is easy to see how she can
quickly become hindered by poor layout in the visual design. For
information on laying out Alerts, see <xref linkend="alert-spacing"/
></para>
<figure id="improved-layout-figure"><title>Improved window
layout</title>
@@ -504,7 +504,7 @@
<listitem><para>As a basic rule of thumb, leave space between user
interface components in increments of 6 pixels, going up as the
relationship between related elements becomes more distant. For
example, between icon labels and associated graphics within an icon,
6 pixels are adequate. Between labels and associated components,
leave 12 horizontal pixels. For vertical spacing between groups of
components, 18 pixels is adequate. A general padding of 12 pixels is
recommended between the contents of a dialog window and the window
borders.</para></listitem>
- <listitem><para>Break long lists of choices into smaller groups.
For lists of less than about eight items, use radio buttons or check
boxes. For longer lists, use a list control or drop-down list.</
para></listitem>
+ <listitem><para>Break long lists of choices into smaller groups.
For lists of less than about eight items, use radio buttons or
checkboxes. For longer lists, use a list control or drop-down list.</
para></listitem>
<listitem><para>Try to keep elements of the same type left-aligned
with each other. For instance, in <xref linkend="layout-callouts-
figure"/>, the group titles (<guilabel>General</guilabel> and
<guilabel>Actions</guilabel>) are left-aligned and justified with
each other.</para></listitem>
@@ -541,7 +541,7 @@
<listitem><para>In the right column, place a GtkVBox
containing a row per control you wish to place in the category. Set
the <property>Spacing</property> to <userinput>6</userinput>.
<itemizedlist>
<listitem><para>For left-side labelled controls such as text
boxes, drop-down lists, and many others, place a 2 columned GtkHBox
inside the row with a label in the left column and the corresponding
control in the right. Set the <property>Spacing</property> on the
GtkHBox to <userinput>6</userinput>. Place all labels such as this
(for the whole window) in the same GtkSizeGroup (there is currently
no way to do this using only Glade, you will have to use code as
well). This will align the controls to their right, even between
categories, which is important for allowing quick visual scans.</
para></listitem>
- <listitem><para>For right-side labelled controls such as
check boxes and radio buttons, simply place them directly in the
row.</para></listitem>
+ <listitem><para>For right-side labelled controls such as
checkboxes and radio buttons, simply place them directly in the
row.</para></listitem>
</itemizedlist>
</para></listitem>
</itemizedlist>
@@ -614,7 +614,7 @@
</row>
<row>
- <entry>Radio button and check box labels</entry>
+ <entry>Radio button and checkbox labels</entry>
<entry>6 pixels to the right of and vertically center aligned
with radio button</entry>
<entry align="center">
<mediaobject>
@@ -762,7 +762,7 @@
<row valign="top">
<entry colname="col1" align="left" valign="top">
- Check box labels
+ Checkbox labels
</entry>
<entry colname="col2" valign="top">
_______________________________________________
Usability mailing list
Usability gnome org
http://mail.gnome.org/mailman/listinfo/usability
