Last update Dec29/19W3C//Dtd html 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>

<head>
  <title>Master Style Guide: Chapter 10</title>
  <liNK rev="made" href="mailto:jss@colltech.com">
  <META http-equiv="Content-Style-Type" content="text/css">
  <STYLE type="text/css">
    <!--#include virtual="guidestyle.css"-->
  </STYLE>
</head>

<body bgcolor="#FFFFFF" TEXT="#00287A" liNK="#0000FF" AliNK="#EAAF00"
      VliNK="#8000FF">

<h1>Chapter 10<br>
Working with checklists</h1>

<p>This chapter discusses the issues involved with checklists, including:</p>

<ul>
  <li><a href="#CREA">Creating checklists</a></li>
  <li><a href="#FORM">Formatting checklists</a></li>
  <li><a href="#OFFL">Using checklists offline</a></li>
  <li><a href="#INTE">Using interactive checklists</a></li>
</ul>

<p>These are discussed in the following sections.</p>

<a name="CREA"></a>
<h2><hr> Creating checklists</h2>

<p>Checklists are useful for providing a list of specific tasks to perform
in a particular order.  Similar to procedures, using the NumStep and
NumStep+ paragraph styles as defined elsewhere in this book, checklists
have the following attributes:</p>

<ul>

  <li><b>Be concise</b>--Checklists should be short and concise.
    Do not explain why a task has to be performed or how to do the task;
    tasks should begin with action verbs such as "Reboot" or "Install"
    or "Change."  If the user needs to know how to perform a task,
    the explanation belongs outside the checklist.<br><br></li>

  <li><b>Two or more entries at every level</b>--Following the "always
    two, never one" rule for bullet lists and headings, any one level
    of a checklist must contain at least two entries.<br><br></li>

  <li><b>No more than three levels deep</b>--Just as three levels
    of bullet (1, 2, and 3) and heading (2, 3, and 4) are generally
    allowed, checklists should have no more than three levels of elements.
    The completion of all child elements is required before the parent
    level's checkbox can be marked as complete.<br><br></li>

  <li><b>Each element has a single box to check</b>--In simple checklists,
    each element has a single box to check when the task is complete.
    In complex checklists, a single document may be used for performing
    the same tasks on several different systems or several different
    times; in these cases, having multiple aligned checkboxes, one per
    system or per time, is appropriate.<br><br></li>

</ul>

<a name="FORM"></a>
<h2><hr> Formatting checklists</h2>

<p>The format of the checklist depends on the publishing tool being used
and the complexity of the checklist.</p>

<p>The suggested style rules for checklists are:</p>

<ul>
  <li>For simple checklists, use a square box, such as the Zapf
    Dingbats "o" character ("<font FACE="Zapf Dingbats",
    "Dingbats">o</font>") and an em space to the left of the
    task.<br><br></li>
  <li>For complex checklists, consider using a table instead of individual
    paragraphs.  An empty cell can be used in lieu of a checkbox.  If the
    entire document is the checklist, the table would have no caption.
    If the checklist is only part of the document, the table should have
    a caption (like "Table 1 &nbsp; Checklist for whatever") and be listed in
    the list of tables (should one exist).<br><br></li>
  <li>Indent each sublevel another 0.50 inches from the left of the
    preceding level.<br><br>
    If the entire document is a checklist, the top level can be aligned
    as if it was a normal paragraph (1 inch margin), which means level
    2 would be at 0.50 inches and level 3 at 0.75 inches indented.<br><br>
    If the checklist is only part of the document, the top level of
    the checklist should be indented 0.50 inches like the Bullet 1 Para
    style, which means level 2 would be at 0.75 inches and level 3 at
    1.00 inches indented.<br><br></li>
  <li>Use the standard fonts, such as Times New Roman and Arial Black,
    for normal text and for headings (respectively) in the checklist,
    just as with normal technical documents.<br><br></li>
</ul>

<p>The formatting for checklists that will be used offline (as hard-copy
documentation) as opposed to online (via a web form) are different and
are discussed in the following sections.</p>

<a name="OFFL"></a>
<h2><hr> Using checklists offline</h2>

<p>If the checklist is to be used offline, as hard-copy documentation, we recommend the following additional style rules:</p>

<ul>
  <li><b>Keep elements together</b>--When possible, keep all children
    elements on the same page as their parent.  When not possible,
    try to avoid widow/orphan issues (where only one element of the
    family is on one page and all the other elements are on a different
    page).<br><br></li>
  <li><b>Use white space</b>--You should use white space in the left
    margin (indents) as well as between the elements at the various levels
    (such as 12 points between level 1 elements, 10 points between level
    2 elements, and 8 points between level 3 elements).  Be consistent
    in your use of white space.<br><br></li>
</ul>

<a name="INTE"></a>
<h2><hr> Using interactive checklists</h2>

<p>Checklists can be interactive as well as static.  Interactive
checklists can be web forms or living documents.</p>

<a name="CWEB"></a>
<H3>Using checklists on the web</H3>

<p>If the checklist is to be used on the web, we suggest using an html
FORM and the INPUT TYPE="CHECKBOX" tag to generate the checkbox.</p>

<p>Web based checklists can be automated with JavaScript or Java to
automatically mark a parent element as completed when all its children
elements are themselves completed.</p>

<a name="CPUB"></a>
<H3>Using checklists through the publishing tool</H3>

<p>Some people like to maintain a living document that acts as a
checklist.  One example is a Y2K readiness checklist, where each system
had to have several specific tasks performed (upgrade the OS, upgrade
the base application suite, upgrade the departmental application suite,
and so on).  A living document, which would have the most current status,
was used.  In this example, the checklist was a table and each cell was
either the system name (in text) or the checkbox.  Empty checkboxes
were blank, completed checkboxes were "<font FACE="Zapf Dingbats",
"Dingbats">4</font>" ("4" in Zapf Dingbats), and tasks that did not need
to be completed (for example, the machine was being decommissioned)
were marked "<font FACE="Zapf Dingbats", "Dingbats">5</font>" ("5"
in Zapf Dingbats).</p>

<p>We do not recommend using "living document checklists" for customer
deliverables.</p>

<hr>
<br><a href="index.shtml">
  <img src="/icons/buttons/toc.gif" alt="[Contents]" height="20" width="20">
  Jump to table of contents</a>

<br><a href="9.shtml">
  <img src="/icons/buttons/previous.gif" alt="[Back]" height="20" width="20">
  Back to Chapter 9, "Working with legal documents"</a>

<br><a href="11.shtml">
  <img src="/icons/buttons/next.gif" alt="[Next]" height="20" width="20">
  Onward to Chapter 11, "Working with flowcharts"</a>

<hr>
Copyright &copy; 2001 Joshua S. Simon.<br>
</body>
</html>