HyperCard and (or?) Hypertext

Michael Swaine

The only honest way to start a column about the suitability of this product for hypertext is by quoting its creator:

"I don't think of HyperCard at all as a hypertext system. It is not a very good one." -- Bill Atkinson.

That would also be the end of the column if every father knew his own child. But out there on the nets over the past three years, HyperCard has been doing things Bill never envisioned, and is playing an important role in the development of hypertext systems. The role is a research role.

Field Research

Since Apple caved in to Atkinson's ultimatum, agreed that HyperCard was system software, and began bundling it with every new Macintosh back in 1987, HyperCard authors of varying levels of skill have been all over the nets, showing their work with the obnoxious eagerness of a teacher's pet in grade school. I predicted in DDJ back then that the release of HyperCard would lead to a hyperglut of trashware, a pretty obvious prediction.

Not all this hyperactivity is trashware; and even in the trash there are some interesting items. (Jean-Louis Gassee says that this latter point is not lost on trash can grubbing "MacLeak" reporters, but he's just grumpy because he had to give back the company car.) (Many Americans discovered the joy of searching through trash cans in the 1980s, for which Apple must share the credit with Ronald Reagan.) (The parenthetical note is one technique that writers use to overcome the limitations of linear text. It's a kludge.) Interesting items, I was saying, thinking particularly of what can be learned from that "interesting experiment" that didn't quite work out. A lot of HyperCard development fits this description.

I want to call this undisciplined, uncontrolled, enthusiastic amateur HyperCard development work "research," but this is bending the word. Then again, magazines sometimes use the word "research" to refer to casual reader-interest surveys, which is just as bad. These two uses are, and you saw this word here first, "isotropes" -- they're similarly bent.

Moving right along. There is a lot of serious, professional, controlled experimentation in hypertext going on in universities and in the few corporate research labs that haven't turned into short-range product development shops. In particular, the people at Brown University's IRIS (Institute for Research in Information and Scholarship) have been following one thread of hypertext research ever since Ted Nelson coined the term, and have demonstrated the virtues of hypertext for promoting non-linear thinking. This kind of result does not come from playing with HyperCard and uploading your work to CompuServe.

But in a looser sense, these HyperCard experiments, failed and flawed as they may be, are crude offerings of aspects of hypertext. Seeing what has been tried, and how it has been received out there among the savages, is an education in hypertext field research.

"Crude offerings," I say, but I do not mean it as a criticism of the developers. HyperCard is, as Atkinson acknowledges, not a hypertext system. What is it, and why are people using it to do hypertext-like things? Atkinson calls it a "software erector set." That's pretty accurate, down to the point made by one critic that when you build things with an erector set, you get things that look like they were built with an erector set. HyperCard provides a limited set of classes of objects: Stacks (which are HyperCard documents), cards (information chunks displayed as screen-sized bitmap), fields for text (which can exceed the screen size by scrolling), and buttons (basically icons with attached programs). In limited object-oriented style, HyperCard lets you create stacks by writing message handlers and associating them with instances of these classes of objects. The basic metaphor is of a stack of 3 x 5 cards, each card displaying text and/or graphics, and the cards linked to one another quite freely, with buttons being the usual tool for following the links.

This model supplies several things that a hypertext system ought to have. The user can create links among chunks of information without doing any programming and the programmer can create different links relatively easily. HyperTalk, the programming language in HyperCard, is interpreted, so it's a quick development tool, yet it's powerful for an interpreted language. Apple gives HyperCard away with every new machine, so you can count on Mac users having it, and this also has led to a lot of people having fiddled with it, so HyperCard is helping to spread familiarity with some hypertext ideas.

It also lacks some things a hypertext system needs. It has no built-in navigation system, although Apple encourages stack developers to include maps in their stacks. There is nothing analogous to a browser. HyperCard's links are coarse-grain links, taking the reader from card to card. Fine-grain linking, triggering off items the size of an individual word, is possible, but is not inherent in the product. HyperCard has no text links.

In Search of the Missing Link

The biggest failing of HyperCard for anyone interested in hypertext is the lack of text links. By the time this column sees print -- I'm writing this in January, believe it or not -- Apple should have released Version 2.0 of HyperCard, widely expected to implement some kind of text links. I think it's fairly safe to predict that Apple's text links will not satisfy all those people who want HyperCard to be a better hypertext tool.

The text link solution supported in Version 2 is likely to be an extension of the button model. As I write this, buttons are the chief tool in HyperCard for supporting links. A button is restricted to one line (usually a word or two) of text. Fields are where you put text in HyperCard. Fields were never designed to support linking.

HyperTalk programmers have been coding workarounds for this failing since HyperCard was released, though, and some of these are effective in limited domains. The work these programmers are doing with text links typifies the kind of work being done with HyperCard in other hypertext or hypermedia areas, and it shows how easy it is to test alternative hypertalk user interface techniques using HyperCard.

What Atkinson gave us is the button. To create a link to another section (card) of a HyperCard document (stack) or to another stack, you create a button and link it to the card or stack. The link is by default unidirectional, except that the user can always return from a linked card via a standard key combination or menu selection. If you want explicit bidirectional links, you have to create and link two buttons. (Buttons can also be used to trigger pop-up fields, for such fine-grained hypertext purposes as displaying, in a pop-up window or field, a definition of a term.)

The first thing many people did when they started working with HyperCard was to place an invisible button over a text field or a graphic to make something happen when the text or graphic was clicked on. The earliest stacks from Apple used this technique. One early third-party developer who made good use of such invisible buttons is Amanda Goodenough, whose AmandaStories stacks showed one way to author interactive, child-directed stories for young readers. But the buttons were constrained to be rectangles and were not really connected with the text or art with which they were associated. Change the text, copy the art and paste it elsewhere, move the button, and the button is no longer associated with the text or graphic.

Soon after HyperCard's release, Keith Rollin of Apple demonstrated how to write a HyperCard external command to implement region buttons. These buttons, which used QuickDraw regions, could take on arbitrary polygonal shapes. This development, along with the fixed bitmap of a card (which makes screen position a somewhat reasonable way to refer to a picture), appears to make transparent buttons fairly useful for linking off pictures. Good stacks continue to be developed using this technique. But it doesn't do the job for text: You can't even change the font in a field without having to reposition the button. For hypertext linking, you need to be able to link off text, not off a screen position.

One step toward better linking might be to extend the find facility of HyperCard. Users can already select text in a field and perform a find operation. Why not insert a step between selection of the text and the conventional search? If the text selected is on a list of hypertext link words, follow the link; otherwise, let the find proceed as usual. Harvey Chang and Steve Drazga are two stack developers who extended the find function. Listing One (page 153) shows Drazga's hypertext technique while Chang's is in Listing Two (page 153). Chang's technique starts by allowing the user to select any contiguous text, even dragging across word boundaries. Then it attempts to use the selected text as the name of a card in a "go to card..." command. If that fails, it uses the selected text as a conventional search string. His implementation suffers from the requirement that the user select text, then explicitly click on a hypertext button.

There are a couple of problems with this technique as an approach to hypertext. (Chang, I should point out, doesn't call it that.) First, it doesn't give the reader any indication of where the links are. Second, it raises the question of what unit of text can serve as links.

Which Text is Hyper?

Chang's technique doesn't identify the links, so the reader must hit them by chance. In other hypertext systems, the linking text is often identified by a change in type style: Boldface, italic, underlining, or all of these, may be used. HyperCard doesn't make such an approach easy. Text fields in HyperCard are impoverished text of a single font, size, and style. One stack developer, Gregory Nelson, investigated what it would take to create even the appearance of rich text in HyperCard fields. He faked rich text by using 10 (!) overlapping fields and a thoroughly unworkable text-entry procedure. That blind alley is thoroughly mapped, thanks to Nelson.

John Anderson had better luck in introducing style variations in HyperCard fields, by creating a specialized font that included italic and roman characters. Because it means losing the special characters that had been in the font, this approach trades text impoverishment for font impoverishment, and is still a long way from support for the kind of hypertext link identification seen in products such as Guide.

HyperWords and HyperLines

The other problem with Chang's technique, viewed as an approach to hypertext linking, is that it depends on the select operation, which is nicely standardized across the Macintosh-user interface, but which is not a technique designed for grabbing links. This is particularly so in HyperCard, where the user can't select text unless the field is unlocked -- in which case the text is subject to modification. You certainly don't want the user selecting a hypertext link only to delete it from the document by a careless touch of the delete key.

Many stackware developers have found the same fix for this problem. To allow the user to select a word in any field simply by clicking on it once as though it had a button attached, you do the following:

   % lock the field
   % wait for a click in the field
   % save the coordinates
   % unlock the field invisibly
   % send two clicks to the coordinates
   % save the selection
   % relock the field

The first significant implementation of the single-word link I know of is XrefText by Frank Patrick (available as shareware from BMUG or BCS). Raines Cohen of Team BMUG inspired this shareware quasi-hypertext system, which lets users create links from arbitrary single words in fields by option-clicking, and lets them follow these links by simply clicking. XrefText limits its search for the selected word to a keyword field on every card. The link words are identified by an asterisk.

This works well for selecting a single word, and I've found it a useful way to allow the user to select an item from a scrolling list, even when the items in the list are not single words. My technique, which handles moved or scrolled fields, is shown in Listing Three, page 153.

This technique is all right for picking a line from a field, but neither this nor the toggle-lock-and-simulate-double-click technique for picking a single word is something you want to be doing regularly in an interpreted language.

One serious problem with all these approaches is that not every key can be a single word or a complete line. Footnotes in linear text sometimes apply to a single word, but can also apply to a sentence, paragraph, chapter, proper name, or to the general idea of a passage. Hypertext links ought to be just as flexible.

From SuperScript to Tagsterisk, or Footnotes of the Future

John Anderson, when he was developing stacks under the Acme Dot logo, came up with something he called the "tagsterisk," a tool for identifying for the reader not only where links are in the text, but also what they are. "The idea," he said, "is to give the reader a clue indicating just where he or she will branch if he or she clicks on a tagged word." Tagsterisks are just alphabetic superscript characters to be used in the way that asterisks are used in linear text to point to footnotes. Anderson implemented them as part of his custom font.

Tagsterisks, he claimed, "give the reader a greater feeling of control over the hypertext process. The key is to use no more than three or four." One Anderson stack used four tagsterisks: s to flag a source reference, m for more information on the subject, g for a graphic, and p for pronunciation (the last two being hypermedia rather than hypertext). Another stack used p for a picture, g for a graph, d for a definition, and l to bring up a list of links to other documents on the subject. Only the last of these was actually implemented as a link to another card or stack; the other three tagsterisks triggered pop-up windows or fields.

Tagsterisks are not tied to any particular method of implementing the link, which could be done with a button over the text, a field script, or with whatever technique is included in Version 2 of HyperCard. It's worth noting that, if the linking script is associated with the tagsterisk character itself, it becomes possible to attach two or more links to one word, say, a picture and a definition, without ambiguity.

Hypertext has been called the extended footnote, but only as a reference to its closest analog in linear text, not as a design direction. Tagsterisks take the expression literally, extending the footnote in several dimensions. There are some advantages to this extended footnote approach over, say, boldfacing links in text. One could argue, for example, that hypertext ought to extend the concept of text, not limit it. Using boldface to represent links "uses up" this font style variation, precluding its use for other purposes. The proponent of boldface links could counter that every use of boldface in linear text is really a wannabe link. Maybe our typographic conventions and type style variations were developed precisely to circumvent the limitations of the linear medium. If so, boldface has been waiting all this time to be used for hypertext link identification. The response might be that it's a little naive to think that we haven't found other, nonhypertextual uses for these typographical conventions over the centuries.

It's not clear that either side of this argument is wrong. No doubt different techniques are appropriate for different purposes. Designers of training manuals, help systems, and the like seem to be doing all right with boldface and italic variations to identify links. Universal hypertext may require something else, but universal hypertext is something else.

Whether or not one buys the argument that hypertext should extend text and not limit it, it seems clear that HyperCard should stop limiting its users' use of text. The impoverished text fields of HyperCard have not helped research in this area, either to investigate ways to use text style variations to identify links, or to show that this is a bad idea. HyperCard needs richer text fields.

Hypertext, though, is still very much in the research stage, and HyperCard stack development is one legitimate form of hypertext research. The laboratory studies, valuable as they may be, are not going to tell us much about the market acceptance of particular user-interface implementation decisions regarding hypertext. I recommend that anyone interested in hypertext download some stacks and take a look at them. Even better, upload some.


on mousewithin
   --hypertext technique by Steve Drazga, AnalytX
   --if you use this in your scripts please include these 2 lines.
     if the locktext of the target is true then
       set locktext of target to false --unlock the field if it is locked
    end if

   if selection is not empty then --something was selected
       put selection into SelectedWord
       if space is in SelectedWord then --user selected > 1 word
          click at loc of target --so we will clear the selection
          exit mousewithin --and exit to wait for another selection
       end if
     --this is the section where you do something with the selection
     --You can bring up a pop up note or you can go to another card.
     end if
 end mousewithin


on mouseUp

   -- This code, placed in a button script, implements
   -- Harvey Chang's hypertext trick.  The user selects
   -- any text in a field and clicks on the button.
   -- The script first tries to use the selected text as a
   -- hypertext link, then falls back to simple search.

  doMenu Copy Text
   put "Montreal Hypertext, Harvey Y Chang MD, 1988 Jan 16"
   push card
   go to Montreal Hypertext Demo
   doMenu Find...
   doMenu Paste Text
   put " in field " & quote & "Title" & quote after message
   do message
   if the result is "not found" then
     answer "not found in Titles:  search text?" with "OK" or "No"
     if it is "No" then
       pop card
       exit mouseUp
       doMenu Find...
       doMenu Paste Text
       put " in field " & quote & "Text" & quote after message
       do message
     end if
   end if end mouseUp


on mouseUp

   -- This is a scrolling field script.  Its field must be locked.
   -- It implements an index field, to be placed on the first
   -- card of the stack to be indexed.  This is the index card.
   -- When the mouse is clicked inside the field, this script causes
   -- a jump to the card corresponding to the line clicked on.
   -- The line commented out uses the text in the line,
   -- rather than its number, as the link.

  go to card getLineNum(the mouseV)
   -- find line getLineNum(the mouseV) of me in field keyword

end mouseUp

function getLineNum mouseVert

  -- Returns the number of the line clicked on.

  -- It works like this:
  -- Subtracting the top of the field and its scroll from
  -- the mouse's vertical location gives the
  -- mouse's vertical location within the field.
  -- Dividing this by the textHeight of the field & adding 0.5
  -- converts pixel counts to line counts.
  -- Rounding gives a value acceptable as a card number.

  -- Note: although this technique should work with any font size,
  -- turning on WideMargins will confuse the count.
  -- To adapt this script to a non-scrolling field,
  -- remove "+ the scroll of me" from the computation.

  return round(((mouseVert - the top of me + the scroll of me) / (the textHeight of me)) + 0.5)

end getLineNum