HyperCard and the lost end-user

HyperCard is the case that complicates everything. The argument of the last chapter — that Xanadu’s ambitions were the right ambitions, that the system that did not ship was articulating something real, that the web’s reduced feature set was a real loss — is an argument that has to reckon with HyperCard, because HyperCard was the hypermedia system that did ship. It shipped on every Macintosh sold between 1987 and 1992. It was used by millions of ordinary people to build things they would not have called software. It did almost nothing of what Nelson had specified. It had no two-way links, no transclusion, no version permanence, no rights model, no global address space. Its addressing scheme was a single linked list of cards inside a single file. And yet it produced a culture of end-user authorship that has not existed on any major computing platform since, and it is the example that anyone who wants to argue that hypermedia “could have been popular” has to point to first. This chapter is about what HyperCard actually was, what it made possible, what its decline cost the broader culture, and why nothing on the web has replaced it.

What HyperCard was

HyperCard was introduced by Apple at MacWorld in August 1987, the work of a small team led by Bill Atkinson, the principal author of MacPaint and one of the original Mac engineers. Atkinson had built QuickDraw, the graphics layer of the Macintosh, and had been thinking, after MacPaint shipped in 1984, about what a programming environment for ordinary users would look like. HyperCard was his answer. It bundled, in one application, three things that had previously required three different applications and considerable expertise to combine: a way to draw on the screen, a way to store and retrieve structured information, and a way to write small programs that linked drawings, information, and user input into interactive sequences. The bundling was the breakthrough. Each of the three things had existed in other forms. Putting them together in a single, integrated, free-with-the-machine application meant that the technical floor for making something interactive collapsed.

The data model was four levels deep. A stack was a file, the thing you opened and worked in. A stack contained cards. A card was a screen-sized rectangle that the user saw at any given time. Each card contained fields, which held text the user could enter or read, and buttons, which could be clicked. Cards also had backgrounds, which were templates shared by multiple cards in the same stack — the equivalent of a master slide in a presentation program. The whole system was layered: a button on a card was on top of the field on the card was on top of the background. The screen showed all of them composited.

Navigation was, structurally, very simple. The cards in a stack were in an order. You could go forward to the next card, back to the previous one, or — and this is the part that mattered — to any specific card that some button or script told you to go to. A button could be scripted to take the reader to any card in any stack. That capability, plus the universal availability of HyperCard on every Macintosh, made the stack a portable, executable, interactive document.

HyperTalk

The scripting language was HyperTalk, designed by Dan Winkler. HyperTalk is the unsung breakthrough of HyperCard. It was an English-like language in which the typical statement reads almost as a sentence. A button might contain the script:

on mouseUp
  go to card "Index"
  put "Welcome" into field "Title"
end mouseUp

This is, in HyperTalk, a complete program. The verb-object syntax is consistent: you put things into fields, you get things out of them, you go to cards, you play sounds, you show and hide objects. The grammar is forgiving of variations. The vocabulary is small. The language has variables, conditionals, loops, and the ability to define your own commands and functions — it is a real programming language — but its surface looks like English instructions, and its error messages are mostly comprehensible to non-programmers.

Many languages have been advertised as English-like. Most are not. HyperTalk actually was. The reason it worked is that the language designers accepted a hard trade-off: they made the language verbose, where most languages are terse, and they restricted what could be expressed to what could be expressed in this verbose style. A skilled programmer writing HyperTalk produces code that is several times longer than the equivalent in a conventional language. The trade was worth it, for the audience the language was for, because the audience was not programmers in the conventional sense. The audience was elementary school teachers, museum docents, small-business owners, doctors, lawyers, librarians, and the millions of ordinary Mac users who had something specific they wanted to make and were not interested in learning C.

The cultural effect was that you could read other people’s HyperCard scripts. You could open someone else’s stack, click on a button, look at its script, and understand what it did, and modify it, and have your modification work. This was a recovery of the BASIC-program-listings tradition of the late 1970s, in which computer magazines published programs as code and readers typed them in and modified them. HyperCard restored that pattern for the Mac generation, with a tighter integration between code and the things the code manipulated. The script for a button lived on the button. The button lived on a card. The card lived in a stack. You could move them around and the relationships moved with them.

The author–reader continuum

The single most important property of HyperCard, for the argument of this book, was that there was no distinction between author and reader. The application was the same in both directions. If you could read a stack, you could open it, edit it, change its buttons, rewrite its scripts, save your changes, and share the modified stack with a friend. There was a single keyboard command — Command-Option-T, or pressing a “Tab” key after entering certain modes — that toggled between reading and editing. Most stacks shipped with editing enabled by default. The vocabulary of “user” and “developer” did not apply, because the user and the developer were the same person at different moments.

This is the property the web did not preserve. The web’s view-source feature, treated in chapter one, was a partial recovery: you could see how a page was made, you could copy its source, you could make your own version. But the web’s authoring and reading interfaces have always been different applications. To read the web, you use a browser. To write the web, you use a text editor, or a content management system, or a static site generator, or some platform’s authoring tool. The integration HyperCard had — the same tool, used by the same person, switching between reading and writing with a keystroke — is not what the web is. The closest the web has come is in-browser editing systems like Wikipedia’s, or wikis generally, or some collaborative document tools, all of which restore the property within their own walled gardens. None of them restore it for the platform as a whole.

The continuum mattered because of what it implied about who could participate. HyperCard’s user base was not a programming community. It included programmers, but it was dominated by teachers, doctors, lawyers, hobbyists, and tens of thousands of people who had bought a Mac for some other reason and discovered, by clicking around in the included stacks, that they could make things. The activation energy for making a HyperCard stack was orders of magnitude lower than the activation energy for writing a Mac application. The proof of the activation energy being low is the population of stacks that got made, by whom, and for what.

What got made

The published HyperCard culture of the late 1980s and early 1990s included substantial volumes of work in several distinct categories. A partial inventory:

Education: schools used HyperCard heavily, especially in the years when the Mac had a strong position in K–12 institutions. Teachers built stacks for classroom use: interactive vocabulary drills, geography tutorials, science simulations, reading exercises. The Apple Classroom of Tomorrow program funded the production of HyperCard educational stacks at several sites in the late 1980s. Roger Wagner’s HyperStudio, released in 1989, was a competing stack-based authoring tool oriented toward education and remained in use in schools well into the 2000s.

Reference works: many CD-ROM reference titles of the early 1990s were HyperCard stacks, sometimes with custom extensions. The Voyager Company, founded by Robert Stein in 1984 and producing CD-ROMs from the early 1990s, used HyperCard as the substrate for its Expanded Books series and several of its multimedia titles. The interactive guide to the Beatles’ Hard Day’s Night, the multimedia Macbeth and Hamlet, and several other Voyager titles were HyperCard at the bottom.

Games: HyperCard was the original platform for Myst. Cyan, the studio run by brothers Rand and Robyn Miller, had previously made The Manhole (1988), Cosmic Osmo (1989), and Spelunx (1991) in HyperCard. Myst, released in 1993, was a HyperCard stack with QuickTime video and Sound Manager audio, and it became the best-selling computer game of the 1990s. The fact that the bestselling PC game of its decade had been built by two brothers in a small studio using HyperCard is not a detail. It is a statement about what the platform made possible.

Personal information management: thousands of small stacks were written by individual users to manage their own data — address books, recipe collections, bibliographies, customer databases for one-person businesses, lab notebooks for scientists who needed something specific. The shareware market for HyperCard stacks, on AppleNet and the BBS systems of the era, was substantial. Most of these stacks were not significant artifacts. They were significant in aggregate: they represented a culture in which ordinary computer users built ordinary tools for themselves and shared them with their friends.

Art and literature: the literary hypertext community, treated in chapter eight, used HyperCard for several of its early works. The art-software tradition produced a stream of HyperCard pieces, including some that were exhibited and published as art objects. The Voyager Expanded Books series included annotated literary editions in HyperCard format. The cultural respectability HyperCard achieved in these milieus was real; it was not a toy.

This is not the population that ships software for the web today. Web applications are built by professional developers in development organizations, with build systems and frameworks and deployment pipelines. The dollar-figure economics of web development make it hard for a doctor or a teacher to build a small thing for their practice or their classroom and share it. They can, in principle. They mostly do not, in practice, because the floor is too high. HyperCard’s floor was on the ground.

The decline

HyperCard’s commercial story is not a happy one and the responsibility is mostly Apple’s. The application shipped, free, with every Mac through System 6. When Apple needed to consolidate its software business in 1990 and 1991, it moved HyperCard to Claris, its software subsidiary, which began charging for it. The free version that shipped with new Macs was reduced to a “player” that could read stacks but not author them. A separately purchased version was required for the authoring tools. The price was modest by software-industry standards — $50 to $200 depending on version and bundle — but the effect was catastrophic. The continuum between reading and writing was broken. A user who got a Mac in 1992 could read stacks but could not modify them. The activation energy that had been on the ground was now several dollars and a separate purchase decision away.

The strategic reasoning at Apple was that HyperCard cannibalized other Apple software businesses, particularly tools like AppleWorks and the database products that Claris was trying to sell. The reasoning was wrong in retrospect, and probably should have been recognizable as wrong at the time. HyperCard was not a competing product to the database tools; it was a platform on top of which entirely different categories of work were being done, and pricing it out of universal availability did not transfer demand to AppleWorks. It just stopped the demand.

The 1990s saw the cumulative effect of this decision. The HyperCard userbase aged and was not replaced by a new generation of HyperCard users, because new Mac owners no longer had HyperCard. The competing products — SuperCard, MetaCard, the various successors that became Revolution and then LiveCode — survived but never reached the install base HyperCard had had. The web arrived in this period, and a generation of people who would have made HyperCard stacks in 1990 made web pages in 1995. The web, for all its limitations, was where the action was. HyperCard authoring continued to exist in a smaller and more devoted community through the 1990s and 2000s. Apple formally discontinued HyperCard in March 2004.

What was specifically lost

The web inherited some of HyperCard. HTML’s link element is a direct descendant of HyperCard’s button-with-go-to-card script, though without the integration with the rest of a stack’s machinery. JavaScript inherited some of the impulse that produced HyperTalk, though it inherited very little of the readability. Browser-based applications descend, in part, from the HyperCard demonstration that a single tool could host both content and behavior. The web did not start in the same place as HyperCard but several of its later developments rhyme with what HyperCard had been doing.

What the web did not inherit was the cultural pattern. The unified read-and-write tool, available to every user on every machine, with a forgiving language that allowed non-programmers to make working things — that was HyperCard’s specific contribution, and the web has never reproduced it. The closest replacements have been the various tools that revive the pattern in narrow domains: spreadsheets (which are HyperCard-in-table-form for tabular data), Scratch (which is HyperTalk-by-blocks for kids learning programming), HyperCard-revival projects (LiveCode, Decker, HyperCard.js, various others) that have small communities and no mass audience. The audience that HyperCard had — ordinary Mac users, by the millions, making things — has scattered.

It is sometimes argued that this audience reformed itself on the web. There is something to this argument. The blogging tools of the early 2000s, the wiki communities, the MySpace HTML profile customization era — these were genuine returns to mass authorship. So were the modding communities, the YouTube video production explosion, the iOS Shortcuts ecosystem that gives ordinary iPhone users a Hypertalk-like environment for automation. The pattern reappears in pieces. It does not reappear as a single integrated environment that ships with every machine and is the default place to make something.

The other thing the web did not inherit from HyperCard is the local quality of the artifact. A HyperCard stack was a file. You owned it. You could copy it to a floppy disk, hand it to a friend, store it on your own machine for thirty years and still open it. The stack belonged to the maker in the strong sense that the maker’s data was on their disk. Web applications produce no such artifact for the user. The user’s contribution to a web application is, in almost every case, content held on someone else’s server, accessible only through that server, with no local copy in any meaningful sense and no portability if the server goes away. The recovery of local-first software, treated in chapter twenty-one, is in significant part a recovery of what HyperCard had been doing as a matter of course: the artifact lives where the maker is.

The case HyperCard makes

HyperCard’s lesson is not that hypermedia could have been popular in the abstract. Hypermedia was popular, on one platform, for about five years, and the popularity ended when the platform stopped distributing it for free. The lesson is that the floor matters more than the ceiling. The hypermedia systems that were technically more ambitious — Intermedia, NoteCards, the academic systems treated in the next chapters — never escaped their institutional contexts because their floors were too high. The floor was an expensive workstation, a piece of software you had to be at a research university to use, a learning curve measured in months. HyperCard’s floor was opening an application that was already on the Mac you already owned.

The system Nelson described, and the systems the academic hypermedia community built, would have produced more powerful tools than HyperCard if they had reached HyperCard’s audience. They did not reach that audience. HyperCard did. The cost of HyperCard’s accessibility was that it was much less than what hypermedia could have been; the benefit was that millions of people used it. The web later chose a similar trade-off, on a much larger scale, and for some of the same reasons. The web at its launch was also less than what hypermedia could have been, and millions of people used it.

The difference is that HyperCard’s millions made things, and the web’s billions, with some real exceptions, mostly consume things. The activation energy on the web for making, as opposed to reading, is again high. It is not as high as it was for academic hypermedia systems, but it is much higher than it was on the Mac with HyperCard. The chapter twenty-four on Roam and Obsidian and Logseq, and the chapter twenty on Bret Victor and the dynamic document tradition, treat some of the recoveries. None of them have yet reproduced HyperCard’s particular combination of being on every machine, being the same tool for reading and writing, and being readable in its source by the people using it.

The next chapter goes back further than HyperCard, to the system that was, in a sense, what HyperCard would have been if Atkinson had been Douglas Engelbart and the Mac had been a 1968 SRI workstation. NLS was earlier, more ambitious, less successful, and almost entirely forgotten outside of the small group of people who care about this history. It is the system most computing professionals know one thing about — that it introduced the mouse — and almost nothing else, and the gap between that one thing and what NLS actually was is the size of the field.