HYPERCARD version 1.0 came out five years ago--an amazing thought. Even version 2.0--long awaited, much delayed--is more than a year old. But while Apple has bundled HYPERCARD with every new Macintosh for years, many people have never used or even installed it. Some have told me that they can't imagine a use for it; others feel inadequate because they lack the programming skills they are sure HYPERCARD requires. Still others say they just aren't sure what HYPERCARD is. These are all legitimate concerns. What is HYPERCARD and why should a teacher and scholar of writing take it out of the box?

To begin with, HYPERCARD is a computer program that permits individual users to create systems relating different kinds of material, including text, graphics, video, and sound. It combines a partial implementation of hypertext with a powerful set of design tools. Hypertext involves creating electronic links among blocks of different material and allowing readers to follow various pathways through the linked material. I'll discuss hypertext in more detail later in this review. If the review itself were in hypertextual form, you could point to the word hypertext above, click the mouse button, and "travel" immediately to the discussion of hypertext.

The combination of hypertext and design tools gives HYPERCARD great potential for writing instruction. First, you can use it to enhance learning by intensifying your students' involvement with course materials; second, HYPERCARD itself indicates some of the ways in which the computer extends the definition of writing. It is also much easier to learn and use than you might think.

Like one of its ancestors, a program called NOTECARDS developed at Xerox's Palo Alto Research Center, HYPERCARD is organized around the familiar 3-inch by 5-inch index card, highly metaphorized and considerably souped up. The individual "card" is equivalent to a screenful of material; a "stack" consists of one or more cards, and a complete HYPERCARD application consists of one or more stacks. There is usually a "home" card or stack such as the one you see when you start HYPERCARD itself. As the name implies, the home card serves as a kind of home base or reference point, a place to start from and to come back to from time to time. In courseware, the home stack might present an overview of the material, with the actual home card providing a menu and navigational aid from which the student can move to different topics.

Each card or screen contains some or all of the following elements in combinations determined by the stack designer: fields, which contain text or numerical information; images, which may be drawn with HYPERCARD's built-in graphics tools, imported from another program, or scanned from a print source; and buttons, which govern movement among cards and stacks, or cause some other action to occur. These actions might involve playing or recording a brief audio sequence using HYPERCARD's built-in sound digitizing facilities, or running a video sequence using Apple's recently released video compression utility, QUICKTIME. (QUICKTIME is not part of HYPERCARD, but it is a significant extension of HYPERCARD's capabilities.)

Each card in a HYPERCARD stack has two basic layers, background and card, each of which may contain its own graphics, fields, and buttons. [1] (A stack may include several different backgrounds.) On the background layer are elements that will be common to a number of cards. In a stack to help students coordinate library research activities, for example, there might be a "Bibliography" background containing fields for author(s), title, date, publisher, edition, and so forth. There would also be buttons for moving forward and backward through the cards, returning to the home card, moving to linked activities, sorting the bibliography, and so forth. Another button might connect the student to tutorials on bibliographic procedures or research methods, a map of the library, or even an on-line encyclopedia or database. To create a new entry, the student need only choose "New Card" from the menu to create a card containing all these buttons and fields, with the fields blank and ready to receive new information. (If you prefer not to display the menu bar, you can create a button that has the same effect.)

Whereas the background layer contains features common to all cards belonging to the same background, the card layer contains elements unique to individual cards. For example, there might be a button that causes a scanned image to appear on the screen, or a button that links a particular bibliographic card to a different set of cards containing reading notes, or material on a related subject. All these objects--fields, buttons, cards, even backgrounds and stacks--may have scripts, small programs that generate particular events in response to action (or inaction) on the user's part.

Such an application sounds--and can easily become--quite complex. With HYPERCARD, however, creating a stack like the one I've outlined above is relatively easy. There are two reasons for this. First, you create new objects--buttons, for example--by simply selecting "New Button" from the "Objects" menu (the procedure is the same for new fields and backgrounds). Second, it is easy to build on previous work, whether your own or someone else's. One might begin work on the bibliographic materials outlined above, for instance, by making a copy of the Addresses stack included with each copy of HYPERCARD, deleting unnecessary buttons or fields, changing the size of the remaining ones, and creating new elements as necessary.

Creating links is as easy as creating a new button, and requires no more scripting--which is to say that it requires none at all. A few simple mouse clicks and HYPERCARD automatically writes a button script defining a link between the current card and another one, even if the destination card is in another stack. You can also choose a button icon (e.g., an arrow pointing forward) from HYPERCARD's extensive library.

But all is not sweetness and light. There are areas where HYPERCARD seems to me surprisingly deficient. It is both inconvenient and annoying that HYPERCARD 2.0 doesn't display color automatically but must be tweaked into doing so; there seems to me no reason why Apple and Claris couldn't have found a simpler, more elegant solution.

I am more concerned, however, with the places where the notecard metaphor, in many respects surprisingly flexible and powerful, reveals its limitations. As these are limitations specifically having to do with HYPERCARD's implementation of hypertext, a few definitions are in order before I go any further.

A hypertext program is software that encodes in the form of an executable program a conception of reading and writing as interactive processes involving the creation and pursuit of connections. A hyperdocument (often called a hypertext as well) is a system of electronically linked nodes; these may contain graphic or video images and sound as well as text; in theory, the units of text may range in size from a single character to the equivalent of a printed volume. Unlike the elements in a printed text, the nodes in a hyperdocument may belong to many different sequences, as defined by different sets or webs of links (a hypertext element becomes a node by virtue of its being linked to one or more other elements). Thus, the hypertext or hyperdocument constitutes a set of possible documents; particular documents become temporarily actual as readers decide which links to follow. Every hypertext program, every implementation of the concept, must encode certain decisions about its basic elements: that is, about how to define nodes and links. HYPERCARD, true to its organizing metaphor, defines the node as a card; my concern here is with the problems that stem from that equation.

I come now to the way HYPERCARD handles hypertextual links within scrolling text fields. In the context of HYPERCARD, the scrolling text field is by definition a workaround, a way to overcome the limitations that arise from equating the card with a single screen full of material; the whole point of the scrolling field is that it contains more text than it can display at one time. There's nothing wrong with that, but there were two problems with the way the original version of HYPERCARD implemented scrolling fields. The first was that a given field could accommodate only one text style (e.g., boldface, italics, small caps, etc.) at a time. The second problem became evident when users tried to place buttons on top of words or phrases in scrolling fields: the text would scroll, but the button stayed put. Thus, there was no longer a meaningful relationship between the button and the text that appeared on the screen--and no way for the reader to know that the button had become irrelevant.

These two problems have nothing to do with each other, technically speaking--or rather they didn't. But the programmers working on HYPERCARD 2.0 tried to kill both birds with the same stone. First they devised a way to allow scrolling fields to handle multiple text styles, just as word-processing programs do. Then they used the same tactic to solve the problem of how to make the text in scrolling fields linkable. That is, they defined a new text style called Group. In this way, one can select a block of text (of any size) and define it as a Group, in exactly the same way one would have italicized it. The result is that when a reader later clicks on any point within the grouped text, it will have the effect of selecting the whole group. One can then write a script that responds to that selection as if the user had clicked on a button.

This seems an ingenious solution, but it creates new problems. First, the grouped text is not an object in the way that a button or a field is an object; thus, unlike TOOLBOOK's "hotwords" (Asymetrix's solution to the same problem), it can't have its own script. The script must instead be written for the field that contains the grouped text. If the field contains more than one block of grouped text and you want the system to respond differently in each case, you will find yourself writing complex scripts with if-then-else clauses nested inside other if-then-else clauses; these can be difficult to keep straight, and can slow things down.

The second problem is that the field must be "locked"--and therefore unmodifiable--in order for the script to take effect. (TOOLBOOK poses the same problem.) This is especially annoying during the design process because it means you have to keep locking and unlocking the field in order to test and then modify your scripts.

More seriously, it violates one of the fundamental precepts of hypertext--though HYPERCARD is by no means the only program to do so. Hypertext is founded in part on the recognition that making, and marking, connections among texts is a fundamental aspect of scholarship, and indeed of reading; this is the essence of hypertextual linkage. Locked text fields violate this premise by inhibiting readers from making new connections and creating new links. By contrast, the team that designed Brown University's INTERMEDIA decided to decouple the links from the text; this makes it possible to add and delete links while preserving the integrity of the text.

I would argue that the "group style" strategy rests on a fundamental misapprehension about the scale at which linkage is taking place, and I suspect that the index-card metaphor is at the root of the problem. Because HYPERCARD treats the card as the basic hypertextual node, the smallest possible unit that can appear by itself on the screen, the program assumes that creating links is a matter of linking cards to one another. That assumption is not valid in the case at hand, however; the units in question are considerably smaller than the individual card.

At the other end of the scale, HYPERCARD lacks mechanisms for obtaining a global overview of large, complex projects. This makes both planning and maintenance more difficult than they should be. The lack of a planning facility is again not by any means unique to HYPERCARD, but it reveals the limitations of the index card metaphor--though here the difficulty is that the stack is the largest unit that HYPERCARD defines, and it simply isn't large enough.

Hypertext poses significant problems of orientation and navigation: Absent the landmark structures of traditional printed materials and it is difficult for hypertext readers to tell where they are in relation to the whole. This is equally a problem for authors composing hypertext materials and for instructors developing computer-based course materials. HYPERCARD does virtually nothing to address such problems. By contrast, STORYSPACE provides the kind of "Chart" and "Outline" views one finds in outline processors such as Symantec's MORE, as well as "Roadmap" and "Pathbuilding" facilities; the latter are more cumbersome than I would like, but they certainly help. (Developed by Jay David Bolter, Michael Joyce, and John B. Smith, and now marketed by Mark Bernstein's Eastgate Systems, Inc., STORYSPACE is reviewed elsewhere in this collection.) I want a planning tool that will allow me to designate a number of different stacks as belonging to a single course, for example, and will then present different overviews of those stacks and the relationships among them as indicated by the links I had created. It would be useful to be able to define links at this overview level as well and to view and edit scripts--at least those that define links. A "Merge Stacks" command would also be extremely valuable. In short, I want to be able to browse and edit the structure of a large HYPERCARD project, but the software limits me to stacks and cards.

Don't be frightened away from trying HYPERCARD by anything I've said here. HYPERCARD's limitations are real enough, but so are its virtues, and the program's importance is undeniable. As I said at the outset, HYPERCARD begins to suggest how the computer can extend the concept of writing.

The first extension has less to do with HYPERCARD than with the fact that computers work with digitally encoded information. As Richard Lanham (1989) has pointed out, digital encoding makes text coextensive with other digitally encoded material from music to video; thus "writing" comes to include visual and auditory dimensions that used to belong to other media.

Second, HYPERCARD extends writing to include programming. Though I hasten to add that it is quite possible to create highly successful HYPERCARD stacks without writing a single line of code, it is important to recognize that "computer programming is a kind of writing," as Jay David Bolter (1991, p. 9) has said, and that the problems involved in the design of computers and computer software are precisely language problems, as Terry Winograd and Fernando Flores (1986) have argued. Furthermore, HYPERCARD's scripting language, HYPERTALK, is more tolerant of syntactic and verbal variety than any other programming language that I know. This not only makes scripting easier, it means that HYPERTALK incorporates some of the principles we commonly associate with good writing.

The final extension I have in mind involves designing the ways in which readers will interact with the system one is creating; this is called interface design. The user interface mediates a person's relationship with the computer; it includes not only screen layout but also the "behavior" of the elements on the screen (e.g., the placement and function of buttons, menus, and so forth). Perhaps even more vital, the user interface mediates relationships with materials off-screen. The interface provides access to the functions of the computer--functions that readers require, for example, in order to activate links they wish to follow. Interface issues are thus rhetorical issues.

Interface design is particularly important for hypertext because, as Scott Johnson (1990) has written, in hypertext the document is the interface. Thus, in saying that HYPERCARD extends writing to include interface design, I mean to imply both that authors of HYPERCARD "stackware" must be conscious of issues that do not impinge so heavily upon authors of print-oriented academic documents, and that interface design offers writing teachers a new rhetorical domain to explore. One of the real joys of HYPERCARD is that the software makes it so easy to create an attractive and powerful interface--and again, I emphasize that this need involve no scripting whatever. Indeed, for nonprogrammers interested in creating computer-based course materials for their students, or simply experimenting on their own, HYPERCARD is unsurpassed.

1. I am oversimplifying a bit: In fact, each screen obect--field, button, graphic--occupies its own distinct layer, either within the background or at card level. Thus, a background with, say, five fields and four buttons consists of nine layers superimposed on each other like a series of plastic transparencies. This makes it possible to move these objects back and forth.
   

John M. Slatin is Director of the Computer Research Laboratory in the Department of English at The University of Texas at Austin.

Bolter, J. D. (1991). Writing space: Computers, hypertext, and the history of writing. Hillsdale, NJ: Lawrence Erlbaum.

Johnson, J. S. (1990, June). The DDJ hypertext project. Doctor Dobb's Journal, 165, 16-18.

Lanham, R. A. (1989). The electronic word: Literary study and the digital revolution. New Literary History, 20(2), 265-290.

Winograd, T. & Flores, F. (1986). Understanding computers and cognition: A new foundation for design. Norwood, NJ: Ablex.