Internet Culture

It’s time to revive HyperCard

Hypercard is dead: Long live HyperCard.

Photo of Jer Thorp

Jer Thorp

Article Lead Image

In 1963, my dad was looking for a job. Born in England and raised in Africa, he ended up in London after a few years of travel by ship and train. In those pre-pre-Craigslist days, people still searched for employment in newspapers, and an unusual listing in a London newspaper caught his eye: A listing looking for computer operators. The listing raised two immediate questions: What is a computer? And how do you operate it? (A similar reaction would have come from job listings for auto mechanics in 1914 or Web designers in 1994). Responding to that listing turned out to be a life-changing decision for a man who has spent over 40 years working with computers and technology. A very similar directional moment came for me 24 years later, in 1987, when my dad arrived home from work with a Macintosh SE computer.

Featured Video

The Mac SE was actually not as important to my life as was the software that came with it for free—in particular, an unusual and innovative application called HyperCard. HyperCard was a tool for making tools—Mac users could use Hypercard to build their own mini-programs to balance their taxes, manage sports statistics, make music—all kinds of individualized software that would be useful (or fun) for individual users. These little programs were called stacks, and were built as a system of cards that could be hyperlinked together. Building a HyperCard stack was remarkably easy, and the application quickly developed a devoted following.

HyperCard was the brain child of Bill Atkinson, one of Apple’s earliest employees, and the software engineer responsible for (among other things) the drop-down menu, the selection tool, and tabbed navigation. Bill played a big role in making the Mac what the Mac was—a personal computer that made the whole process of computing easy for the general public. HyperCard represented perhaps the bravest part of this “computing for the people” philosophy, as it enabled users to go past the pre-built software that came on the machines, and to program and build software of their own.

Assuming that a typical computer user would and could learn how to program may seem like a mad idea, but it’s one that has a long legacy. When personal computers were first envisioned in the 1960s, scenarios included the owners of these machines making their own software. The small group of people who were working in computing probably couldn’t imagine why anyone would want a computer if they didn’t know how to program it! With HyperCard, the learning process was facilitated by pre-built UI elements, and a simple drag & drop interface. Maybe most important, though, was HyperCard’s unique, innovative, and very easy to use programming language, HyperTalk.

Advertisement

Reading programming instructions written in some languages can be confusing. Statements in HyperTalk, on the other hand, tend to read like sentences in English. For example, if I wanted to create a variable called “name” with the string “bob dole” in it, I would write this:

put ‘bob dole’ into name

If I wanted to put the last name into a list of last names that I had already created, I could do this:

put the second word of name into last_names

Advertisement

And if I wanted to display the name on screen, I would simply write:

put name into field ‘name_display’

This type of plain-language programming makes sense, particularly in an application that was designed specifically for non-programmers. I have been teaching programming to designers and artists for nearly a decade, and I find the largest concern for learners to be not with the conceptual hurdles involved in writing a program, but with obscure and confusing syntax requirements. I would love to be able to teach HyperTalk to my students, as a smooth on-road to more complex languages like JavaScriptJava, or C++.

HyperTalk wasn’t just easy, it was also fairly powerful. Complex object structures could be built to handle complicated tasks, and the base language could be expanded by a variety of available external commands and functions (XCMDs and XFCNs, respectively), which were precursors to the modern plug-in.

Advertisement

This combination of ease of use and power resonated with the HyperCard user base, who developed and shared thousands of unique stacks (all in a time before the Web). A visit to a BBS in the late ‘80s and early ‘90s could give a modem-owner access to thousands of unique, often homemade tools and applications. Stacks were made to record basketball statistics, to teach music theory, and to build complex databases. The revolutionary non-linear game Myst first appeared as a HyperCard stack, and the Beatles even got into the scene, with an official stack for “A Hard Days Night.”

During the same time, developers made hundreds of extensions. Some let HyperCard stacks talk to other applications on your computer (opening the door to the first computer virus, “Concept,” in 1993). Others let you communicate to the outside world—BeeHive Technology’s ADB I/O) box was a kind of an Arduino for the ‘80s, and let stack-makers connect to sensors and send commands to electronics. A large community formed around HyperCard, providing tips and resources as well as a distribution channel for home-brew software makers.

Over the last few years, we’ve seen many exciting projects that work in the spirit of HyperCard—projects that offer free and simple ways to create custom software tools. Replace the word “HyperCard” in the paragraphs above with “Processing” and the word “stack” with the word “sketch,” and many of the innovations and advantages described can be moved 20 years into the future without much of a re-write.

HyperCard was the first real hyper-media program, paving the way for the Web and everything that came with it. It was used by thousands of people, and by most accounts, seemed to have been a fairly successful piece of software. Which, of course, begs the question: What happened to HyperCard?

Advertisement

A small project in the larger suite of Mac software, HyperCard never really saw the type of development commitment that it would need to remain current as the Mac OS advanced. The small, black-and white application looked more and more antiquated as screens got bigger and more colorful. To compound matters, the project was shuffled back and forth between Mac and its software subsidiary Claris and seemed never to get any kind of sure footing. Though a second version of HyperCard was released in 1990, the product made few advances since its release five years earlier.

Ultimately, HyperCard would disappear from Mac computers by the mid-nineties, eclipsed by Web browsers and other applications which it had itself inspired. The last copy of HyperCard was sold by Apple in 2004.

In new media, practitioners are often identified with the specific tools that they use. I started out as a “Flash guy” and over the last few years have been connected more and more with the open source software project Processing. Though I originally came to Processing to escape the Flash Player’s then sluggish performance, I value the platform as much for its ease of use and its teachability as I do for its ability to quickly add floating point numbers. Lately, I’ve been asked the same question, over and over again:

“Why don’t you move to OpenFrameworks? It’s much faster!”

Advertisement

It is true that projects built in OF run faster than those built in Processing. This question, though, seems to be missing a key point: Faster does not always equal better. Does every pianist want to play the pipe organ because it has more keys? Is a car better than a bicycle?

In my case, choosing a platform to work with involves as much consideration to simplicity as it does to complexity. I am an educator, and when I work on a project I am always thinking about how the things that are learned in the process can be packaged and shared with my students and with the public.

Which brings us to the broader concept of accessibility. HyperCard effectively disappeared a decade ago, making way for supposedly bigger and better things. But in my mind, the end of HyperCard left a huge gap that desperately needs to be filled—a space for an easy to use, intuitive tool that will once again let average computer users make their own tools. Such a project would have huge benefits for all of us, whether we are artists, educators, entrepreneurs, or enthusiasts.

Over the years, there have been several attempts to revive HyperCard, most recently on the Web. The now-defunct TileStack was HyperCard for a social media world, a site in which users could build their own stacks, program them with HyperTalk, and share them with friends. It was a bit of a time capsule, with many classic HyperCard stacks available to satisfy any nostalgic cravings for black and white pixel art you may be harbouring. Unfortunately, HyperCard, as much as we might love it, is 25 years old. These big initiatives to revive it directly end up looking and feeling antiquated.

Advertisement

I could imagine a new version of HyperCard being built from the ground up around its core functional properties: HyperTalk, easy to use UI elements, and a framework for extensions. It’s the kind of open source project that could happen, but with so much investment already existing in other initiatives such as Processing and OpenFrameworks, it might not be the best use of resources. So, let’s forget for now about a resurrection. Instead of thinking bigger, let’s think smaller.

It might not be as crazy as you think. Imagine having a single meta app that could be used to make smaller ones. This “App-Builder App,” like HyperCard, could combine easy to use, draggable user interface elements with an intuitive, plain language scripting language. As a quick visit to the App Store will show you, many or most of the apps available today could be built without complex coding. You don’t need Objective C to make a stock ticker, or a unit converter, or a fart machine. These homemade apps could be shared and adapted, cross-bred and mutated to create generation after generation of useful (and not so useful programs).

By putting the tools of creation into the hands of the broader userbase, we would allow for the creation of ultra-specific personalized apps that, aside from a few exceptions, don’t exist today. We’d also get access to a vastly larger creative pool. There are undoubtedly many excellent and innovative ideas out there, in the heads of people who don’t (yet) have the programming skills to realize them. The next Myst is waiting to be built, along with countless other novel tools and applications.

With the developer restrictions and extreme proprietism of the iPhone App Store, it’s hard to remember the Apple of the ‘80s. Steve Jobs, Bill Atkinson and their team had a vision to not only bring computers to the people, but also to bring computer programming to the public—to make makers out of the masses. At Apple, this philosophy, along with HyperCard, seems to have mostly been lost. In the open source community, though, this ideal is alive and well—it may be that by reviving some ideas from the past we might be able to create a HyperCard for the future.

Advertisement

This piece originally appeared on Medium, and has been reprinted with permission.

Photo via João Trindade/Flickr (CC BY 2.0)

 
The Daily Dot