[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
First Class Links Make Second Strike
- To: <heh>
- Subject: First Class Links Make Second Strike
- From: Mark S. Miller <mark>
- Date: Sat, 21 Oct 89 17:21:33 PDT
- Cc: <marcs>, <xtech>
- In-reply-to: <Hugh>,38 PDT <8910200059.AA25954@xanadu>
Date: Thu, 19 Oct 89 17:59:38 PDT
From: heh (Hugh Hoover)
I think that this will tend to be true for unsophisticated users. The idea
of a link as a "thread" between two documents is probably their primary concern.
Note that creating a link requires a "save" (bert hop) of the document in which
the link resides. This may be confusing to early users.
Which bert are you talking about hopping? In the two-bert editing
model, there's the edit-bert which is hopped for every edit change or
undo, and the save bert which is hopped on every save or revert.
Creating a link is just an edit and involves only a hop of the edit
bert. Once again, just like typing in a sentence. Whether this
confuses the user depends CRITICALLY on how links are presented to the
users. If the front-end is much like our current designs, then the
user virtuallity (yes, it is the correct word here) will be one of
first class links, so using embedded links internally will be terribly
confusing. I am a strong advocate of embedded links long term, but
ONLY if a radically different presentation can be found so that
embedded links are thought of by the user as as natural a part of
their containing document as embedded sentences are. When this
front-end problem is solved, embedded links will be there waiting for
them. Note that, given such a hypothetical front-end, using
first-class links internally would lead to at least as much user
confusion as using embedded links in the current front-end.