MATT: Thus far we’ve been describing things you do while Storyspace itself is up and running, and no doubt you’ve been thinking of uses in your own life to which its read/writable windows and configurable links between them might be put. But there is also another entire side to Storyspace. You can create a Storyspace document and present it as a stand-alone application to someone else without Storyspace itself by building a "reader" into it. Three different styles of reader are provided, including one that permits not only clicking but also answering yes/no and typing words as a means of responding to prompts; in two of them (the ones most likely to be used) all the user sees is one text space at a time, and as screens, not as moveable windows. In any reader, the text spaces and links are absolutely fixed: neither the user nor the application has any way to alter their content once the reader is constructed.
You might think that the result is rather a hamstrung version of Storyspace, but this is not so. Readers have a different purpose from Storyspace itself; and to reflect this, they have a feature that Storyspace does not (well, it does actually: you can always step temporarily into "reader" mode from within Storyspace). It is at this point that Storyspace’s third rule of navigation comes into play. When you build a document in Storyspace, you can set up "guards" on any link; these guards take effect only from inside a reader, and what they do is to require that the user have performed certain actions before being permitted to navigate that link. This gives us the following rule:
- Rule 3: In "reader" mode, the user can navigate a given link only as long as her/his previous actions have satisfied any guards placed on that link. The guards can depend on either of two basic action types – if the user selects (or types) a certain word, or if the reader has already visited a certain text space. Moreover, you can use the Booleans, AND, OR, and NOT on these basic actions. (There’s also a special guard field, BACK!, which sends the reader back to the previous writing space.) It is easy, therefore, to create documents in which the user’s chain of behaviour determines in a fairly complex way what screen s/he is shown next.
ADAM: The guards are what give Storyspace’s links their true power. The ability to link items is rare, certainly, but I don’t know of any other program that gives you the same sort of conditional control over linking. HyperCard might be able to do it with a lot of work and careful scripting, and Owl International might have come out with a newer version of Guide that can do something like this, but otherwise Storyspace is unique in this respect.
MATT: I completely agree. When I first started playing with Storyspace I thought it would be the names of links (and Rule 2) that I would rely on most; but in building my Greek paradigm reader I find that everything depends upon a combination of guards with links from particular text. Using guards you can ask a question and have the next action depend upon whether the user types/clicks Y or N; you can teach a user a repertory of typed commands (Next, Prev, Subjunctive, Help) and respond to them. That’s why yet another feature of the interface bothers me. When you create a link you are always given an opportunity to name the link; but sometimes, and only sometimes (the conditioning factor is hard to explain), you are given an opportunity to name the link and attach a guard, all in one dialog. I feel you should always be shown that dialog when you create a link; it’s better to let the user turn down an option than to force her/him to take two actions (attaching the guard later on) when one will do.
An included utility also permits you to turn a Storyspace document into a HyperCard 2.0 stack, in which each card consists of a scrolling field showing the text of a text space (your character formatting is lost, alas), where selecting a word by click-dragging across it has the same effect that double-clicking would have had in a Storyspace reader. In essence, this provides HyperCard with the true hypertext abilities that it still otherwise lacks. Such a stack might need considerable modification to be made more useful than a Storyspace reader, though. Tools for importing text, and for exporting it with character formatting intact to MacWrite, are also included.
ADAM: The use of the HyperCard-based reader, called Storycard, is two-fold. First, as Matt says, you can use Storycard as a replacement for one of the three readers included with Storyspace. The resulting stack is much smaller (about half the size) than a Storyspace document that has the application code embedded in it, and it can easily have extra stuff added, though of course that requires a bit of work scripting in HyperTalk. More the idea, I suspect, is that you can very easily link the Storycard stack to other HyperCard stacks that might or might not have been created by Storycard. For example, you could create a stack (to use a hackneyed and tiresome example) with training information that uses snazzy graphics and pseudo-animation and all, and link into that with a Storycard-created technical description of what was happening. Alternately, you could hang out and wait for the truly System 7-savvy version of Storyspace that should have QuickTime capabilities. Unfortunately, the HyperCard version of a Storyspace document is much slower than any of the readers, so I suspect most people will stick to using the readers for distribution.