6.3 Rapid Prototyping in HyperCard

The Apple II was Apple Computer's first big success. Indeed, it was the first big success of any personal computer outside the hobby market. Every Apple II included a BASIC language interpreter for users who wanted to write their own programs. When Apple introduced the Macintosh, many potential users were disappointed that it came without a standard programming language. HyperCard, introduced a few years later, is a low cost, low effort programming environment that answers some of those users' concerns. It goes well beyond BASIC in terms of the ease with which a graphical user interface can be created.

Programs written in the HyperCard environment are usually called "stacks" because they present a stack-of-index-cards metaphor. The HyperCard application itself is required not only to write but also to run a stack. Every new Macintosh comes with HyperCard Player, a version of the application that will run any stack but allows only limited programming.

HyperCard provides an object-oriented visual programming environment in which the user can create and customize three main classes of object: buttons and text fields, which are on-screen controls; and cards, which are individual windows that contain the buttons and fields. A HyperCard program for a personal phone list could be implemented as a stack of 26 cards, each with text fields containing names and phone numbers, and with buttons on each card labelled A through Z that take the user to the appropriate card. The phone list is exactly the kind of program HyperCard was designed for, and it would be supported by a number of built-in functions that the user can access through the standard run-time menus, such as "go to next card" and "find a string of text." Since all the cards are the same except for text content, they could even be implemented as a single class, called the "background."

The phone-list application can be programmed entirely by interacting with the visual programming environment -- selecting from menus, filling in dialog boxes, dragging buttons and fields into place. For more sophisticated applications, HyperCard provides a Pascal-like language called HyperTalk. HyperTalk procedures (handlers) are activated by messages from user controls and other procedures. For example, you might want to add a feature to the phone stack that would find all the names with a given area code. You could write a HyperTalk procedure that prompts the user for the area code, searches for that code in the area-code field of each card, and collects all the names into a new field. You'd associate that code with a new button, "Find Folks by Area Code," either by actually writing the code "in" the button itself (command-option-click the button to open it up), or by writing the code in the stack as a message handler and having the button send a message when clicked.

HyperCard is an interpreted language, so procedures can be tested as soon as you write them, with no compilation. But they don't run exceptionally fast, and they provide only limited access to the Macintosh operating system toolbox, which is needed to create standard interface objects such as general-purpose dialog boxes and scrolling windows. (Pulldown menus can be created with HyperTalk commands.) You can overcome these limitations by writing external functions and commands (XFCNs and XCMDs). These are procedures written in a programming language such as C or Pascal and incorporated into a HyperCard stack as code resources. They can be called from a HyperTalk procedure as if they were built-in HyperTalk functions.

We've found HyperCard to be very valuable for prototyping simple interfaces. An idea can be roughed out and shown to other designers in less than a day, and building enough functionality for early user testing won't take much longer. The system has two shortcomings. First, unless you use XCMDs and put in a lot of effort, the programs you develop look like HyperCard stacks, not like Macintosh programs. Even with external commands, menus and dialog boxes never become true objects in the visual programming environment. This makes HyperCard a good environment for prototyping things with buttons and text, like automatic teller machines, but not so good for prototyping Macintosh applications.

The second problem with HyperCard is that it wasn't intended to be a general purpose, full functionality programming environment. It's very good for simple prototypes or small applications that fit the stack-of-cards metaphor, but if you try to push beyond its limits you'll soon find yourself with a large, unwieldy program in an environment that has little support for modularity and versioning. In the worst case, you'll also be juggling functionality between XCMDs and HyperTalk. Together these problems are an invitation to some pretty flakey code.

HyperCard and similar programs are simple design tools, something like an artist's sketchpad, that you should have available and use when appropriate. For extended testing and final program delivery on the Mac, you will usually want a more powerful UIMS, either a visual environment or a programming language with object-oriented extensions supporting the target system's full toolbox of interface objects.