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

[pollarda@xxxxxxxxxx (Art Pollard)]

In article <Pine.SUN.3.90.960313112452.9896A-100000@xxxxxxxxxxxxxxx>,
KIRTO  <olson@xxxxxxxxxxxxxxxxxxxx> wrote:
>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."

O.K., we'll call them "chains" if you like.  However, I'm not sure what 
you mean by "chains" except perhaps chains of links but that implies that 
links do more than "link" and would be thus chains by your defination (as 
I understand it.)

>
>> 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? 
>

Well  sure, perhaps a user wants to only see links created by a certain 
user, after a given time, dealing with a particular subject, etc.  The 
title could be used in an interface to tell the user where they are going 
to shoot off to and the comments could be used to tell the user how the 
new information applies to the subject at hand.  All sorts of ways this 
info can be useful.

>> 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). 

Again, that then assumes that the links can do something which means that 
they are chains (which are chains of links which are themselves chains.)
Anyways, it is all a semantic issue and I'm dealing more with an 
implementation issue.  (Though I could see some implemenations 
implementing it as chains however.)

>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.

Nice idea!  I could see how this could be very useful in a number of 
hypertext/hypermedia systems.

So, 

>> 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?
>

Well, I suppose it depends on the link author(s) and the implmentation.  
If there are too many colors etc. it would only get confusing.  However, 
if there were a way to handle things cleanly, it could be very useful to 
have multiple link types.

>> 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.

O.K., what actions would be useful for "chains" to carry?  

Cheers!

-Art

>
>--Kirt
>
>