Principles of Stack Design

By TAY VAUGHAN
In the Premiere Issue of Hyperage Magazine, 1988

The design of good HyperCard stacks is a true interdisciplinary process demanding the careful marriage of graphics, text, and subject matter.

The design of good HyperCard stacks is a true interdisciplinary process de-manding the careful marriage of graphics, text, and subject matter. Properly blending the ingredients of superior stack design is a practical exercise in good planning, experimentation, and refinement. Poorly planned stacks may cause an unsuspecting user to feel abandoned in the chaos of a designer's ill-conceived stack, wandering the card void without reference or direction, groping for milestones. Users of poor stacks quickly learn the shortcuts to Home.

The following four principles of stack design present very basic working criteria which may be used as benchmarks for designers during development and implementation of stack ideas.

First Principle

"If you can't organize your stack idea, it won't work."

Before you begin to create cards and backgrounds and paste buttons, before you even consider clicking on the "New Stack" option, you need to formally develop your idea. You must clearly define its shape and prepare a preliminary outline of the stack which will implement the idea.

Ideas are elusive. This important preparation and outlining exercise will force you to chart out where you are going and what you are doing while underway. During development, a good designer relies on plans which mayor may not evolve into a logical map for the user. Both will provide guidance as you coalesce your idea from the void.

If you just hack away without forethought, you have no guarantee that the final product willI) do what you initially hoped, 2) be worth the effort of rework when you discover that you have been using the wrong backgrounds all along and have to individually move your card graphics, fields, and buttons onto new backgrounds, or 3) be more than a tangled web of scattered links and disappearing messages from which you cannot escape. On ocean charts in the middle ages, where the cartography faded out toward unknown edges, there were great seas of kelp illuminated with annotations that "There be Dragons here. " Without up-front design and organization, you could end up in that place.

Second Principle

"Graphic design is as important as script elegance."

There is a tendency for serious programmers to overlook the visual interface and devalue the screen presentation in favor of performance elegance. They pride themselves more on unique algorithms and the finesse of their recursives, less on what the user sees. These programmers, as stack designers, may draw hasty rectangular boxes sufficient to get the job done. Worse (although simple can be very beautiful), they may attempt to apply ill-rendered flesh to their stick figures, creating uneasy mutations even more disturbing than the original sticks. If you are not interested in the graphic side of HyperCard, then keep your screens, buttons, and fields straightforward and uncluttered. If you are indeed very serious, then the services of a competent graphic designer are often worth the expense.

Third Principle

"Bad script can ruin your day."

In most microcomputer programming environments today programmers write source code in a language such as Pascal, C, Lisp, or Basic -- among others. Then they compile their source code into executable machine language code. Other programmers can easily read the source code, but the machine language code is, without heroic and uncertain effort, virtually impossible to decompile into meaningful computer activity. The binary machine language code is made available to the public, never the source. Not so with HyperCard. A programmer's script is usually readily available to end user scrutiny, and even if the "Protect Stack" feature of HyperCard is employed, it can be cracked.

As a designer, you must deal with the notion that your code will be open to inspection. HyperTalk tricks that you spend hours developing may be easily cloned by others. Perhaps they will rename your global variables or tweak the guts to suit their application, but your good algorithm will be passed around. If you are concerned about your proprietary algorithms, perhaps the HyperCard arena is not for you.

If you are concerned about neatness or suffer from the "messy bedroom syndrome", clean up your code before releasing the stack or passing it to others. Neatness is considered to be simply good programming fonn.

Far more important than the issue of open code, however, is the fact that it is the script that makes your stack work. Learn the HyperTalk language. You must know the language and its capabilities to be able to design stacks that do more than link together a few cards in the Authoring mode.

Fourth Principle

"Test it, then test it again."

The process of stack design and building must include procedures for testing and review to ensure that the stack is operationally and visually on target and that the end user's requirements are met. Do this testing before the stack is finalized and released for public consumption because your goal must be to provide lOOper cent accurate and "bug-free" software. No serious programmer or designer wishes a reputation for buggy software; in the commercial marketplace, reputations gained by too early and buggy release have destroyed major projects which were otherwise 99 per cent perfect, even before the software had a chance to compete on merit. Whether you are designing stacks for yourself or for others, heed this principle. Apple's own Human Interface Guidelines advise developers of any Macintosh software to "Test early, and test often!"

Managing feedback is critical to the testing and revIsion process. If tester comments fall on the floor to be swept away and trashed before being considered and profitably incorporated into the stack, the testing effort becomes merely a futile and wasteful exercise; it is necessary to record and track user comments. Most serious developers provide a system for the reporting of bugs. You should do the same.

When you have beaten all the bugs from the stack and are comfortable that it serves the purposes for which you have designed it, let it fly!

No publication dedicated to hypermedia today can fail to include the thoughts of ray Vaughan, the founder of KTI (Key Thinkers, Inc.) The inventive and charismatic Vaughan roams the halls of Apple's City Center I designing and engineering hardware, software and robotic systems for high technology environments.

Prolific Vaughan, along with the KTI Hypermedia Group, has a book coming out this year on HyperCard. We're looking forward to bringing you more of these key thinkers.

(Note: This article is condensed from a chapter in the forthcoming book Using HyperCard published by Que Corporation about HyperCard and the HyperTalk scripting language, due in bookstores in the spring of 1988.)