Practical Magic:
Issues In Link Planning and Design

By NEIL PERLIN
Boston Chapter

Tables of contents and indices have consistent and familiar designs that evolved in the print world and carried over to online.  Links, however, are so new that they’re still evolving.  Today, eleven years after WinHelp appeared, many developers still struggle with three questions about links:

• What level of terms should I link?
• How many links should I have in a topic?
• Where should I put the links?

As with many design questions, there are no single answers.  Instead, there are tradeoffs.  This column discusses those tradeoffs to help you make the most appropriate design decisions.

What Level of Terms Should I Link?

This seems like a simple question.  Link dialog box names, field names, and so forth.  But the real issue is not so much what terms to link as it is what terms to link based on the audience.

For example, let’s say you’re writing an online book on radar systems.  The term “radar” appears many times in many topics.  Should you link each instance of the term to a topic that introduces the concept of radar?

When I ask this question, many people say yes because “radar” is a new concept.  On reflection, however, it’s impossible to answer this question without defining the audience.  If you’re writing for a lay audience, then it makes sense to link the term.  But if you’re writing for an audience of avionics technicians, it doesn’t make sense to link the term because the readers already know what radar is.  In fact, linking “radar” when writing for the avionics techs, or linking any basic term when writing for advanced or experienced readers, will cause you three problems:

• The more basic the term the more often it will appear, so you add work for yourself since you increase the number of links to create.
  
  
• Since basic terms appear often, topics will be cluttered with the color and underlining that indicates text links.  You can unclutter the display by turning off the color and underlining, but you then have to tell users that the links are there since, without those visual cues, many users may assume that there are no links.
  
  
• The more basic terms you link, the greater the risk of losing credibility with the audience. 

Fortunately, there’s a simple solution — perform audience analysis.  Many people don’t — because they haven’t been trained to, because they don’t think they have time, or because the company’s culture doesn’t require it.  But the more you know about the audience, the better your links will be.

Bear in mind also that audience analysis may be more important for contract developers than for those with full-time jobs.  Developers in full-time jobs often get to know the audience well enough to make their own link level decisions.  However, if you’re a contractor, you may bounce from job to job, with different audiences, and never get to know any of them well.  This means it’s crucial to coordinate with the client in order to understand the audience.  (If you’re a project manager, you’ll have to stress the need for this coordination to your contract developers.)

How Many Links Should I Have In A Topic?

Is there a minimum or maximum number of links per topic?  Developers have debated this forever with no good answer.  A common rule of thumb is “7 plus or minus 2,” which is actually the figure for short-term memory retention.  However, I’ve always argued against this on two bases:

• It’s irrelevant.  Links are always visible so readers don’t have to remember anything.
  
  
• It’s arbitrary, inflexible, and fails to account for the fact that different types of material may simply require different numbers of links.

I simply advocate using as many links as necessary and no more, period.

Where Should I Place the Links?

I discussed this question in a column in 1995, and the options are largely the same.  There are three approaches:

• Put all links at the bottom of each topic under a “See Also” heading or button.  There are no links in the topics’ body text.
  
  
• Display links in the topics’ body text.
  
  
• Put all links in the title region at the top of each topic under a “See Also” heading or button.  There are no links in the topics’ body text.

Evaluating these approaches requires balancing four goals:

• Immediacy of access.
  
  
• Minimized risk losing the starting topic of a link chain.
  
  
• Quick and convenient explanations of new terms.
  
  
• Clean interfaces.

Let's look at the three approaches.

A “See Also” List At the Bottom of the Topic

The practice of putting all links in a “See Also” list at the bottom of each topic began with WinHelp 3.1 and continues in the Related Topics buttons or links at the bottom of topics in the Windows 95 and 98 help.

The benefits:

• Familiarity.  Many readers are accustomed to scrolling to the bottom of a topic to look for a “See Also” list.
  
  
• An uncluttered interface without splotches of colored, underlined text.
  
  
• Elimination of the need to decide how often to link multiple instances of a term within one topic.  (More on this in the next section.)

The drawbacks:

• Loss of immediacy.  Readers must scroll to the bottom of the topic (and click a “See Also” button) to see if the desired term is linked.  If all your topics are short enough to not need scrolling, this is not a problem.  Otherwise…
  
  
• The need to scroll to the bottom of a topic can make readers lose their place in the topic.  For example, let’s say a reader finds the new term “polymers” on the second screen of a topic and want more information about it.  He scrolls to the bottom of the topic, finds a link for “polymers” and clicks it to jump to the related topic.  After reading that topic, he clicks the Back button to return to the starting topic, the one in which he found the “polymers,” term, to keep reading.  However, clicking the Back button actually takes him to the “See Also” list at the bottom of the topic, not to the place where he found the term “polymers.”  He has to scroll up to that place, if he can remember where it was. The need to re-find a position sounds simple until you do it on a regular basis.  Then it becomes a real irritant.

Linking in Context

An alternative is to create links within the body text and skip the “See Also” list.  In other words, if the term “polymers” appears in paragraph two, link it there.

The benefits:

• Immediacy.
  
  
• Reduced risk of readers losing their place.

The drawbacks:

• A cluttered interface with lots of splashes of colored, underlined text on the screen.
  
  
• Difficulty deciding how often to link a term that occurs repeatedly within the same topic, especially if you use link anchors (that is, targets or mid-topic jumps).

  For example, let’s say the term “polymers” appears several times within a topic and you need to link it to a separate Polymers topic.  Standard practice is to link just the first instance of the term.  This gives readers a link when the term is (presumably) new to them, without the distraction of repetitions of the link.  This is fine as long as you don’t use link anchors.

  What if you only link the first instance of the term but then add a link anchor that takes the reader into the topic below the linked instance of the term?  Now, the reader may see the term and wonder what it means but be unable to find out because the linked instance is further up in the topic and out of view.  In this case, the reader has to realize the need to scroll up to find the link.  Very few readers ever realize this.

  Juggling the use of link anchors and linking multiple instances of the same term is difficult to begin with.  It’s more so if you’re adding link anchors to online material as part of an upgrade, since you may not be familiar with the original design and might not realize that the original developer only linked the first instance of a link term in each topic.  The only way to avoid this problem is to know your material and to write comprehensive specs as part of any online project in order to help your successor.

A “See Also” List At the Top of the Topic

This approach is similar to the first in that it also uses a “See Also” button or link but puts it at the top of the topic, in the title region, rather than at the bottom.

The benefits:

• Immediacy.  The “See Also” is visible as soon as the topic opens.
  
  
• The clean interface. 
  
  
• No more difficulty deciding how often to link a term that occurs repeatedly within the same topic, especially if you use link anchors.
  
  
• Reduced risk of readers losing their place.

The drawbacks:

• This approach dates back to the WinHelp days and is predicated on using a non-scrolling title banner to keep the “See Also” visible as readers scroll up and down a topic.  HTML-based help eliminated the non-scrolling banner feature, replacing it with the frameset, so this approach isn’t as convenient as it used to be.  If your topics are short enough so as not to scroll, then this approach is basically a more effective version of the “See Also” at the bottom approach.  If your topics do scroll, however, and if you don’t want to create a frameset for each topic in order to duplicate WinHelp’s non-scrolling banner effect, then you may decide that this approach just isn’t worth the effort.

Summary