Preview for Link Traversal on the WWW
Johannes Kepler University Linz
Altenbergerstr. 69, 4040 Linz, Austria
Johannes Kepler University Linz
Altenbergerstr. 69, 4040 Linz, Austria
KEYWORDS: hypertext navigation, user interface, link preview, world wide web
A novice user of the World Wide Web is usually impressed about the vastness of information available. At a second glance the impression gradually turns into desperation when the user tries to actually find valuable information. The usual solution is to contact a search engine like Altavista  or a web portal like Yahoo  which usually work as a starting point for global navigation.
But even when navigating through small webs (or hyper-documents), users tend to have navigation problems; in essence, these problems boil down to the decision about which links to follow and which to ignore. Considering a state of the art of about twelve years, little improvement was made. It was as early as 1987 that Conklin  mentioned the phenomenon in his late introductory article. Zellweger et al.  note that it is especially burdensome to follow a link just to find out that it is not relevant for the reader. They state that the reader leaves the source context just to return to the previous reading position after determining the uselessness of the chosen link. We will briefly review what we consider three levels of support for link navigation.
1. Textual Hints: Landow  appealed to authors to enrich the context of link anchors in order to help users to decide if a link is worthwhile to follow. Furnas  discussed the advantages of links having a scent or residue of contents to come (this may be compared to "highway signage" where the sign shows, e.g., what is next and what is farther away). Zellweger et al.  introduce the notion of a gloss, which they define as a "brief explanation positioned in the margin or between the lines of a text". A gloss may contain a description of the target of the link, meta-information and more. Some early hypertext systems like HyperTies  or the Guide system  already address some issues related to glosses. As to the WWW, the Internet Explorer  supports a very basic kind of gloss by optionally displaying a small popup window with a textual description of the link to be followed
2. Typed Links: This concise and well-defined remedy to the link navigation problem described has been proposed early on, too. Halasz  required typed links, even composite links, in his late "seven issues" article, back in 1988. Manfred Thüring et al.  put up eight design principles and ten cognitive design issues to increase global and local coherence of hyperdocuments, one of them being "use typed link labels". However, typed links are i) not yet well supported and ii) not sufficient. Not well supported refers to the fact that HTML 4.0 offers support for link types like "contents", "chapter", "next", etc. , but the standard browsers - like Internet Explorer  and Netscape Communicator  - currently do not support this feature yet. In the context of XML, a special-purpose XML linking language called Xlink  is emerging, but its wide-spread use is still far out. As to the attribute "insufficient", the limits of typed links are obvious: i) unless a commonly accepted ontology is given for a field, the semantics of a given link type are known to the user but not to the reader. The latter must infer these semantics either from the type mnemonics (what might a link of type "in-depth" lead to?) from formal or informal descriptions (which distract the reader even more); ii) even if both author and reader have a common understanding of link types, the type information is just one kind of abstraction of the target contents; iii) additional authoring effort is required, so that typed links are neither a remedy for the bulk of existing WWW documents nor can they be expected to be soon applied by the myriad of Web designers active in the Internet.
3. Further advancements. Bieber et al.  categorize hypermedia environments in four generations in analogy to programming languages (machine languages, assembler languages, high-level programming languages, and finally packages like word processors which let users concentrate on what they want to do). They believe that current authors and readers of the World Wide Web are working in a second generation hypermedia environment. Further they discuss a set of hypermedia functionalities which they believe to improve the usability of the Web. One of these functionalities is "global and local overviews", to be achieved by overview diagrams and link previews. Obviously, textual hints and typed links as described above are just two facets of link navigation support. Among the more advanced concepts, work on information shape  is cited here just as a sample reference. This example illustrates a common problem with hypertext: many concepts have been studied in the past, but they have a long way to go until they are widely available for the WWW community.
In this paper, we describe a technique to implement local overview for web browsing, called "visual link preview". The approach falls within category three described above (further advancements) and at the same time works with standard browsers without authoring effort; in other words, this approach can be made available to the WWW community immediately.
Visual Link preview
An author of web documents has the following options to provide link information to the readers:
- He can describe in the context of the link by text or by image where the link will take the reader. This has been done for example in the image map in figure 1.
- He can use the weak support provided by existing browsers. This support is limited to displaying a small text window.
- He can use dynamic HTML to enrich each link specification and may provide link information in another window or another frame.
All three possibilities demand work to be done by the author. But in the web environment there is another source of information about the link: the target of the link itself.
Usually the reader does not get to see the link target until he has activated the link, leading to the problems stated in the introduction.
If the reader has already visited a region of the web, he has built a mental map. Depending on the time passed the reader may need information in addition to the URL to remember that he has already visited this region. This is were the view of the page at the end of the link, provided as thumbnail preview, may help the readers memory and will aid him in the decision of following the link.
Generating this thumbnail preview by hand can be done for small, static web sites, but is unfeasible regarding large and fast changing sites on the web. Thus automatic generation is necessary.
In addition to automatic generation these thumbnails have to meet the following requirements:
- The image should be small to save bandwidth and server space.
- The image should be in color, and
- the quality of the image should be good enough to allow the reader to recall the accompanying image of the target of the link from memory. This is also the reason for point two.
For the first and the second requirement JPEG  was chosen as format for the thumbnail images because it provides small image files with a 24 bits color representation.
As for point three, the quality of the preview images largely depends on the scaling algorithm used. Given the image in figure 1, two scaling algorithms are compared.
Below the difference between simple pixel resizing (faster) and bilinear resizing (slower, better quality) can be seen.
To improve recognition the slower method with better results was chosen. In addition, the second method usually yields smaller image files. To see the original image, take a look at figure 1.
Although explicit link types are part of HTML 4.0, no standard browser currently supports those.
But links also have implicit types, which can be used for preview purposes. The following list shows which link types are recognized by our system and how they are visualized. As the linking mechanism works with URLs we are using properties of the URLs to categorize a link.
- The URL points to the beginning of a web page, as in http://www.tk.uni-linz.ac.at/. Links of this type are visualized using a thumbnail picture as in figure 2b.
- The URL points to an anchor, as in http://www.encyclopedia.com/h.html#hypertext. Links of this type may be visualized using a thumbnail picture or, if there is text after the anchor, the text referenced by the link itself may be displayed (see figure 3a).
- The URL starts with a protocol different from HTTP, like FTP, TELNET, MAILTO, etc. Although these link types are rather self-explaining a symbol is used to represent the protocol used (see figure 3b below for an example).
In addition to these properties links can have meta-properties, like dead or forbidden. If the reader knows in advance that a link is dead, he can safely ignore it. The symbol chosen for a dead link is presented in figure 4. These meta-properties are currently derived from the answer of the web server where the link leads to, and so for example a 404-error is mapped to the dead end symbol.
Figure 4. Symbol for a dead link.
Figure 5 shows how the preview looks like using the Netscape Communicator 4.5.
In case the reader requests a preview which is not available yet the reader is informed about that fact at the same location, as seen in figure 6.
The Presentation of the Link Preview
A document delivered by the proxy server doesn't look different to the reader than the original document. The link preview is simply activated by moving the mouse over a link.
The presentation of the link preview is animated. This means that the reader has time to accommodate to the new situation. The preview opens below the link and will remain open for seven seconds.
The preview can be closed by moving the mouse over the preview and than out of it. The preview will close also when the reader moves the mouse over another link and thus activating a new preview image.
To follow the previewed link, the user has the possibility to activate the link itself as usual or to click on the preview image.
Our aim was to implement link preview without requiring support from the web author. This approach has the advantage that all existing pages on the web can be browsed without requiring any change to be made by hand. On the other hand the material has to be changed for the preview to work.
To solve this problem an approach using a proxy server was chosen. An overview of the main components of the proxy server, which has been implemented in Java, can be seen in figure 7.
The proxy server has the following tasks:
- Analyze the links in a requested HTML document and generate the preview images for all links in the document.
- Cache the requested HTML documents and the computed link preview images for future access.
- Modify the HTML documents in a way that the requesting browser is able to show the link preview images.
This approach has the following advantages:
- The proxy server has to generate the preview information only once (depending on server space).
- Many readers can share one proxy server and thus benefit from already generated preview information.
- Readers only have to make one change in their browsing environment: they have to configure the web client to use a proxy server. Everything else is done automatically.
- The proxy server can use other proxies servers and thus benefit from information already fetched from the web.
Flow of Events
A typical flow of events is described in the following steps (this assumes that in the beginning the required page is cached nowhere):
- The reader enters an URL.
- The browser asks the proxy server for the requested document.
- The proxy server fetches the document from another proxy server or directly from the web. After the document is fetched completely it is passed to the parser.
- The requesting browser displays the document. Link preview images may or may not be ready yet.
- If the reader moves the mouse over a link, the code inserted by the proxy server tries to load the preview image. If it is available at the proxy server, it will be transmitted and displayed, otherwise a notification regarding the missing image will be displayed (see figure 6).
Part of these activities happen in parallel to speed up processing.
Client side implementation
To enable link preview at the client side, we had to utilize dynamic HTML. Unfortunately Internet Explorer and Netscape Communicator implement dynamic HTML each in their own way. The Internet Explorer uses cascading style sheets  which are not fully supported by Netscape's Communicator and the Communicator uses a technique called layers which is not supported by the Internet Explorer. We decided to implement the first version for the leading browser at that time (which was Netscape).
To display the preview information so called layers are used. Layers can be viewed as small HTML documents which are displayed in the same browser window. Layers are displayed over the base window thus hiding part of it. In addition layers may overlap other layers.
<LAYER NAME="preBase" LEFT="0" TOP="0" width="100" height="100" CLIP="0,0,100,100" VISIBILITY="hide" onMouseOut="deactivate()" bgcolor=#FFFFCC> </LAYER>
Figure 9. Client side architecture
Unfortunately the current implementation has some limitations:
- It only works with the Netscape Communicator. If an Internet Explorer is configured to work with the preview proxy, no preview is available. However, normal usage is not restricted.
- The proxy server needs a lot of bandwidth to build the preview images because for each link encountered and not found in the cache a web browser is started. Imagine a reader following a link to a web page containing a link index with hundreds of links. The proxy server will need some time to build all the preview images.
- The size of each HTML document transferred from the proxy server to the client increases approximately by 2k.
Different types of link preview or displaying the link type exists in several classical hypertext systems, like for example in Sepia  which displays the link label next to the link arrow in its link overview diagrams or in HyperTies , where a brief description is displayed at the bottom of the screen
There exists an interesting concept which is called displets . Displets provide a principled way to extend HTML. In their proof of concept implementation the authors implemented among others a displet for anchor groups (a way to implement multi endpoint links (see also ) and anchor labels. Because displets are implemented as Java classes, they may show any image as well but they lack the server side component which generates the preview images.
Other User Interfaces
A lot of different approaches exist to display an overview of large information spaces, like Pad++ , which uses an interactive panning and zooming navigation metaphor, or distortion-oriented viewing techniques like the generalized fisheye views  which employs a distorted representation of out-of-focus material.
Zooming has as disadvantage that the material in focus is moved out of focus if the reader zoom in on a detail. Another disadvantage is that zooming is difficult to integrate in standard web browsers unless one is willing to implement a plug-in for a browser. Our approach integrates well and requires minimal user intervention to be set up.
Distorting techniques have the same limitations as mentioned with zooming when trying them to integrate in a browser and usually need their own window to work effectively. Our approach reuses the available screen space.
An interesting approach to enhance usability of the World Wide Web is the use of a link service . Via link services readers can gain a surplus of information by applying different sets of links to one and the same web document. Link services store link information external to the documents linked. Current implementations (as shown in ) don't store thumbnail information along with the link information. We think that by storing the preview image link services could gain attractiveness
As already stated the current implementation only works for Netscape 4.x browsers. We are currently working on a version which will include full support for the Microsoft Internet Explorer as well.
In addition we are considering to implement following features:
- Support for visualizing 1 to n links and selecting them in a screen estate saving way. An example can be seen in figure 10 which shows an excerpt from "As We May Think" by Vannevar Bush . A preview window opened below the link "wholly new forms of encyclopedias" revealing two links to choose from. This technique can be easily adapted to display more links.
Figure 10. Excerpt from "As We May think"
- Displaying more information about a link. This could be for example the ping time to the server where the link is pointing to. Other interesting information could be keywords associated with a link (as long as provided in a format understood by our system).
- More control over the preview. Currently control is limited to the states "preview on" and "preview off". Users could for example define which link to preview in which manner.
- There are some interesting "fluid link"  techniques we are interested to mimic on the web.
- As the proxy server approach is basically an intermediary approach as introduced in  we are looking into utilizing the power of the Web Browser Intelligence (WBI) architecture
Visual preview of the target of a link can provide valuable clues for the reader when making the decision if to follow the link or not.
We have shown that a simple preview service can be implemented using standard web browsing software and described an implementation which requires minimal user activities to be set up and doesn't need additional client software.
We are continuing to develop our approach adopting to new technologies as they become available and integrating novel navigating concepts.
I would like to thank Shai Kariv, Noam Ambar, and Amir Gur for letting me use the source code of their basic proxy server, and Ronald Angerer and Andreas Schwediauer for implementing parts of the system.
1. AltaVista. http://www.altavista.com/
2. Barrett, Rob, Paul P. Maglio. Intermediaries: new places for producing and manipulation Web content. Computer Networks and ISDN Systems 30 (Proc. 7th international WWW Conference), pp. 509-518, 1998
4. Bieber, Michael, Fabio Vitali, Helen Ashman, V. Balasubramanian, and Harri Oinas-Kukkonen. Fourth generation hypermedia: some missing links for the World Wide Web. Int. J. Human-Computer Studies 47, pp. 31-65, 1997
6. Bush, Vannevar. As we may think. Atlantic Monthly, 176, July 1945, 101-108. [http://www.theatlantic.com/unbound/flashbks/computer/bushf.htm or http://www.ps.uni-sb.de/~duchier/pub/vbush/]
7. Carr, Les A., David De Roure, Wendy Hall, Gary Hill. The Distributed Link Service: A Tool for Publishers, Authors and Readers. Proc. 4th International World Wide Web Conference (Boston, Massachusetts, USA), O'Reilly & Associates, December 1995
10 Dillon, Andrew, Misha Vaughan. It's the journey and the destination - Shape and the emergent property of genre in evaluating digital documents. The New Review of Hypermedia and Multimedia, Vol. 3. pp. 91 - 106, 1997
13. JPEG. Joint Photographic Experts Group. http://www.jpeg.org
17. Microsoft. Internet Explorer 4.01. http://www.microsoft.com/windows/ie/ie40/
18. Netscape. Netscape Communicator 4.x. http://developer.netscape.com/
19. Streitz, Norbert, Jörg Haake, Jörg Hannemann, Andreas Lemke, Wolfgang Schuler, Helge Schütt, Manfred Thüring. SEPIA: A Cooperative Hypermedia Authoring Environment. Proc. Fourth ACM Conference on Hypertext, Systems I, pp. 11-22, 1992.
21. Vitali, Fabio, Chao-Min Chiu, Michael Bieber. Extending HTML in a principled way with displets. Computer Networks and ISDN Systems (Proc. 6th WWW Int. Conf.), Vol. 29, Number 8-13, pp. 1115-1128, 1997.
22. World Wide Web Consortium. Cascading Style Sheets. http://www.w3.org/Style/
23. World Wide Web Consortium. HTML 4.0 Links: Document Relationships: the LINK element. http://www.w3.org/TR/REC-html40/struct/links.html#h-12.3
25. Yahoo. http://www.yahoo.com/
Theodorich Kopetzky is a PhD. candidate at the Telecooperation department at the Johannes Kepler university of Linz.
He received his master of Computer Sciences in 1993 and worked afterwards in the field of embedded systems. He began to work as a researcher at Telecooperation department in 1996.
His research interests are hypermedia authoring, navigation, and web based training.
|Max Mühlhäuser is a full professor of computer science and head of the Telecooperation Research Group at Linz University, Austria. His research domain is software engineering for distributed multimedia systems, mobile and ubiquitous computing, and human-human and human-computer cooperation. He received his diploma and PhD in computer science from Karlsruhe University, Germany, in 1981 and 1986, respectively. He is a member of ACM,. the German Computer Society, and IEEE.||