CLS Museum: Phoenix

The Phoenix alternative development environment (ADE) was designed to sit atop the standard HyperCard interface. HyperCard was used to develop stacks as it had been, but the Phoenix environment provided new features to speed development efforts, include useful new and replacement palettes, windows, dialogs, style sheets, and contextual menus. Phoenix was designed from the ground up to:

* Allow for easy access to both standard and improved HyperCard features
* Provide an intuitive interface for stack development
* Adhere more closely to the Human Interface Guidelines, improving HyperCard ease-of-use
* Allow developers to selectively which Phoenix features they use

Palettes

The included palettes were a big improvement over HyperCard’s standard UI. Phoenix palettes could be set via preferences to always open at a specific spot or remember their positions from session to session. The palettes could be set to automatically open at launch time. Several palettes had both tall and wide versions available, to best match the user’s preference.

One troublesome violation of the Apple Human Interface Guidelines was that HyperCard often invoked modal dialog boxes to adjust properties. The Inspector palette eliminated this problem. Developers could use a contextual menu selection to set any object as the Inspector focus, or objects could be selected in the palette itself via a list (which could be hidden to conserve screen real estate). The Inspector palette changed based on the type of object selected; configurations for buttons, fields, cards, backgrounds, stacks, and HyperCard global properties were all available.

Other palettes included:

The Development palette provided the same functions as the standard HyperCard Tools palette, plus object manager buttons (which allowed creation of objects using style sheets and quick access to their scripts), as well as one click access to stacks-in-use and function keys managers.

The alternative Navigator palette provided standard HyperCard features, plus direct access to specific cards, backgrounds, favorite stacks, and Internet resources.

The LinkManager palette created hyperlinks in text fields to HyperCard stacks or cards, Internet resources, QuickTime files, or executed HyperTalk handlers or commands. Developers could also install the resources necessary to make their stacks (and its hyperlinks) independent of the alternative development environment.

The MediaManager palette provided single click access to the clipboard, as well as text and image file import and export. Other buttons allowed HyperCard to quickly speak a text field (using Apple’s Text-to-Speech software) and open QuickTime supported media files (including movies, pictures, and music in a variety of formats).

The TextStyle palette allowed for quick application of text styles to field or button text. It was a real improvement over the non-standard text style dialog box.

Other Windows and Dialogs

The environment included several windows and dialogs that extended or improved HyperCard’s functionality, many used by the Phoenix interface but also available to developers for use in their own stacks with simple handler calls. These included a text editor, a feedback window, a single- or multi-line message box, a stacks-in-use manager, an icon chooser dialog, a list window dialog, and a script editor.

Others sometimes questioned the script editor, because it did not extend the functionality of HyperCard’s editor at all. There was a reason for its inclusion, however: in later stages, the Phoenix ADE was intended to be usable with versions of HyperCard Player, tranforming it into a full (and free) development platform. Apple had abandoned HyperCard, but we hadn’t. Unfortunately, before such a version of Phoenix could be released, many HyperCard XCMDs used in the project were broken under Classic in OS X, halting development on the project. Only a few lucky souls in the HC community received early betas of this version of the Phoenix.

Style sheet dialogs were used to create button and field property sets, which could then easily be applied to new or existing objects. A single click could set all the properties of a button or field.

Contextual Menus

Control-clicking stacks and objects produced pop-up contextual menus including HyperCard and Phoenix commands. Amazingly handy, and far ahead of its time.