An author writes a document and submits it in electronic form to a reviewer. The reviewer makes vocal annotations about the document and collects these annotations into a script. The script might traverse the document in decreasing order of importance of the needed changes. Within the script, examples of a single problem could be collected together. For example, suppose that there are three places in the document where the author refers to linked lists, but he uses slightly different terminology at each place. The script might have an initial entry describing the overall problem of confusing terminology, immediately followed by entries at each of the confusing spots, with remarks about particular difficulties at each. In this way, the script approximates the reviewer sitting down with the author and a copy of the document, making comments and flipping back and forth through the document to substantiate these comments. The reviewer could make multiple scripts on different topics, such as positive comments and negative comments, or overall comments and specific typographic and spelling corrections. Comments from multiple reviewers could be represented as multiple scripts.

Scripts could also be used as an organizing technique during authoring, similar to 3x5 note cards. When analyzing a source document, the user could create multiple scripts on different topics. These scripts could be reordered as needed. The use of voice to collect the information could make the whole process very quick and painless.

These operations are treated as edits to the document in which the script entry appears.

Create script [scriptname]. This operation creates a new script, allowing the script writer to name the script with an arbitrary string.

Destroy script [scriptname]. This operation removes the named script from all associated documents.

Add entry [selection, scriptname, seqNum, action]. This operation adds the selected location to the named script after entry seqNum (that is, as entry number seqNum+1). The script writer fills in the action field as a textual sequence of commands. These commands can include calls to specially-written user procedures. The script tool records the filename with each script entry.

Delete entry [scriptname, seqNum]. This operation removes entry number seqNum from the script.

Find entry [scriptname, seqNum]. This operation scrolls the document to entry number seqNum and highlights its location. It also displays the associated action in the tool's action field.

Next entry/Prev entry [scriptname, seqNum]. These operations allow the user to step through the named script easily in either direction. Next (Prev) entry is equivalent to incrementing (decrementing) seqNum and clicking Find entry.

List scripts [selection]. All script names that appear in the selected document are listed in the script tool's message area.

List entries [selection]. All <script name, sequence number> pairs that appear in the selected location are listed in the script tool's message area.

Play script [scriptname]. This operation plays the named script, starting at the first entry and proceeding automatically in sequence through each entry to the end of the script.

Play entry [scriptname, seqNum]. This operation performs the action of entry number seqNum in the named script.

Stop. Cancels all script playback operations.

Script visualization is a problem for both the script reader and the script writer, because script sequencing and script actions are not directly visible by examining the document. The script reader must be able to tell that a document has associated scripts and which scripts are appropriate for him or her to play back. The script writer has the more difficult problem, in that he or she must also have tools for debugging faulty scripts.

The script reader is alerted to the presence of scripts available to be played in a document in two ways. First, when a document is displayed, a Script button appears in the document header if and only if the document has scripted locations. All script examination and playback operations are available from a popup menu generated by clicking the Script button. Second, each scripted location is distinctively marked with a surrounding rectangle. This rectangle indicates membership in some script, but does not show either the number and identity of the scripts or the sequence number within those scripts. To discover this information, the script reader can use the List entries function in the Script Tool. Similarly, to discover what scripts have entries in a given document, the script reader issues the List scripts command.

The script writer can use the preceding commands together with the Find entry, Next entry, and Prev entry commands to traverse the scripts and examine each action field. These functions are sufficient for creating and editing scripts, but they can be tedious, and they are certainly not evocative.

The Extract script command prints out a named script in textual form. It lists the script name. Beginning with the first entry in the script, it then lists the sequence number, the filename, the character indices of the start and end of the scripted location, and the action field for each entry in the script. This command records the create date of each underlying document in addition to its filename; it can only be applied if all underlying documents are in a saved state (that is, they have no pending unsaved edits).

The Apply script command reads a textual script and applies it to a document (or set of documents), replacing any scripts with the given name. Using this command, a script can be created in textual form and applied to a document, or it can be used in conjunction with the Extract script command to examine and edit action fields more easily, with global substitutions, etc. It also allows the script writer to create additional scripts that are slight modifications of old scripts. Scripted locations can be moved by using the Tioga editor's Position command to calculate the indices of the new positions. The script writer must confirm application of the Apply script command if any of the underlying documents has been edited since the script was written, because the document position indices may have changed.

The Tioga editor is a what-you-see-is-what-you-get galley editor, used for both program text and high-quality documents. Tioga documents are tree-structured, where the writer constructs the tree to correspond to the structure of the document; a node may be a section head or a paragraph. Tioga documents can be displayed at any level of detail, from the single root node to the full tree.

In addition, Tioga documents can have rich formatting and typography. Each node has an associated format, which specifies such parameters as its leading, its margins, its default typeface, and so on. A document as a whole has an associated style, which defines the meanings of all formats used in that document. Nodes can also have arbitrary named properties, added by the user or by programs. These properties are not directly visible when the document is viewed, but a separate tool called the Edit Tool can be used to examine their values. One use of node properties is to specify bitmaps and other necessary parameters for pictures embedded in Tioga documents.

Individual characters in a Tioga document can have looks, which specify special typeface parameters such as bold face, italics, subscripts, and the like. Characters can also have arbitrary named properties. Tioga has search commands that allow documents to be searched rapidly for given node or character properties.

The experimental Etherphone system [SwiSteOrn83] uses Ethernet communications to transmit digitized voice. The system consists of microprocessor-based electronic telephones, a centralized switching server, a voice file server, and workstation programs to support voice communications and voice recording services. From a workstation, a user can place and receive telephone calls, maintain private telephone directories, and manage a database of voice messages. A voice annotation package allows voice to be added to Tioga documents and provides simple voice editing functions [AdeSwi86]. In addition, a commercial text-to-speech synthesizer exists as a server in the Etherphone network. The synthesizer allows the system to `speak' text, initiated either by the user (perhaps by selecting the text in a viewer) or by a program (such as speaking an error message or proofreading a document).

This work on scripted documents began as a project to exploit the capabilities of the Etherphone system by creating narrated documents. Narrated documents are scripted documents whose actions play previously-recorded voice annotations.

In our prototype implementation, script entries are part of each scripted document. A split representation of script entries allows scripted documents to be edited without constantly updating the character indices for a scripted location.

A saved document contains a list of its scripts in Apply/Extract script form as a node property ($Scripts) on its root node, with the addition that each script entry is given an internally-generated unique identifier. As an optimization, a saved document need only contain references to script entries within it, together with a filename for each Next or Prev entry outside that file. Those entries can be discovered and played back when needed by accessing their containing file. The beginning of a script is indicated by the script entry with sequence number 1.

A character that is a part of a scripted location has a character property ($ScriptEntries) that contains the script name and the script entry's unique identifier. If a character has more than one associated script entry, either because it appears in multiple scripts or because it appears more than once in a single script, then that character's $ScriptEntries property contains a list of these tuples. As mentioned above in the section on visualizing scripts, these characters also have properties that give them a unique appearance, with a small rectangular box surrounding them.

While a script is being edited, the Script Tool maintains an internal linked representation of the script, allowing for easy insertion and removal of script entries. Whenever the Tioga Save command is issued, character indices are computed for the script entries, to speed playback. For unsaved documents, the character indices are ignored, and character property search commands are used to find the character with the desired unique identifier. In fact, the system treats character indices at all times as only a hint: if the indicated indices do not have the matching unique identifier, the search commands will be used instead.

Using character properties means that the scripting system need not monitor all insertions and deletions of characters in unscripted locations. In fact, using character indices as only a hint means that the scripting system need not be running to edit or view a scripted document without playing back its scripts. However, changing and/or copying a scripted character still cause problems. (Recall that scripted characters have a unique appearance, so the user is alerted.) Changing a scripted character removes its character properties, leaving the script referring to a possibly non-existent unique identifier, and copying a scripted character creates two possibly non-contiguous copies of the same unique identifier. Flaws of this kind in a script are detected the next time that the document is saved (if the script system is active) or the script is played back, and the user is given a chance to repair the damage by repositioning the script entry in question.

The current implementation has the drawback that changing the number of script entries in a script that crosses document boundaries forces the system to edit other documents in that script to update their sequence numbers. We plan to relax this constraint by using the script entry naming scheme described below in the section on conditional scripts. Of course, scripts that cross document boundaries do present problems in ensuring that the documents are kept in a consistent state and are not deleted piecemeal. As an interim measure, we use the Cedar DF Tool system to maintain consistency [SwiZelBeaHag86], but a system-wide database for recording such interrelationships is under development [Terry86].

The Extract script and Apply script commands are useful for examining and editing a script's action fields, but they do not adequately depict the script's sequencing information nor the document contents at the given indices. A promising idea for displaying a script in situ is to create a fisheye view [Furnas86] of its scripted locations, with sequence numbers added to the script rectangles, as shown below.

Even if this view does not fit entirely in one screen, it can be scrolled to present a much better overview of the sequencing and location information than viewing the entire document.

A more graphical approach would be to create thumbnail sketches with superimposed arrows depicting the script's path.

Conditional scripts would allow a single script to vary to suit the script reader's needs. For example, a script could take one path if the script reader's experience level is novice, another if intermediate, a third if expert. Interactive scripts would allow user interaction to gather parameters for conditional scripts, so the script reader can participate in the creation of a particular viewing path.

One way to extend the current implementation of scripts to permit conditional scripts would allow the script writer to specify the next field directly, as a sequence of <condition, script entry name> pairs. A script entry would be expanded to contain an optional corresponding name. Script entries that follow in unconditional sequence need not be named. For conditional scripts, the sequence number of an entry would no longer be well-defined, and we could use the well-known assembly language naming scheme of namedLocation, namedLocation+1, namedLocation+2, anotherNamedLocation, anotherNamedLocation+1, etc. The Write script command must list the entries in a reasonable order (e.g., some form of topological sort). In addition, the Prev entry command would be available only during script playback, at which time a history mechanism would be used to implement it.

We are also considering ways to specify conditional scripts by combining structured programming ideas and direct manipulation techniques.

For interactive scripts, we would like to provide mechanisms to help the script writer gather input from the script reader, such as popup choice buttons. These mechanisms are available as packages in the underlying Cedar system (and hence could be accessed as part of an entry's action), but it may prove useful to tailor them to ease the script writer's task as much as possible.

At each script entry, the script writer may wish to control the appearance of the document, such as how many levels of the document's tree structure should be displayed, the manner in which the scripted location is highlighted (such as reverse video, underlining, or blinking). In addition, when a script crosses a document boundary, the script writer may wish to specify whether the new document is loaded into the existing window or a new window is created. Scripts can become arbitrarily complex as they try to specify the appearance of the result more fully, just as typesetting tools allow more or less control over the fine points of document layout (such as Scribe vs. TeX).