On August 11, 1987, Apple genius Bill Atkinson — and this was before every kid in a clean shirt was a candidate for Apple Genius — held a press conference at MacWorld to unveil HyperCard. I was there.

I watched Atkinson’s presentation as a PR/marketing guy at a software company, and as an early user of the initial Mac (although my personal machines were CP/M, MS-DOS, and then Windows). As a PR guy, I was awestruck by the skill of the presentation. I remember Atkinson dynamically resizing a bit-mapped graphic and casually mentioning that figuring out on the fly which bits to keep and which to throw out was no small feat. And at the other end of the scale, the range of apps — each beautifully designed, of course — was fantastic.

HyperCard was pitched as a way to hyperlink together a series of graphic cards or screens. The cards had the sort of detail that bitmapped graphics afforded, and that Apple knew how to deliver. Because the cards were bitmapped, they tended to highlight their uniqueness, like the pages of a highly designed magazine, or etchings in a gallery.

Atkinson also pitched HyperCard as a development environment that made some hard things easy. That part of the pitch left me unconvinced. Atkinson emphasized the object-orientation of HyperTalk — I remember him talking about message-passing and inheritance — but it seemed to me as a listener that building a HyperStack (as HyperCard apps were called) was going to be beyond typical end users. (I created a Stack for my company a few months later, with some basic interactivity. Fun.)

Apple killed off HyperCard in 2004, but it remains more than a fond memory to many of us. In fact, some — including Bill Atkinson — have noted how close it was to being a browser before there was a Web. A couple of months ago, Matthew Lasar at Ars Technica wrote:

In an angst-filled 2002 interview, Bill Atkinson confessed to his Big Mistake. If only he had figured out that stacks could be linked through cyberspace, and not just installed on a particular desktop, things would have been different.

“I missed the mark with HyperCard,” Atkinson lamented. “I grew up in a box-centric culture at Apple. If I’d grown up in a network-centric culture, like Sun, HyperCard might have been the first Web browser. My blind spot at Apple prevented me from making HyperCard the first Web browser.”

First of all, we should all give Bill A a big group hug. HyperCard was an awesome act of imagination. Thank you!

But I don’t quite see HyperCard as the precursor to the Web. I think instead it anticipated something later.

HyperCard + network = Awesome, but HyperCard + network != Web browser. The genius of Tim Berners-Lee was not that he built a browser that made the Internet far more usable. TBL’s real genius was that he wrote protocols and standards by which hyperlinked information could be displayed and shared. The HTML standard itself was at best serviceable; it was a specification using an already-existing standard, SGML, that let you specify the elements and structure of particular document types.. TBL went against the trend by making an SGML specification that was so simple that it was derided by the SGML cowboys. That was very smart. Wise, even. But we have the Web today because TBL didn’t start by inventing a browser. He instead said that if you want to have some text be hyperlinked, surround it with a particular mark-up (“<a href= ‘http://pathname.com/page.html’></a>”). And, if you want to write a browser, make sure that it knows how to interpret that markup (and support the protocols). The Web took off because it wasn’t an application, but a specification for how applications could share hyperlinked information. Anyone who wanted to could write applications for displaying hyperlinked documents. And people did

There’s another way HyperCard was not Web minus Network. The Web works off of a word-processing metaphor. HyperCard works off of a page-layout/graphics metaphor. HTML as first written gave authors precious little control over the presentation of the contents: the browser decided where the line endings were, how to wrap text around graphics, and what a first level heading would look like compared to a second level heading. Over time, HTML (especially with CSS) has afforded authors a much higher degree of control over presentation, but the architecture of the Web still reflects the profound split between content and layout. This is how word-processors work, and it’s how SGML worked. HyperCard, on the other hand, comes out of a bitmapped graphics mentality in which the creator gets pinpoint control over the placement of every dot. You can get stunningly beautiful cards this way, but the Web has gained some tremendous advantages because it went the other way.

Let me be clearer. In the old days, WordPerfect was unstructured and Microsoft Word was structured. With WordPerfect, to make a line of text into a subhead you’d insert a marker telling WordPerfect to begin putting the text into boldface, and another marker telling it to stop. You might put in other markers telling it to put the same run of text into a larger font and to underline it. With Word, you’d make a line into a subhead by putting your text caret into it and selecting “subhead” from a pick list. If you wanted to turn all the subheads red, you’d edit the properties of “subhead” and Word would apply the change to everything marked as a subhead. HTML is like Word, not WordPerfect. From this basic decision, HTML has gained tremendous advantages:

• The structure of pages is important semantic information. A Web with structured pages is smarter than one with bitmaps.

• Separating content from layout enables the dynamic re-laying out that has become increasingly important as we view pages on more types of devices. If you disagree, tell me how much fun it is to read a full-page pdf on your mobile phone.

• Structured documents enable many of the benefits of object orientation: Define it once and have all instances update; attach methods to these structures, enable inheritance, etc.

(It’s disappointing to me that Google Docs document programming environment doesn’t take advantage of this. The last time I looked, you can’t attach methods to objects. It’s WordPerfect all over again.)

I should mention that the software company I worked at, Interleaf, created electronic documents that separated content from presentation (with SGML as its model), that treated document elements as objects, and that enabled them to be extended with event-aware methods. These documents worked together over local area networks. So, I think there’s a case to be made that Interleaf’s “active documents” were actually closer to presaging the Web than HyperCard was, although Interleaf made the same mistake of writing an app — and an expensive, proprietary one to boot — rather than a specification. It was great technology, but the act of genius that gave us the Web was about the power of specifications and an architecture independent of the technology that implements it.

HyperCard was a groundbreaking, beautiful, and even thrilling app. Ahead of its time for sure. But the time it was ahead of seems to me to be not so much the Age of the Web as the Age of the App. I don’t know why there isn’t now an app development environment that gives us what HyperCard did. Apparently HyperCard is still ahead of its time.

[A few minutes later] Someone’s pointed me to Infinite Canvas as a sort of HyperCard for iPhone…

[An hour later:] A friend suggests using the hashtag #HyperCard25th.

Categories: infohistory dw