Best Practices Manual

Table of Contents

Who this Document is for
General Dos and Don’ts
Page Format
1. Use of non-HTML formats
2. Multiple formats for a single piece of content
Error handling
1. 404 errors
2. Runtime exceptions
3. Use of action pages
4. Use of a robots.txt file
Navigation
1. Separating site tools from site navigation
2. Including a site’s navigation in the footer
3. Chunking information using the seven plus or minus two rule
4. Site “intro” pages
5. Dropping below the fold
6. Consistent navigation controls
7. Consistent typography throughout navigation
8. The target area for form objects
RSS Feeds
Search Engine Behavior
Timeliness of information
Additional resources

Chapter One—Who this Document is for

This manual is for anyone charged with administering a web site. The intent is to provide web site managers with an easily accessible reference about some best practices for web content management and usability. The NABE Committee charged with putting this document together has not conducted its own user testing, but has drawn from the expertise of usability guru Jakob Nielsen of the Nielsen Norman Group whose usability advice columns are published every other week and made available at www.useit.com.

The majority of the manual however, is born out of the collective experience of the committee members and also practices which are well established in the web usability community.

Chapter Two—General Dos and Don’ts

Do ensure all text links have some visual cue that they are links
It naturally follows that giving links a distinctive visual cue, means NOT giving that visual cue to any other type of text on the site. Whatever formatting you choose should be off limits for anything else on the site. If you go with a certain shade of blue, your unlinked headers should never use this color, no matter how pretty it looks in layout. Visit http://www.useit.com/alertbox/20040510.html for more best practices on text links.
Don’t use “click here” to instruct a user where to click
A link has emphasis. Link too much, and soon everything has emphasis—so nothing does. Also, make sure you are emphasizing useful text. Picture the page with only the linked text and see if you can figure out what the link is for. If you can’t, consider changing the link or the wording.
For example:

Worst: The service committee has many excellent resources on their website.
Bad: The service committee has many excellent resources on their website.
Better: The service committee has many excellent resources on their website.
Better still: There are many excellent resources available on the service committee’s website.

Example two:

Don’t: Click here for a complete listing of upcoming events.
Do: Upcoming events.
Avoid “so-what” content on the home page

Examples includes:

*Messages from the president
*Welcome to our webpage!
*Our mission/vision/creed
* Our history

This material may have value, but it’s almost never important enough to feature on the homepage. In print publications, a message from the president column always ranks among the least read in the publication and there’s no reason to believe they are any more popular in web publishing. To the contrary, people are coming to your site because they have some task to complete (I.E. pay dues, register for an event, update address information, etc.) and home page clutter (like that listed above) only reduces a page’s “visual digestibility” and gets in the way of them completing that task.
Use consistent terminology to describe site elements
Don’t call the user registration form a “signup form” in one place, and a “new user form” someplace else. Consistent terms aid navigation and reinforce a user’s navigation choices. If your user clicks on a link that says “Free trial” and ends up on a page that calls itself a “Registration form” they will wonder if they’re in the right place. Give your site elements names and enforce their usage.

Chapter Three—Page Format

Use of non-HTML formats

Non-HTML formats refers to PDF, Word, PowerPoint documents, etc. The following guidelines use PDF as an example, but the rules apply to other non-HTML formats as well since the usability problems are the same.

PDF
When to use it
Nearly all web pages should be formatted as HTML or XHTML. However, for occasions when a web page is intended specifically to be printed, as would be the case with a user manual, or book, PDF may be an acceptable alternative.

Why not to use it
Use of PDF should be limited to the very infrequent occasions where a page is to be printed for the following reasons:
1. From useit.com at http://www.useit.com/alertbox/20030714.html.
  
  “Users get lost inside PDF files, which are typically big, linear text blobs optimized for print and unpleasant to read and navigate online. PDF is good for printing, but that's it. Don't use it for online presentation.”
  
  “PDF files are typically converted from documents intended for print, so the authors wouldn’t have followed the guidelines for web writing.”
  
  “PDF lives in its own environment with different command and menus. Even simple things like printing or saving documents are difficult because standard browser commands don’t work.”
  
  “You’re more likely to crash users’ computers if you serve them a PDF file.”
  
  “PDF layouts are often optimized for a sheet of paper.”
2. From useit.com at http://www.useit.com/alertbox/20010610.html
  
  “Forcing users to browse PDF file makes usability approximately 300% worse compared to HTML pages. Only use PDF for documents users are likely to print.”

How to use it

Never dump a user directly into a PDF file without fair warning. “Fair warning” means presenting the user with a gateway page in front of the PDF that provides the following information about the document.
1. The page count.
2. The size in KB.
3. A description of what the document is.
Because users should never be dumped directly into PDFs, but gateway pages instead, PDFs should not be included in site wide keyword search collections since clicking a link to a PDF in the result set of a keyword search would take them directly to the file. Instead, index the gateway page in your search collections.
Do not allow the PDF to be opened in the browser’s Acrobat Reader plugin. Instead, create a hyperlink that invokes the Save As dialog box so the user may save a copy of the file to his or her own computer. This link should read, “Download and save now,” rather than some more conventional labeling. This is because the action that occurs upon clicking the link is different from the action the user is conditioned to expect—that is, just having the document open. Labeling the link “Download and save now” counters the confusion they might otherwise experience when the Save As prompt appears instead of the document itself.

Forcing the Save As dialog box is accomplished by overwriting the page request’s content-disposition header with “attachment; filename='file_name.pdf' where “file_name.pdf” is the name to be given to the file during the save.

An example of the code to invoke the Save As window follows. The example uses ColdFusion syntax, but may be adjusted as appropriate for other languages.

<cfheader name="content-disposition" value="attachment; filename=fileName.pdf">
<cfcontent type="application/pdf" file="c:\inetpub\wwwroot\filename.pdf" deletefile="no" reset="no">

In the example above, there is a second line of code beginning with a <cfcontent> tag. In the case of a PDF document, it is obviously impossible to add the first line of code directly to a PDF file as could be done with an ASP, ColdFusion, PHP, etc. file type. To get around this, one must create a template that serves a PDF file as its content. The value of the file attribute in the cfcontent tag should point to the path where the PDF to be downloaded resides on your web server. These two lines of code working together will invoke the Save As dialog box and allow PDFs to be downloaded rather than to have them open directly in the browser window.

Multiple Formats for a Single Piece of Content
Publishing a piece of content in several different formats like Word, WordPerfect and PDF, etc. should almost never be done as it adds clutter to the web page and subjects the user to making a choice they shouldn’t have to. A site visitor should only have to focus on completing whatever task they are at your site to complete—not the format of the content. That’s your job, so don’t pass the burden off on the user.

Having said that, there may be very infrequent occasions when you know with absolute certainty that your users require something in one or more specific formats. Should such an occasion arise, it is permissible to offer the content in those formats. This should never be done merely to offer a different way of reading the same content, but when the format is somehow tied to the functionality of the content.

Chapter Four—Error Handling

Some best practices for error handling might sound like technical issues. In fact, they are, but they also directly effect the usability of a web site.

404 Errors
404 errors are thrown when the requested page cannot be found. This obviously has a detrimental effect on usability as it discourages the user and lessens the likelihood they will stay on your site if they can’t find what they’re after. To lessen the effect, always specify a custom 404 error template in your server. This may not be possible for web sites hosted on shared servers where you don’t have administrative access to the server itself. In that case, there is little you can do. But when possible, there should be a custom 404 handler with the following traits.
1. The file should look like one of your site’s pages instead of the server’s ugly default error pages.
2. The file should send an email to the site administrator specifying the page requested when the error was thrown and also the address of the referring page so the link on that page may be repaired.
3. The page should tell the user that an email has just been sent to the site administrator so the user can see that the site is being well maintained.
4. It should enable a site wide keyword search so the user may continue searching for what they were looking for when the error was thrown instead of feeling like they hit a dead end.
Runtime exceptions
A runtime exception is anything that disrupts the normal execution of a web page. Like 404 errors, these too should be dealt with using a custom exception template. Failure to do so not only hurts the usability of your site, but may also expose sensitive information about your site’s inner workings. Information which could potentially be very beneficial to a hacker. The template should:
1. Look like one of your site’s pages.
2. Shield the user from potentially sensitive information.
3. Send an email to the site administrator containing complete diagnostic information so the problem may be repaired.
4. Notify the user that an email informing the site administrator of the error has just been sent so the user gets the sense that the site is being well maintained.
Action pages
All action pages (the pages that process parameters fed into them from HTML forms or other sources) should check the value of the referring page. If it isn’t what it should be, the request should redirect to a more appropriate page. If an action page which relies on parameters appears in a site wide keyword search, a user may simply click the link to that page without any way of providing the necessary parameters. In this case, the action page should redirect to some page where parameters may be specified. This both prevents an error from being thrown, but also gets the user where they need to be.
Always use a robots.txt file
Search engines index web sites by using “spiders” to crawl the web updating their indexes as they do. When a spider comes to your site, it begins this process by looking for a robots.txt file in the site root. Robots.txt instructs the spider on what parts of the site to index and what parts to leave alone. Examples of things you may want left alone are administrative folders, folders containing areas still under development, or things which are otherwise not of interest to the general public. Without using a robots.txt file, the spider will index as much on your site as it can meaning that a user may stumble upon some irrelevant page on your site via a search engine if you don't instruct the spider about how to index your site. Creating a robots.txt is very simple and there are many online tutorials to instruct you on how to do it. Just type “robots.txt tutorial” into your favorite search engine.

Chapter Five—Navigation

Separating site tools from navigation
Intermingling site tools with top-tier content navigation should be avoided. Site tools refers to things such as login, site map, site wide keyword search functions, a contact page, etc. Content navigation refers to the options that allow a user to navigation to your site’s substantive content. While it may be appropriate to have something like a Contact Us option under an About the Bar type heading, Contact Us should be treated as a child of About the Bar and not a sibling.
Including a site’s navigation in the footer
Including a site’s navigation in the footer of the page is unnecessarily redundant and adds clutter to a page. This is an antiquated technique to ensure accessibility of a site’s navigation for legacy browsers that may have had difficulty predictably rendering more technically sophisticated navigation and should not be done today.
Chunking information using the seven plus or minus two rule
The 7 plus or minus 2 rule was a concept introduced by psychologist George Miller in 1956. While the theory is considered sound, Miller was referring to the ability of a human to retain seven pieces of information at once in short-term memory. The concept has been applied to web sites, but is not really always applicable to web site design since use of a web site rarely relies on a user’s ability to hold the navigation in memory. To the contrary, navigation is generally available on every page within a site so there’s no need to memorize it at all.

Information chunking however should still practiced, but this is as much an art as a science and it is difficult to provide hard fast rules that could be considered “best practices” for bar web sites. Chunking refers to the grouping of related types of information. When visiting the supermarket for example, all the fruit is in the produce section and not scattered at random throughout the store. In this example, the fruit has been “chunked” into the produce section. Likewise the seafood department chunks anything from the ocean into a single department so a shopper in search of shrimp doesn’t have to wander around the store aimlessly hoping to stumble upon it.

By chunking your site’s content into logical groupings, you allow a user to drill down from broad navigational heading to those that are more specific until reaching the desired page. Visual cues such as different colors, font sizes and position on the screen all help to separate these information chunks and also to specify the position of a navigational heading within the site’s hierarchy thereby giving the user a point of reference.
Do not include “intro” pages into a site
Allow users to get directly to the home page without there being any site introduction pages getting in the way. Strive to make the site “transparent” to the user, meaning that it doesn’t get in the way of the users performing their tasks.
Dropping below the fold
Think of a newspaper that has been folded to show the headlines prominently. When unfolded, the bottom half of the newspaper becomes visible and displays secondary headlines. This same concept maybe applied to web pages where the “fold” is said to be the bottom of the browser window. The fold may be in different places on the same page depending on the resolution setting of the user’s computer monitor. However, assuming an 800x600 monitor resolution (showing 800 pixels across the monitor and 600 pixels from top to bottom), a site’s navigation should never drop below that fold. The content on a lengthy page may drop below it, but never the navigation. Always view your pages with an 800x600 monitor setting to be sure all navigation stays above the fold.
Main navigation must remain constant throughout the site
Ensure that the main navigation of a site remains constant throughout the entire site. You may want to supplement main navigation with some navigational controls specific to each area of the site while in that area, but top-level navigational controls should remain constant.
Consistency in fonts throughout navigation
All fonts within a single navigational group should use the same font family, size and color. To differentiate one group from another, and to differentiate a child group from its parent, it may be permissible to use different sized fonts, but everything within the same group should be identical to reinforce the perception that all elements within that group belong together.
Increasing the target area for form objects
Always use the <label> tag for radio and checkboxes on forms to provide as large a clickable target area as possible. Consult an HTML reference on use of the <label> tag.

Chapter Six—RSS Feeds

Many sites now offering an RSS feed are creating links that take the user directly to the XML source file where XML code is displayed in the browser creating the perception that an error has occurred, rather than that the site is working properly. To eliminate this:

Never create a link that points directly to an RSS’s XML file. Instead, there should be a page that provides the address for the XML file, but that address should not be displayed as a hyperlink.
This page should also have a very pithy instruction on how to subscribe to the feed by entering the provided address into an RSS aggregator. Because at the time of this writing RSS is so new, you may even wish to provide a Q&A section talking about what RSS is.
Apply a style sheet to your XML document. In the event a user should request the XML file in a browser, this will ensure that it at least displays nicely instead of just dumping out code.

For a perfect example of how to handle RSS, visit the Macromedia RSS feed center at www.markme.com/notifications.

Chapter Seven—Search Engine Behavior

Given how popular the Google search engine is and how accustomed users have become to its search behavior, we should strive to make the search engines on our own sites mimic that behavior as closely as possible for two reasons. One, the user won’t be surprised by the results, and two, the user won’t need to learn a second method for submitting search terms.

To begin, the default behavior of your site’s search engine may be to conduct a case-sensitive search when the user submits a string made up of mixed-case characters. Google searches however are not case-sensitive. So, best practice number one for search engines is to ensure that searches are not case-sensitive. If your site uses Verity as its search engine, you can do this using the Lcase() function which converts the entire string to lower case. When using Verity, lower case strings are treated as case-insensitive searches in the style of Google.

Google also inserts a logical “AND” between all search terms not enclosed in quotes. That means that when entering Best Practices Manual to Google, the search string is altered to read Best AND Practices AND Manual. Therefore, best practice number two is to manipulate the search strings not enclosed in quotes so that spaces are replaced with “ AND ”. That’s a space, then the word AND followed by another space.

If the user submits a search string containing terms enclosed in quotes, those strings must be preserved and treated as a single phrase, not a set of multiple search terms. For example, the user may submit "Best Practices Manual". In this case, the string must be preserved without there being any logical AND inserted between the terms. There may even be times when a user submits a string with only some of the terms enclosed in quotes. In a case like that, the quoted section should be preseved with logical AND operators inserted between the search terms in the non-quoted part of the string.

Google omits common words like conjunctions, articles and prepositions from the submitted search string to speed up search execution. Special characters should also be removed from the search string so best practice rule number four is to remove common words and special characters from the search string.

Lastly, it should be possible for a user to exclude a word from your search by placing a minus sign (-) immediately before that word. Any documents containing that word would then be exluded from the search.

In summary, the best practices for search engine behavior are:

Ensure that your searches are not case-sensitive.
Insert a logical AND operator between all non-quoted search terms.
Preserve quoted search strings without inserting any operators between words at all.
Omit common words to speed up search execution.
Enable word exlusion by allowing the user to insert a minus sign immediately before the word to be excluded.

Sites running ColdFusion may take advantage of the search UDF which has all this functionality wrapped up in a single function. To use:

View the UDF’s code.
Copy and paste that code to a plain text file on your web server. Name the file search.cfm.
Include search.cfm on your search page.
To call the function use search() and pass the value of the search terms submmitted by the user to the function. An example would look like #search(FORM.search_terms)#.

Chapter Eight—Timeliness of Information

Few things make a site appear to be as ignored and poorly maintained as outdated information. There is little more to say here other than that once an event listing, news item, or any other piece of content has become stale, remove it.

Chapter Nine—Additional resources