The Importance Of Hypercard

Different people want different things HyperCard helps you with this.

By Chris Espinosa, Apple Computer, Inc., MacTech Magazine Regular Contributing Author

In early 1986 Bill Atkinson showed me a demo of an address book application he was writing for the Mac Plus. It had some fairly simple capabilities-it let you enter names and addresses, and go from card to card, and find addresses really fast. Over the next couple of months he added support to paste pictures in, to handle multiple files (which he called “stacks” of “cards”), and to drop a button onto a card that could instantly jump you to another card. The last feature was particularly neat. Several years earlier, Steve Capps and I had made a start at something Steve called “flashcards,” which were cards full of objects that could be linked to other cards. We thought that this would make an interesting form of on-line documentation for the Mac, somewhat like software quick reference cards with built-in cross-referencing. Bill had started from a different place and ended up with a similar idea: cards with hypermedia links.

As it grew, HyperCard accumulated features. The card transitions became more sophisticated through visual effects. Buttons expanded from “go to” to do one of ten or twelve things, then became scriptable. Users of the script language found a rich object and message model.

All the while, it was my job to work with the marketing and sales people and explain what this thing was. Half of the features were pulling it towards the address book on steroids, and a lot of early stack writers basically made it an information utility, a front-end for local or remote data. On the other hand, other features drew it towards being a new kind of document creation tool, like a spreadsheet or word processor. We joked about these two natures, and thought that HyperCard was like Glory, the fictional Saturday Night Live product that was “both a floor wax and a dessert topping!”

Those of you who have products that don’t fit an established category know what this is like. You have two or more (sometimes vocal) customer sets pulling for different and contradictory features. Maybe office users want more limits, rules, and protection because they’re trusting their business data and processes to your program, while creative users want more openness and access. Maybe power users are asking for a passel of new features while your user testing is showing that the interface is getting too complicated for new users. The magic of HyperCard is in not only navigating these dilemmas, but resolving them in a way that serendipitously benefits both groups. In version 2.2, for example, the same mechanism that allows a multimedia developer to deliver a standalone media title (the Save As Application option) also lets an in-house developer easily “lock” scripts from tampering. For another example, opening up HyperCard to the Open Scripting Architecture lets educators use HyperCard as a system “dashboard” by using AppleScript or QuicKeys, but also lets serious scripters use the language and storage capabilities of Userland Frontier. The past few years for HyperCard have been rocky. The early confusion over whether it was a programming tool or a multimedia tool (along with some unhelpful organizational and technical moves) kept it from really gathering steam. But what was clear to a few people in 1987 is becoming obvious now: the line between multimedia tools and programming tools is blurring. Dynamic languages, object architectures, and interface builders are becoming common in professional development, and multimedia is getting much more serious than “visual effect wipe right.” The importance of HyperCard is that it remains smack in the middle of this convergence, and is set to be an important tool in the Nineties because it didn’t take sides.