Hide full article
As a long-time user of Apple's HyperCard, I had never given SuperCard a glance. HyperCard, when it was free, had been my reason for first buying a Macintosh; with it, I've written language-lab courseware and distributed stacks on the net, and I still reach for it to contrive spontaneous solutions when information storage or task automation beckons. It's easy: you draw buttons for clicking, and fields to hold text, arrange them on "cards" (sets of window contents), and endow it all with functionality through HyperTalk, an English-like, powerful, mildly object-oriented, dynamic scripting language. Presto, you've put up a Mac-like interface to a homemade program.
My HyperCard loyalty verges on fanaticism; a once-again free HyperCard figures heavily in my secret, mad strategy to save the Mac. Nevertheless after HyperCard's explosive development between 1987 and 1991, it languished and nearly died at version 2.1. True, in early 1994, version 2.2 appeared, a major upgrade that greatly heartened users, including me. But progress since then, although we're now at version 2.3.5, has been all but insignificant. HyperCard 3, Apple's planned port to QuickTime, seems an intriguing but as-yet distant dream.
SuperCard, meanwhile, I knew of only by hearsay, as a "HyperCard wannabe." Then I saw SuperCard demonstrated at Macworld Expo in January and wondered: what if, after all, this was HyperCard done right?
SuperCard was created by Silicon Beach Software, eventually acquired by Aldus. Allegiant Technologies, Inc., then broke away from Aldus to take over SuperCard's development. That was at the end of 1993; thus, exactly while HyperCard has seemed most moribund, SuperCard has most vigorously evolved. SuperCard 3.0, a major upgrade, was unveiled just this past December. [A 3.0.1 updater that improves performance is available via the Allegiant Web site. -Adam]
<http://www.allegiant.com/>
Objects All Sublime -- SuperCard rethinks and extends the HyperCard battery of objects. The top of HyperCard's hierarchy is the stack; changing windows means changing stacks, unless you use an XCMD to put up an "external" window. SuperCard starts with the "project"; one project can open another, but it can also contain multiple windows, and each window, though in effect a HyperCard stack, can be of any standard type, including dialogs and floating palettes.
Menus are similarly well integrated. A project can contain multiple menu sets, each containing menus which contain menu items. Both menus and menu items are full-fledged objects, both containing scripts and receiving messages.
Like a HyperCard stack, a SuperCard window has backgrounds and cards, and these can contain buttons and fields. But they can also contain graphics; these too contain scripts and receive mouse-event messages, just like a button. A graphic can be a bitmapped rectangular region, or it can be vector-based, thus taking up little memory and adopting any standard shape (rectangle, oval, arc, roundrect, polygon, or freehand). Since buttons themselves can be polygons, too, it's no wonder that "Anything can be a button" was once a SuperCard motto.
The SuperTalk language is mostly a superset of HyperTalk, extending it in clever and desirable ways. Some telling examples: there's a "case" control structure; besides the string offset function, there's the lineOffset that tells you in what line of one string another is found; the "describe" function makes lists of similar features, such as all the buttons of this background; the textHeightSum tells you the pixel height of all text in a field as currently wrapped; you can set not just the itemDelimiter but the wordDelimiter and the lineDelimiter as well. The message-passing hierarchy beats HyperCard's too, especially when HyperCard's "start using" feature is generalized to allow insertion of scripts from any object at either the bottom or the top of the hierarchy.
In just one respect, I feel, SuperCard's structure falls short. Imagine a stack (project) of to-do items: every card contains a field describing the item, plus a checkbox to show if the item is completed. Since these elements are common to all cards, they should be background items; but SuperCard background buttons cannot have different highlighting on each card (checkbox checking is considered highlighting). The same problem vitiates one of SuperCard's most brilliant innovations: user properties. You can define and manipulate custom properties for any object, thus associating information directly with the object to which it pertains; yet a background object cannot have different values for its user properties on different cards. To me, that undermines the value of background objects.
The Multimedia Is the Message -- In line with its image as a multimedia tool comparable to Macromedia Director, SuperCard integrates many features to dazzle and entertain the end-user. Of these, the most welcome to HyperCarders is surely color, which is fully built in. Vector graphics, fields, and buttons can have colored and patterned frame and fill. In fields, a character style can involve color. Buttons can have color icons (but not, curiously, colored text). Vector graphics can contain colored text, or a picture image (importable from various popular formats). Overlapping colors can interact in complex ways via many transparency, blending, and addition effects. Custom color tables and import of 16-bit and 24-bit bitmaps allow top-quality images.
Powerful movie commands let you manipulate QuickTime to your heart's content, and if that isn't enough you can play PICS animations and PICT "filmstrips" - plus, objects can be made to move along paths, and change their pictures or icons. Sounds can be played either from resources or from AIFF/AIFC files, and you can access text-to-speech through the Speech Manager. Since these effects are available asynchronously, your project can easily become a riot of activity and sound.
Edit for Your Life -- The SuperCard environment is not fully dynamic; you are either running a project as an end-user, or you are editing it to add, remove, and alter objects, with system messages suppressed. The two states do overlap somewhat: in run mode you can still edit scripts, and in edit mode you can still send messages via the message box. Nevertheless, the dichotomy seems unfamiliar and awkward to a HyperCard user (and the transition between the two modes is rather tedious on my 68K machine).
Editing uses the new Project Editor, a set of windows, floating palettes, and menus which themselves are a SuperCard project, an astonishing demonstration of SuperCard's power (and a commendable example of the toolmakers relying on their own tool, a practice which invariably improves the tool). The Project Editor supersedes SuperCard's earlier editing environment, called SuperEdit - which is still included (because not all its functions could be emulated by the Project Editor), even though it has not been upgraded for SuperCard's new entities.
The result is a hybrid. Only SuperEdit can edit cursors, icons, color tables, and bitmaps in close-up ("fatbits"); only SuperEdit lets you shape polygon buttons via auto-tracing, or replace a card's background without affecting its card layer. But it ignores color icons, and can't import PICT resources into graphics. In general, you're expected to work in Project Editor and quit out to SuperEdit only when necessary. It's disconcerting.
The good news is that many of the Project Editor tools are just what HyperCarders are starved for. The Property Inspector palette lists and lets you select every object of the current card or background, then shows and lets you set the selected object's name, position, size, and major properties. The Project Browser lets you list, select, create, and delete windows, cards, backgrounds, and menus - plus it includes a resource copier. There are palettes for object color and object text. Object editing includes the ability to align, scale, and rotate objects, lock them to prevent accidents, and even group them into new compound objects. A fine Search feature lets you look for text in names, scripts, or contents, and restrict your search to various object subsets, obtaining a clickable list of objects and scripts.
Best of all is the message box - why on earth didn't HyperCard do it this way? The SuperCard message box has two parts, one for your command, the other for SuperCard's response (whereas HyperCard's response overwrites your command). The response area can be enlarged and scrolled so you can see a whole multi-line response, and your commands are saved into a history pane for later repetition. But why didn't Allegiant go all the way and let the command area be multi-lined too, so that you could type and run a utility script from it? Instead, you have to create a handler in some object's script and then call it, as in HyperCard.
Script editing takes place in a modal dialog box that covers the screen and can't be resized (unless you're in SuperEdit). I find this unpleasant and astonishingly primitive; while editing a script, one needs to investigate objects and consult other scripts.
What's Up, Docs? The manuals are not at all bad, considering the size of the subject. There are quite a number of misprints, including occasional howlers where a crucial sentence asserts exactly the opposite of the truth. There's also a certain amount of repetition; the manuals are a bit out of synch with what's actually shipped, and some of the coolest new features are omitted. But much effort has evidently gone into making the manuals both compendious and instructive, and it has paid off.
Letting Go -- SuperCard projects can be released in three forms. The project itself can be given to someone who has SuperCard or the free SuperCard Player. Or, the project may be built into a stand-alone application. Or, the project (provided it has but one window, and subject to many other restrictions) may be played over the Internet through a Web browser using the free Roadster Web browser plug-in.
I tried to convert a project into a stand-alone and found the process harrowing. My main difficulty turned out to be SuperCard's handling of color icons from its SharedFile library. These need to be transferred into the project, but if you set up the Standalone Maker utility to do this automatically it changes the icons' ID numbers and the project can no longer see them. So you have to find all color icons manually and move them into the project, then change every button that uses them to see its newly renumbered icon. This took a couple of hours, and the interface was buggy and crude. At the end of the process the Standalone Maker quit with an unexplained error and I never got my stand-alone. I did learn that a stand-alone aimed at 68K machines adds nearly 1 MB to the size of the project, much more than the 540K claimed by the manuals.
I didn't have the wherewithal to test the Roadster distribution method properly for this review. It's intriguing, though, and the manual outlines numerous techniques for loading data so the project will start running on the user's machine before all the resources and data have downloaded (and even how to behave if particular data or media is not yet available). Acceptance is the real problem - whether people will download a 1 MB browser plug-in just to view your project, especially with so many other plug-ins, plus Java, clamoring for attention.
SuperCard won't replace HyperCard in my personal software arsenal, because to me they aren't in the same category. To throw together a solution for personal use, HyperCard will always get the nod: it's faster, smaller, and far more convenient. And even though Allegiant touts HyperCard compatibility, few of my existing HyperCard stacks could be effectively ported to SuperCard, because they each rely on HyperCard features that SuperCard lacks: its ability to print reports and fields; its full scriptability (and its capacity to run OSA scripts internally); its use of fields for list-selection (SuperCard has list-selection fields but you can't style individual chunks of text in them); its far better sorting; its Boolean card-marking; and (as already mentioned) its use of non-shared background button highlighting. I believe that these shortcomings could mostly be worked around or made up for by XCMDs (not all of them free), but it's interesting that the focus of my HyperCard stacks is so exactly SuperCard's missing features.
Nonetheless, to build and distribute stand-alone applications that don't need any of these features (since presumably my issues with Standalone Maker can be ironed out), SuperCard ought to be ideal. Its rational design shows up HyperCard for the quirky, misshapenly grown plant that it is. Its extended HyperCard-like metaphor is a powerful, easy, and flexible way to make an interactive application, and its integrated color and other multimedia effects ensure high presentation value. I do think the price tag (at about $330) is somewhat high, though the academic version comes in at a more reasonable $129, with site license options. If you know a current SuperCard user, that user may have received a mailing enabling them to share with you Allegiant's recent $149.95 "SuperCard for a Friend" offer. Still, SuperCard 3.0 is a major upgrade of a product that deserves to attract serious attention; perhaps it will get it despite the price.
DealBITS -- Cyberian Outpost is offering SuperCard to TidBITS readers for $317.95 ($10 off Cyberian Outpost's regular price) through this URL:
<http://www.tidbits.com/products/super-card.html>
Allegiant Technologies, Inc. -- 800/255-8258 -- 619/587-0500
619/587-1314 (fax) -- <info@allegiant.com>
