In contrast to our system HYPERFACS, the WORLD-WIDE WEB does not support multiple link anchors located at the same position. Instead, intermediate nodes have to be introduced that enable the selection between different URIs (see figure 7). With regard to images, this functionality can be implemented rather easily: there, the basic functionality of clickable images can be extended using modified versions of map files (see section 2.2) and the evaluation script. The normal evaluation scripts receives the coordinates of a mouse-click, looks for the first matching region within the map file if it exists, and provides exactly one URI as its output. In contrast, the modified script delivers all matching URIs. Therefore, it is necessary to provide for additional information about the links in order to support the user in finding an appropriate one: this information consists of the type of the link and the name of the node at the link's destination. The intermediate node is also created if only one link anchor exists at the clicked-upon position. This solution was implemented in order to inform the user about the type of a link before it is traversed: thus, the rather costly transfer of images may be avoided in some cases if the user can judge from the type of the link that it is of no use to him.
Different approaches could be thought of if link typing and the embedding of link anchors within images were supported by the WWW more directly. Then, the WWW browser could inform the user about the types of links instantly without the need of accessing a different node. Furthermore, if the browser knew about the links embedded within an image, a more flexible representation of links would be possible: according to the preferences of a user, the embedding links could be either marked (e. g. by means of surrounding boxes) or hidden in order to increase readability. A similar argument is true for link destinations that are located within images: the WWW only references the image as a whole, but cannot select part of this image as the destination (as it is possible within the text of HTML nodes).
As a result, either more static or slow approaches have to be chosen at the moment: links are either marked up all the time or time-consuming dynamic manipulations of images have to take place. With regard to the link anchors, the insertion of frame boxes for link indication is done during the transformation process described in section 2.2. As already stated there, this is sensible, because the set of links can be regarded as static. With regard to link destinations, an approach similar to that applied in full text searches is possible: the user may decide whether he wants to wait and get a highlighted version of the destination node or receive a plain image immediately.
Page links are an exception and are therefore treated differently. The link source as well as the link destination of a page link is always a complete node. Therefore, no highlighting of special image regions is necessary. Furthermore, as exactly two page links exist for almost any page (except the first and the last page), these links or types of links, respectively, may be represented by means of fixed buttons (buttons ``<-'' and ``->'' in fig. 3).
___________________________________________________
___________________________________________________
Figure 7: Link selection node
Next: Conclusions
Up: Document access
Previous: Full text searches