What Made Hypercard Great?

Hypercard took away many of the barriers which make it hard for people to make software. Here are some of the reasons why:

Immediacy

Hypercard was one of the original RAD tools. It was incredibly easy to quickly knock together a demo.

User Authoring

The line between “user” and “author” was very blurred in Hypercard. It was easy to step over the line almost without realising it, as and such it was a very inclusive tool which encouraged a lot of people to do things that they wouldn’t have imagined that they were capable of.

User Programming

The blurring between user and author extended to the scripting language, Hypertalk, which had a very clear, descriptive, natural language syntax that one could read almost as if it was a sequence of sentences in English, for example:

get the number of cards

sort cards by field “name”

on mouse up
  go next card
end mouse up

The authoring interface also allowed people to script the simplest of actions (e.g. going to the next card when a button was clicked) without actually realising that they were writing scripts, thus dipping their toes in the water.

Accessibility

Hypercard was free, and was installed on every Mac. This meant, for the Mac community at least, that it was very easy to get hold of, and that it was very easy to deploy content made with it.

Openness

Because one could switch between user and authoring mode, a culture of openness was promoted.

One could take a stack from someone else, open it up, and see how it worked. One could then change it, embellish it, or simply take the scripts and re-use them elsewhere.

Open Source software was in it’s infancy when Hypercard was in its heyday, but in many ways the Hypercard programming community helped to demonstrate the advantages of an open approach.

Compactness

Hypercard stacks were compact, so could easily be shared, even in the days of 400k floppy discs and 9600 baud modems.

Extensibility

In many ways the extensibility of Hypercard was flawed, but nevertheless it was extensible, and this became an increasingly important aspect of its success.

It was possible to write small chunks of code in lower-level languages like C or Pascal to extend the capabilities of the scripting language and interface it with the rest of the computing world.

This extensibility was modular, allowing add-ons from different sources to be mixed & matched, giving authors a large toolkit to work with.

The extensions could be distributed along with content in a relatively safe manner, allowing authors to rely on the presence of certain extensions.

A Concrete Metaphor

Hypercard was based around a very concrete ‘rolodex’ card file metaphor.

This provided an obvious place to start when making something, and made it easy for people to visualise models of the data that they were storing, manipulating, and presenting (as is often the case, this could become a strait-jacket for people who wanted to express other metaphors or organise things in different ways!).

Again this lowered the barriers preventing people from becoming authors, by taking away many of the initial decisions that users of a more general purpose authoring system have to make before they start.

A Wealth Of Examples

In addition to the openness and the culture of sharing mentioned above, Hypercard came with lots of example stacks, and lots of clip art, sounds, cursors, etc.

This gave people a massive head start, and made it easy for people to tweak an existing stack, or use an existing graphic, rather than having to start from scratch.