On Generalizing the Concept of Hypertext

Hypertext

On Generalizing the Introduction The core idea of hypertext has been described Concept of Hypertext cieariy and accurateiy:

The concept of hypertext is quite simple: By: Michael P. Bieber Windows on the screen are associated with Computer Science Department objects in a database, and iinks are pro- Boston College vided between these objects, both graphl- caiiy (as iabeiied tokens) and in the Chestnut Hill, Massachusetts database (as pointers) (Conklin. 1987, p. 02167-3808 U.S.A. 17)

Steven 0. Kimbrough (See aiso Nieisen, 1990, and Shneiderman and Decision Sciences Department Kearsiey, 1989, for book-length introductions to The Wharton School hypertext.) University of Pennsylvania Stiii, as is universatiy recognized, there is more Phiiadeiphia, Pennsylvania to the idea of hypertext than iinked information 19104-6366 U.S.A. items that allow a user to explore ideas and pur- sue thoughts in a free and "non-iinear" fashion. After ail, weli-designed standard computer ap- Abstract plication programs, including reporting systems and decision support systems, have long Hypertext has quickly become an established delivered such capability, at ieast to a respectable paradigm in the design of information systems. degree. What hypertext systems add, with their The success of products in the software market, emphasis on the vaiue of iinked information evident benefits as reported by users, and the items, is: (1) easier, richer, more highiy featured flowering of related research activity all attest to iinking of information; and (2) system-level, rather the significance and staying power of hypertext- than application-ievel, support for creating, main- rich information systems. Although standard taining, expioiting, and managing iinked informa- hypertext has a number of unquestioned benefits, tion items (Bieber, 1991). Like database systems, the concept also has a number of well-known pro- report generators, graphics packages, and user blems and limitations. This article reviews the interface management systems, hypertext soft- main problems and limitations of basic (standard) ware can be seen as application-independent, hypertext that constrain the use of hypertext in system-ievei toois for providing usefui features practical applications. Further, this article for specific appiications. presents and discusses our "generalization" of the basic hypertext concept, which we call Our aim is to describe and discuss certain ex- generaiized hypertext. These generalizations en- tensions at the system level to the core ideas of compass, among other things, automatic crea- hypertext, which we call generalized hypertext. tion of hypertext elements. Generalized hypertext We have been motivated to deveiop generaiized promises to be more powerful than standard hypertext concepts as part of a iarger effort, fund- hypertext as well as less expensive to implement ed by the U.S. Coast Guard, to develop decision and maintain. To illustrate these concepts, we support system shelis, i.e., system software for describe the implementation of a decision sup- generating particuiar decision support systems port system currently in use by the U.S. Coast (Bhargava, et ai., 1988; Kimbrough, 1986; Kim- Guard. brough, etal.. 1990a; 1990b; Minch. 1990). Our purpose in this articie is mainiy to describe these Keywords; Hypertext, generalized hypertext, concepts, the reasons for them, and their present hypertext computation, virluai iinklng. impiementation. dynamic iinking, decision support systems, information presentation The paper is organized as foiiows. In the next section, we present briefiy the core concepts and ACM Categories: H.1.0, H.3.4, H.4.2 vocabulary for basic hypertext, as well as certain

MIS Quarterly/March 1992 77 Hypertext

problems and limitations of this hypertext con- represents a particuiar iink in the hyperdocument, cept. These problems and iimitations are wideiy e.g., XX. which links nodes AA and BB. recognized. They are the primary motivation behind our concept of generaiized hypertext, Typicaiiy, a user sees a node dispiayed in a win- which is the main focus of this articie. We then dow, its buttons highiighted in some fashion. The present the essentiai ideas of generaiized user expiores the hyperdocument by, e.g., click- hypertext, foiiowed by a discussion of our im- ing on a particuiar button, thereby causing the plementation of the system. system to find the internal representation of the link named by the button, to then traverse the link, to find the node at the link's endpoint, and to display that node as another text passage. The Basic Hypertext newly displayed node may have buttons as well, which the user may employ in order to continue Our aim in this section is to briefly present and exploring the hyperdocument. Alternatively, the discuss basic hypertext. In the foiiowing section user may at any time decide to return to an eariier we shaii contrast this with the generalized node and explore from there. Users may continue hypertext system that we have conceived, in this way more or less indefiniteiy, thereby ex- developed, and implemented. Certainly, many pioring at wiii the hypertext network. A particuiar existing systems have richer feature sets than we hyperdocument—a coiiection of nodes and iinks shaii describe in connection with basic hypertext, —may be thought of as an application written but our focus in this atlicie is on generaiizations under the hypertext system, it is the system that to the basic hypertext concept. Further, aithough provides the general means for exploring the par- we shaii iimit our discussion to hypertext, most ticular hyperdocument. Thus, a basic hypertext of what we say (when not describing our im- system may be thought of as operating a select- piementation) can be applied as weii to traverse-display loop. The user selects a button, hypermedia.' the system traverses the iink named by the but- The central concept in hypertext is that of iinked ton, and the system dispiays the node at the far coiiections of information. A hypertext document end of the iink. possibiy using information picked may be seen as a graph, with nodes that are coi- up in traversing the iink. iections of information (caiied, e.g., windows (Conkiin, 1987), documents (Brown, 1987; 1989; Typicai, basic operations supported by hypertext Haan, et ai., 1992), cards (Appie Computer, 1989; systems inciude: Halasz, 1988), information items (Bhargava, et al., 1988), chunks (or pieces of text) (Koved, • User-directed navigation (traversai (of iinks) 1988; Trigg, 1983), frames (Akscyn, et al., 1988)). and dispiay (of nodes)) of the hyperdocument. Links specify reiationships between nodes. They • Search and dispiay (for example, the user will may have properties themseives and faii into provide a search string and the system wili types. They are maintained by the system, and search until it finds a node containing that are named or referred to by buttons (aiso caiied string and then wili display the node). link icons (Conklin, 1987) and link markers (iHaiasz and Schwartz 1990)), which normaily are • Map-based navigation (the system dispiays a found in the nodes. To iliustrate, see Figure 1 graph (called a map or network overview) of (based on Conkiin, 1987), where nodes Window the hyperdocument, and the user may direct A and Window B are presented as windows on navigation of the hyperdocument based on the the dispiay. Within the nodes are the buttons x, map, whose buttons, when selected, cause the y, z. What is displayed represents part of the corresponding node in the hyperdocument to underiying hyperdocument (network of hypertext be dispiayed). nodes and links). Window A is a representation of node AA in the hyperdocument, and Window • Creation, modification (e.g., editing the con- B represents BB. Simiiarly, a button, e.g., x. tents of a node), and deietion of nodes and iinks and their attributes. • Display of iink and node attribute information ' The hypermedia concept extends hypertext to types of infor- (e.g., the name of the node at a iink's endpoint, mation items besides text, such as graphics and sound (Haan, et ai., 1991). the type of node or iink).

78 MIS Quarterly/March 1992 Hypertext

Underiying Hyperdocument: Hypertext Database

AA yy

Figure 1. Central Hypertext Concept

• Procedural attachment (link endpoints may be explain and discuss the keyword in question. procedures that are activated by traversal of The hypertext system might infer a link (and their incoming iinks. These procedures typical- thus the existence of an accompanying but- ly affect how certain nodes are displayed (see ton) by being abie to recognize keywords in ar- Apple Computer, 1989; Halasz, 1988; Koved, bitrary nodes and dynamicaiiy creating buttons 1988, and Thompson, 1990). out of them that are iinked to the appropriate keyword nodes. With such a capability, a However interesting this basic hypertext concept builder couid simpiy type text into a node and is, and however usefui various implementations have the system create many of the needed of it have proved to be, a number of probiems buttons and links associated with that node.^ and limitations have been identified with this Clearly, there is considerable potentiai basic concept (Bhargava, et ai., 1988; Conkiin, benefit—especiaiiy in terms of reducing the 1987; Feinerand McKeown, 1991; Halasz, 1988; cost of buiiding a hyperdocument—to having Van Dam, 1988). For this article we are the hypertext system capable of creating but- concerned with the foiiowing widely recognized tons and iinks automaticaiiy. probiems and limitations in basic hypertext (and in many current impiementations of hypertext). Manual node creation (Bhargava, et al., 1988; Halasz, 1988; Jordan, et al., 1989; Parunak, • Manual iinking (Bhargava, et ai., 1988; 1988). This is the node version of the above DeRose, 1989; Feiner and fwIcKeown, 1991; link limitation. Under the basic hypertext con- Haiasz, 1988; Jordan, et ai., 1989; Van Dam, cept, the hyperdocument builder builds nodes 1988). Basic hypertext systems provide editing by using an editor to key in or to paste in in- features for linking existing nodes and for formation. There remains the possibility of the creating and manipulating buttons (iink icons). hypertext system generating nodes (along with These features axe highiy useful to the buiider—or annotator—of a hyperdocument. The basic hypertext concept, however, does ' Although we wili not discuss it further, this feature is supported not encompass inferred or virtual, iinking of in the system we illustrate later. Other researchers have been active in exploring this sort of feature, e.g., in the context of nodes by the system at run time. To illustrate extended electronic mail systems (Ackerman and Malone, the inferred iinking concept (called implicit link- 1986; Harp, 1988: Lai, etai., 1986; Jackson and Yankelovich, ing by DeRose, 1989), consider a system with 1991, Schatz. 1988). Other researchers are working on generatir>g iinks from content analysis on text (Hammwoehner predefined keyword nodes, whose contents and Thiel, 1987; Parunak, 1990).

MIS Quarterly/March 1992 79 Hypertext

embedded buttons) on the basis of user inputs, pertinent information before display (Beeri and in conjunction with existing information in its Kornatzky, 1990;Tompa, 1989), For example, database {Furuta and Stotts, 1990; Schnase displays specialized by type of user (novice, and Leggett, 1989). (See Feiner and experienced, e,g.) might be implemented in McKeown. 1991, for mention of work on this way, generation of graphical objects.) Again, it can be hoped that with such a capability the cost * Cost of building hyperdocuments of developing a hyperdocument might be {Bhargava, et al., 1988; Jordan, et al., 1989; reduced. Finally, we note that automatic crea- Kimbrough, et al., 1990a; 1990b). Basic tion of nodes is quite different from procedural hypertext systems provide substantial support attachment (see above), which has been used for building applications in which the user may to modify—or modify the display of—nodes, interactively explore a large collection of rather than to create them. associated information. Nevertheless, much more might be achieved by embedding • Network disorientation (Conklin, 1987; knowledge into the hypertext system Nielsen, 1990b; Parunak, 1989). This is the (DeYoung, 1989). For example, contextual often-cited "lost in hyperspace" problem. At- information could be used automatically to in- will exploration of a rich hyperdocument can voke filtering routines in support of multiple easily lead to user bewilderment. Basic views of nodes. Also, nodes (and embedded hypertext systems use map-based navigation, buttons) might be generated automatically, at logging of nodes traversed, and search-and- run time, by machine-based inferential pro- display commands as tools for ameliorating cesses. There are many other possibilities as this problem. well, e.g., automated node creation and linking. • Cognitive overhead disorientation: dispiayed information (Conklin, 1987; With the basic hypertext concept and a list of Glushko, 1989). A main virtue of hypertext is some of its pertinent limitations at hand, we shall that it provides system-level support for now discuss our generalization of the concept building software that both presents cognitiveiy and how this generalization addresses the list of tractable amounts of information on the screen limitations. and makes easily accessible arbitrarily large amounts of associated information. In the basic hypertext concept, however, the builder must explicitly design the application's Generalized Hypertext displays. System-level support for tailoring the Our concept of generalized hypertext is basic amount of information displayed and its mode hypertext plus generalizations with regard to of display is functionality beyond that in the nodes, links, and link traversal. These generaliza- basic hypertext concept.^ tions are further extended by system-level support for user and domain contextual • Muitipte views (Halasz, 1988; Koved, 1988; dependencies. The aim of this section is to ar- Perlman, 1989). Basic hypertext systems ticulate our concept of generalized hypertext by typically provide a limited number of ways to presenting and discussing these generalizations. view nodes. For example, many systems ne*' In the following section, we shall illustrate mit buttons to be displayed with or without the generalizations with example's from our highlighting, and some offer both a user's view implementation. and a builder's view for nodes. Other views not envisioned in basic hypertext are possible. As a means of reducing cognitive overhead, Node generalization nodes might be filtered and transformed for In basic hypertext, nodes are largely document or card nodes: collections of text with embedded * it Is not. however, entirely beyond the functionality of some hypertext systems. As noted above, some systems allow pro- buttons and (often) graphics. Further, these cedural attachment for altering node display characteristics. nodes are explicitly represented in the system. "Card-based" hypertext systems (e.g., Akscyn. et al., 1988; We generalize nodes in two principal ways. First, Apple Computer, 1989; Halasz. 1988), restrict the size of nodes in some way in order to limit—in a limited way—the while nodes may be collections of text with amount of information avaiiabie on screen at any time. embedded buttons, under our concept a node

80 MIS Quarterly/March 1992 Hypertext

may be any information item (structured bit a command. In basic hypertext each analysis link stream, e.g., a document, a symbol, a picture, may be thought of as a command to display one and so forth) about which the system may reason. of the two endpoints of a link. This generaliza- Just about any sort of entity may be the endpoint tion allows arbitrary commands for operating of a link (including other links), and all such end- upon a link endpoint and is a richer concept points are considered to be nodes. Abstractly, than that normally encompassed by procedural nodes are objects that may be named (referred attachment. to) in various ways (explicitly or implicitly) and linked to other nodes. Further, information about Our second generalization is that links need not nodes may be declared in the system, and this be explicitly represented in the system. Like information (including contextual information) nodes, they may be inferred at run time from may be used by the system during its link traver- declarations used to build the system, as well as sal operations- Our second generalization is that from other information, such as user inputs, at- nodes need not be explicitly represented in the tached applications, and context. In fact, system. They may be virtual, i.e., inferred (or generalized hypertext buttons will often indicate computed (Halasz, 1988)) at run time from the presence of such virtual links. These links are declarations used to build the system, as well as not generated until the user actually chooses to from other information, such as user inputs and traverse them. attached applications (such as TEFA, see below). Generalizing link traversal For example, in the decision support system sup- In basic hypertext, as noted above, link traver- ported by our generalized hypertext implemen- sal is normally performed through a select- tation, (illustrated later), models are represented traverse-display model: the user selects a button in the attached application, TEFA, and every (e.g., by pointing to it with a mouse and clicking declared model is also a node. Linked virtually on the mouse), the system finds the link named to every model are the results of various opera- by the button, traverses it, and displays the node tions on it, e.g., describing it and evaluating it. found at the link's endpoint. (In the case of pro- These results are themselves nodes, typically cedural attachment, the system may find a pro- document nodes with embedded buttons, and cedure at a link endpoint. If so, the system calls are created in real time during operation of the the procedure, which normally changes the con- system. tent or display of a node.) Link generalization We generalize link traversal as follows. Inference (Indeed, arbitrary processing) may occur both In basic hypertext, each link establishes a rela- before and after traversal of a link. After the user tion between a single source node and a single selects a button, the system may perform a series destination node, called the link endpoint. We of inferences in order to determine what the generalize links in two principal ways. First, links available links are (i.e., the system collects the may fork into multiple links. Thus, in selecting a link ensemble), possibly taking context into ac- button, which names a link, the user may then count. If there are several options available, the be asked to choose among several sub-links. (We user is then prompted to choose a particular sub- call such collections of sub-links link ensembles.) link and (when needed) to supply parameters. For example, later we shall see that the name of (Alternatively, the system may invoke a default.) a mathematical model may be a button In a docu- Inferencing is performed again in order to validate ment. Upon selecting such a button, the link the refined request. Upon successful validation, traversal routine will infer that several analysis the system determines (finds or generates) the options are presently available, e.g., to run the appropriate sub-link and traverses it. Traversal— model, to describe the model, and to suggest a which may itself be a complex inferencing pro- scenario (data set) for running the model (see cess and may use application-level procedures Figure 2). There are also two hypertext documen- —produces a symbol that names a node. Infer- tation options for adding a comment and for in- encing, or processing, is then performed on that itiating a user-declared (i,e., explicit) link. symbol (e.g., for the purpose of formatting and Each of these sub-links, or link forks, is traver- display). Usually, this final inferencing results in sable by the system and may be thought of as display of a new node. Thus, our generalization

MIS Quarterly/March 1992 81 Hypertext

File Edit Information Query Processing MaH Financial describe(&asset) The flSSET Cost flnalyais tlodule calcuiates ship acquisition and I i f e cycle co: rouide data which can be i f competing systems of sh Information fluailable: dei asset is CflHDIOflTE C (1)run isl Guard H.Q The modei ass (2) describe (3) suggest-scenarlo f_c =: c_l_! (4) add comment C_1_S -J C_' (5) start link c_l_p =; c_" c_1_acq -; ' p_l =: C_l_( c_f_s -: c_ Display Select c_f_p =: c_ Option c_f_acq -: [ Cancel ] Number—> p_f =: c_f_i

The modei asset caiis assel_cer to euaiuale c_f_cC; c_f_profit, c_l_cc and c_l_profit.

Figure 2. Inferred Link Ensemble Associated With the "Asset" Button foiiows a select-infer-traverse-infer model. {For important element of our design concept is that more details see Bieber, 1992.) the application should declare—explicitly or implicitly—what is important to it, and the generalized hypertext system should exploit Use of the generalizations these declarations in order to infer links, nodes, Under our concept of generalized hypertext, and views. (This is done, in our system, through nodes are objects (declared or inferred), and links the use of universally quantified generalizations, declare operations that may be applied to objects, which we call bridge laws. The purpose of bridge usually producing a hypertext document upon laws is to map terms in the attached applications completion. These generalizations are the out- {such as TEFA, see below) to expressions come of our intention to construct a hypertext {nodes, links, and so forth) native to the general- system in which the cost of building hyper- ized hypertext system. Detailed discussion of this documents is greatly reduced through automatic technique is beyond the scope of this article. For creation of nodes and links on the basis of further information see Bieber, 1990; 1992; application-dependent declarations. System-level Bieber and Kimbrough, 1990. Further, it is our procedures that implement these generalizations hope that network and cognitive disorientation work on application-specific declarations in order are reduced by inferencing procedures that are to make the necessary inferences for automatic broadly available for reporting on and explaining linking, automatic node creation, and support for various system entities, notably nodes, links, and multiple views of nodes, links, and buttons. An buttons. The essential idea is to employ a stan-

82 MIS Quarterly/March 1992 Hypertext

dard format to declare information about system which are formatted and interpreted in an entities (nodes and links); use generic (applica- elementary message management system (Kim- tion-independent) inferencing procedures to brough and Moore, 1992). In Figure 3, A is t h e generate nodes, links, and alternate views; and user, B is the communications path on which provide system-level explanation features. messages from the message management system flow, and C is the locus of external pro- We Shalt now illustrate these ideas with a discus- cedures (e.g., subroutine libraries and commer- sion of our implementation of them. cial model solvers) and data (e.g., in database management systems).

Maxi is a standalone event-driven generalized Illustration: Max, a DSS Shell hypertext editing and management system. It Max is a generalized hypertext knowledge-based dynamically creates user interface environments DSS shell. It is written in Prolog and is currently based on requests from TEFA, which are tailored being used at the Research and Development using context information about the task and the Center at the Office of Engineering, and user (Halasz, 1988). As seen in Figure 3, Maxi elsewhere, in the U.S. Coast Guard. Max has two has two main components. The user communi- main modules: a user interface subsystem, call- cates directly with the dialog subsystem, which ed Maxi (Max Interface), and a modei and data handles the physical input and output. The (large- management subsystem, called TEFA (The ly) configuration-independent hypertext sub- Eileen Ford Agency, model management being system passes information between TEFA and such a "fashionable" subject). The two sub- the dialog subsystem, performing hypertext systems have no code in common and com- editing and inferencing as necessary. TEFA is a municate via expressions in a formal domain-independent model and data manage- communications language, the expressions of ment system currently supporting models that

KSS Shell

Maxi

Hypertext Subsystem B

Dialog Subsystem

Arbitrary Application

Application Knowledge Base

Figure 3. Max KSS Shell Hlgh-Levet Architecture

MIS Quarterly/March 1992 83 Hypertext

can be expressed as mathematical equations. is not excessive because buttons name—or refer For the appiication at hand, it provides a model- to—links, and these buttons are copied, not the ing language (which DSS builders use to record links.) Executives, on the other hand, generally the domain models and data) and information do not build reports. Instead, they typically read about the models and data (Bhargava, et al., reports produced on the system by analysts. 1988; Bhargava and Kimbrough, 1990; 1992). Because analysts can easily include generalized hypertext buttons in their reports, executive Maxi currently runs only on a Macintosh com- browsers have access to the same standard puter. TEFA is written in generic Prolog and is reports and other generalized hypertext informa- therefore substantially configuration-indepen- tion as their analysts. This allows executives to dent. When not combined with Maxi it has its own explore the information supporting the analyst's generic Prolog command language component recommendations and findings without placing and is currently functioning in this way in the undue burden on the analysts. VAXA/MS environment. For TEFA to function in an event-driven windowing environment, these Imagine that an executive needs to make a deci- commands are translated by the message sion based on the costs of two different fleets, management system into the communications one consisting of hydrofoils and the other of language. SWATH (Small Waterpiane Area Twin Hull) vessels. The analyst's task, then, is to perform an analysis exercising the Asset life cycle cost Example: Working with a cost model model to create a report. The steps taken are In order to give a sense of how Max works, we outlined in Figure 4. shall discuss some of the features a user would Steps 1 and 2: Analyst's Point of View. After employ in a Max appiication—called Max starting the Max session, the analyst asks for a Financial—to work with a particular model. We full description of the Asset model. To do this he shall use as our example a model called Asset, or she selects the describe command/query from which is used by the Navy and the Coast Guard a menu in Max's menu bar and the Asset model to estimate ship acquisition and life cycle costs. as the subject of the command. The system pro- Asset was originally implemented in Fortran. We duces a standard report mode! description reimplemented it in the model representation (displayed in an interactive document), shown in language of TEFA. The various reports and Figure 5. Buttons are highlighted in boldface, in- features we shall illustrate are produced inferen- dicating that further information is available about tiallyat run time by Max, i.e., by our generalized the objects they represent. hypertext system. They are automatically avaiiabie for any model declared in TEFA. (It has Steps 1 and 2: System's Point of View. Dur- been our experience that this strategy significant- ing Max's initialization, the Max Financial applica- ly hastens the building of a particular DSS (Kim- tion (under TEFA) passed a list of command brough, et ai., 1990a; 1990b.) options in the communications language to Maxi, the shell interface subsystem, which installed Max was designed to support two types of users; them in the menu bar under the heading Max analysts and executive browsers (or other Financial (see Figure 5). When the analyst chose readers of prepared reports). Each typically ap- one of these items, he or she initiated the follow- proaches the system with a different purpose. ing dialog with the Max Financiai application. Analysts execute models under various data scenarios. Information is returned in standard reports that are dynamically created by the • Dialog Subsystem system. The analysts can then copy and paste — Intercepts user input. from these standard reports to create their own — Passes the hypertext subsystem a message ad hoc finai reports. Again, it is important to note relaying that the user selected the describe that Max dynamically generates standard reports menu item and entered the text string and automatically embeds buttons that name "asset." generaiized hypertext links. Copying and pasting • Hypertext Subsystem preserves these links in both the original and — Receives the describe menu item and duplicate copies. (The computational cost of this associated text string.

84 MIS Quarterly/March 1992 Hypertext

Step 7 request Executive decision start make (main task) information Max decision

i repod report I requested received

Step 11 Step 3 Step 4 Steps

start execute Asset execute Asset Analyst Max modei using modei using (main task) hydrofoii(i) swath(i) data data scenario scenario

Step 2 Step 5 Steps Additional hypertext- learn about expiore explore style Asset model execution ad hoc exploration results report

Figure 4. An Anaiysis Task Supported by Max

— Determines that this is a generalized — TEFA generates a composite report con- hypertext link traversal request. taining this information (which Maxi will — Infers that processing must be performed perceive as the destination node), formats by TEFA to determine the destination node. it in the formal communications language, — Formulates a link traversal request to TEFA and passes it to the hypertext subsystem. (which TEFA will perceive as a command request) in the formal communications Hypertext Subsystem language. — Receives the link's destination node from TEFA. TEFA — Processes the node's contents into a for- — Receives the describe command request mat that the dialog subsystem can use. This with input text string "asset." involves tagging buttons with an internal ID — Infers that the text string "asset" represents and formulating display information (e.g., a Max Financial model. the buttons' base display text, and whether — Infers the generic describe report model for each is textual, numeric, monetary). a (financial) model. — Passes the destination node's contents to — Executes the generic report model for the the diaglog subsystem. asset financial model. This involves inferring the financial model's description, source in- Dialog Subsystem formation, equations, and any related sub- — Receives an ordered set of text and buttons models. The knowledge base is used to from the hypertext subsystem. derive these elements, many of which — Processes the data to create an interactive themselves are entities containing subcom- document. The button information compiled ponents. by the hypertext subsystem is used to

MIS Quarterly/March 1992 85 Hypertext

File Edit Information Query Processing MBK Financial IDi descrlbe(O'o$$et) The RSSET Cost flnalysis fiodule calculates ship acquisition and life cycle costs. The intent of the nodule is to provide data uhlch con be used to eualuate the relatlue costs of coApetirva systeas of ships. The source / reference for the model asseU—? IsCRNDIDRTE CRRFT STUDV (second analysis), U.S. Coast Guard H.Q The Diode t asset has the following equations:

f_c -: c_l_s * n_f * c_f_s c_l_s =: c__I_acq + c_1_p c_l_p =: c_l_mp * w_mp + cph • n_h c_l_acq =: 1.335000 • p_l p_l »: c_I_cc • c_l_profU c_f_s =: c_f_acq + c_f_p c_f_p -: c_f_mp * w_mp + cph * n_h c_f_acq =: 1.295000 * p_f p_.f -: c_f_cc + c_f_profit

The Kodel asset colts asset_cer to eualuate c_f_cc, c_f_profit, c_l_cc and c_I_profit.

Figure 5. Standard Report Describing the Asset Model

determine the actual text representation of links), which is generated inferentially. Thus, we each button on the screen. say that a button names a link ensemble, or bun- — Displays the interactive document shown In dle of links, rather than a single link as in basic Figure 5 on the screen. hypertext. The highlighted buttons in an interactive docu- Step 3a: System's Point of View. What hap- ment denote links, real or virtual. Although they pened internally is thai the system interface indicate a relation to information in the knowledge determined that the user clicked on a set of base, they (usually) are not explicitly linked to known entities: the asset button, the report node, anything. As we shall see, only when they are and the interface window itself. By default the queried directly wiii a link be determined and system chose to take the most specific entity (i.e., traversed. the button) and translated its internal ID to its Step 3a: Analyst's Point of View. Next, sup- TEFA identifier in Max's generic "What can I do pose the analyst wants to execute the Asset with this?" query. To the options (sub-links) model under two scenarios. The analyst presses returned by the application (TEFA), Meixi's the (Macintosh) option key, and the "show me hypertext subsystem added the hypertext all available options" cursor appears as shown documentation options for commenting and user- in Figure 5 (near the upper right-hand corner). declared linking. The analyst then clicks the mouse on one of the "asset" buttons. Figure 2 shows the list of Steps 3b to 5: Analyst s Potnt of View. Fram available options (i.e., generalized hypertext this (filtered) list of options the analyst executes

86 MIS Quarterly/March 1992 Hypertext

the Asset model twice, once witrt the scenario node comprising the major resulting vaiues was (data set) "hydrofoil(I)" and once with "swath(l)." generated as the link destination (i.e., the node The analyst believes the variable "f_c" stands was created) and passed to the interface for for the total fleet costs, but just to be sure, clicks display. on it to ask for a short description. The general- Steps 6 to 6. Figure 7 shows the finai ad hoc ized hypertext reports generated are shown in report that the analyst has constructed for the ex- Figure 6. These standard reports are quite ecutive browser. Note that the analyst has had sparse, but they could be made more explicit for, to do no explicit linking. Instead, the automatic say, a novice anaiyst. Alternatively, if only the iinks were carried over through the buttons total fleet cost were needed, a report with only (boldface text in the figures) via copy and paste this value could have been returned. operations and editing of the final report. Steps 3b to 5: System's Point of View, in order Aithough the final report is quite short, an ex- to execute the Asset model for the user, the ecutive or browser can query any button for fur- system traversed a virtual "execution" link (as ther detail (Bieber. 1992). in fact, a large amount opposed to the other options of traversing a of information is available in this fashion. For ex- "describe" link or a "suggest scenario" link, etc.) ample, in Figure 7 the executive has queried the from a report button for a model node. As a result value representing the SWATH fleet cost. The of following the execution link, the model was ex- system recognized that this button represents the ecuted, and, as it happens, a standard report result of a model execution and determines that

File Edit Infonnation Query Processing Maw Financial describe((}'Qsset) The flSSET Cost Rnalysia tiodule calculates ship acquisition and fioduie is to prouide data runC&asset.&hydrofoiKD) 1 runt&asset.C'sujathd)) r_c = 3 . 1 6 5 7 0 Ie8 c_l_s = 3.448127e7 f_c = 2.1 10006e8 c_f_s = 2.820888e7 c_l_s = 22894a4e7 C_l_p = 9325000 c_f_s=: l.881057e7 c_f_p = 8150000 c_l_p = 9325000 c_I_acq = 2-515627e7 C_f_p = 8150000 c_f_acq = 2.005888e7 c_l_acq = 1.356984e7 c_f_acq = 1.066057e7

ID! uihat i The variable f_c stands for total fleet cost.

c_f_cc, c_f_profil, c_l_cc and c_l_profil.

Figure 6. System Generated Reports From Executing the Asset Model and Describing the f _ c Variabie

MIS Quarterly/March 1992 87 Hypertext

File Edit Information Query Processing MaH Financial

Final Report Ue used the a33et nodel to calculate the life cycle costs for the 3vath ( 1 ) and h y d r o f o i l ( 1 ) fleet scenarios. The total fleet costs under each scenario Is:

saath ( 1 ) 2.110005e8($) hydrcj 2.110005e8

Ue therefor Information Huailable: onf iguratIon. (1) explain (2) add comment (3) add user-link max

a* «r DW BM

m 1)1^ ou BM [ Dispiay J Select . Option Cancel Number ~>

Figure 7. Anaiyst s Finai Report and Link Ensembie for SWATH Fieet Cost an explanation can be generated dynamically. the cost and effort of creating and using hypertext This explanation appears in Figure 8, complete systems. By providing efficient and standard with automatic links from the embedded buttons techniques for incorporating necessary and to provide further information for the executive. recognized features, our generalization of the concept of hypertext provides a robust basis for Max supports many other features (e.g., explicit knowledge-based hypermedia systems. creation of nodes, links, and buttons; user- induced, machine-interpretable comments on Our experience with the Max system has models and data) and contains several substan- demonstrated that generalized hypertext con- tial mathematical models, but discussion of these cepts are both computationally feasible and lies beyond our current purpose, which is to pre- useful for builders, as well as users, of hypertext sent and discuss generalized hypertbxi and the systems. By way of summary, we shall comment essentials of our implementation of it. briefly on the relation of generalized hypertext to the problems and limitations of basic hypertext, presented earlier.

Discussion and Conclusion • Manuai iink creation, manuai node creation. Hypertext is recognized as a method for reduc- Under our concept of generalized hypertext, ing the human operating cost and cognitive both links and nodes may be either explicit (as overhead of using information systems. in basic hypertext) or virtual (created during Generalized hypertext is a method for reducing run time by t h e system, based on inference

88 MIS Quarterly/March 1992 Hypertext

File Edit Information Query Processing MaK Financiai IDI = Finai Report IHI U e used the a s s e t model to calculate the life cycle coats for O the svath ( I ) and hydrofoil ( 1 ) fleet scenarios, The totai fleet costs under each scenario Is;

2.110005e8($) hydrofo i i 3.165701e8($)

Ue therefore recommend the 3vath ( I ) fleet configuration. eual(O'f_c,O'asset,&$ujath(l)) 2.11 0005e8 is the result of evaluoting f_c under scenario smath ( 1 ) . The variable f_c is: Total fleet cost It is computed using the model asset as follows: f_c =: c_i_s + n._f * c_f_3 Here Is the data used:

c_l_s = 2 . 2 8 9 1 B 3 e 7 n_f = 1 0 c_f_3 = 1 . 8 8 l 0 5 7 o 7

.-M...-.-l^.:..:a.v-.ia.^.:.Bv.-..a..-..B Figure 8. System Generated Report Expiaining the SWATH Fleet Cost Number in the Anaiyst's Finai Report

from general declarations). We have demon- so. in the case of DSS and model manage- strated this concept with an impiementation of ment, it is fairly clear what sorts of things are a DSS shell and model management system, important and hence should be used for called Max, which is currently in use by the automatic link and node creation. The exten- iJ.S. Coast Guard. Applications of Max beyond sibility of the generalized hypertext idea to DSS have been developed to the prototype other application domains depends upon stage {e.g., for project management and for ex- whether it is possible to state a general, broad ecutive information systems) but are not yet theory (set of declarations) regarding what is deployed. The generalized hypertext system important in that domain. Without such is indeed quite general and application- declarations (bridge laws or something like independent. Automated link and node crea- them), it would of course be impossible for tion can be thought of as being based on a automatic node and link creation to be declared theory of what is important to the ap- practicable. plication. In the Max Financial system (the DSS application described above), models are Network disorientation. We do not claim to important, data are important, and things that have a major advance on this problem. We can be done with them (e.g., describe, explain, have, however, learned something that sug- run, suggest a scenario) are important, and the gests some progress in this area. Our system system contains internal declarations that say is, as we have seen, oriented toward helping

MIS Quarterly/March 1992 89 Hypertext

an analyst construct an interactive document • Cost of building hyperdocuments. It is evi- with generalized hypertext functionality. The dent that by relying on automatic generation analyst or document buiider can create one or of nodes and links through runtime inferenc- more documents that are organized as the ing on general declarations, generalized analyst sees fit. Text and buttons can be hypertext can greatly reduce the cost of copied from other documents, normally gen- creating specific hyperdocuments. This is par- erated by the system, into a document of the ticularly clear for the application we have analyst's choice. (Again, this was iliustrated chosen to illustrate here. In Max Financial the above.) Working with the system in this way. number of virtual nodes is essentially infinite. the hypertext network tends to take on a nice There is a generalized hypertext node cor- structure. Instead of being an essentially ar- responding to every possible parameter set- bitrary network of nodes (documents) and ting for every model in the system, but only a links, the hyperdocument begins to have the few nodes are ever actualized in any given ses- structure of a collection of trees with a com- sion. Also, it should be emphasized that from mon root, where that root is the document the the DSS builder's point of view the general- analyst is using the system to create. One ized hypertext features "come for free." begins at the document, forays out for infor- Specifically, models, data, and information mation, copies the information (including the about them are declared in a simpie. buttons), returns to the document (with a click straightforward language. (The same tech- on its window), pastes in the retrieved infor- nique is used in other application areas as weii. mation, makes any needed editing changes, e.g.. project management.) Once declared, and repeats the basic cycle until done. Similar- this information is fully available to the ly, browsers may use a single document or set generalized hypertext system. The builder in- of documents as a home base for exploration. puts (explicit) information about models and We believe this structure for hypertext ses- data, not about windows, buttons, and links. sions reduces the problem of network disori- It is this latter information that the system pro- entation. but proving it is another matter and vides and manages. will be the subject of future research efforts. Finally, it might be asked. "What does general- Cognitive overhead disorientation, muitipte ized hypertext do for the user?" In one sense it views. Because links and nodes may be does nothing, nor should it. Debuggers and created automatically based on declarations compilers do not deliver new functionality for end from the application, it is possible to set up the users. Instead, they make it easier and cheaper declarations in a way that results in salient to produce application software. Similarly, chunking of the information. What counts as generalized hypertext—based on our experience salient chunking, of course, is difficult to deter- —makes it easier and cheaper to produce hyper- mine and will likely be application-dependent. documents for those who can use them in their We have illustrated above the outcome of our jobs. In Max. for example, a few pages of declara- choices in the context of DSS and model tions describing a mathematical model (such as management. How, in general, information the Asset model) can result in thousands of (vir- should be organized for presentation under tual) hypertext links that can be generated hypertext is a proper subject for an extended dynamically by the system. Most of these links research program. Generalized hypertext, as get used. Without automatic generation, we have presented it, does not solve this prob- however, it simply would not be cost effective to lem or complete the research. Instead, it set up the links manually, i.e.. with a standard facilitates implementation once a solution—a hypertext editor. salient chunking—is chosen. By making the In sum, while we have installed a functioning application-specific declarations (including generalized hypertext DSS. there is still very contextual information) in the right way, the much room for further work. We view our current generalized hypertext system can be made to system as a platform for investigating orientation, present information in cognitiveiy useful scaling, networking, and knowledge-base chunks, and this can be done in a context- maintenance issues, and particularly for further sensitive fashion {Bieber, 1991b). Much re- exploiting contextual clues. We are improving our mains to be learned on this subject. specifications of contexts and task environments

90 MIS Quarterly/March 1992 Hypertext

and are working on incorporating a hypermedia Generalized Hypertext and Model Manage- model input and modification subsystem, as well ment in a Symbolic Programming Environ- as a hypermedia project management system, ment," Proceedings of the Ninth International as standard features of the DSS. We are also Conference on Information Systems, Min- modeling a "hypertext engine" to make neapolis, MN, November 30-December 3, generalized hypertext available to information 1988, pp. 179-191. systems other than DDS (Bieber, 1991). These Bieber, M.P. Generalized Hypertext in a are topics for forthcoming systems and future Knowledge-Based DSS Shell Environment, papers, both of our own and, we hope, of others. doctoral dissertation. University of Penn- sylvania, Philadelphia, PA, 1990. Bieber. M.P. "Issues in Modeling a 'Dynamic' Acknowledgements Hypertext interface," Proceedings of Special thanks to Hemant K. Bhargava and Hypertext '91, San Antonio, TX, December Christopher V. Jones for stimulating discussions, 1991a, pp. 203-218. ideas, and comments on an earlier draft. Dr. Bieber, M.P. "Template-Drive Hypertext: A Bhargava is largely responsible for the TEFA sub- Methdology for Integrating a Hypertext Inter- system mentioned in the body of the article. This face into Information Systems," working work was funded in pan by the U.S. Coast Guard paper, BCCS-91-4 Computer Science Depart- under contract DTCG39-86-C-E92204 (formerly ment, Boston College, Boston, MA, 1991b. DTCG39-86-C-80348), Steven O. Kimbrough Bieber, M.P. "Automating Hypermedia for Deci- principal investigator. sion Support," Hypermedia, forthcoming, 1992. Bieber, M.P. and Kimbrough, S.O.. Towards a References Logic Model of Generalized Hypertext," Pro- Ackerman, M.S. and Malone, T.W. "Intelligent ceedings of the Twenty-Third Hawaii Interna- Agents, Object-Oriented Databases, and tional Conference on System Sciences, 1990, Hypertext," in AAAI-88 Workshop. Al and pp. 606-515. Hypertext: Issues and Directions, St. Paul, Brown, P.J. "Turning Ideas into Projects: The MN, August 23, 1988, pp. 1-3. Guide System," Hypertext '87 Proceedings, Akscyn, R.M., McCracken, D.L., and Yoder, E.A. Chapel Hill. NC, November 1987, pp. 33-39. "KMS: A Distributed Hypermedia System for Brown, P.J. "A Hypertext System for UNIX," Managing Knowledge in Organizations," Computing Systems (2:1), 1989, pp. 37.53. Communications of the ACM (31:7). July 1988. Conklin, J. "Hypertext: An Introduction and pp. 820-835. Survey," Computer (20:9), September 1987, Apple Computer, Inc. HyperCard User's Guide, pp. 17-41. Cupertino, CA, 1989. DeRose, J. "Expanding the Notion of Links," Beeri, C. and Kornatzky, Y. "A Logical Query Hypertext '89 Proceddings, Pittsburgh, PA, Language for Hypertext Systems," Hypertext: 1989, pp. 249-258. Concepts, Systems, and Applications. Pro- DeYoung, L. "Hypertext Challenges in the ceedings of the European Conference on Auditing Domain," Hypertext '89 Pro- Hypertext '90, Cambridge University Press, ceedings, Pittsburgh, PA, 1989, pp. 169-180. Cambridge, England, 1990, pp, 67-80. Feiner, S.K. and McKeown, K.R. "Automating the Bhargava, H.K. and Kimbrough, S.O. "On Generation of Coordinated Multimedia Ex- Embedded Languages for Model Manage- planation," IEEE Computer (24:10), Ocober ment," Proceedings of the Twenty-Third 1991, pp. 33-41. Hawaii International Conference on System Furuta, R. and Stotts, P.D. "The Trellis Hypertext Sciences, 1990, pp. 443-452. Reference Model," Proceedings of the Bhargava, H.K. and Kimbrough, S.O. "Model Hypertext Standardization Workshop, NIST Management: An Embedded Languages Ap- Special Publication SP500-178, Gaithersburg, proach," Decision Support Systems, forth- MD, January 1990, pp. 83-94. coming, 1992. Gloor, P.A. "CYBERMAP: Yet Another Way of Bhargava, H., Bieber, M., and Kimbrough, S.O. Navigating in Hyperspace," Hypertext '91 "Oona, Max, and the WYWWYWI Principle: Proceedings. San Antonio. TX, December

MIS Quarterly/March 1992 91 Hypertext

1991, pp. 107-121. Project." Interfaces (20:6). November- Glushko, R. "Design Issues for Multi-Document December 1990b. pp. 5-16. Hypertexts," Hypertext '89 Proceedings, Pitts- Koved, L. "Imposing Usability and User Perform- burgh, PA, November 1989, pp. 57-60. ance with Hypertext Documents," AAAI-88 Haan, B.J., Kahn, P.. Riley. V., Coombs, J.H., Workshop, Al and Hypertext: Issues and and Meyrowitz, N.K. "IRIS Hypermedia Ser- Directions, St. Paul, MN. August 23. 1988, pp. vices," Communications of the ACM (35:1), 121-122. January 1992, pp. 36-51. Lai, K., Malone, T.W., and Yu, K. "Object Lens: Halasz, F.G. "Reflections on Noteoards: Seven A 'Spreadsheet' for Cooperative Work," ACM Issues for the Next Generation of Hypermedia Transactions on Office Information Systems Systems," Communications of the ACM (6), 1988, pp. 332-353. (31:7). July 1988, pp. 836-855. Minch, R.P. "Appiication and Research Areas for Halasz. F.G. and Schwartz, M. "The Dexter Hypertext in Decision Support Systems." Hypertext Reference Model," Proceedings of Journal of Management Information Systems the Hypertext Standardization Workshop, (6:3). Winter 1989/90, pp. 119-138. NIST Special Publication SP500-178, Nielsen, J. Hypertext and Hypermedia, Academic Gaithersburg, MD. January 1990. pp. 95-134. Press, New York. NY, 1990a. Hammwoehner, R. and Thiel, U. "Content Nielsen. J. "The Art of Navigating Through Oriented Relations between Text Units—A Hypertext," Communications of the ACM Structural Model for Hypertexts." Hypertext (33:3). March 1990b, pp. 296-310. '87Proceedings, Chapel Hill, NC. November Parunak. H.V. "AAAI Hypertext Position Paper." 1987, pp. 155-174. AAAI-88 Workshop, Al and Hypertext: Issues Harp, B. "Facilitating Intelligent Handling by Im- and Directions, St. Paul. MN, August 23,1988, posing Some Structure on Notes," AAAI-88 pp. 140-142. Workshop, Al and Hypterext: Issues and Parunak, H.V. "Hypermedia Topologies and Directions, St. Paul. MN. August 23, 1988. pp. User Navigation." Hypertext '89 Proceedings, 79-83. Pittsburgh, PA. November 1989, pp. 43-50. Jackson, S. and Yankelovich, N. "Intermail: A Parunak, H.V. "Toward a Reference Model for Prototype Hypermedia Mail System," Hypermedia." Proceedings of the Hypertext Hypertext '91 Proceedings, San Antonio, TX, Standardization Workshop, NIST Special December 1991, pp. 405-409. Publication SP500-178. Gaithersburg. MD, Jordan, D.S., Russell, DM., Jensen, A.S.. and January 1990. pp. 197-209. Rogers. R.A. "Facilitating the Development of Perlman. G. "Asyncronous Design/Evaluation Representations in Hypertext with IDE," Methods for Hypertext Technology Develop- Hypertext '89 Proceedings. Pittsburgh, PA, ment." in Hypertext '89 Proceedings, Pitts- November 1989. pp. 93-104. burgh. PA, 1989, pp. 61-81. Kimbrough, S.O. "On Shells for Decision Sup- Schatz, B.R. "Proposal to Attend Workshop on port Systems." working paper. Decision 'Al and Hypertext'," AAAI-88 Workshop, Al Sciences Department, University of Penn- and Hypertext: Issues and Directions, St. sylvania, Philadelphia, PA, 1986. Paul, MN, August 23, 1988, pp. 147-149. Kimbrough, S.O. and Moore, S.A. "Message Schnase, J.L. and Leggett. J.J. "Computational Management Systems: Concepts and Pro- Hypertext in Biological Modelling," Hypertext spects." Proceedings cf the Twenty-Fifth An- '89 Proceedings, Pittsburgh, PA, November nual Hawaii International Conference on 1989, pp. 181-198. System Sciences, January 1992. Schneiderman, B. and Kearsiey. G. Hypertext Kimbrough. S.O.. Pritchett. C.W., Bieber, M.P., Hands-On! An Introduction to a New Way of and Bhargava. H.K. "An Overview of the Organizing and Accessing Information, Coast Guard's KSS Project: DSS Concepts Addison-Wesley Publishing Company. and Technology." Transactions of DDS-90, Reading, MA. 1989. Tenth International Conference on Decision Thompson. C. "Strawman Reference Model for Support Systems, Boston. MA, May 21-23, Hypermedia Systems," Proceedings of the 1990a, pp. 63-77. Hypertext Standardization Workshop, NIST Kimbrough. S.O.. Pritchett, C.W., Bieber, M.P., Special Publication SP500-178, Gaithersburg, and Bhargava. H.K. "The Coast Guard's KSS MD, January 1990, pp. 197-209.

92 MIS Quarterly/March 1992 Hypertext

Tompa, F. "A Data Model for Flexible Hypertext Pennsylvania. His research interests include Database Systems," ACM Transactions on In- hypertext, information presentation, and formation Systems (7:1), January 1989, pp. knowledge-based decision support. 85-100. Trigg, R.H. A Network-Based Approach to Text Steven O. Kimbrough is associate professor in Handling for the Online Scientific Communi- the Decision Sciences Department, the Wharton ty, doctoral dissertation. University of School. University of Pennsylvania, and is cur- Maryland, College Park, MD, 1983. rently the William Davidson Visiting Professor of Van Dam. A. "Hypertext '87: Keynote Address," Computer and Information Systems at the School Communications of the ACM {Z^•.7).M'/^98B, of Business Administration, University of pp. 887-95. Michigan. He received his M.S. (industrial engineering) and Ph.D. (philosophy) degrees About the Authors from the University of Wisconsin. His research interests include hypertext, decision support Michael P. Bieber is assistant professor of in- systems, electronic commerce, and logic model- formation systems at Boston College. Carroll ing. Since 1986, he has been principal in- School of Management. He received his B.S.E. vestigator for the U.S. Coast Guard's KSS in computer science and Ph.D. in decision (knowledge-based decision support systems) sciences at the Wharton School, University of project.

MIS Quarterly/March 1992 93