How to Design a Table of Contents
By Steve Toub
There's something in our human nature that makes us want to dive into things, to browse, to dabble. We first try to program our VCRs without looking at the manual. We drive for awhile; if we get lost, we look at a map or ask directions (or not, depending on our gender).
When we visit a Web site, we dive right in. We take the default path through the site, stopping for instructions or directions only when we're confused, when we're tired of browsing, or when we have a very specific task to complete. At these times, we often depend on a table of contents. (I frequently use the phrase "table of contents," but other terms such as "contents," "site contents," and "site map" are acceptable and often preferable on the Web.)
A contents page provides an overview of the entirety of content. Since a table of contents represents the way a document collection is organized, it shows the way content is grouped and labeled, and it shows the relationships between those content elements. It also lets users navigate to find particular areas. A table of contents in a print publication or a map in a shopping mall merely points you to a certain location. Hyperlinks on a Web table of contents transport users immediately. The structure of a table of contents also facilitates serendipitous browsing, similar to what happens when you look up a book in the library, and find that the books on the shelf nearby are more relevant to you than the one you initially sought.
A table of contents is an effective tool to quickly explain what the site is for and why users may want to visit. It can help orient lost users, help educate users about the site contents, and help users navigate through the site. Most sites should aim to meet these goals. If your site is relatively small (anything less than, say, 20 pages) or largely experiential (like hypertext fiction) rather than informational, you may not need a table of contents. However, the vast majority of Web sites should have something that provides this functionality.
It's easier to create a table of contents for a site that has a strong hierarchy, but even a flat, database-like site may need one. In print media, even a dictionary has a table of contents, which is invaluable for answering questions such as "Is the guide to editorial style in the front or the back?" and "Does this dictionary have a section for foreign words and phrases?"
A table of contents is not only useful to site visitors; it can be helpful for Webmasters as well. It shows you where content is deep or shallow, whether there are inconsistencies in the way content is grouped and labeled, whether groupings and labels fit user tasks, and whether labels are direct and unambiguous.
Design Options
There's no one right way to implement a table of contents. It can vary from a simple text representation to a 3D application that takes advantage of VRML, such as the page in Figure 1. Parameters to consider as you design a table of contents include:
Components. The most common components are titles of sections and pages, and visual elements representing the relationship between content elements. A table of contents sometimes includes other components, such as phrases or sentences describing the content, icons representing the content, and thumbnail images of pages.
Depth. Most tables of contents fall somewhere between the extremes of presenting only the top level of the hierarchy and presenting every element of every page of every section of the site.
Visual Arrangement. Color, size, and the amount of images and text used vary widely. The table of contents can have a vertical, horizontal, columnar, or other orientation. It can look like an outline, like a hub-and-spokes format, or any other 2D or 3D representation.
Feedback and Interactivity. While plain vanilla HTML is the norm, many tables of contents now offer some rollover effects (information that's displayed when the mouse passes over an entry -- for example, color changes or "tool tips"), as well as some capacity for interaction such as the ability to collapse or expand nodes of the hierarchy. Figure 2 demonstrates this well.
Location Within the Browser Window. Traditionally, the table of contents has been a separate, stand-alone HTML page like other pages in a site. Many sites now feature tables of contents that appear on every page layout. It's also possible to launch the table of contents in a separate window; it might appear similar to a help application. Figure 3 shows a table of contents in a separate window, combined with links to an index and search engine.
Design Guidelines
Based on my use of tables of contents on the Web and my experience in testing their usability, here are some guidelines to consider when designing a table of contents for your site.
Availability. Make sure users can find it easily. With regard to the location of navigation elements, conventions for the Web aren't as established as they are for shopping malls and books. While not all navigation tools (for example, a contents page or a search engine) should be visible in their entirety on every page of the site, ideally they should be one click away via the global navigation bar. Users need to know that a table of contents is there if they need it, and they should be able to get to it quickly.
Balance. Strike a balance in length. Users tell me that they want the table of contents to provide a high level of detail while fitting on a single page. This paradox reflects the fact that the twin goals of a table of contents -- providing an overview while encouraging navigation to specific areas -- are somewhat contradictory. When forced to make a choice between providing ample detail and making everything fit on a page, every usability test participant told me they preferred more detail, even if they had to scroll as a result. When designing a table of contents, provide more than just the top level of the hierarchy, but make absolutely sure that users can easily scan through the top-level groupings. Limit the length of the default page to no more than two or three screens; when users scroll down through longer tables of contents to scan the top-level groupings, they tend to forget about the first groupings by the time they reach the end. Collapsible/expandable implementations help solve this problem, at the expense of increased complexity or latency. For a static implementation, you don't need to include every page of the site; rather, provide enough detail (two to three levels down in the hierarchy) so that users can get a sense of what's there.
Contrast. Use visual contrast to make scanning easy. Your groupings and relationships should have enough contrast (via layout, color, size, or font) to facilitate easy scanning of the hierarchy. A good way to gauge the level of contrast is to slide your chair back a few feet and see if you can focus on (but not necessarily read) the top-level groupings, and see the relationships between the different elements. Keep in mind that too much visual contrast can be distracting; simply indenting the hierarchy is often sufficient.
Organization. Reflect the organization scheme of the site accurately. A table of contents should represent the entire site, not portions of it. The labels and groupings within the table of contents should mirror the labels and groupings of the site content exactly. If the labels on your site seem fuzzy or ambiguous, now is a good time to change them; your goal should be to make labels precise so that their meanings are unambiguous, while keeping them as short as possible.
Show, Don't Tell. Usability experts say -- and my usability experience confirms -- that people tend not to read narrative on the Web. Rather than using a sentence to describe what Section X contains, show users its subsections. If you feel like you must have narrative, relegate this to a different area of the site, like a welcome letter, a site tour, or a guide for new users.
Text. Focus on textual labels and their arrangement, not on extraneous information. Text is usually the most efficient way to present an overview. Eliminate unnecessary numbers, symbols, and graphics, keeping only what's necessary for conveying groupings and relationships between elements. The point is to make scanning the table of contents as easy as possible.
Uniformity. A table of contents is neither a billboard attempting to draw users to certain portions of the site, nor a place to highlight new or popular content. It should present like elements equally, providing an objective overview of the entirety of content.
Clickability. Give users enough room to click. While many tables of contents do not hyperlink the textual labels because of the "sea of blue" effect, forcing users to click on a tiny icon may be a worse alternative. Many users, especially older users, need a wide berth to place their mouse.
Interactivity. Implement interactive applications with discretion. An interactive table of contents (via Shockwave, DHTML, Java, or ActiveX, for example) lets users collapse and expand the table's hierarchy to their liking. While this is a nice (functional) feature, consider how long it takes to download on to the user's machine, and whether it requires users to download plug-ins or other tools. If the benefits of a media-rich technology outweigh the costs and you decide to implement this kind of application, make sure you also provide a version that's accessible to browsers that handle only text.
The Bottom Line
People will be people. You can't stop Web users from meandering through your site, browsing through pages in any order they wish. That, in fact, is the beauty of the Web.
However, when users don't want to meander or when they get tired, lost, or confused while doing so, it's your duty to provide an alternative in the form of a table of contents, as well as other navigation tools (see the box titled "Navigation Shortcuts" for some products that can make your job easier).
Keep in mind that a perfect table of contents can't make up for a weak information architecture. Ideally, the architecture of your site will anticipate users' needs and expectations so well that they won't have to use your (perfect) table of contents.
Steve holds an M.S. in Information from the University of Michigan Library School. He designs Web sites -- and the tables of contents that represent them -- at Argus Associates ( argus-inc.com), an information architecture design firm.
