Examining "HyperCard on the Macintosh"

For my latest post on the Stone Tools blog I took on a big title, HyperCard. Since posting I’ve had many fond memories shared with me as people recall the empowerment this program brought to the table.

I spent a bunch of time (re?)learning it, building stacks, and getting to know the ins-and-outs. I also spent a little time thinking about efforts to make English itself into a programming language.

There have been many attempts to keep the HyperCard dream alive over the years, but the original still has some special “je ne sais quai” that keeps people enchanted decades later. I hope the community enjoys the post!

7 Likes

HyperPad was a HyperCard clone for MS-DOS.

2 Likes

I strongly suspect HyperPad will be a future article.

3 Likes

Thanks for the really great post! I really enjoyed it and brought back memories when I first played with HyperCard (on a Mac Plus, IIRC). I did some programming before but HyperCard blew me away :slight_smile:

2 Likes

It’s worth noting that “Myst” the hit puzzle game from 1993 was authored using HyperCard. They later ported the game to other platforms, which must have been a PITA by comparison. Another way of framing this is that the Mac version was the deliverable prototype, and the ports had to be coded.

2 Likes

In the article I did mention both the fact that Cyan started as a HyperCard shop (with The Manhole) and later specifically call out that Myst was created with it. Agreed about the PITA in porting it to other systems, but the slideshow nature of the presentation (plus QuickTime on Windows had released) I’m sure simplified the task at least a little.

1 Like

I didn’t know what Hypercard was for a long time. I heard about it, and watched a few demos, but I had a hard time making sense of it. It looked like some graphical thing that you could program, but I didn’t understand how people were doing it. I finally watched some videos re. it recently, and it clicked. It seemed like a combo of a paint program with links, and the HyperTalk programming language for scripting.

I also didn’t understand how I’d “missed” it, because I’d used Macs for a few years before I started hearing about it. I didn’t understand that it wasn’t released with the first Macs. It came out in 1987. I saw Hypercard stacks around on Mac disks, but had no idea how to use it. I went off to college after that, and never touched it.

What threw me off for the longest time was the term “card stack.”. I got an image of index cards, or playing cards. It didn’t make sense to me in relation to what I saw at the time.

Another thing that threw me off was it had built-in database functionality. I’d sometimes see people use what looked like Rolodex cards with it. You could set up fields on it, enter text, and use a search function to look up records. This didn’t jive with the graphics demos I was seeing, but I later learned this database functionality was put into Hypercard, because the designer thought it would be a common use case.

Now I understand each “card” is like a separate screen. You can relate it to webpages. What the web calls a page, Hypercard called a “card.” The point being you could link cards together, and “card stacks” were complete packages of linked cards, stored together as one file; making it like an “app” you could bring up.

I think what continues the appeal of Hypercard; why people like myself still look back at it, is it brought together the ideas of multimedia with linking, something the web has always struggled to do as easily, since it was designed around word processing/document metaphors.

3 Likes

Another analogy would be a PowerPoint presentation, where each slide is equivalent to a Hypercard card. You can put something on a given slide or you can put it on the master slide and then it shows up on all slides. While in PowerPoint you normally only go to the next or previous slide in Hypercard the navigation is more flexible.

3 Likes

Yes, it’s of course easy these days to find all kinds of analogies to HyperCard’s way of organizing information. Not so easy for Apple when HyperCard first launched and didn’t have those common reference points to relate to. Their marketing (and I use the term loosely here) was fairly obtuse in getting the point of the software across.

“Something something ideas! Something something associations!
“Here’s a drawing of a lobster and a birthday cake. Now do you get it?”

2 Likes

Index cards have been an explicit design metaphor of early hypertext systems, see for example this frame of a 1985 Xerox PARC videotape about the NoteCards hypermedia system.

3 Likes

A frame showing a demonstration of index cards from another 1985 PARC videotape on NoteCards:

3 Likes

HyperCard may have “completely transformed [Douglas Adams’s] working life”, but perhaps not in a good way. This is what the author who put the “pro” in procrastination had to say about developing in HyperCard:

I’ve just spent a cheerful hour of my time writing a program on my computer that will tell me instantly what the volume of the mound was. It’s a very neat and sexy program with all sorts of pop-up menus and things, and the advantage of doing it the way I have is that on any future occasion on which I need to know the volume of a megapode nest, given its basic dimensions, my computer will give me the answer in less than a second, which is a wonderful saving of time. The downside, I suppose, is that I cannot conceive of any future occasion that I am likely to need to know the volume of a megapode nest, but no matter: the volume of this mound is a little over nine cubic yards. […]

So all the megapode has to do to incubate its eggs is to dig three cubic yards of earth out of the ground, fill it with three cubic yards of rotting vegetation, collect a further six cubic yards of vegetation, build it into a mound, and then continually monitor the heat it is producing and run about adding bits or taking bits away.

And thus it saves itself all the bother of sitting on its eggs from time to time.

— from Last Chance to See by Douglas Adams and Mark Carwardine.

Thankfully, Douglas’s work has been preserved here: HyperCard Stack: Douglas Adams’ Megapode Nest Volume Calculator for all those embarrassing situations when you have to calculate the volume of a brushturkey nest in polite company. I know it’s saved my bacon NaN times.

2 Likes

Speaking for myself, I find value in building things like that in service of a larger creative piece. I do the exact same thing, going off on little side projects that are conceptually parallel to the larger piece. I find it helps immerse myself in the topic further, taking me into deeper introspection and mastery. Even if that side project is never shown to the public, building it helped me get closer to the truth of my subject and that can ultimately make the public work more “authentic.” (YMMV)

1 Like

Hmm, so HyperTalk didn’t have any syntax error messages. That would’ve been a frustrating experience, since you’d get no answer to “Why doesn’t it run,” except, I guess, if you looked in the manual.

The historical note about HyperCard being the first instance of “no code” was very nice.

I learned some years ago that AppleScript was based on HyperTalk. I’ve enjoyed working with AppleScript, where applicable. I’ve wished it was able to exert more power over its environment, though. Apple has relegated it to doing simple tasks. I’ve also found it’s a bit buggy. This goes for its workflow cousin, Automator, as well. I don’t know what it is, but there are times when you know that a set of commands should work, because you’ve seen them work, but there are cases, in a slightly different context, where they don’t, and there’s no way to tell why. In those cases, I’ve cast about for alternative ways of doing things with it that end up being more reliable. They may look messy, but they don’t “bug out,” for some reason.

Both AppleScript and Automator can have concurrency issues, where the scripting runtime and the application you’re trying to automate get out of sync with each other. The runtime sends it messages, which get dropped by the application, and the job only gets partially done. It’s frustrating that neither of these tools offer a way to correct that, other than to suggest, “Don’t do that.”

Unfortunately, AppleScript looks to have fallen out of use by Mac users. There’s been some talk of taking it out, for lack of application support. The explanation has been that people have just found it easier to find an application to do what they would’ve tried to do with AS. There’s truth to that, but I still find uses for it. I think a major reason for that is AS was not made as powerful as it could be. Plus, its occasional bugginess is frustrating. Part or all of the problem may be bugs in applications themselves. It’s hard to tell.

2 Likes

I think that’s me - I played just a little with AREXX on my Amiga, I’m happy to write and use shell scripts on Linux, but I’ve never even tried to use Applescript. (I can of course use shell scripts.)

1 Like

Having cut my teeth on AppleScript, I check out the state of things from time to time even today. I was first surprised to see it still exists, though it seems like AppleScriptObjC has kind of taken over the heavy duty parts.

The other thing I found was how few 3rd party apps allow themselves to be AppleScriptable. There are things that can still be done simply by nature of being macOS apps, but building in real AppleScript support is a time consuming process, I understand, and it seems many developers don’t see any reason to do so.

Personally, I never encountered the concurrency issues you mentioned. What would happen is that sometimes a portion of a script would require something like a window to be at a very specific position on screen so that a button click could be automated. Stuff like that was fragile, for sure. The feeling of watching a series of unrelated applications churn through a complicated workflow automatically was fantastic though.

At that job, we specifically would have FileMaker Pro automate report generation, InDesign layout creation (to match a template), photo import (from photo studio job requests), and batch printing to our PostScript RIP. I don’t know what the state of the Adobe Suite and AppleScript is like these days, but Affinity Suite doesn’t have any scripting support (it’s supposedly coming this year). The feeling that the industry has taken a slide backward is real.

1 Like

Re. the concurrency problem - I’ve seen it with Photos and Automator, and AppleScript and the QuickTime player. I’ve since gotten rid of these attempts, because they didn’t work, but what I remember was I created a Quick Action in Automator, using AppleScript inside it, that I could access from a context menu (right-click), so that I could select a series of jpegs in Finder, right-click, and add them to Photos. This worked if Photos was already up and running, but if it wasn’t, it took a bit for Photos to start up. Maybe I’d picked 10 photos to add. Only something like 3 would make it.

Automator has a specific widget for importing images into Photos, but it only works while Automator is running. It doesn’t take input from another widget in the workflow. You have to copy and paste the list of images you want to add into the Photos-importing widget (easy enough to do with copy/paste from Finder), and then run the workflow (laborious), and what I remember is it operates cognizant of this problem. The widget makes sure Photos is up and running, and then does the import, so everything works reliably. With what I tried with Automator/AppleScript, I tried putting in delays so that it would wait until Photos was up before doing the import, but Photos didn’t always take the same amount of time to come up. So, images were still getting dropped.

I eventually found it was more reliable to just select the images, and drag them to the Photos icon in the Dock. That always worked.

The problem with QuickTime player was annoying, because AppleScript seemed to make it easy to do things with QuickTime, since it had commands for talking directly to it. I was trying to bring up QT, and access its menu items to configure it the way I wanted. Sometimes that worked, but sometimes it didn’t. Again, it seemed to depend on whether I had QuickTime up and running or not, before running the script. I realized there were a couple ways to do this. One was “tell”-ing QuickTime directly to do them. The other way was to access menus indirectly, I think using SystemEvents, which works through Finder, as I recall. This turned out to be reliable; never had a problem with it, but the code is messy.

The most sophisticated thing I’ve done with AppleScript was to make the equivalent of something like Alfred. I wanted a way to type a query into a search bar for specific web apps. without bringing up the website, waiting for it to load, and typing it into its search bar. So, I had a menu I’d either hardcoded or configured through a resource file that the script would load (I forget), and display in a selection box, containing the different web apps it supported. I’d pick one, then it would bring up a text box allowing me to type my query. Based on the app I picked, it would format a URL for that app, and send it through my default web browser, which would show the result in a new tab. I was pretty happy with it. Then I found out about Alfred, and have been using that, instead. :slight_smile:

2 Likes

That rings a bell. I do recall we would sometimes have to put a delay after activating the app, to make up for launch times. AppleScript is no different than doing things by hand, and we can’t use an app until it’s fully launched either way.

I seem to recall there being a way to use “System Events” to monitor app state and wait in a loop until the app was visible or something like that. It’s been a long time and my memory is fuzzy. I’m going to look at classic Mac apps again later this year. I might spend a little time with AppleScript and see what I can find then, although System 7 scripting is quite a bit more rough than OS X 10.2, 3, 4, 5 were.

1 Like

Re. “visible”

Hmm. I’ll have to look into that. I thought I remember looking up how to make AS wait for the app. to start up, and the best I could find was telling it to wait some amount of time.

The two commands I learned for directly accessing an app have been “activate” and “tell.” I recently learned about doing similar things with SystemEvents. It just feels disappointing that this sort of logic wasn’t already programmed into AS. If you’re going to “tell” an app. to do something, the runtime should be sure that the message is going to be received, rather than taking a “fire and forget” approach. That’s not very user-friendly.

1 Like

I have found Decker to be a fun Hypercard-inspired modern app & scripting environment. It borrows heavily from the System 7 look and doesn’t try to be a Hypercard clone, but clearly takes a lot from it. It’s actively developed and the programming language, Lil, is multi-paradigm and powerful.

5 Likes