[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

First Class Links Make Second Strike



So much for my hope that a fact forum could lead to a truce on 
first class and embedded links.

I have ordered the bombers into the air, SAC Posture 7. The missiles 
are standing by on DefCon 1 :-)

But before launching my final terrible attack on embedded links, 
I would like to try one more time to find the heart of our disagreement, 
and reach reconciliation. I am suspicious that there are two 
goals, dean, that you and I share. What we disagree on is the 
utility of embedded links for achieving those goals.

Terminology: I use the term sensor here. I believe I use it correctly--there
 is an alert sensor attached to a recorder, and we all recognize 
that the recorder is the thing actually attached to the document 
(and the sensor is the thing actually attached to the user :-)

Goal 1: We must find a really powerful way of displaying, selecting, 
and going to the "right" bert context when the user traverses 
a link. Here, the term "right" means, "the context the user wanted 
to go to, whether he knew it or not." Embedded links, since they 
are copied along with the rest of the document, give you a visible 
choice of bert...sometimes.

Unfortunately, whether the link is embedded or not, FINDING THE 
RIGHT CONTEXT IS STILL AN UNSOLVED PROBLEM. In the scenario I 
created to ask questions earlier, we had 4 berts, A1-A4, and 
3 links, to A1, A3, and A4. A2 didn't have a link embedded in 
it because it had branched off before we made the link. 

Question for the reader: Was A2 left without an embedded link 
because of the careful, methodical planning of the creators of 
A1 and A2 and A3? Or was it left without a link because the author 
didn't know about B until after A2 had spun off, or because the 
author forgot that B was there until A2 spun off, or because 
B was created after A2 spun off? If the cause were any of the 
reasons except Cause Number 1 above (Number 1 being the careful 
intentional planning of the author, the cause which I honestly 
find the least likely), A2 is just as interesting as an endset 
as A3 and A4.

We have to find a solution to the fundamental problem of picking 
the right context for the user. I am suspicious that this is 
a frontend function, one way or the other. The best solution 
I have yet heard is dean's idea for going to the most recently 
used context, i.e., if the user already has a window open on 
one of the berts at the end of the link, go to that one. This 
is not a complete solution, though I believe it is a part of 
a complete solution.

But embedding the link is not the answer to finding the right 
context--it depends too much on successful preplanning by the 
users.

Goal 2: Get alerted when someone improves on a document that 
we have reason to believe will be interesting when improved. 
Since duplicating a document with embedded links causes new links 
to be created, sensors will ring, and readers will get alerted 
to the presence of a new version.

Unfortunately, if a document has 5 links embedded in it, and 
it is in my area of interest, I will probably attach recorders 
to every document it is linked to. If a new version of the document 
is created, I don't want 5 sensors to go off--I want one, and 
I want exactly one. 

The correct answer to this desire is a recorder that will tell 
me  if the bert hops, and a recorder that will tell me if a new 
bert acquires a part of the document. We already have recorders 
for those, right? This is a solved problem, is it not? 

(below are a couple of accidental, low yield nuke bursts; this 
is what happens when you go to DefCon 1, accidents happen :-)

Even if recording on vcopying is not currently solved, 5 sensors 
ringing is not the right answer. Rather than face that kind of 
noise (which you, dean, claim I would have earned for having 
a promiscuous sensor), you can be sure that I would make my sensor 
less promiscuous--I would say, "hey, filter it out and don't 
bother me if that guy makes a vcopy of an existing link". At 
that point, I get NO rings on a new version. This is in no one's 
interest, though as a reader, it's better than the alternatives 
left me.

Please note also that the filter criteria I described above, 
to filter out the duplicates, is the only one that will work: 
by definition, the vcopy of a link that passes my filters will 
itself pass my filters. It has a type that is interesting, and 
it has an author whom I used to think was interesting, at least 
until he started reusing his documents, creating slightly customized 
alternates of them for slightly different situations (the fiend! 
How dare he? :-). Since the "new" link passes all my filters, 
it has perfect "camouflage". 

But because the "new" link is attached to material that I have 
already read (albeit in a new context), it is of lower quality 
and lower value to me than a really new link, to really new material 
(after all, if I wanted to know about changes in the context 
of the material surrounding the link, I would have attached a 
version-stimulated recorder and sensor to the document). I want 
to be alerted to really new things with a level of intensity 
far beyond my interest in being alerted to slightly different 
things.

Dean, you say "We invented embedded links because first class 
links broke in so many unpredictable and surprising ways." To 
quote you out of context :-), 
"Got a good example?" When I look at embedded links, I see something 
that breaks every time someone embeds a link after the original 
document has started spinning off variants.

Speaking of examples, here is an example of a situation requiring 
a first class link, i.e., a link that follows the permissions 
of neither the beginning nor ending document: Suppose I want 
to mail to you  a link to my mailbox, in effect sending you my 
mailbox address. The mailboxes are private. So a link embedded 
in my mailbox would be invisible to you, and a link embedded 
in your mailbox cannot be created by me. 

Second example: How can I find your mailbox, when neither of 
us has the other's mailbox? This is even more amusing than how 
I send you my mailbox once I've got yours. We would probably 
go to a public document with a list of mailboxes. And therein 
lies a tale:

You don't want this mail list to be publicly writeable, 
you just want everyone to attach links to it. So to get my mailbox 
listed, I create an intermediary document with embedded links 
to both the mailbox and the public mail list--in other words, 
I create a first class link from the mailbox to the mail list 
by hand. Except it's not as good as a real first class link for 
the reader--because, of course, the link in the public mail list 
is not actually the link that mail senders want to use. Oh no, 
the link in the mail list is only a link to the document that 
contains the mail link! 

As an aside, it took me some considerable thought to figure out 
how to trade mailboxes at all with embedded links--the average 
manager and secretary wouldn't have a chance. There are subtleties 
here that will require system administrators, just to trade mail 
addresses! 

On the other hand, if we give those managers and secretaries 
first class links, they just run the link and set the permission 
(permit themselves as authors, everyone as readers, the intuitive 
thing to do); we do the rest for them.

(end of mild nuke bursts)

Is part of the difference a difference in the viewpoint between 
the reader and the writer? Dean, when you said, "I want the link 
to version with my comment" you were thinking from a writer's 
point of view, wanting to make sure the readers all got the message 
that something new had happened. Looking at it from the reader's 
point of view, I say, well I SOMETIMES want to know something 
new has happened, but I want to know the nature of the newness--and 
since the link is a duplicate, it is not a good indicator of 
what is new. The newness indicator should indicate what is new, 
not what is duplicated.

I suspect we may be looking at different size documents, too. 
I worry about large documents with lots of links and many versions. 
If you think primarily about small documents with few links and 
few versions, the issues and choices all get gentler.

Getting very, very philosophical, I go back to an underpinning 
of the Xanadu religion: the reader must have control over what 
he sees.  Only this way can one have a pool that is 99% sludge 
while every reader sees a view of a pool that is 99% gold. I 
see the automatic creation of camouflaged links via document 
vcopying as taking that control out of the reader's hands and 
giving it to the author. To paraphrase dean again, no, no, no.

Dean, if you aren't overwhelmed by my reasoning here, we probably 
need higher bandwidth, i.e., let's nuke it out in the office.

--marcs