Vision&Reality
     of Hypertext and Graphical User Interfaces

NoteCards (cf. 2.1.6) is originally a research project at Xerox PARC starting in the early-1980s. It uses a physical card metaphor; i.e. each card displays its content in a separate window. The system is designed to support information-analysis tasks, like reading, interpretation, categorization and technical writing [Shneiderman/Kearsley 89]. For that reason the focus lies on structuring and editing information compared to a more browsing and reading focus of Hyperties and Guide that run on less powerful personal computers. Consequently a special browser card displays an overview graph to illustrate the connections between the cards.

NoteCards is fully integrated with the InterLisp environment for Xerox workstations. This means that it is highly customizable for the skilled user.

2.1.6 NoteCards

in Vision and Reality of Hypertext and Graphical User Interfaces

One of the developers of NoteCards, Frank Halasz, describes the hypertext system in Reflections on NoteCards: Seven Issues for the Next Generation of Hypermedia Systems [Halasz 88]. Halasz and his team at Xerox PARC use the physical world of index cards as metaphor. A card corresponds to a window, i.e. each card has its own window. Hyperlinks are references to other cards, but not to special locations within the cards. The framed title of a card is used as a link marker to the card. Clicking the box does open a new window to display the content of the destination card – or the window comes to front and gets activated if the card was already open.

In addition to the standard text and graphic cards, NoteCards has more card types built in. These are filebox and browser cards. They support the user in sorting and categorizing the content cards. A filebox is a simple way to collect cards that have some aspects in common. Fig. 2.6 shows two filebox cards in the lower left corner. Fileboxes can also contain other filebox cards and provide to such an extent a hierarchical structure among the cards. A browser card shows a diagram based on the link structure between the cards. The large window in Fig. 2.6 is an example for this.

Cards are interconnected by typed links. That means a label is assigned to a link to describe the kind of relationship between two cards.

Fig. 2.6 NoteCards. The browser card shows a structural diagram of nodes and typed links. 2 filebox cards (bottom left and center) hold links to other cards.The standard note card (bottom right) contains a link to a card entitled “Tomahawk Characteristics”.(‘<Unspecified>’ probably means that the link type is yet undefined.) The example is taken from the working materials of a graduate student in history, who has used NoteCards to structure the domain of the research topic [Halasz 88, p. 839].

Frank Halasz continues his paper with the discussion of 7 issues, that are crucial in his opinion for the next generation of hypertext systems [Ibid., p. 841] (respectively his presentation at the first hypertext conference 1987 with the same title [Halasz 87, p. 352]). Four points will be presented here.* * The skipped items are Issue 4: Computation in (over) hypermedia networks, Issue 6: Support for collaborative work and Issue 7: Extensibility and Tailorability.

Search and Query in a Hypermedia Network. Sophisticated search capabilities should extend and complement the navigational character of link following. This should act against increasing problems with the user’s orientation in hypertext. Content searches like «all the nodes containing the string “hyper*”» [Halasz 88, p. 842], as well as structure searches should be provided. An examples for a structure search would be, «all subnetworks containing two nodes connected by a [link of the type SUPPORTS], where the destination node contains the word “hypertext”» [Ibid.]. Another example would be the search for «a circular structure containing a node that is indirectly linked to itself via an unbroken sequence of “supports” links» [Ibid.]. This query would reveal circular arguments.

Composites – Augmenting the Basic Node and Link Model. Filebox cards and browser cards serve a special purpose in NoteCards. They are temporary provisions for a missing concept in the ordinary hypertext model with nodes and links. Dealing with a set of nodes should be well integrated into the model. For example a specific group of hypertext nodes describes various aspects of a juristic case. It should be possible to refer to the case as a whole rather than linking to all nodes individually.

Virtual Structures for Dealing with Changing Information. Not all kinds of data fit into the static structure of hypertext. Information is in flux and requires the author to update the network ceaselessly. Just take a news ticker as an extreme example for a source of continuous flow of information. Future hypertext systems should be able to manage this kind of situations.

Versioning. The area of versioning has already been mentioned as one of the xanalogical conditions. Halasz carries on with versioning for changing link structures. And he rises the question of semantics: Is it correct to automatically link to an updated node without verifying the link?

Many of Halasz’ statements sound also familiar in the Web context, albeit they have been written nearly fifteen years ago and long before the Web took off. Search and Query – Search engines that index and categorize Web services like Google and Yahoo play an important role for the World Wide Web. Composites – just the concepts of filebox cards and browser cards integrated into the Web would boost the current appearance of the Web. Possible areas for application are guided tours, site maps, and bookmark lists. Established interface standards for composites could support the user in navigating the Web. Virtual Structures – Content Management Systems deal with databases and xml templates to dynamically create Web pages. Finally versioning is still an unsolved but important problem.



 For a free PDF version of Vision and Reality of Hypertext and Graphical User Interfaces (122 pages), send an e-mail to:
mprove@acm.org   I’ll usually respond within 12 hours. [privacy policy]