When computer technology was first being introduced into the writing classroom, a common complaint focused on the inadequacy of the available software. Specific complaints ranged from the perception that the software being developed involved students in activities that could just as well have been completed without the technology to the observation that, although a particular application certainly accomplished something not easily replicable with pen and paper, it was not clear that what it enabled students to do was worth doing. The source of these and other problems was generally seen to result from a gap between those who knew the kinds of problems that needed to be solved in the writing classroom but knew too little about programming to create the needed software and those who knew little or nothing about the problems teachers and students needed to solve but could do wonders with the technology. Actually, this version of the situation oversimplified things somewhat, but it provided a ready explanation for why the software available for writing instruction seemed so ill-suited to what students actually needed to learn. One additional factor that could only become apparent with time and the development of technology was the limited power, relative to the problems that needed solving, of the technology available at the time. As technology has developed, we have grown to understand retrospectively its role in limiting what could be done with computer technology 10 years ago.

Since those early days, all of the factors cited above have changed and in the process have created a significantly different environment for the development of software for writing instruction. For one, instructors have had more time to work with computers in the classroom, and this has led to a greater sophistication about computer hardware and software. Even if they do not develop their understanding to the point of doing their own programming, they are more aware of what is possible, and consequently, they consider the software available to them more judiciously than they once had. At the same time, some writing specialists have become knowledgeable enough about programming that they either are able to develop their own software or are able to participate significantly enough in software development to make software more attentive to the actual problems instructors and students face in writing courses. A few examples include The Daedalus Group and the integrated software they have created for both the Macintosh and the PC, Bill Wresch's WRITER'S HELPER, Helen Schwartz's SEEN: TUTORIALS FOR CRITICAL READING, and Nancy Kaplan's REVISE.

Perhaps one of the most significant developments within the last five years or so is the ready availability of HYPERCARD on the Mac and the effect it has on instructors' control over the means of instruction through technology. Using a relatively simple scripting language that directs the operation of text and graphic images through which a learning writer negotiates movement through a particular task or constellation of tasks, the instructor could suddenly structure experiences capable of contributing significantly to students' understanding of the operations of text. In effect, HYPERCARD on the Mac, and more generically the hypertext and hypermedia programming tools that have followed it, has minimized and continues to minimize the three factors discussed above as the sources of early disappointment in the software being developed for writing instruction.

Hypertext and hypermedia authoring tools for IBM-compatible machines have lagged somewhat behind what has been available on the Mac. But in the last few years, the gap has been closing. One of the leading software packages of this kind for use in an IBM-compatible environment is TOOLBOOK from Asymetrix. Advertised as a software construction tool for WINDOWS, TOOLBOOK is now available in version 1.5, which embodies several significant improvements over its earlier version, 1.0. The two most significant of these are its enhanced speed and the addition of a multimedia capacity through an optional Multimedia Resource Kit (MRK) capable of incorporating into a TOOLBOOK application sound, speech, video, and animation with color graphics and text. The program's clipmaker utilities make the integration of nontextual information exceedingly easy, assuming one has the proper peripheral equipment (e.g., a laser disk player or PC-VCR). Running TOOLBOOK alone without the multimedia extension requires a minimum of 2 MB of RAM and 2 to 8 MB of free disk space, depending on the options to be installed. However, to run the program comfortably, the user's machine should have at least 4 MB of RAM. Of course, taking advantage of the multimedia options requires additional hardware and software (CD ROM, a laser disk player, a soundboard, animation software, a video board, an MIDI sequencer) according to the multimedia choices one wants to pursue. The more complex the application, the more expertise required of the user, and even though some instructors may be put off by the seeming complexity involved in building multimedia applications, even limited exposure to the program quickly dispels any fear or anxiety.

For most teachers to be able to create genuinely useful classroom materials, the programming tool they use must be both accessible and powerful. At the center of TOOLBOOK and one of its primary virtues is a scripting language--OPENSCRIPT--that fits both of the above criteria. Not only is OPENSCRIPT accessible but features built into TOOLBOOK also simplify the process of learning this language. The script itself, which attaches to an object on screen and directs the operations of the object, is created in a script window and written with a text editor. Creating, editing, and saving a script is comparable to creating, editing, and saving a file in a word-processing program. The language is about as close to English as anything I have seen. Although the syntax operates according to rules of its own, the user has the option of building comments into the script to keep a running commentary on its purpose, design, and individual features. This not only assists program maintenance over time, but it also helps a novice learn the relationship between OPENSCRIPT arguments and the operations of a particular application.

TOOLBOOK also offers learners recording and debugging features. Simply put, the "Record" function allows the user to create a script by actually performing the tasks the script will be designed to automate. The user turns on the "Record," goes through the motions that she or he wants to script, and when finished, shuts off the "Record" function. When this process has been completed, a script for the action is ready for use. This feature has two obvious advantages. First, it can be a means of creating some rather sophisticated scripts without having a full command of the programming language. Second, the "Record" function offers a quick and convenient means of learning the programming language. That is, after using the "Record" function to create a script, one can study it to see what was required to perform a particular action within the program. Because the language and syntax are seen through the lens of the action one wants to build into an application, this process offers a concrete method for learning the terms of the language and the effects of its syntax.

A second means of assisting one's efforts to learn OPENSCRIPT is TOOLBOOK's integrated "Debug" function. Many errors in a script can be detected by simply opening the script window, examining the script, and identifying typographical or syntax errors that keeps the script from running as intended. The "Debug" function also identifies more-complex run-time errors resulting from some problem in the program's effort to execute an operation. With some of these errors, the "Debug" function identifies why and where the error occurred and gives the user the option of editing the problematic script, debugging the script, or canceling the "Debug" operation. For other run-time errors, the "Debug" function allows several options for tracing or trapping the error in order to correct the script. Admittedly, some aspects of the debugging operation require a more sophisticated command of the program than do others; however, regardless of the level of the programmer's expertise, the "Debug" tool can offer assistance of some kind in teaching the user more about how the program works and how to get the most out of its features.

Two additional features useful in helping one develop a command of TOOLBOOK are its extensive on-line help and its long list of sample applications. The two primary means of on-line help are an explanation of the program's key features and a tutorial that can be called up from within the program. The explanation of key features can be accessed through an alphabetical listing of all of the available program features or through a topic index. The latter organizes an explanation of program features according to topic headlines that correlate nicely with the overriding kinds of questions users, particularly new users, are likely to have. These topic headlines include: "Menus and Commands," "Building Books," "Using Tools and Palettes," "Working with Objects," "Working with Scripts," "Hotwords and Linking," "Shortcuts," and "OPENSCRIPT References." In addition to the general on-line help, individual functions within the program have their own help menus. So, if one is in a script window and has a question about some aspect of developing a script, she or he can select the "Help" option from the menu at the top of the window and select an item bearing on the issue in question.

The sample applications included with the program range from a primer on creating animated applications with TOOLBOOK to a program that offers templates for creating on-line presentations. These sample applications assist people learning the program in two ways. First, each application contains a "Help" command explaining how the application works. The user can access the script for each feature of the program to see what was required in building this feature into the application. Second, if one is building an application and finds a feature in a sample that would work well for the application under development, the script can be copied ready-made into this application. The effect of these features is to streamline both the process of learning the program and the process of developing an application. In very little time, an instructor new to developing applications can be constructing fairly sophisticated applications.

Emphasizing the support available for developing a working command of TOOLBOOK, with special attention to how readily the program assists application development, naturally triggers follow-up questions about the program's power. The ease of use does not mitigate against the capability of the program to support the development of sophisticated applications. The program accommodates the full range of programming operations generally associated with sophisticated software creation tools--including, but not limited to, loops, branches, case statements, and math and string functions. This is not to say, however, that these operations are necessary to build worthwhile applications. The most elementary functions, combined with preexisting scripts that can be copied into a developing application, can allow even a novice user to create powerful course materials.

The metaphor on which TOOLBOOK is based is one that writing instructors and students will find familiar and comfortable. Each application is considered a "book," with each screen treated as a page in the book. Unlike conventional books, however, TOOLBOOK dynamically links different pages in a book and different books so that the user can leave one book to go to another and return to the first book after completing operations in the second. This and other features of the program--mostly features reflecting its hypertextual character--suggest how the metaphor itself, when taken literally, works against some of the most powerful features of the program. That is, if the user expects the program to function no differently from a conventional book, she or he may bypass the essential power of the program. Interaction with a book occurs at two levels, the author level and the reader level, and movement back and forth between the two is readily managed. The author who creates a book can shift with the click of a mouse to the reader function to see the screens that the reader will be presented in using the application. Some may find this surface emphasis on author and reader as discrete roles incompatible with the concepts of both writing and reading as constructive activities, and, in fact, incompatible with the central virtues of hypertext and hypermedia.

To read a book, a user must have TOOLBOOK operating on her or his machine, though a developer can purchase a kit that makes it possible to attach a run-time version of TOOLBOOK to an application. With the run-time version, those who do not have the full version of TOOLBOOK loaded on their machines can still use an application developed through the program. This may be the most economic strategy for developing classroom applications because it may be prohibitive to purchase individual copies of the program for all students, and in many settings, purchasing licenses for multiple sites could also prove too costly. The run-time version, however, only allows the user access to an application as a reader. This means that the kind of interaction with the application that the user is allowed will be limited to the interaction that the developer built into the application in the first place. In many instances, this is as much interaction as the developer desires, but in others it may be desirable to allow users to alter the application itself.

Addressing questions concerning ease of learning and use, the power of the program, and the nature of user-program interaction do not allow us to bypass the more fundamental issue of how TOOLBOOK, and indeed all hypertext and hypermedia authoring tools, allows an instructor to address the kinds of problems of concern in writing courses. As long as instructors keep in mind the database nature of the program, its navigational possibilities, and its capacity to integrate (particularly with the MRK option) a range of different media, they will be able to match program features with issues needing attention in the classroom. Many of the available educational applications of hypertext and hypermedia stress the role of the student as a navigator of media created by others. Much less seems to have been done in bringing the power of hypertext and hypermedia to bear directly on challenges students face in generating their own texts. Certainly, to a degree, these orientations overlap, and in negotiating materials generated by others, the students will be involved in text construction in a way that influences and informs the understanding they bring to creating texts of their own. However, some applications are more direct than others in addressing students as writers, focusing on having students generate, organize, and navigate through their own documents as they move toward a final paper.

In "Toward the Metapersonal Essay: Exploring the Potential of Hypertext in the Composition Class," Anne DiPardo and Michael DiPardo (1990) offer an example of this approach to using hypertext and hypermedia tools in the classroom. They describe a hypertext application designed to bridge the gap between personal and narrative writing and the "more abstract, generalized avenues of inquiry" characteristic of academic and professional writing (p. 7). Their HYPERCARD stacks include five writing assignments: a personal story, an expository text linked to the story, another narrative, an essay on a topic closely related to the second narrative, and a final essay asking students to "integrate the narrative and expository strands they have been exploring into a linear essay." Such an assignment would work well with any hypertext program, including TOOLBOOK, as long as the program allows students to create the database of their own texts and offers them the navigational options needed to explore the links that the assignment sequence aims to highlight.

More and more writing instructors, rather than having students use hypertext and hypermedia programs to navigate the students' own texts and the texts of others, are attracted to having students' essays constructed as hypertext or hypermedia documents (hyperdocuments). Of course, the two approaches are not mutually exclusive, and pursuing both at the same time seems a highly instructive way of getting at key questions about the nature of text and its processing. Discussing the differences between conventional texts and hyperdocuments would accentuate the distinctive features of each kind of text. Having these distinctive features so accentuated, in turn, could enable students to understand more readily than they otherwise might what these features entail. Everything stated earlier about the ease of use and learning and the power of TOOLBOOK would suggest that it could accommodate quite readily efforts to have students create hyperdocuments in a writing course. The critical consideration would be less a matter of the program's capabilities and more a matter of the resources available that would allow the instructor to purchase enough site licenses or copies of the complete program to allow the students to be authors as well as readers.

Software that gives users the power to build hypertext and hypermedia applications is proliferating on all personal computing platforms. As writing instructors become increasingly familiar with these tools, programs such as TOOLBOOK are likely to become more and more important in the repertoire of options writing instructors use in guiding and supporting the learning pursued in their classrooms. Not only does the current version of TOOLBOOK, with its combination of ease of use and learning and power, accommodate the needs of those already committed to incorporating hypertext and hypermedia into their writing instruction, but it also offers a platform through which those just developing an interest can quickly and effectively mo