One of the most difficult design problems in creating a hypertext document is deciding where to position go-to links in a topic. There are three possible approaches, each with their own benefits, drawbacks, and effects on usability. In order of their most common usage, these approaches are:

• List the go-to links at the bottom of each topic under a "See Also" heading and nowhere else.

• Display the go-to links in context, when each link term appears in a topic's contents, and omit the "See Also" list.

• List the go-to links in a pop-up topic that readers access by clicking a "See Also" button or icon in the topic's title region.

How can you evaluate these approaches? One way is to try to balance four goals:

• Make each go-to link as immediate as possible. The less scrolling or clicking that readers must do, the faster they'll reach the information they want.

• Minimize the risk of readers losing their place in the topic they're starting from. The easier it is to backtrack to the starting point of a link chain, the happier readers will be.

• Link a new term the first time readers may encounter it. The less hunting your readers must do, the happier they'll be.

• Keep the interface clean.

Let's take a look at the three approaches.

The 'See Also' List At the End of the Topic
The most widely used approach is to place all go-to links in a topic under a "See Also" head at the end of the topic. Some authoring tools automate this approach.

This approach has the benefit of familiarity. Many readers are accustomed to scrolling to the bottom of a topic to look for a "See Also" list. This approach also provides a clean interface since it doesn't scatter splotches of green text all over the screen. Finally, it eliminates the problem of trying to decide how often to link multiple occurrences of the same term in one topic.

A problem with this approach is loss of immediacy; readers must scroll to the bottom of the topic to see whether a particular term is linked. This can also make readers forget where they were in the topic. For example, assume that you find the unfamiliar term "polymers" on the second screen of a topic and want more information, so you scroll to the bottom of the topic and look for a "polymers" link. Assuming you find it, you jump to the related topic. After reading that topic, you click the Back button to return to your starting topic. However, this takes you to the "See Also" list at the bottom of that topic or back to the top of the topic, not to the place where you found the term "polymers." You must scroll up and hunt for that place, if you can remember where it was. The fact that it's easy to lose your place within a topic reduces usability.

Linking in Context
Another common approach is to show all links in a topic in context and skip the "See Also" list. In other words, if the term "polymers" appears in the second paragraph, link it right there.

The benefits of this approach are that the links are immediate and there's less risk of readers losing their place in the starting topic.

A drawback is the fact that heavy linking splashes green text all around, which annoys many readers. In addition, you must worry about linking each term the first time readers might see it, a complex problem if you used mid-topic jumps. If the term "polymers" appears near the top of a topic and again after a mid-topic entry point, you must link it in each place. If you don't, readers who access a topic via a mid-topic jump and see the unlinked term "polymers" may not think to or want to bother scrolling up to see if you linked the term elsewhere. Trying to account for mid-topic jumps when linking multiple occurrences of the same term is a major link management task.

The Pop-Up 'See Also' List
The third approach, a relatively new one, is to list each topic's links in a separate pop-up topic. Readers access this list by clicking a "See Also" button or icon in the starting topic's title region or toolbar. They then click on the desired term in the pop-up to go to that topic. This offers the benefits of the other two approaches while avoiding most of their drawbacks, and is becoming more common.

The links are less immediate than they are in the second approach since it requires a mouse click to see them. But they're more immediate than in the traditional "See Also" list since readers don't have to scroll to the bottom of the topic to see whether a term was linked. This approach also avoids the risk of readers losing their place in a topic. It creates a cleaner interface. Finally, it eliminates having to determine each entry point into each topic and find and link the first occurrence of each link term after each entry point.

Summary
The third approach avoids many problems found in the other two and seems to be the best choice. Before using it, however, consider this. Are you just creating a WinHelp file, for example, or do you also want to convert the RTF file to a DOC file to create hard-copy also? If it's the latter, the third placement approach may create a management problem since you have to decide where to place the pop-up topics within the RTF file. If you're just creating a help file, you can place each pop-up topic right after the topic it's tied to. However, this is less effective if you'll use the RTF file to create hard-copy also since each true topic will be followed by a pop-up topic that you'll have to delete. The solution is to put all the pop-up topics at the end of the RTF file where you can easily delete them for the hard-copy version. You may spend more time jumping around the file during authoring, though. All too often there's no definitive answer, and this is one of those cases.

Note: If there's a specific topic that you'd like to see covered in this column, please feel free to contact me directly.