Doug Engelbart always said that backpointers were necessary. I just encountered a concrete example that points out why.    (01)

If a chunk of text is referenced in several difference contexts--perhaps linked in one and included in another--then /backpointers/ show where they are. They let you see where and how a particular segment of information is being used.    (02)

Mechanically, backpointers are very much like links. In fact, they are essentially links with a type tag that says "I'm pointing backwards".    (03)

Note: Type tags on links are something else that Doug always claimed as necessary. They were actually implemented in the NLS system he demonstrated in 1968, and never seen since. (For more on "The Mother of all Demos", see Doug Englebart's NLS System).    (04)

It's important to identify backlinks because they have different /semantics/ than regular links. So while forward links and link-transclusions would be automatically processed when displaying a document, back-pointers might not be seen unless you ask for them.    (06)

A concrete example will make it easier to see why backpointers are vital.    (07)

In my role at Sun Microsystems, I've had an opportunity to think about to structure the installation pages for the Java platform. The Document Information Typing Architecture (DITA) looks like a natural fit here because:    (08)

• With small deltas, the instructions for Linux and Solaris are virtually identical.    (09)
• The instructions for the 64-bit architectures are a clean super-set of the 32-bit architectures. It would be nice if the 64-bit folks had one set of instructions, and it would also be nice if the 32-bit readers didn't have to read around the 64-bit information.    (010)
• The material for some add-on technologies (browser plugins for example, and Java Web Start) apply to both the development kit (JDK) and runtime utility ("runtime environment", or JRE).    (011)

There are a few other opportunities for reuse, but those are the major ones.    (012)

The issue to be solved came up when one of the reviewers pointed out that some of the Linux instructions don't apply to Solaris (or vice versa) and that, every time he takes them out, they wind up reappearing later.    (013)

It was easy to see why. The instructions were so long, and the differences so minor, that would only be natural for a writer working on one to simply copy their changes over to the other.    (014)

With manually pasted text, it's possible to consider taking the writer to task for not being detail-minded enough to observe the minor discrepancies. The fact that no human being on earth is not that detail-minded does not have to dissuade us from our righteous indignation. We can chastise that writer to our heart's content. Why not? It does our soul good.    (015)

But in an environment of automatic reuse, there would be /no way/ for a writer to know who might be using their content, and in what context--unless there were backpointers to follow.    (016)

The first several interface implication for backpointers is simple: You need to know how many backpointers there are for a given bit of material. That number gives you important information all by itself:    (017)

• If there is only one, you know that you can safely make any changes you want.    (018)
• If there is none, the material hasn't been used. It might not be worth editing, or it might need a home.    (019)
• If the number is greater than one, and it matches the number of times you have refererenced it in your documents, then you can proceed with confidence in the knoweldge that you know how the material is being used.    (020)
• If the number is greater than the number of your personal references, you have to inspect them. (Imagine for example that there is one more. You may have seen it before. But if that reference was dropped and a new one was added, the extraneous context in which it was used could have changed completely.    (021)

Finally, when a piece of information is used in more than one context (yours or others), you need a way to see them in some reasonable fashion. As contemplate the change you plan to make, you then have several interesting options. In choosing which options to implement, the authoring system needs to balance interface complexity against functional completeness:    (022)

• Trivial change (fix a typo, for example): Just make it.    (023)
• Note that a relatively small change like adding or removing the word "not" can completely change the meaning of a sentence or paragraph. So whether or not a change is "trivial" depends on how it affects the meaning, not on the number of characters that change.    (024)
• Change that applies in all contexts (improve wording, add an explanatory note): Just make it.    (025)
• Modification (changed wording) or deletion that applies in a subset of contexts: Version fork. Select the contexts that should point to the new version.    (026)
• Addition that applies in a subset of contexts: Three possible options:    (027)
  • Simple version fork, as for a modification    (028)
  • Create a higher level topic that includes the original material and appends the additions. Choose the contexts that change to point to the larger topic.    (029)
  • If the change applies to only one of the contexts, add the new material in that context instead of at the original location.    (030)
  • If the change applies in multiple contexts, add the new material in one of them and add references to it in the others.    (031)

Summary

With reuse comes the necessity for managing backpointers, so that editing and revisions can be carried out intelligently.    (032)