Word_Template.rtf

Visual Preview for Link Traversal on the WWW

Theodorich Kopetzky
Telecooperation Department
Johannes Kepler University Linz
Altenbergerstr. 69, 4040 Linz, Austria
e-mail: theo@tk.uni-linz.ac.at

Max Mühlhäuser
Telecooperation Department
Johannes Kepler University Linz
Altenbergerstr. 69, 4040 Linz, Austria
e-mail: max@tk.uni-linz.ac.at

ABSTRACT

This paper demonstrates a technique for augmenting current WWW browser implementations with features found in classical hypertext applications but unknown to the WWW community until now. An example implementation is shown using Netscape Navigator 4.x using JavaScript, dynamic HTML and Java. The implementation follows an architecture based on a proxy server which acts as a gateway between the net and the browsing client. Based on the detailed example, support for further features is discussed.

KEYWORDS: hypertext navigation, user interface, link preview, world wide web

INTRODUCTION

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 [1] or a web portal like Yahoo [25] 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 [9] mentioned the phenomenon in his late introductory article. Zellweger et al. [26] 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 [15] 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 [11] 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. [26] 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 [16] or the Guide system [5] already address some issues related to glosses. As to the WWW, the Internet Explorer [17] 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 [14] required typed links, even composite links, in his late "seven issues" article, back in 1988. Manfred Thüring et al. [20] 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. [23], but the standard browsers - like Internet Explorer [17] and Netscape Communicator [18] - currently do not support this feature yet. In the context of XML, a special-purpose XML linking language called Xlink [24] 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. [4] 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 [10] 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:

Figure 1. The homepage of the Telecooperation Department.

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 reader’s 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:

  1. The image should be small to save bandwidth and server space.
  2. The image should be in color, and
  3. 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 [13] 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.

Figure 2a. pixel resizing, 3628 bytes JPEG file

Figure 2b. bilinear resampling, 2884 bytes JPEG file

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.

Link Types

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.

Figure 3a. Possible preview for a link to an anchor in a document

Figure 3b. Preview of a link to an e-mail address

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.

Link Preview

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.

Architecture

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.

Figure 7. Basic architecture of the proxy server

The proxy server has the following tasks:

This approach has the following advantages:

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

  1. The reader enters an URL.
  2. The browser asks the proxy server for the requested document.
  3. 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.
  4. The parser analyses the document regarding its structure and searches for link information. If link information is found, for each link an internal web browser will be started. These browsers will be used to generate the preview images. The document is modified to enable link preview by inserting the JavaScript code. After parsing is finished the modified document will be cached and passed to the requesting browser.
  5. The requesting browser displays the document. Link preview images may or may not be ready yet.
  6. 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 [22] 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).

Layering

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.

To enable the browser to show the link preview, the proxy server inserts a layer definition for invisible layers and a short JavaScript program at the beginning of each downloaded HTML-page. An example for a layer definition can be seen in figure 8. The position where the insertion actually takes place depends on the structure of the document (if it contains a head tag or a frame set, for example).

    <LAYER NAME="preBase" 
    LEFT="0" TOP="0" width="100" height="100"
    CLIP="0,0,100,100"
    VISIBILITY="hide"
    onMouseOut="deactivate()"
    bgcolor=#FFFFCC>
    </LAYER>

    Figure 8. A simple layer definition

Additionally each <A HREF> tag is modified to react to events when the mouse pointer moves over the link. A mouseover event-handler is inserted into each link description. This handler will activate a procedure in the inserted JavaScript program if the reader moves his mouse over the link. The handler passes as a parameter the name of the preview image to the procedure. This name was inserted into the link definition just as the event-handler. The procedure will make the invisible layer visible and set some parameter of the layer, e.g. the information which preview image is to be shown.


    Figure 9. Client side architecture

The figure above shows how a document looks like after modification by the proxy server. First there is the inserted layer and JavaScript code. Then follows the modified HTML code which still may contain links without preview code (e.g. if the parser was not able to parse link information correctly). Preview images are fetched on demand from the proxy server.

Limitations

Unfortunately the current implementation has some limitations:

Related Work

Classical Hypertext

Different types of link preview or displaying the link type exists in several classical hypertext systems, like for example in Sepia [19] which displays the link label next to the link arrow in its link overview diagrams or in HyperTies [16], where a brief description is displayed at the bottom of the screen

The Web

There exists an interesting concept which is called displets [21]. 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 [4]) 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++ [3], which uses an interactive panning and zooming navigation metaphor, or distortion-oriented viewing techniques like the generalized fisheye views [12] 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.

Link Services

An interesting approach to enhance usability of the World Wide Web is the use of a link service [7]. 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 [8]) don't store thumbnail information along with the link information. We think that by storing the preview image link services could gain attractiveness

Future Work

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:


Figure 10. Excerpt from "As We May think"

Summary

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.

ACKNOWLEDGMENTS

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.

REFERENCES

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

3. Bederson, Benjamin D., James D. Hollan. Pad++: a zooming graphical interface for exploring alternate interface physics. Proc. ACM UIST '94, 1994

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

5. Brown, Peter J. Turning ideas into products: the Guide system. Proc. ACM Hypertext '87, pp. 33-40, 1987

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

8. Carr, Les A., David De Roure, Wendy Hall, Gary Hill. Implementing an Open Link Service for the World Wide Web. World Wide Web Journal 1, 2. 1998.

9. Conklin; Jeff . Hypertext: An Introduction and Survey. IEEE Computer, pp. 17-41, September 1987,

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

11. Furnas, George W. Effective View Navigation. Proc. ACM CHI '97 Human Factors in Computing Systems, pp. 367-374

12. Furnas, George W. Generalized fisheye views. Proc. ACM CHI '86, pp. 367-374, 1986

13. JPEG. Joint Photographic Experts Group. http://www.jpeg.org

14. Halasz, Franz G. Reflections on Notecards: Seven issues for the next generation of hypermedia systems. Communications of the ACM, 31, 7, July 1988, pp. 836-852

15. Landow, George P. Relationally encoded links and the rhetoric of hypertext. Proc. ACM Hypertext '87, 1987

16. Marchionini, Gary, Ben Shneiderman. Finding facts vs. browsing knowledge in hypertext systems. IEEE Computer, pp. 70-80, January 1988

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.

20. Thüring, Manfred, Jörg M. Haake, Jörg Hannemann. Hypermedia and Cognition: Designing for Comprehension. Communications of the ACM, 38, 8, August 1995

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

24 World Wide Web Consortium. XML XLink Requirements 1.0. http://www.w3.org/TR/NOTE-xlink-req/, Feb. 1999

25. Yahoo. http://www.yahoo.com/

26. Zellweger, Polle T., Bay-Wie Chang, and Jock D. Mackinlay. Fluid Links for Informed and Incremental Link Transitions. Proc. ACM Hypertext '98, pp. 50-57 1998

Vitae

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.