Blazing Trails on the World-Wide Web

Blazing Trails on the World-Wide Web

Corinne Glynn, Rachel Heck, Sarah Luebke, Weichao Ma, Hilary Mason,

Erin Nichols, Eleanor Raulerson, Isabel Staicut, and Samuel A. Rebelsky

Glimmer: The Grinnell Laboratory for Interactive Multimedia Experimentation and Research

Department of Mathematics and Computer Science

Grinnell College

United States

[e-mail]

Abstract: Hypertext clearly has the potential to change the way students learn. However, the World-Wide Web lacks many of the features necessary for truly interactive hypertext; while hypertext pundits speak of students annotating existing pages, building new pages, and linking them into existing hypertexts, the World-Wide Web typically limits interaction to simple point-and-click browsing. At the same time, students encounter a quite different problem when they venture beyond course webs: they get “lost in hyperspace”. That is, students have trouble determining where they are and where to go next.

In this paper, we suggest one solution to these two problems: Blazer, a system for extending the Web with trails, named sequences of annotated pages. When a student loads a page on a trail, she sees not just the page, but also information about the trail. Trails can give students increased interactivity while grounding navigation.

1. Introduction: Why the Web Needs Trails

The term “hypertext” suggests a rich environment in which readers could not only navigate between pages, but also extend and modify their own reading spaces. Hypertext visionaries suggested systems in which readers could add their own pages, make links between pages, and create trails between pages (Bush 1945) (Nelson 1974) (Landow 1997). Consider Nelson's first description of hypertext, in which he writes “links may be artfully arranged according to meaning or relations in the subject, and possible tangents in the reader's mind” (Nelson 1974, p. DM19, emphasis ours). Similarly, Bush envisioned a convenient mechanisms for constructing “useful trails through the enormous mass of the common record” (Bush 1945, Section 8). Clearly, linking and trailblazing are essential to interactive hypertext.

Compare this rich model to the typical Web site. Readers can click on links to select the next page they view, but that is the limit of the opportunity they have to interact with the hypertext. While some sites provide more interactivity, few provide the rich environment the hypertext pioneers envisioned. In particular, while it is certainly possible to link to a site, few sites let you link from them. But without such links, how can readers arrange links according to their “meaning [,] relations [...] and possible tangents”?

Are there ways to permit Web readers to make and share their own links? Are there ways for teachers to give their students appropriate guidance for traversing the morass of information on the Web? To help students, teachers often want to write:

To learn more about this subject, read the following Web pages in this specified order. I've included notes on each page to help you understand what is on the page. I've also suggested a few alternate sequences for those of you with different backgrounds.

Similarly, a teacher might wish to provide a sequence of readings and questions, with each element building on the previous ones. A teacher or student might also trace the evolution of an idea or design principle through a sequence of pages. These trails may also include a number of subtrails (which Bush calls “side trails”).

How can a teacher implement such sequences? It is certainly possible to write a separate Web page that lists the elements in the sequence and links to each element. However, such an implementation is difficult for students to navigate, as they must go back and forth between the sequence and linked pages, often forgetting where they are. There are also a number of ad-hoc solutions. For example, a teacher might build a sequence of framed pages, each of which includes the remote page, notes, and a link. Unfortunately, the construction of such solutions is often time-consuming and difficult.

We have developed a suite of tools to make it easier for faculty and students to build and use trails of pages, both local and remote. The suite includes a variety of trail-authoring tools intended for both novices and expert users. Similarly, there are a number of ways that students can view trails, so that each student can choose the way that best suits her. Trails have an added benefit: they ground students in their reading of the Web. Students on a trail know that there's always one good place to go next: the next page on the trail. The trail name also gives students some information as to why they're reading the page. Finally, because our trails can include notes from the trail author, the instructor can give additional context within the notes.

In this paper, we discuss selected issues in the design and implementation of our system, particularly our observations during close user testing.

2. Using Trails

While it is necessary to blaze trails before you can use trails, the technique for blazing trails is somewhat secondary to the interface for using trails, since trails will be more frequently used than blazed. Hence, our work began with the consideration of possible user interfaces for presenting trails to students.

Our work began with an analysis of the necessary components of any interface. We decided that,

• 
  students must always know their current position: what trail they're on, where they can go next, where they can go back to;
  
• 
  students must be able to reach an overview of each trail;
  
• 
  a displayed page must include not only the page content, but also the trail context and, possibly, notes from the trail creator;
  
• 
  pages on a trail must use standard URLs; and
  
• 
  each page may, but need not, include links to all of the pages in the trail.
  

These design guidelines gave us a great deal of freedom in the ways to present these different attributes. There are clearly a number of design choices relating to

• 
  positioning of the trail information, which might appear above the page material, to the side of the page material, or even in a separate window;
  
• 
  the number of links to other pages in the trail, from just two links (next and previous) to a complete list of links, or even a small window on the trail;
  
• 
  the level of detail in the links to the other pages, which might give the full name of the other page, or simply a position number; and
  
• 
  the presentation of links to other pages, which might appear as a menu or series of textual links.
  

At this stage of the work, our goal was to evaluate how students might react to different presentations of the trail. We began with four mockup interfaces that explored different combinations of these choices. While it might have been more appropriate to test each design choice independently, it was also clear that some combinations were more natural. For example, if the trail is presented in a second window, it makes sense for that window to include many or all of the nodes in the trail with their name, and not just the next and previous nodes or numbers for each node. The four mockups were

• 
  A simple interface which included the full list of pages in the trail at the top and bottom of each page. The links were numbers, giving the position of the page within the trail. To give the reader some context, we included a blue dot at the current position within the trail. The first picture in (Fig. 1) shows this interface with a course page.
  
• 
  A simpler interface which included only trail name and next and previous links as arrows. The second picture in (Fig. 1) shows this interface with an institutional home page.
  
• 
  A framed interface which presented a textual “trail table of contents” to the left of the page. The third picture in (Fig. 1) shows this interface with a set of major guidelines.
  
• 
  A separate window listing the textual table of contents.
  

In almost every case, the design strategy for the mockup bore some resemblance to typical site interfaces on the Web. The two simpler interfaces resemble the lists of pages of search results typically given by search engines like Altavista. Similarly, the table of contents at the left format is a typical navigation tool for sites, one that is sometimes implemented with HTML tables and sometimes with frames.

Experienced computer users preferred the “table of contents at the left” or the “separate contents window” interfaces. Less-experienced users preferred the simpler interfaces. However, less-experienced users also noted that they wanted some way to “jump around” the trail. Almost all users noted that the “table of contents” interfaces used a lot of screen space. Because we were testing on large monitors, they did not find this a problem. However, many worried what would happen when used smaller monitors.

Figure 1: Three trail mockups (Numbered “Blue Dot”, Just arrows, and Framed).
Many comments also served to validate our initial design goals. For example, when an interface seemed to provide less context, readers asked for “more context, as in the other interfaces”. Readers also wanted clearer next/back arrows in all but the simplest interface.

Because different readers find different interfaces more intuitive, we decided to include configuration mechanisms in the program. That is, each reader can select which way trails are presented for her.

This decision also gives us the opportunity to do somewhat less direct and more realistic user testing. In particular, we can see how (and whether) readers switch trail interfaces as they become accustomed to using trails. Such testing is planned for spring 2000.

3. Architecture

The architecture of our system is fairly simple and takes advantage of the Web Raveler page-transformation infrastructure (Kensler and Rebelsky 2000). WebRaveler is an account-based system that mediates communication between Web browsers and Web servers. Each time a reader requests a page, Web Raveler intercepts the page before it is returned, looks up information on the reader, and transforms the page according to the needs of the reader. Because Web Raveler supports a plug-in architecture, we were able to develop trails as a plug-in for Web Raveler. (Fig. 2) illustrates the interaction between Web Raveler and Blazers

Figure 2: The Relationship between Blazer and Web Raveler.
A student using Web Raveler with trails first logs in to Web Raveler. She then surfs the Web as normal. After intercepting the page from the server, Web Raveler sends information to the Blazer plug-in (6a) about the student, the URL of the page, and the content of the page to Blazer. The Blazer plug-in then sends the URL to the Blazer server (6b) to determine if the page is part of a trail. The server returns (6c) either a list of trails and associated trail information, or a note that the page is not on a trail. If the page is not on a trail, the plug-in returns it (6d) unchanged. However, when the server indicates that a trail is available for the page, the plug-in modifies the page to add information about the trail and then sends the page back to Web Raveler (6d). Web Raveler may then pass the page through other plug-ins (7) and then returns the “trailed” page to the Web browser (8). The Blazer server uses a simple database to associate trails with each URL.

One unresolved issue in this architecture is how to resolve situations in which multiple URLs are associated with the same page. Many Web servers return a default page when the URL requested is a directory. For example, http://www.math.grinnell.edu/ and http://www.math.grinnell.edu/index.html are the same page. Ideally, Blazer would add the same trail for each URL. Unfortunately, the overhead incurred in checking equivalence of URLs is currently quite great, so Blazer and Web Raveler treat them as separate pages.

4. Blazing Trails

While there are some clear guidelines for how interfaces should present a trail (or at least what interfaces should present), the design of trail blazing tools is somewhat less specified. Just as different Web authors have radically different techniques for building pages, from “raw HTML” to graphical editors like PageMill, from custom applications to “save Word as HTML”, so will different trail authors have different preferences for the ways in which they build trails.

To support different trailblazing techniques, we use a standard file format. Just as some authors write raw HTML, so too can some authors write “raw trails”. Authors can include comments by beginning a line with a pound character (#). An entry in the file begins with the URL, followed by a vertical bar (|), followed by the Web page title as it should appear to a person browsing the trail, followed by another bar (|) followed by any comments that the author wants to share about that particular Web page.

But few authors will want to create trails in this way. Hence, we chose to include two other mechanisms for building trails. Trailmaker, the authoring tool, for novices, runs in any Web browser. The tool presents two frames, one on top of each other. The bottom frame is used for a preview of the page to be included in the trail, and the top frame shows the additional information that will be recorded in the trail. The top frame, used for authoring, includes sections for the URL (which may be dragged and dropped from the top of the browser window), the author's name, page title, and comments. In addition, a preview of the complete trail is shown in a separate Web browser window. Trails can be built from scratch or modified from existing trails.

While this interface is particularly appropriate for those whose primary Web experience is browsing, another interface might be more appropriate for those used to authoring Web pages. Hence, we built a second tool that reads the links in a file and turns those links into a trail. Since every page in a trail includes both title and comments, the link text is used as the comment and the title of the destination document is used as the title in the trail. Authors accustomed to building pages with links can use whatever system they prefer to build a "list of links" page and then run this tool to build their trails. This tool has been successfully used to build some very large trails, including one with over three hundred pages.

We tested the two interfaces on a variety of potential trailblazers, including some whose main use of computers is browsing and some experienced programmers. Surprisingly, users found little to recommend one over the other. Most found it comfortable to create trails in either way.

5. An Application: Student Trailblazing

Why build trails? In the introduction, we suggested two important reasons: trailblazing empowers students and trails ground students, thereby reducing the chance of getting lost in hyperspace. Yet trail-blazing has other educational uses. In particular, a teacher might ask students to create trails based on a particular subject. This activity differs in many ways from the related “build a Web on this subject”.

First, students must do more than collect resources; they must also order those resources. While hypertext encourages multidimensional structures, students must also learn the ordering and relating that is necessary for coherent arguments and narratives. Second, students must annotate these resources. Again, this requires students to do more than just decide “this page is interesting and about my topic”. They must explicitly indicate how the page fits into their “narrative trail”.

Our initial experiments with asking students to build trails have suggested that students find the task quite challenging. Since their primary experience on the Web is gathering, and not sequencing, they find it difficult to think about how one might sequence these pages that are related by topic but not by order.

6. A Risk: Page Modifiers from the Author’s Perspective

While there are many benefits to trail-blazing tools, there are also some significant concerns raised by the use of tools that modify pages on both local and remote sites. Consider the case of ThirdVoice (ThirdVoice 1999) (Warner1999), a browser plug-in that allows readers to add and share annotations. Although there are many appropriate uses for this tool, such as instructors posting notes on remote pages for students to read, many made inappropriate use of the tool, such as posting links to pornography sites on common locations like whitehouse.gov and disney.com. Even without these abuses, many page authors were concerned that ThirdVoice usurped their literal authority, permitting others to “modify” their pages (Oakes 1999). Any page modification tool must consider such issues.

Because we rely on Web Raveler (Kensler and Rebelsky 2000) for our infrastructure, we are able to provide some support for page authors. In particular, Web Raveler includes a language that permits page authors to limit the modifications done to pages. Hence, authors can indicate that they do not want trails added to their pages, or limit trail use to certain domains. If authors permit trails for a page, they cannot specify that certain pages (or types of pages) should not be included in trails.

During early user testing, we built some prototype sites using local copies of remote pages, to support faster access to the locations in the trail. However, we did not always copy images. In one case, a subject-generated trail created some controversy, since the pages in that trail included images from another site. The owners of that site claimed that we were attempting to “steal” both their pages and their bandwidth. Fortunately, we were able to convince those authors that we were working on a useful research project and not attempting to create a mirror of their site. In subsequent work, we turned off remote access for any locally generated trails. However, such issues remain a concern.

7. Related Work

In spite of the importance of trails to the World Wide Web, there seem to be surprisingly few systems that permit readers to add links and trails to pages. The most notable trail-blazing system is Walden's Paths (Shipman et al. 1998) (Shipman et al. 1999). At times, trailblazing is subsumed under a notion of annotation, as in (Roscheisen et al. 1995).

Our Blazer system differs from Walden's Paths in a number of ways. First, Blazer provides more mechanisms for authoring trails. Walden's Paths provides one tool, which has some similarities to our novice interface. Because we use a simple, open, textual, trail format, it is possible to design new interfaces. Second, Blazer gives readers many more opportunities to customize their display of trails and have employed user testing to develop this interface. Walden's Paths uses one fixed display that consumes a significant amount of screen space. Third, Blazer users standard URLs and informs students about the availability of paths when they view pages that happen to be on paths. Walden's Paths assumes that students intentionally start on a path, and also uses special URLs for the pages on the path. Finally, because we rely on Web Raveler (Kensler and Rebelsky 2000), we have the opportunity to use information about the student in presenting path information and to interact with other Web Raveler plug-ins. For example we might automatically present a different path based on information about the student’s skills or browsing history.

Admittedly, Walden's Paths has some advantages over our system. It has been used much more widely and has been used successfully for a number of different applications at different levels. We hope to compare the applicability of the two trail-blazing systems for similar activities.

Both Walden's Paths and the Blazer system have many advantages when compared to annotation-based trails. In annotation-based trails, page annotations can include links to the next and previous pages on a trail. However, such trails are clearly difficult to build and maintain. For example, inserting a page into an annotation trail requires that you modify the annotations in three different pages. While trails provide an interesting application of annotations, a separate annotation system is clearly preferable.

8. Conclusions and Future Directions

For the Web to empower readers, it must permit readers to do more than follow links and build pages that link to and never from other pages. The Blazer system empowers readers by letting them build trails through the Web, using both local and remote pages. It therefore provides an important resource for teachers, not only letting them build trails to help guide their students through the Web, but also providing context to browsing and empowering students to create their own trails.

Yet our work is not done. While we have done some user testing for various parts of the interface, we need a comprehensive study of how readers prefer to see trails (and forthcoming). We also need to study more closely how students and faculty will use trail-blazing tools and whether the assignment to “build a trail” can really make students think about linear structure.

9. References

Bush, V. (1945). As We May Think. Atlantic Monthly, 176 (1), 101-108.

Kensler, A., and Rebelsky, S. A. (2000). Web Raveler: An Infrastructure for Transforming Hypermedia. Proceedings of the EdMedia 2000 World Conference on Educational Multimedia. Charlottesville, VA: Association for the Advancement of Computing in Education.
Landow, G. P. (1997). Hypertext 2.0: The Convergence of Contemporary Critical Theory and Technology. Baltimore, MD: The Johns Hopkins University Press.
Luebke, S., Mason, H., and Rebelsky, S. A. (1999). Annotating the World-Wide Web. In B. Collis and R. Oliver (Eds.), EdMedia 99 World Conference on Educational Multimedia, Hypermedia, and Telecommunications (Seattle, Washington, June 19-24, 1999), 409-414.
Nelson, T. H. (1974). Computer Lib/Dream Machines. Self-published.
Oakes, C. (1999). The Web's New Graffiti? Wired News. Online document at http://www.wired.com/news/news/technology/story/20101.html. (Created 9 June 1999. Accessed 20 July 1999.)
Roscheisen M., Mogensen, C., and Winograd, T. (1995). Beyond browsing: Shared comments, soaps, trails, and on-line communities. Computer Networks and ISDN Systems, vol. 27, 739-749, 1995.
Shipman III, Frank M., Furuta, R. Brener, D., Chung, C.-C., & Hsieh, H-w.(1998). Using Paths in the Classroom: Experiences and Adaptations. Ninth ACM Conference on Hypertext and Media, 267-276.New York, NY: ACM Press.
Shipman II, Frank M., Furuta, R., Hsieh, H., Francisco-Revilla, L., Karadkar, U., Rele, A., Shenoy, G., V., and Brenner, D. A. (1999). Using the Internet in the Classroom: Variety in the Use of Walden's Paths. In B. Collis and R. Oliver (Eds.), EdMedia 99 World Conference on Educational Multimedia, 335-340.
ThirdVoice (1999). ThirdVoice.com. (Accessed 20 July 1999.)
Warner, M. (1999). Third Voice. Fortune.com. Online document at .http://www.pathfinder.com/fortune/cool/thirdvoice.html. (Created 5 July 1999. Accessed 20 July 1999.)

Acknowledgements

Portions of this work were funded by the Computing Research Association's Computing Research Experiences for Undergraduates (CREW) Program, Grinnell College, and the Robert N. Noyce Faculty Study Grant. The current incarnation of our tool owes a great deal to the Web Raveler infrastructure, and we are grateful to Andrew Kensler for his development and support of that tool. Many members of the Glimmer research team contributed ideas to this project.