[Usability] RFC: Revision of HIGs "Check Boxes" section
- From: Matthew Paul Thomas <mpt myrealbox com>
- To: Calum Benson <Calum Benson Sun COM>
- Cc: usability gnome org
- Subject: [Usability] RFC: Revision of HIGs "Check Boxes" section
- Date: Fri, 25 Jul 2008 23:42:09 +0100
Hi Calum (and everyone)
I have written a revision of the "Check Boxes" section of the HIGs.
Patch attached.
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">
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
