Hypercard Importance
Volume Number: 10
Issue Number: 3
Column Tag: Inside Information
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.