|
|
Writing Documentation for BoostHTML Design |
Boost places no requirements on the design of HTML documentation for library submitters. If you are submitting a library for which documentation already exists in either HTML or in a form easily converted to HTML then there is no need for you to read this document. However, if you have not yet written the documentation, or if you expect to have to translate documentation written in a format not easily convertible to HTML then this document can give you a lot of information on how to go about writing documentation in HTML.
In several places this document assumes you're writing the documentation to conform to the structure described in the Documentation Structure document. There is no requirement that your documentation content follow these guidelines, but they provide an effective way to communicate technical specifications for a library in a terse yet precise manner that's familiar to many Boost users.
This document also contains links to HTML template files that can be used to rapidly develop documentation for a library submission. These templates follow the guidelines presented here and in the Documentation Structure document.
Most HTML documentation projects will contain some common pages. General guidelines for these common pages are provided below.
The index page is the first page presented to a user when he browses the documentation. Generally this page should not contain any actual content, but instead contains a list of links to specific content. At a minimum this list should contain a link to every HTML page contained in the documentation. Optionally, sub-lists may be provided for individual pages linking to specific subjects within the page. These sub-lists should form a "tree" hierarchy based on the level of heading tag used for the specific subject. Inclusion of such sub-lists for every page can make the index rather lengthy, and since each page should include its own Page Index, it may make the navigation of the documentation easier if such sub-lists are avoided. However, there is one exception to this guideline: reference documentation should contain a link to every header file in the library and a sub-list with a link to every macro, value, type, class, function and object (see Documentation Structure) found in the header. Users aren't always sure what header file any of these may be contained in, so this structure in the index allows for easy navigation of the reference documentation.
The index list should generally be constructed using an HTML "definition
list" (<dl> and <dt> tags). A definition list has no bullets
or ordered specifications and produces a cleaner layout then an unordered list
(<ul> and <li> tags) or an ordered list (<ol> and <li>
tags). If you choose to use the common Boost Style
Sheet you should add a class="index" attribute/value pair to
the <dl> tag.
An Index page template is provided for use.
The Overview page is used to introduce the reader to the library. It should give a high-level overview of the purpose of the library and introduce the reader to any concepts they may be unfamiliar with. This may also be an appropriate place for some "light" rationale, though more thorough presentation of any rationale would be better placed in the Rational Page.
Like most content pages, the Overview page should include a Page Index.
An Overview page template is provided for use.
The Definitions page is used to provide a list of definitions for terms that a user may be unfamiliar with.
The definition list should generally be constructed using an HTML "definition
list" (<dl> and <DT> tags). A definition list has no bullets
or ordered specifications and produces a cleaner layout then an unordered list
(<UL> and <li> tags) or an ordered list (<ol> and <li>
tags). If you choose to use the common Boost Style
Sheet you should add a class="definition" attribute/value pair
to the <dl> tag.
Because this page's content should only contain a list of definitions, it should not have a Page Index.
A Definitions page template is provided for use.
The Rationale page is used to provide lengthy descriptions of the rationale behind the library's design. This information helps users to understand why a library was designed the way it was and may reduce the frequency of a number of frequently asked questions. For a better description of why rationale is important see the Rationale rationale in the general submission guidelines.
Like most content pages, the Rationale page should include a Page Index.
A Rationale page template is provided for use.
The Configuration Information page is used to document configuration macros
used by the library. Such macros belong in one of three groups: macros used
by library implenters defined in <boost/config.hpp>, macros
used by library users to detect platform configuration information and macros
defined by library users to configure library behavior.
Like most content pages, the Overview page should include a Page Index.
A Configuration page template is provided for use.
As a library matures the users will have questions about the usage of the library. Often users will ask the same questions over and over again. Rather than having to deal with answering the question every time it's asked, a Frequently Asked Questions (commonly known as FAQs) page can be used to document the questions and answers. This is such a valuable piece of documentation not only for the users but for the maintainers as well, that a FAQ page should be provided from the outset. If there are no questions that will obviously become a FAQ, the initial page may just indicate that there are no FAQs yet. This empty place holder helps to indicate to the users that you plan to address any FAQs as they occur.
The Page Index for the FAQ page should contain a list of all the questions contained in the document. The actual question entries should be formatted with the question in a heading tag and the answers in standard paragraph format. This provides a clean presentation that's easy to read.
A Frequently Asked Questions page template is provided for use.
The Bibliography page is used to document any bibliographical information associated with references made within the documentation to external resources. Parenthetical references are used within the documentation which link to entries in the Bibliography page. Bibliographical entries provide detailed information about the external resource and may contain hyper links to the resource if it's available online. There are several formal styles used for writing bibliographies. You may use what ever style you want, but one of the better styles to consider using can be referenced here.
Since the Bibliography page should contain only bibliographical information there is no need for a Page Index.
A Bibliography page template is provided for use.
The Acknowledgment page is used to give credit where credit is due. When individuals provide input on the design or implementation, or when you make use of someone else's work, you should acknowledge them. This is a courtesy that you'd expect others to extend to you, so you should strive to acknowledge the efforts of everyone else in your own documentation.
Since the Acknowledgment page should contain only a list of acknowledgment there is no need for a Page Index.
An Acknowledgments page template is provided for use.
The Header Reference pages are the most important pages in your documentation. They document all library headers, including all the macros, values, types, classes, functions and objects defined in them. In general it may prove useful to follow the guidelines in Documentation Structure when writing the content for these pages.
Like most content pages, the Header Reference pages should include a Page Index.
A Header Reference page template is provided for use.
There are certain page layout concepts that will be used frequently in many of your pages. This section outlines some general guidelines that you can follow when designing each of these layout concepts for your documentation.
The Page Banner is located at the very top of a page and provides quick information about the page contents. This includes the Boost logo, which indicates to the reader that this page is part of the Boost web site, a title for the documentation (generally the library name) and the page title. The Boost logo should hyper link to the Boost home page on the index page and to the index page on all other pages. This allows the user to easily navigate through the Boost web site and through the documentation. The <title> tag for the HTML page should consist of the documentation title and the page title separated by a hyphen.
The Page Banner should be separated from the rest of the page by the use of an <hr> tag. This helps to clearly separate the actual content from the title information and produces cleaner text.
The page index is used to quickly navigate to the various sections of the documentation on the page, and when present should be located just below the Page Banner.
The index list should generally be constructed using an HTML "definition
list" (<dl> and <DT> tags). A definition list has no bullets
or ordered specifications and produces a cleaner layout then an unordered list
(<UL> and <li> tags) or an ordered list (<ol> and <li>
tags). If you choose to use the Boost Style Sheet you should add a class="page-index"
attribute/value pair to the <dl> tag.
Most pages should include a Page Index.
The page's actual documentation content will be formatted according to the specific needs of individual pages, and should be placed right after the Page Index if present, or after the Page Banner if not. In general the documentation content will take the form of paragraph text contained underneath section headings.
Footnotes may be used within a page's documentation. Within the documentation
content a footnote reference should take the form of a footnote number in parentheses
(the parentheses make it easier for the reader to click on the hyper link) hyper
linking to the actual footnote at the bottom of the page's documentation content.
You may either use the <sup> tag to format such footnote numbers, or,
preferably, you can use a CSS style class in order to distinguish the number
as a footnote instead of as part of the actual text. If you choose to use the
common Boost Style Sheet, a footnote
class is defined for this purpose.
At the bottom of every page should be some revision information indicating when the page was last revised. This information should be separated from the rest of the page above by an <hr> tag. The following HTML code snippet can be used to track this revision information (this code uses some server components that exist on the Boost web site to automatically track revision dates with out the need for hand editing the date text):
<hr> <p>Revised <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan --> 01 January, 2001 <!--webbot bot="Timestamp" endspan i-checksum="39359" --> </p>
The very bottom of the page should contain any copyright information that applies to the document.
This section provides general guidelines for formatting documentation using HTML. The description of the various "common pages" gave specific details for formatting specific sections of the documentation, which should override these guidelines.
Code within the documentation should be placed within either <code></code> or <pre></pre> tags. For code that's placed inline with other text you use <code></code> tags, while <pre></pre> tags are used for code "blocks". If a cascading style sheet is used to specify formatting for these tags, a fixed width sans serif font should be used. This insures that the code is easily distinguishable from the rest of the text. It may also be beneficial to set the style for <pre></pre> tags to indent the text, to help separate code blocks from other structural HTML blocks. The Boost Style Sheet specifies formatting for these tags.
Note: "Code" includes variable names, function names, etc.
Lists should be constructed as unordered (<UL> and <li> tags), ordered (<ol> and <li> tags) or definition (<dl> and <DT> tags) lists in HTML. You use an unordered list when you need a collection of items that don't have any kind of logical ordering, such as a list of data types that are defined by the library and can be used for a template argument. You use an ordered list when the collection of items must be grouped in a logical ordering, such as when enumerating the steps that an action logically performs. You use a definition list when the list consists of not only items that have no logical ordering, but also contains definitions/descriptions/etc. of the items. A good example of this is the function specifications as described in Documentation Structure.
Graphics should be used very sparingly, if at all. Graphic images greatly effect the download time for many people, which can discourage users from reading the documentation. If you need graphic images to help illustrate something in your documentation consider supplying only a link to the image within the documentation, instead of embedding it directly in the text. If an image is going to be included in the text of the document you should specify the image's size in the <img> tag, in order to allow the user's browser to optimize the formatting of the text before the image is loaded.
Non-breaking spaces ( ) should be avoided in HTML text. Generally there are more appropriate ways to format the document, such as using list constructs or specifying indentation as a style attribute or in cascading style sheets.
Cascading style sheets allow you to apply some advanced formatting styles to an HTML document. More importantly, they allow you to change the formatting in a single file and effect all pages using the style sheet. Instead of struggling to produce a specific format in HTML it's often easier and more flexible to specify the formatting in a style sheet.
The concept of using cascading style sheets to format HTML is such a good idea that it can be beneficial to apply this across the entire Boost site. Of course we can't require this (if Boost were to require such trivia for submissions it's likely that many programmers would be discouraged from contributing). However, a "standard" Boost style sheet (http://www.boost.org/boost.css) is supplied anyway, so that a contributer can quickly and easily produce clear and consistent documentation that reflects a Boost "brand" if they so choose. If, at a later date, it's decided to update the Boost "brand", it may be done in this single file and all documents using the style sheet will automatically be updated.
The Boost supplied style sheet not only specifies styles for many standard tags, it also specifies several style "classes". A class is specified for a given tag instead of being applied to all instances of a given tag type. Below is a list of the classes specified in the Boost style sheet and a description of when to use them:
Instead of hand coding every HTML page, HTML "templates" can be used instead. The list below provides links to templates that may be used when writing documentation for a contribution to Boost. Links provided in these templates assume the files will reside in the "traditional" directory hierarchy of boost/libs/library/doc. They may need correcting if the file will reside in some other location.
Note: Since these "templates" are just HTML pages simply clicking on the links below will load the template in your browser. You will need to use a browser specific method to download the files instead of loading them into the browser (for instance, on most Windows browsers you can right click on the link and select the appropriate command from the context sensitive menu).
Revised 29 November, 2003
© Copyright William E. Kempf 2001. All Rights Reserved.
