Documents
Lower levels of a site often contain "documents" -- sets of pages that together form a coherent whole. A document may be read from beginning to end, or it may be browsed in any order, including sections and reversed sections of the usual beginning-to-end order, depending on what the reader wants to find out. The "Where am I?" and "Where is it?" questions are just as important in these pages as in the rest of ths site.The structure of a document is not random. Just as in print, documents are structured so that related material tends to be near other related material. Do not use hyperlinks as a excuse to avoid doing the work needed to make this so. The natural trail of a document is from beginning to end, and the document needs to provide this. Note that the trail doesn't imply that a reader will read from start to end, but a good structure that allows such a trail will also enable a reader to take advantage of the proximity of related material to locate required information.
The trail, in case it isn't obvious, must go up and down the document hierarchy as appropriate -- just like turning pages in a book.
As important as a linear trail is a full, hierarchical, table of contents. Michael Hoff argues, in his article Enabling Extremely Rapid Navigation in Your Web or Document, that the hierarchical TOC and a hierarchical index are the most important tools for navigation. He raises many good points, the key one being that just because hypertext is a new medium, it does not mean that tried and proven tools for finding information (the TOC and index) are suddenly ineffective.
He also says that scrolling is better than hyperlinking through separate pages -- in other words, do not split your document into separate pages. I think he is very wrong (not to mention strident) on that count. His page is a good example of why he is wrong -- go read it and judge for yourself.
Having said that, the full hierarchical TOC is extremely valuable in answering the "Where is it?" question. An index is less useful, I think, and I am not sure whether it is more useful than a search engine that has a reasonable pattern syntax.
Needless to say, the TOC should be linked from every page in the document. Finally, before presenting some examples, it is worth overstating the obvious:
Can I say that again? Poor writing, content, or structure, will nullify much or most of any effort that might be put into building effective navigation into a document.
Examples
- Dmitry's design lab
- One of the sections of the (mostly) excellent Webreference page.
(This particular article, by the way, is worth reading.) Documents in
this site feature a row of small icons at the top and bottom of each
page that looks like this:
This is a brilliant idea! It very neatly and compactly provides both a location cue to the reader (the second page of a five-page article), and the links in the start-to-end trail. It also gives you random access to any other location in the trail, but fails to provide any cues on what those locations might be. There is a simple fix to that problem (leave the mouse over an arrow):
I don't know why they didn't do that. One clever trick they have used is to specify the image size, so that you don't get those big ugly "no-image-loaded" icons if you have image loading turned off.
What is missing from this aid is a link to an overall table of contents. Although it may be unnecessary for a five-page document, I would still prefer to have it. In longer documents, such as HTML Unleashed: Internationalizing HTML, they have placed a hierarchical table of contents on the first page, but I think it would have been more useful on a separate page and with a special button on each page for it, like this:
(Although with a more distinctive icon.) This would neatly solve the problems of random access in longer and more structured documents. I think this technique would work for documents up to perhaps twenty pages. Above that, left-hand margin indexes might work better.
(The book HTML Unleashed, by the way, got a couple of extremely poor reviews on Amazon.com.)
- HTML 4.0 Specification
-
The specification for HTML 4.0 is a large (363 pages printed)
technical document that uses a compromise between the
Hoff's single-page model and the card model. The first page
is a complete hierarchical table of contents, and each
chapter is on a single page. Each page is headed by a
TOC for that chapter, and each page has links to
the previous and next chapters.
Nonetheless, each page is still too large, and there is no easy way to get from the middle of the page to the contents list, or to the navigation links at the top and botton of the page. I would make each section a separate page.
The most excellent feature this document does sport is a full, hierarchical index. It also contains indexs of elements and attributes, a feature that could and should be generalized in technical reference documents.
- Cascading Style Sheets, level 1
- The specification for CSS level 1, by contrast, is a single, 180k document that takes almost too long to load on my UltraSparc 2 with a 100 Mbit Ethernet connection -- lord knows how long it takes over a modem, It laudably contains a full TOC at the start, and cross-links within itself, but is otherwise a prime example of why the single-page long document does not work effectively.
- GNU Make -- A Program for Directing Recompilation
- The on-line version of the documentation for GNU Make places
each section on a separate page, with links to the previous and next
section. The trail correctly goes up and down the document
hierarchy. Although there are no location cues within the manual, the
trail, together with the hierarchical table of contents, make for
reasonable easy browsing. What is interesting about this is that is is
(I think) a conversion of emacs texinfo format, which has been
around a lot longer than HTML.
What is not so laudable is the fact that the material is poorly written, making some information very difficult to find anyway.
This manual also has a hierarchical index. The index is almost rendered useless by the fact that it does not link to a location within each page; as a result, you have to search through a page looking for the topic you clicked in the index.
