Brilliant implementation. Sounds like backpointers to me. (01)
Al Selvin wrote:
> I wonder if the way Compendium implements transclusions would count as
> backpointers. A node that is transcluded has a little number in its
> lower right corner that counts the number of views the node appears in.
> Hovering over the number brings up a clickable list of those views,
> while clicking on it brings up a Views dialogue that gives further
> options, including showing which nodes that node is linked to in the
> other views.
>
> Al
>
>
> On 1/22/06, *Eric Armstrong* <eric@treelight.com
> <mailto:eric@treelight.com>> wrote:
>
> Doug Engelbart always said that backpointers were
> necessary. I just encountered a concrete example
> that points out why.
>
> 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.
>
> Mechanically, backpointers are very much like links.
> In fact, they are essentially links with a type tag
> that says "I'm pointing backwards".
>
> 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`_).
>
> _ Doug Englebart's NLS System :
> http://www.treelight.com/software/collaboration/NLS_video.html
>
> 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.
>
> A concrete example will make it easier to see why
> backpointers are vital.
>
> 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:
>
> * With small deltas, the instructions for Linux and
> Solaris are virtually identical.
>
> * 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.
>
> * 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).
>
> There are a few other opportunities for reuse, but those
> are the major ones.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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:
>
> * If there is only one, you know that you can safely
> make any changes you want.
>
> * If there is none, the material hasn't been used.
> It might not be worth editing, or it might need a home.
>
> * 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.
>
> * 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.
>
> 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:
>
> * Trivial change (fix a typo, for example):
> Just make it.
>
> 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.
>
> * Change that applies in all contexts (improve
> wording, add an explanatory note): Just make it.
>
> * Modification (changed wording) or deletion that
> applies in a subset of contexts: Version fork.
> Select the contexts that should point to the new
> version.
>
> * Addition that applies in a subset of contexts:
> Three possible options:
>
> o Simple version fork, as for a modification
>
> o 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.
>
> o If the change applies to only one of the
> contexts, add the new material in that context
> instead of at the original location.
>
> o If the change applies in multiple contexts,
> add the new material in one of them and add
> references to it in the others.
>
> Summary
> =======
> With reuse comes the necessity for managing backpointers,
> so that editing and revisions can be carried out
> intelligently.
>
> --
> Eric Armstrong
> TreeLight Health, Citizens' Advisory
> http://www.treelight.com/health -- nutrition/fitness/mailing list
> http://www.citizensAdvisory.org -- politics, news feed
> http://www.artima.com/weblogs -- software technology web log
>
>
>
> --
> This message is archived at:
>
>
>http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=yak&i=43D3F421.6060902@treelight.com
>
><http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=yak&i=43D3F421.6060902@treelight.com>
>
> (02)
--
This message is archived at: (03)
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=yak&i=43D6C2BF.4070407@sun.com (04)
|