Re: What should hyperlinks do? What attributes should they have?

[KIRTO <Kholson@xxxxxxxx>]

On Tue, 12 Mar 1996, Art Pollard wrote:

> I've been giving a fair amount of thought lately to allowing hyperlinks 
> to have attributes.  This of course, also implies that they have the 
> ability to do other things besides "link".  For example in HTML, it is 
> possible to link to an image.  (i.e., the link in this case had an 
> "action" associated with it -- start up the GIF viewer and display image 
> X) 

This language alone should give us pause because links that do more than 
link will confuse our thinking. I'll unilaterally call the multiple 
function thingies "chains."

> Some of the attributes I have come up with for links are as follows:
> 
> Author
> Creation Date
> Title
> Comments
> etc.

I view links as instructions to the display (rendering) engine which
produces some result. I see them as having one physical location in the
currently displayed text as with HTML. Some engines, like the Flambeaux 
engine, process the link through an alias look-up. Windows 3 uses typed 
links (jump, popup) that display in different colors.

Will these link types you propose display differently? If so, how many 
display differences will the reader tolerate? 

> Some actions associated with links I can think of are as follows:

These are the ones I want to call chains.

> Launch a script (or other program)
> Highlight a phrase.
> Perform a query.

Conceptually, all of these call another program which may be simply a
portion of the display engine or may be an external program. So I assert
that these are collapsed representations of multiple-link sequences (which
is why I want to call them chains). 

I see two possibilities here: 1) the called program does not accept 
parameters because it has a fixed function or obtains its information 
from some context hook to which it has access 2) the called program 
accepts parameters which the link must carry.

In the first case, the called program may require the reader to make a 
new choice when it concludes. In that case the chain becomes a link since 
it makes just one jump and carries no parameters. The link may display 
differently. 

Again in the first case, the called program may do its thing and proceed 
to some constant or calculated destination (including return to the 
originating link) and neither require nor permit user interaction at the 
end of the program function. This choice consists of a simple link to 
start the program and either a link or a chain leaving. This group is 
always a chain.

In the second case, the entry link differs because it carries parameters, 
but the potential actions at the end of the program are as stated in the 
preceding two paragraphs.

None of these require state memory. All the types I categorize can derive 
all needed information by examining the current state of the system when 
the starting link is activated. I do not see any required change if the 
system has state memory, but I know little of such systems.

If my analysis is correct, I end up with two constructs, links and 
chains. Links may be typed, and may carry parameters that must be 
embedded in the starting anchor. 

> Simply jump. <====Except this one that is just a link.

> What other attributes and actions might/should links posess? 

One of the most interesting to me is the "lecturer's chain." Imagine you 
are giving a lecture with slides, and you talk about a slide, *and* you 
make transitional comments as you change the slide. For example, "Now 
let's look at the case where the probability is small, but the 
consequences are devastating."

Reader chooses a slide, gets a sound clip with it, chooses one of four 
output links from the set {prob{lo,hi},consequence{lo,hi}} and gets the 
appropriate transitional comment as the slide is changing to the selected 
one, followed by the discussion sound clip for the chosen slide.

I assert that these are just chains of simple links calling viewers and 
players. But if one cannot choose the slide without getting the audio 
clip, it is a chain, not a simple link.

> I envision that links should have a fair amount of structural
> information to them (much in the same way a document would).  Some might
> argue that links should be fairly minimalest and only link.  

Well, I would argue for the least collection of links needed to build 
chains of useful functionality. 

> However, I disagree as the links themselves in many ways become part of
> the document and thus (like different parts of a document) need to serve
> a wide variety of functions. 

In printed text, we have a large collection of traditional methods of
indicating link functions in text (footnote and endnote notations for
example or see page nnn) that are far less standardized than one might
wish after hundreds of years. Some, such as [1] for footnotes, carry over
well, although the need for the numeral is unclear in hypertext. Others,
such as "See page nnn," fail immediately in a world of un-numbered pages,
but "See typed links" seems informative and useful. Note that these are
writing styles to embed the information in text. I do not know of such
traditions in graphics, but I think we need graphic symbols that mean
footnote, or author (artists do sign their work). 

I believe that changing text properties (italic, underlined, green) 
differs from a stylized phrase in many ways. People learn to ignore the 
"links" in printed text. Can they learn to ignore the multiple word 
colors and type properties as well?

> How robust should links be?  

About like the cartridge fuses in your electric entrance box. Still able 
to perform after 20 - 30 years.

> What attributes should they have?  

I think this is a property of chains, defined by the item linked to.

> What actions should be associated with them?

I came up only with the ability to carry parameters to the called 
program. And if the parameter container may be empty, I'm back to one 
link type. But chains construct an endless array of possibilities.

--Kirt