Architext 180

Document Examiner 180

Guide 182

HyperCard 184

SuperCard 187

Hypergate 189

Intermedia 190

KMS 192

LinkWay 193

Neptune 194

Notecards 195

Problem Solving Applications 197

Ibis 198

Individual Systems of Hypertext

Architext

Architext is a multipurpose hypertext environment built for the Macintosh. It provides a large set of functions for importing, exporting, and editing text and pictures. It has a good toolbox for creating graphics. It supports navigation with a wide variety of goto and search procedures. It lets the user build maps of the nodes that are created. It offers a broad range of the many new ways in which hypertext can be used to organize and process text and data. One of its strong features is the ability to search for words and word combinations using the Boolean operators AND or OR at the sentence, paragraph, or document level.

Document Examiner

Janet Walker from Symbolics presented the Document Examiner which is one of the few HYPERTEXT systems to see real commercial use. It is used for the online manuals for the Symbolics workstation and had two goals: To be a better tool for the technical writers and to allow easier access for customers. They set out to solve those two practical problems and not specifically to build a HYPERTEXT system as such even though that is what they ended up having.

Also, readers should not have to work as hard as writers, so they designed two separate user interfaces to the system. The one for the writers is called Concordia while the Document Examiner is the readers' interface. Currently the system has 10,000 nodes and 23,000 explicit links between nodes as well as 100,000 implicit links. Each node has an average size of 1 K, so the total system has 10 M of info. The information was modularized by conducting an analysis of the information needs of users: If they would need or want to look up some specific issue then they made a module for that info.

The goals in the design of the user interface were as follows: 1) Keep the user's model of what is in the system as simple as possible, so don't use a network based navigation model. 2) Learn from how people use paper-based documentation and provide the same capabilities. 3) In addition, exploit what is unique about the computer.

The Document Examiner project started 1982 and it was first shipped to users April 1985. The local engineering staff at Symbolics by now prefer the system over the paper version: About half of their engineers had not even taken the new manuals out of the shrink-wrap. I asked whether they had considered totally getting rid of the printed manuals and was told that they probably would do so but that it still was some years away. Also, of the 24 engineers surveyed, 2 said that they did prefer the printed version.

They have monitored the use of the system for a year and collected 68,000 data points, 43,000 of which are from "real users". It turns out that searching and context commands account for 40 % of the use.

The Document Examiner has been used in several projects for instruction. In Fischer and Mastaglio's Lisp Critic, the Document Examiner is used to provide detailed supplemental inforamtion about Symbolics Lisp, when the Lisp programmer has repeated diffiuclties with a function.

Guide:

Guide, from OWL International, was the first hypertext system for personal computers, preceding Apple's HyperCard by a year. Guide did not start as a hypertext project. Rather, it was designed by P.J. Brown as a document presentation vehicle. Guide was developed into a hypertext system and implemented in the PC world by OWL.

Guide can be described as a system in which the reader is provided with a friendly interface to screen-based documentation. Guide does not attempt to imitate the linear structures of paper-based information. Rather it presents an hierarchical view of information, allowing the user to read only those parts of the documents in which she is interested. The reader simply points to a text highlight (called a button) with a mouse driven cursor, clicks the mouse, and displays a detailed expansion. In addition to text, Guide supports high resolution graphics, and graphical objects can also be made into buttons. Similar point/click actions on other types of button cause reference points in the same document or in other documents to be displayed, or cause pop-up notes to appear. Navigation within and between documents is simple and intuitive. Another important feature of the software is that the author's view of documents is identical to that of the reader.

The original version of Guide, begun in 1982 at the University of Kent, ran under UNIX on a PERQ workstation. The development there continues on UNIX workstations, although Guide's best known applications are on personal computer. OWL developed the initial PC version for the Apple Macintosh. In converting the original version to the Macintosh, many features were eliminated in order to fit it into the limited memory of the machine. In 1988, OWL introduced an IBM version, which runs under Microsoft Windows on the PC, XT, AT, and compatible machines.
The most distinct feature of Guide is that it sees a document as a single, continuous scroll rather than a series of nodes or information packets. Guide links document substructures together rather than fragments.The user has the option of scrolling through the document in a linear fashion.
Guide provides three primary linking structures (hotspots or buttons). The most commonly used is the replacement button, which replaces information on the screen with new, usually more detailed information, so the replacement button supplants the need for built in menus. They enable the user to select between several alternative replacements. Replacement buttons typically lead to more replacement buttons, which enable the user to document to the desired level of detail. Text, graphics, or other documents may be stored under these buttons to a depth of 32 levels. The advantage of this linking method is that all new material is seen in context. Guide also provides note/glossary buttons for quick reference and reference buttons which transport the user to different parts of the documents.

Typographical cuing is used extensively as a graphical interface technique in Guide. Guide versions of lengthy articles or 'books' use such cuing . The example shows some cuing. Here a journal article has been turned into a hypertext document. Simple, but effective cuing is used. The 'folded' elements are displayed in bold characters, e.g. "Table 3". Further when the cursor moves over such 'hot spots' it changes shape to a cross-hair from the standard vertical bar. Graphical browsers, text frames and even cursors can be used to indicate the nature of the task and thus facilitate browsing. Different buttons are signalled by the changing shape of the cursor.
Guide, like most other environments, is a hypertext system for creating hypertext as well as a browsing tool for viewing documents.

HyperCard

The fastest growing application of hypertext, particularly for general-purpose, personal-computer-based systems, is for authoring computer based instruction materials. Hypertext environments like HyperCard are so friendly and productive that educators are producing large quantities of HyperCard "stackware." At AECT 90 in Anaheim, there is even a stackware exchange program for HyperCard . Stackware typically supports the instructional goals of the producer. Much of this stackware, however, lacks many of the characteristics of hypertext. Much of it is linear, frame-by-frame instruction that possesses little interactivity.

HyperCard provides many sophisticated design tools, so the courseware produced with it is easier to produce and looks more inviting than the traditional textbook products or even earlier CBI it to some extent resembles. Hypertext environments like HyperCard are capable of producing sophisticated computer-based instruction as well as hypertext.

John Sculley, CEO of Apple Computers, has referred to HyperCard as a hypermedia tool kit. He claims that it is as important to the MacIntosh family of computers as Applesoft BASIC was to the Apple II family a decade before. Hypercard is an authoring environment and information organizer, according to Bill Atkinson, its creator. He pieced together, adapted and expanded other Macintosh application programs like MacPaint to produce Hypercard. He insisted that it be free to the buyer. Apple agreed that it would be such an important application that they have bundled it with Macintosh computers. HyperCard is a general purpose tool for Macintosh users as well as a hypertext editor.

HyperCard functions at three levels--browsing, authoring, and programming. At the browsing level, users may navigate through existing HyperCard stacks and add to or edit the stacks to the extent allowed by the author. At the authoring level, authors use a variety of powerful field, button, and paint tools to create stacks of cards. These cards are linked together sequentially in the order they are created, and can be shown this way in a kind of automated slide show. But more interesting effects can also be created by developing unique trails and meshes by the creation of buttons, scripted fields, and more complicated control structures written in the HyperCard programming language, HyperTalk.
HyperCard provides flexibility in the style, position, and type of buttons that can be easily created. More sophisticated linkages are created at the programming level, where authors may use a simple, structured, object-oriented programming language called Hypertalk. HyperCard can import text and graphics and export text as well as launch other programs.

HyperCard provides a very useful navigation and overview facility summoned by pressing the menu command "Recent". This command allows the user to see a table of shrunk versions of up to 42 of the most recent cards visited. In the example shown below the cards are laid out in the order visited, with repeated visits to the same card removed. This overview browser is very different from the hypergraph node and link browsers made popular by Notecards. In part, this is because Hypercard and Notecards, in spite of the similarity of their names, are basically two different kinds of hypertexts; the "Holy Scroller" versus the "card shark". Notecards lets the hot spots in text scroll with the text (Holy Scroller); whereas the first version of Hypercard forced hotspots within fields to be on non-scrollable text, fixed on the card (Card Shark). Recent updates have overcome this problem to some extent, allowing better text management and supporting "sticky" buttons on scrolling text fields. However, the archeology of the

Here is what Jakob Nielsen had to say about his experience developing a HyperCard stack from a trip report of his attendance at the first Hypertext Meeting in North Carolina in 1987:----------------------------------------------------------------

At first, I wrote this trip report as a traditional, paper-oriented document in Microsoft Word.
This version is about 36,500 characters and is printed in the ACM SIGCHI Bulletin. I spent approximately 12 hours writing this basic text.
Then I developed the basic set of background cards and the necessary software to handle such tasks as linking reader comments with the right cards and establishing menus of comments in case there is more than one comment for a given card. I spent about 17 hours on this software development.
Finally, I imported the text from the Word file into the HyperCard structure and edited it to become a hypertext linked structure with concept maps to guide the reader.
This reorganization took me about 11 hours (plus 7 more hours to import three earlier reports which were not reorganized as thoroughly into hypertext).

I have had considerable difficulty in building complex hypertext structures in HyperCard. By complex structures I e.g. mean hierarchically nested pop-up notes with their own graphics, buttons and nested pop-ups.

Most of these problems can be solved by programming special handlers which e.g. hide and show a large number of fields and buttons at the same time (they are slow on an ordinary Macintosh, but they will run). It is not possible however, to have nested graphics.---------------------------------------------------------------

What he says is not at all correct, and shows the dominance of a functional programming orientation. Nested graphics are easy to create, using the copy and edit techniques that HyperCard excels in. By copying the whole card and editing it, and then continuing to copy and edit, virtually any structure can be created. What this does however, is create enormous waste of memory, since the same thing might be done much more economically with a few simple functions. However, for those who cannot write the functions, copy and edit provides an iterative procedure that is fast and direct, and uses much more general and generally available skills than functional programming.

HyperCard has been used in several large trials. The first, sponsored largely by Apple, is an overview and user's guide to the 1988 Human Computer Interaction Conference in Boston (<< >>). Another is the Glasgow - Online project (Baird, 1989) which now encompasses some 21 floppy discs (over 14 megabytes of data) on the MacIntosh.

Glasgow Online - HyperCard database

Glasgow Online is a hypertext system being developed by the Department of Information Science at the University of Strathclyde, using Apple's HyperCard. Glasgow Online is an integrated database on the life and times of the City of Glasgow. The information is already available in other forms, but scattered far and wide.The aim of the project is to use the medium of hypertext, not to emulate the many books, pamphlets, guides, etc. on Glasgow, but to integrate, repackage and restructure that information to provide users with an electronic conspectus on the City and its culture. Essentially, therefore, Glasgow Online will be a hypertext of community information for many interested people: tourists, researchers, teachers, students, and businessmen.

SuperCard

This product from Silicon Beach Software, Inc. is a powerful, but some say slow and memory-hungry, upgrade to HyperCard for the Macintosh. It adds many utilities, such as floating menus and dialogue windows, color images, reflowable text windows, and sticky buttons to scrolling windows, beyond those available in HyperCard. The potential for color is what attracts many to this system. The many utilities for programming, including having all possible functions, commands, properties, and variables available from menus in the scripting environment, is an enormous advantage to those who have an inclination to program in this environment. Graphic objects as well as bitmaps are supported, adding much greater flexibility to copying and editing functions. However, for the non-programming majority, there are not many additions that actually increase access to programming power without a dramatic increase in the complexity of the skills needed to work in the environment.

Perhaps one exception to this, is the several ways in which animations can be created by just moving objects on the screen and having the system record and then later replay those motions. SuperCard uses PICS, an animation file format supported by several animation programs for the Macintosh. SuperCard provides several simple functions and examples to open, record, and playback PICS files simply by pressing a button or using the commands in a message box. The full sequence, then, is to draw a scene that is to be animated, open a PICS file, record the scene, move the object several times while recording the scene, close the PICS file, and then play it back as the full animation. Most of this process can be automated by simple scripts,a nd the result is very pleasant and convenient.

Some of these functionalities, such as sticky buttons in scrolling fields, and color bitmaps, are now available in release 2.0 of HyperCard itself. However, it is still not possible just to select text in the window and turn it automatically and smoothly into a hotspot that links to other text or graphics. In part this retraces the archaeology of the development of Macintosh-based hypertext systems, with their bitmap-based origins, rather than having roots in text and retrieval mechanisms. The selection used as the basis for computational activity, is a selection of a piece of area on the screen, rather than a set of characters. In both HyperCard and SuperCard it is quite possible to develop text-based hypertext by writing search and find, or link routines based on system features like selectedChunk, selectedLine, or selectedText; but they are not as convenient to use as buttons or fields. In fact, it is fair to say that neither HyperCard nor SuperCard have the basic data structures for fast hypertext.

Here is a short HyperCard routine to use to look up unknown words in a dictionary. The dictionary is placed in a background field on as many cards in a stack as are needed. The text you are reading is on a card with this routine on its script. You invoke this script by double-clicking on a word that you are reading. The script will then highlight the dictionary entry in the background field, and if you say "YES", will embed the dictionary entry into the text of the material you are reading. That way you will have the explanation available to you the next time you read the text, and the text will be marked with the fact that you didn't know the meaning of the word the last time you read the text.

This is a fairly simple script, but to write it demands skills far beyond most of the users of HyperCard, and it could have been implemented carefully as a single menu item, if the right data structures were available in these systems.

Figure 10.2 A HyperTalk Script

on mouseUp
global selectedPlace, unknownWord, translatedText, sourceCard
put the id of this card into sourceCard
put the selectedChunk into selectedPlace
put the selectedText into unknownWord
find string unknownWord in background field Dictionary
if the result is not empty then
answer "Not here! But try one more time ..."
exit to HyperCard
end if
select after the foundChunk
put "no" into answer
repeat until answer = "yes"
Ask "is this the right meaning?" with "yes"
put it into answer
if it = "yes" then
select the foundLine
put the selection into translatedText
go to sourceCard
select selectedPlace
put translatedText into the selection
else
find string unknownWord in background field Dictionary
select after the foundChunk
end if
end repeat
end mouseUp

Hypergate

Created by Mark Bernstein of Eastgate Systems, Inc., this is a pure hypertext system, that tries to be as nonlinear as possible. In it, there is no natural "next" card. Everything must go through a button with a title, or at least to a margin note attached to a card. Cards may be marked easily, and "Bread crumbs" are strewn beside the buttons to mark the trails that have been followed. Thumb tabs at the corner of pages provide easy access to bookmarks. Maps must be drawn by hand, not mechanically generated. Every attempt has been made to create a clear and simple user interface. Each card or page is small, independent, and self- contained. They do not scroll. The only other direct navigation aid is a "previous" command that takes the reader back to the last card seen. Some very powerful indirect aids to navigation are an indexing system and a global search mechanism that lists all cards containing any particular string.

Hyperties:

Hyperties runs on standard IBM PC's and compatibles with and without touchscreen. It was first written in APL but has recently been rewritten in C. Hyperties has also recently been implemented for a Sun3 workstation, which provides it with multiple windowing and touchable graphics capabilities.
Hyperties, originally called TIES (The Interactive Encyclopedia System), has been under
development at the University of Maryland since 1983. Rather than using a pointing device,
Hyperties uses the arrow keys to move a light bar onto highlighted objects. It was developed as a browser for information in libraries and museums but has evolved into a fully interactive
hypertext environment for instruction, problem solving, and self-help manuals
(Shneiderman,1987).

The Hyperties editor prompts the author for titles, brief definitions, more lengthy text and synonyms for article titles. The author marks important terms in the text. Hyperties collects these important terms, prompts the author for synonyms, indexes the articles, and provides for notetaking. It also prompts the author for relationships and then creates a link system between terms. In addition to this file management, Hyperties provides a simple word processor for creating the text

Intermedia:

Intermedia has been mainly used in education and research. The first and now typical applications are in English literature and Biology (cf. Landow, 1989; << 1989>>). An excellent videotape of the system in use by Brown students and faculty is available from the Annenberg/CPB project:

Intermedia Tape # 550491
The Annenberg/CPB Project
Intellimation, Inc.
130 Cremona
Santa Barbara, CA 93117

In classes at Brown where the system has already been used, it contains a large number of literary works and annotations and commentary. In the biology course where it has been used the data are digitized microscope slides and many text explanations. Students browse the hypertext by following the links (or a set of links, called a web) on the documents. Several webs may exist for the same underlying data - e.g. one for each student who builds her own understanding of the relationships among the data. Students also start with a web supplied by the professor and then work on refining it. Students find themselves thinking in terms of the relationships explicitly laid out in the hypertext. Because the overall structure is made concrete and explicit it appears easier for students to acquire the conceptual framework of inquiry that the instructor has long sought to transmit. In analyses of the conceptual maps drawn by students before and after using Intermedia, the instructor reports a significant increase in the complexity of the relationships, and at the same time, a dramatic increase in the clarity of the graphs.

A problem now exists when the underlying data changes (perhaps because the professor inserts new material). Because the system does not support versioning (keeping track of the states of the hypertext as it is being updated) there is no objective record of what the students have done that the faculty can call upon to show the new links. If they could return to the old, unmodified version of the hypertext; make their changes; and then ask the system to reimpose the students' changes, it would be easy to update many of them, even automatically, especially in the cases where they link two unchanged parts of the document.

One salient and unique feature of Intermedia is the use of "anchors". Anchors are words imbedded in paragraphs or pages of text that can be automatically accessed from other nodes or links. Anchors are very useful for highlighting important comments that might otherwise be hard to find in large bodies of text. By setting the cursor on the anchor automatically when a node is accessed, annotations and abstract selections are guided gently and the student can be directed subtly to focus on important points.

One important drawback in using the system, currently, is the absence of collaborative facilities and student annotations. Student anchors in particular are lost when hypertext is updated, and these could easily be maintained by the system if versioning were supported.

This description of the Intermedia environment was written by Meyrowitz (1986):
The Intermedia system is built on top of the 4.2 BSD UNIX operating system and runs on IBM RT/PC, MacIntoshes under AU/X, and Sun workstations which support Sun's Network File System (NFS). To create Intermedia, the software development team adopted an object-oriented processor to the C programming language licensed to Brown University by Bolt, Beranek, & Newman as well as Apple's MacApp facility for creating generic Macintosh applications and Cadmus's CadMac toolbox, both under special agreements with Apple Computer. With an object-oriented development environment and a UNIX-based implementation of the Macintosh toolbox, the Intermedia programmers constructed a system that starts with an application framework similar to the Apple Lisa or the Xerox Star environments and adds to that framework's full hypermedia capabilities.

Another important feature that is used extensively in Intermedia, is the time line editor (InterVal) (cf. Yankelovich et al,1987). Time lines provide a very useful orienting system for navigating through complex materials. They impose a linear organization that might hint at a suggested sequence, but also support nonlinear navigation of the same space. They let the user keep track of her position, while giving an overview of how much came before and after. In a sense it can also be seen as a very general scroll bar, with distinct anchors and navigational supports.

KMS

KMS is designed to facilitate collaboration between members of an organization on a variety of applications. It is essentially a knowledge manager. KMS has developed a model for organizational computing for the future--wide-area networks of large screen, diskless workstations (Akscyn et al, 1988).

KMS runs on Sun and Apollo workstations. Large portions of the database can be downloaded to the workstation from a main-frame computer. The user interface is based on a three-button mouse which is used for 90% of the user interactions. After selecting a link, KMS accesses and displays the information in less than a half a second on average. The response time depends upon the size of the display and whether it is cached in the workstation or downloaded from a remote computer.

The basic unit of KMS, like other hypertext, is the frame. KMS has only one type of frame or
node into which text, graphics images, or nothing may be put. A frame is 1132 x 805 pixels. The frame (see the example) consists of a title, system frame name, the body of information, a list of links (usually in a tree or hierarchical structure), annotations, and a command line. The KMS screen is capable of displaying two frames, the previous frame and the current frame, which physically connects the two nodes in a link.
Links in KMS are not embedded in the workspace text, as with other systems such as Hyperties . The destination of a link is a frame, rather than an object within a frame. KMS provides two types of links--tree items which lead to hierarchically related information and annotation links which lead to peripheral material. The primary data structure is created by linking nodes together in a tree structure.

KMS evolved from the ZOG Project, begun at Carnegie Mellon University in 1972. The technology was not available at that time to support the project's goals. The project began developing functioning versions of ZOG from 1975 to 1980 on PDP-10s and VAXs. The major step forward came in 1980 when the project began using ZOG to develop an information management system for the aircraft carrier, USS Vinson. It ran on a system of 28 PERQ workstations and supported policy, task management, and maintenance and use of weapons systems. In 1981, the project was reformed into Knowledge Systems, which developed a commercial version of ZOG now known as KMS. KMS now supports a wide range of projects.

LinkWay

A relatively recent IBM product, LinkWay offers the power and convenience of a. hypertext programming environment for very small PCs. Even the IBM PS/25 or earlier PCs, or XTs, can run sizeable applications with color and sound. Simple animations are relatively straightforward and effective. Text buttons and links can easily be installed and edited. Standard navigation aids are available to retrace and link to other files. It is easy to run DOS within the application and so to run programs written in other convenient languages. In order to run on simple PCs with standard memory options, many of the sophisticated tools of the other systems are not available, and the scripting language has fewer than fifty commands. However, it has all the basic essentials: pop up text fields, buttons for scripts and images, animations, and even whole documents. On a powerful computer, multimedia control is efficient and authoritative.
Figure 10.3 A LinkWay Script

Neptune:

Neptune was introduced in 1986 by Tektronix as a generic hypertext system developed in order to support the design of documentation for large-scale software systems, that is, a design-support environment. It enabled writers, designers, implementors, and evaluators to collaborate on the development of a system and its documentation. It can facilitate the collaborative efforts of a team of software engineers.

Neptune is a layered system. The user interface is written in Smalltalk. It is supported by a server, the Hypertext Abstract Machine (HAM), which manages all of the transactions requested through the interface. The HAM facilitates the creation, storage, editing, and accessing of nodes and links, regardless of their content, making Neptune application-independent. The HAM traces user interactions and provides a version history of each node and link. The HAM provides distributed access to the application on a variety of workstations over a network.

Neptune provides several types of browsers. The three primary ones are document, graph, and node. The document browser provides a hierarchical listing of topics. Users select items from the top panes to navigate through the document. The graph browser depicts nodes as labelled boxes and links as arcs. The node browser access individual nodes in the document. Neptune also provides attribute browsers, which accesses sets of nodes based upon their attributes, and version browsers, which search for specific versions of nodes. The destination of a Neptune link is a particular point in the node, rather than the node in general, which permits fine-tuning of links.

Mayer Schwartz, a designer of Neptune, defined Hypertext as follows: A document consists of a set of nodes and directed links between these nodes. Each node can be text, graphics, animations, etc. Hypertext is meant to be viewed and accessed interactively on a computer (i.e. a printout is not hypertext) and it should be possible for multiple people to access the document concurrently. Also he wanted some kind of version control in the system so that it would be possible to update some nodes and not others and having the system keep track of the status of the overall system (including perhaps keeping some of the old versions of the nodes). Version control would be especially important for software engineering use of hypertext as in their Neptune system which among other things is used to provide source code management. It is also used for a network news browser allowing annotations.

Delisle, N.M. & Schwartz, M.D. (1986). Neptune: A hypertext system for CAD applications. In Proceedings of the International Conference on Management of Data (Washington, DC, May 28-30, 1986). New York: ACM, pp 132-143.

Delisle, N.M. & Schwartz, M.D. (1987). Contexts---A partitioning concept for hypertext. ACM Transactions on Office Information Systems, 5(2),

Notecards:

Probably the best of the first generation of hypertext systems is the Notecards system developed at Xerox PARC, largely by Frank Halasz under contract to DoD and the Army. It is a general purpose hypermedia environment for collecting, analyzing, storing and organizing information, constructing arguments and models, and producing reports. It has been used successfully for several large projects, including maintenance training, and it is the foundation for the IDE instructional design environment (Russell, et al., 1988).

NoteCards is written in what was called Interlisp and more recently, Xerox Lisp, although a version under Common Lisp for the MacIntosh is said to be under development. It is a very flexible and powerful system. The user may tailor it by using over 100 Lisp functions specially built for a user interface. These functions largely mimic the underlying lisp functions in the system; but they remove the user from interfering with the underlying architecture. This has some benefits (shielding the user from powerful errors) and many drawbacks (adding a layer of slowness to the system, and reducing its overall flexibility). Probably the drawbacks exceed the benefits. Notecards is a very large system and takes an extraordinary effort to learn to use (particularly if one includes the need to learn Lisp!). It runs on the now defunct Xerox workstation, and Suns.

The basic components of Notecards are notecards, links, browsers, and fileboxes. A notecard is a workspace that emulates a notecard within a resizable and scrollable window. Notecards may contain any text, structured drawing, or bitmapped images. There are various types of predefined notecards which differ in the type of information that they contain. New types of cards may be defined by the user. Links interconnect notecards into networks. Each link can be activated by buttoning on it to connect to a destination card by popping up that window. The nature of the link is specified by a verbal label, and any labels can be defined by the user. Notecard Browsers are the heart of notecards, and all main activities of creating links, cards, and structured hierarchies can be done from the graphic browser. It is a structured hypermap of the network of notecards in the system.
Notecards may also function as a platform for launching any other Lisp-based program. Fileboxes are special cards on which the user may organize the cards in the network by classifying them into different cards. In this way, the user may impose their own structure on the network.

NoteCards has been mainly used for individual work. Although it is essentially based on a graphic browser, it is really a knowledge structuring environment rather than a reading, browsing system unlike many other hypertext systems where the user basically reads existing information. Instead it is an idea structuring system where the user is supposed to generate new cards and link them to an evolving structure. Randy Trigg and Cathy Marshall (1989, in Hypertext '89) discussed their limited experience with using NoteCards for collaborative work. where two users were generating and editing cards in the same document data base. They introduced special history cards which recorded the changes made during a session with the system so that the other user later could see what had been done. They also adopted a convention where each of the two users used a different font when entering text into the cards.

Collaborative work has become an important focus of new functionalities in Notecards, now that Halasz has returned to PARC from MCC to continue this work. Two other kinds of activities considered by Trigg were substantive (those that constitute the work itself) and annotative (about the work, including comments, critiques, and questions). Substantive activities are supported by many systems (even to some degree by a traditional text processor supplemented by printouts or electronic mail). Annotative activities lack support in traditional systems, but more and more systems include some possibility for having annotations kept separate from the text itself (and of course annotations are a basic feature of hypertext systems).

According to Nielsen, one problem with using NoteCards for cooperation is that it requires too early commitments in the form of how to make up cards, which title to use for things. Making changes in existing networks to redefine these early commitments is very time consuming and difficult. However, this is a problem faced by every knowledge structuring environment. Still it should be possible to create a system with very general card types that can be specialized later when the nature of their contents becomes more self- evident.

This problem is intimately connected to all design activities. When highly novel designs are involved, the designer does not have a fully defined structure, framework, or design to begin with. Then the system has to be structured to talk back to the designer slowly; letting the system itself reveal its content to the designer. This is analogous to the artist "finding" the hidden statue in the stone, a frequent comment made by expert sculptors, as they proceed through their artistic act. It is not until they are deeply into the sculpture that the true object reveals itself to them. Of course, it is very important that no radical changes in the stone have been made that now prevent the completion of the work of art. So, in designing a hypertext product, it would be very useful to be able to create general outlines, generally shape the product, without making too specific commitment s early on that get in the way of the eventual design.

The gist of part of this slowly tightening constraint in design is captured in the general notion of "rapid prototyping" environments, which many hypertext systems can rightly claim to be. The rapid prototype is a general structure that can offer valuable insights into the strengths and weaknesses of a design. It may be a minimalist structure (in the sense of the training wheels approach recommended by Jack Carroll of IBM) that is particularly useful for training; or it may be a very cumbersome prototype that needs special handling in order to be made to work. Either way it offers researchers an extraordinary opportunity to carry out usability studies of the human interface, with the potential of saving large sums of money. For instance, a recent GOMS analysis of the effectiveness of a new workstation for telephone operators has saved a local telephone company millions of dollars ( Gray et al., 1990).

Problem Solving Applications

Problem solving applications of hypertext, like NoteCards from Xerox PARC, are multi-user environments that use structured nodes, information fragments and associative links to define problems, processes, or papers. The purpose of the hypertext is to organize the information that is normally unstructured using links that make it more structured. The users of such a system create and modify existing nodes and links to make the information more meaningful. Their personal styles are reflected in the changes and additions that they make (Trigg & Irish, 1987). Other systems, like IBIS and NLS (On-Line System) are problem-resolutions environments that provide multiple users the opportunity to restructure the material or analyze it from different points of view. The important components of problem solving are decomposing knowledge into manageable bites; defining goals; building plans; uncovering errors; describing structures; analyzing functions; building relevant mental models; defining the issues; and summarizing the arguments pro and con each issue. The processing of ideas provided by these systems makes these steps more manageable.

Viewpoints:

Ibis:

IBIS interactions typically start with a question about how something should be done. The hypertext structure constrains the approach to the question through Position, Issue and Argument nodes. New issues that arise are included in Issue nodes. Individuals may add conflicting positions in Position nodes and support those positions by adding Argument nodes. The system provides for a reasoned electronic dialogue.

ToolBook

Nearly two and a half years after the release of HyperCard for the Macintosh, full fledged hypertext and hypermedia graphics became available with a product by Asymetrix Corp. built on top of Windows 3.0, ToolBook. Although it will be compared with HyperCard because of the broad range of graphics and text processing capabilities it has, it is much more of a hypertext system than HyperCard, while at the same time being an excellent graphics and animation construction and development environment. As its name implies, ToolBook uses a "book" metaphor with "pages" as a way of ordering its content. Each page can hold buttons, graphics, and scrolling fields. All of these things are full-fledged objects with system properties and user-definable properties. They can also all contain scripts written in OpenScript, a language very similar to the scripting language in HyperCard and SuperCard. It is so similar, in fact, that a system called ConvertIt! by Heizer Software will turn HyperCard stacks into ToolBook Books that run under Windows 3.0. Windows 3.0 has built into it a facility that runs all ToolBook applications (a runtime version of ToolBook).

Like HyperCard, ToolBook has a sophisticated set of drawing tools, a large set of icons for buttons, and supports bitmaps or draw objects. A built in recorder captures trajectories for moving objects automatically. It can also capture more complicated interactions to create highly effective animations.

Each Book can have variable page sizes. More than one Book can be open at any time, and books can communicate with each other through Dynamic Data Exchange as part of Windows 3.0 . Colors are supported for all objects.

ToolBook explicitly supports a database metaphor. Record fields can be used to organize data like a conventional- flat file database. These records can be sorted using up to 8 key fields. A front end is provided to link seamlessly with dBase III©.

The compatibility with HyperCard and Windows 3.0 offers to make this an extraordinarily productive environment. Building on the large base of existing HyperCard stacks and making them available on the huge base of personal computers capable of running Windows 3.0 promises to make ToolBook an astounding success. As ToolBook advertises itself, it is a construction kit for Windows, that makes it as easy to program as it is to draw pictures and use a mouse.

Chapter 9

Chapter 11