Colors defined here are only valid on the default white background. Pages with non-white backgrounds may define different colors for TEXT, liNK, VliNK, or AliNK.
This chapter discusses web site design issues, including:
This section discusses font aspects for web sites.
For online documentation, studies have shown that sans serif fonts are easier to read than serif fonts. Therefore, your style sheet should use sans serif fonts-such as Arial, Geneva, or Helvetica-for body paragraph text. This affects the following html tags:
For headings, the serif fonts should continue to be used. Your style sheet could reference Times New Roman, Times, and Palatino. This affects the following html tags:
The H6 html tag, representing a fifth-level heading, should never be used.
For code sections, use either the TT or CODE tag blocks to use monospaced type.
You should always use plain (normal or regular) text in all headings and body text, with the following exceptions:
The html version 3 and version 4 specifications define four possible text color settings by default:
A hypertext link goes through three states: it starts out as liNK (blue) until you click on it. Clicking on a link turns it AliNK (red). Once you've followed the link and go back to the page, the link color is VliNK (purple).
Collective Technologies recommends that the body text be either black (#000000 in hexadecimal notation) or blue (#092869), and the other colors (liNK, AliNK, and VliNK) be left in their default states. Further, we recommend that table header cells be white-on-navy blue (#ffffff and #092869 respectively).
Colors defined here are only valid on the default white background. Pages with non-white backgrounds may define different colors for TEXT, liNK, VliNK, or AliNK.
This section discusses headings. There are three major types:
These are discussed in the subsequent sections.
In the body of the document you can have up to four headings defined:
The html H6 tag is available for a fifth-level heading but its use is not allowed in Collective Technologies intranet web sites. The html h1 tag is reserved for page headings or document titles.
Body headings should be in a serif font such as Times New Roman.
Every html page should have a page title. This title needs to appear in the browser's title bar (in the title tag) and in the body of the page (in the h1 tag). Collective Technologies reserves the h1 html tag for page headings or document titles.
Page headings should be in a serif font such as Times New Roman.
Tables should have column headings or row headings, depending on the layout. For example, the topmost row or the leftmost column or both could be considered headings. The table headings for rows and columns should use a serif font such as Times New Roman.
Alignment can follow the data (left, right, or center aligned).
The heading cells should use white (#ffffff) text over a blue (#092869) background. If multiple levels of heading are required, use your best judgement for subsequent heading color levels.
Historically, the Collective Technologies internal web pages have not followed a single style format. Timesheets would use one shade of blue, management pages a different shade of blue, reviews and development plans yet another, with some other areas using plain white, or white with a CT embossing, or even yellow or other colors.
This is confusing to the user and hard to read.
From this point forward, the page background for all new CT intranet pages should be plain white with no embossing or background images. The only exceptions are for areas of the intranet that are being expanded; these areas can continue to use their existing styles and formats, including backgrounds, until they are revised and rewritten.
As various areas of the intranet are revised and rewritten, their formatting should be adjusted to match the current defined styles, as documented in this chapter.
Frames allow you to break the browser's window into separate sub-windows, with different documents in different windows. Frames can be very useful to the web designer, providing a means to keep some information, like company logos, web site menus, and navigation links, always on the screen, in the browser window, no matter which page the user visits. However, the use of frames does not work well in older browsers, including some text-only browsers like lynx. We therefore strongly recommend that you consider carefully the benefits and costs of using frames for your site.
Collective Technologies' technical writers and web designers generally advise against the use of frames. If you must use frames for your section of the web site, follow the following guidelines:
Graphics should only be used on web pages for the following purposes:
Obviously a page dedicated to providing pictures or movies should use graphics, and the company logo is a graphic on many pages on the intranet. Navigation controls can be graphics, though it is strongly recommended to include text controls or alt options as well.
As a reminder, not all users have graphics-capable browsers. Either they have turned off graphics to improve download speed, or they are using a text-based browser such as lynx, or they are using a text-to-speech translator that cannot handle pictures. Therefore you must always use the alt option in the IMG tag when you use graphics. If the graphic is next to text that says the same thing, such as "Jump to this other page," you can say alt="" to have no text displayed in the alt block.
There are several different types of menus used in CT internal web sites. These include:
These are discussed in the following sections.
If the menu is reasonably short, or if neither tables nor frames seem appropriate in the specific instance, you can use a bullet list for the menu. Each item in the menu receives its own bullet item. No icons are used in bullet list menus.
The bullet list menu can be simple or complex at the writer's discretion. Simple bullet lists are where each item is the bullet and text. Complex bullet lists are where each item is the bullet, boldface text, em dash, and explanation of the item.
If the menu is really the table of contents for a complex book, such as the Member Manual, it may be appropriate to use frames such that the left 10-15% of the page is the menu frame and the right 85-90% of the page is the data (content) frame.
Refer to the "Using frames" section for details on using frames.
In most instances, using tables for menus makes the most sense. Tables allow for more precise formatting and alignment than either bullet lists or frames. Tables also allow the use of icons, or small pictures that illustrate the concept of the menu item.
In reasonably short menus, the table consists of several rows, each row dedicated to one menu item. The first column is the icon or image in normal size (such as the 40x40 pixel icon used on the Outreach web site). The second column is the menu item in text. The default cellspacing and cellpadding usually provides sufficient white space between the columns, though this can be adjusted as necessary. Both the icon and the menu item text should be hypertext links to the item being referenced.
The text of the menu item can be simple or complex. Simple text is where each item is just the text of the link. Complex text is where each item is the boldface text, em dash, and an explanation of the item.
In longer menus, especially longer menus using complex text, a double-column table with one row per item may be too long to comfortably fit on one page. The author can, at her discretion, use a double- or triple-format, where each row is used for 2 or 3 menu items. In this instance, you may wish to avail yourself of an html trick.
For example, if there are 15 menu items, you might choose a 3-column and 5-row layout. Having to format them manually by row would mean something like the following:
<TR><td>item 1</td><td>item 6</td><td>item 11</td></TR> <TR><td>item 2</td><td>item 7</td><td>item 12</td></TR> <TR><td>item 3</td><td>item 8</td><td>item 13</td></TR> <TR><td>item 4</td><td>item 9</td><td>item 14</td></TR> <TR><td>item 5</td><td>item 10</td><td>item 15</td></TR>
Adding or removing items becomes problematic, especially when the order has to remain intact (such as alphabetical or numerical). The html trick is to use the AliGN option in the table tag:
<table border=0 AliGN=LEFT> <TR><td>item 1</td></TR> ... <TR><td>item 5</td></TR> </table> <table border=0 AliGN=LEFT> <TR><td>item 6</td></TR> ... <TR><td>item 10</td></TR> </table> <table border=0> <TR><td>item 11</td></TR> ... <TR><td>item 15</td></TR> </table>
The right-most or last table omits the AliGN option.
Should additional white space be needed between menu column pairs, either a cell (<td width="5"> </td>) or an extra table (<table border=0 AliGN=LEFT> <TR><td width=5> </td></TR></table>) can be used, as necessary.
When organizing your web site, there are several important issues to consider. These issues include:
These are discussed in the following sections.
Present a clear ordering of information by subject, or some other form of reasonable entry into your web site. Some useful forms are:
The readers need to be able to find what they are looking for, and a good overview that allows the readers to quickly find a particular topic or document is invaluable.
Only make a document as long as it needs to be. If a document can be logically decomposed into more then one file, do so, but only decompose a document if the narrative branches from the linear structure of the current document. An example of this is breaking a book-length work up into chapters, and further breaking those chapters up into sections. Because of the length of time involved in retrieving documents, making the document available in readable chunks means that the reader can use the information without becoming overwhelmed in loading times and a correspondingly large amounts of information presented a single, huge, scrolling document.
Correspondingly, make sure a document is richly cross-referenced, so that if readers want to ask "Why?" they can. If you can split up supplementary information into separate documents, do so. This allows the reader to follow a main flow of narrative, but still able to look up evidence and additional related stories and information as necessary. But don't put in so many links that the reader gets lost trying to follow them all.
Provide a clear, consistent navigation structure. You should always be able to easily to navigate to all documents which immediately relate, but you should also always be able to get any other document in the web site with a minimum of fuss. Always provide access to the original table of contents, or its equivalent. This is especially important for when others create links to documents in your site, but do not necessarily create links to your main entry points; readers can find themselves in the middle of what is obviously a larger document, but without any means of finding additional information.
![[Contents]](/icons/buttons/toc.gif){kind=icon}
Jump to table of contents
![[Back]](/icons/buttons/previous.gif){kind=icon}
Back to Chapter 4, "Web site structure"
![[Next]](/icons/buttons/next.gif){kind=icon}
Onward to Chapter 6, "Online documentation"
![[Note]](/icons/buttons/lightbulb.gif){kind=icon}