mhb@src.dec.com,
http://www.research.digital.com/SRC/people/Marc_Brown/bio.html
Robert A. Shillner, Department of Computer Science, Princeton University, Princeton, NJ 08544
ras@cs.princeton.edu,
http://www.cs.princeton.edu/~ras/
Most Mosaic-inspired browsers support other navigation methods in addition to these primitives; for instance, the user may jump to different URLs using the "Hotlist" and "Open URL" dialogs. Most browsers also offer multiple open windows, each with its own depth-first visitation stack. However, with the exception of Netscape [4] and InternetWorks [3], the browsers are single-threaded, so while one window is downloading a page, all of the windows owned by the browser become inactive.
We have developed DeckScape, an experimental browser for exploring new methods of navigating and organizing pages on the Web. DeckScape centers on the metaphor of a deck: a collection of Web pages, of which only one is visible at a time. When the user clicks a link on a page, a new Web page appears on top of the deck, obscuring the page that was previously visible. The user may leaf through a deck's pages one at a time, jump to the top or bottom of a deck, or move to any particular page by choosing its name from a list of the deck's current contents. The browser itself consists of multiple decks, all in a single top-level window. Users may move, resize or iconify decks, move or copy pages between decks, start new decks, delete decks or pages, and so on. The contents of decks persist between invocations of DeckScape.
The key benefit of the deck abstraction is that it provides a way to organize material. For example, a user may keep the home pages of all of his or her colleagues together in a deck named "Colleagues," or keep several Mosaic-style hotlists, each in its own deck. DeckScape further uses decks to return the results of certain operations, such as "expand all the links on this page."
DeckScape is also multi-threaded. In particular, fetching a new page occurs in the background, in a separate thread. Thus, unlike single-threaded browsers, traversing a slow link or downloading a large file does not freeze the entire application. All decks remain active and ready for browsing, and multiple links may be traversed concurrently.
(Of course, one could start up multiple instances of a single-threaded browser. This would have the advantage that, when traversing a slow link or downloading a large file, the other instances would remain active. However, multiple instances have the drawback of increasing the amount of computer resources consumed. Also, multiple instances are completely independent of each other, so there is no possibility to share the information among instances.)
Choosing "New Deck" from the File menu produces a new deck with a default name, containing a single document: the user's home page. Clicking links adds more pages to the deck. Buttons let the user shuffle through the deck's contents or go to the top or bottom of the deck. The user may create more decks and use them to follow different links. This behavior is similar to that of a traditional browser: creating windows, clicking links and moving forward and back.
Here we see DeckScape with a single deck. The deck,
named "WWW'95", has six pages in it. The user is looking at
the second page in the deck, whose URL is
http://www.igd.fhg.de/www/www95/program.html:
DeckScape retains all pages until the user explicitly discards them, while a traditional browser retains only those pages on the path from the root to the current page. For example, if a user starts at page A, then traverses some pages (including B) and ends at C, both DeckScape and a conventional browser keep copies of all the pages from A to C. However, if the user then backs up to B and chooses a new link, a traditional browser discards all of the pages after B up to and including C. On the other hand, DeckScape keeps all of those pages and inserts the new page into the deck just after B.
This design allows users to quickly switch back and forth between two or more pages which do not lie on one convenient path from the root, but rather lie on different branches of a tree. Traditional browsers would have to download and parse each page on each traversal, while DeckScape allows the user to flip quickly through the deck's contents without refetching any pages. (DeckScape has a "Reload" command to refetch a page, rather than use the page from its internal cache.)
Once a deck has been built up, a user can modify the contents of a deck in several ways. Clicking a document's "D" button deletes the document from its deck. Dragging a document from one deck to another moves the document between decks. Holding down an appropriate modifier key while dragging copies the document. Clicking a deck's "Merge" button and dragging to another deck merges two decks by adding all of the pages from the first deck into the second one, immediately after the second deck's current page.
The ability to pull a page away from its deck allows the user to simultaneously view two or more pages from the same deck. It is often useful to have certain pages, such as glossaries or reference pages, visible for an extended period, even while following another chain of links. DeckScape allows users to drag such pages off to the side and continue following links on the main body of the deck, leaving the "special" pages easily accessible.
In the following screen dump, we see three decks, "Ongoing
SRC Research Projects," "Nifty home pages," and "Palo Alto
stuff." The narrow window in the lower-left is showing an
"away" page from the "Palo Alto stuff" deck:
When the user follows a link on an "away" page, the resulting new page appears on the main body of the deck. This behavior is useful when one page, such as a table of contents, has many links in which the user is interested. Ordinarily, clicking a link on such a page would cause a new page to cover up the table of contents, so that the user must dig through the deck each time he or she wishes to follow a new link from the table of contents. If, however, the user were to pull the table of contents away from the deck, then the page would always be handy for following new links; the resulting pages appear on the deck and do not cover up the table of contents.
Similarly, the user could click many links on an "away" page in rapid succession, causing many new documents to appear on the deck. Since DeckScape is multi-threaded, the user need not wait for one download to complete before clicking another link. The user can browse through the resulting new documents immediately, even before all of the downloads have completed. No traditional browser can support this type of Web exploration because in a traditional browser clicking a link always makes a new document cover up the page containing the link.
Browsing in this manner is particularly effective when combined with a deck's "Make Link Index" command. This command finds all of the links on each page in a deck, then adds to the deck a new page containing all of the links in alphabetical order. The new page provides an index of all the links accessible from any page in the deck. The user may then drag the index page away from the deck and click a series of links, browsing through the resulting documents as they appear on the main body of the deck.
Another use for "away" pages is for creating new decks. If a user wants to start a new deck from a particular page, he or she can drag the page away from its home deck, then issue the page's "Make New Deck" command. A new deck appears, containing the page.
Another use of decks is to organize hotlists. DeckScape has a special hotlist deck, and each document has a "copy to hotlist" button. When a user comes across an interesting page, he or she can click the "H" button to copy the page into the hotlist deck. Users can also use ordinary decks as hotlists by manually copying interesting documents into them; thus, each user may have many hotlists, organized by whatever criteria are appropriate.
In the following screen dump, the hotlist deck is in the
lower center. The hotlist is like any other deck, except
that it cannot be renamed or deleted by the user. The "Goto
Page..." dialog allows the user to select and jump to any
document in a deck, either by its title or by its index.
In the following screen dump, the
deck entitled "Expanding 82 links" is the created by issuing
the "Expand One Level" command in the "Deck 12" deck. This
page in the "Deck 12" is the home page for the Systems
Research Center. It is common to issue the "Expand One
Level" command on the home page of Web sites in order to
create a new deck that contains the pages most relevant to
the home page. These pages can then be rapidly traversed
with a single button. When the screen dump was taken, 79 of
the 82 links had been retrieved, and the user was looking at
the 24th page in the deck.
Global search is another operation which returns its results in a deck. After the user enters the text to be found, DeckScape searches through all the pages in each deck. It copies the pages that contain hits and makes a new deck containing the copied pages.
In the following screen dump, the deck labeled "Search
Results" contains a copy of each page from any deck matching
the string "animation."
DeckScape's primary components are object classes that correspond to portions of the visual interface; these visual classes have names ending in "VBT". The VBT classes, along with other non-visual classes, constitute a hierarchy of abstractions which make it possible to easily integrate the browser's functionality into other Modula-3 applications.
The remainder of this section describes the modules comprising the implementation.
We do not claim that DeckScape is the correct way to browse the Web and organize pages in the Web. Discovering and quantifying the strengths and weaknesses of decks are challenges for the future. We hope that the ideas introduced in this paper will help to advance the standard for navigational and organizational capabilities of Web browsers.
A two-page summary of the DeckScape system will appear in the Conference Companion proceedings of the 1995 Conference on Human Factors in Computing Systems (CHI'95), sponsored by ACM/SIGCHI.