Tay Vaughan - Using HyperCard: From Home to HyperTalk

By Tay Vaughan
Que, 1988, 750 Pages (ISBN: 0-88022-340-5)
This book is out of print

Contributors: Eric Alderman, Richard Antaki, Jim Edlin, Bill Gladstone, Jacob Kandathil, Donald Koscheka, Jan Lewis, Steven Lewis, Suzanna Lewis, Lawrence Magid, Stephen Michel, Katherine Murray, Harry Saddler, D. Sutton-Grant, Jeff Vasek, Tay Vaughan, Hal Wine

Once a year in the late fall, Las Vegas is transformed into the Mecca of the personal computer hardware and software industry as close to 100,000 people from around the world gather for COMDEX.

In a crowded COMDEX lounge, sandwiched between conversations in Japanese, German, and Dutch, several of this book's authors came to a remarkable agreement. The new HyperCard application distributed by Apple as "system software" was the most notable new product of 1987, and it would open a unique window of need. A good reference book was desperately needed; a book not only about HyperCard in general, but about HyperTalk and HyperCard's Macintosh programming environment as well.

Three of the authors had already produced commercial HyperCard software. Another was currently employed by Apple to write a special HyperCard stack for internal corporate use. Another had recently interviewed Bill Atkinson and John Sculley for a major trade publication. All had desperately sought technical documentation about HyperCard and its programming language, HyperTalk, in the very early days when literature was scarce or nonexistent; all had spent many strenuous weeks on learning curves where much of HyperCard's power had to be discovered empirically by trial and error and by brute experimentation.

The writing of this book was a team effort, with each author contributing material specifically relevant to his or her area of expertise. The authors discovered unique tricks and shortcuts as they made their way through the HyperCard landscape, picking up valuable insights such as where the danger spots are and how to save hours of stack design and programming time.

It is these hard-working experiences that have shaped this book. Since the beginning, the author team felt that the finished book would emerge as a work of truly greater depth and detail than that which any single author working alone could offer. Not all of this book's authors are C or Pascal programmers adept at creating XCMDs. Not all are experienced graphic artists. But these skills and more have been synergistically merged into an effort where the whole is far greater than the sum of its constituent parts.

The authors hope that you, the reader, will find this to be a valuable and useful text regardless of your experience level in HyperCard. Your satisfaction will make the many late nights and the lost weekends worthwhile.

The design of good HyperCard stacks is a true interdisciplinary process demanding the careful marriage of graphics, text, and subject matter. A well-crafted stack reflects the designer(s) creative spirit in the same way a fine painting or piece of sculpture radiates a special message from its artist. As artwork, a good stack summarizes the designer's technical expertise in the HyperCard/Macintosh programming environment, his sensitivity to end-user needs, and his own knowledge of the topic or task at hand.

Properly blending the ingredients of superior stack design is a practical exercise in good planning, experimentation, and refinement. Poorly-planned stackware 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. Graphically inadequate stackware reduces the limit of a user's attention span: stick figures are certainly less interesting than more richly endowed visualizations. Irrelevant information, stack content not appropriate to the subject, or annoying sounds and screen artifacts may provide distraction and a nagging whisper in the user's midbrain, the same whisper that usually causes a book to remain unread after the first chapter. Users of poor stackware quickly learn the shortcuts to Home.

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

"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" menu 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. You can do this on a paper napkin over late-night pizza, on a large commercial storyboard in a conference room, or you can use the computer. But do it! How many of your good ideas have vanished because you didn't organize them or failed to note them down before they melted away like rain onto desert sand? The chart gives you a place to save ideas and it provides a critically important reference during the ensuing process building the stack. This reference document, no matter how scratchy, will save you many hours of hit-or-miss revision and might, in the end, mean the success or failure of your project. Programmers and designers, like end users, can get lost in the chaos of the hacker's void -- that strange place of perpetual Brownian motion where objects and activities seem unconnected and no pathway leads anywhere useful. During development, a good designer relies on __plans__ which may or may not evolve into a logical __map__ for the user. Both provide guidance through the void.

"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 worth the expense.

From a programmer's perspective, it's usually a thrill to work with skilled graphic designers. They understand basic things about composition, typefaces, shadowing, and visual effects. They can make stick figures come alive without deformation and can turn a working sketch into a pleasing reality.

Graphic consistency throughout the stack is essential. Don't indiscriminately mix rectangular boxes with rounded boxes. Choose a single font and use it consistently; employ other fonts and heights discretely for highlighting and to make text elements stand out. Avoid what graphic designers call "busy" presentations.

"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. Thus other programmers (from the competition, for example) and end users cannot scroll through a program's code looking for techniques, tricks, or complex algorithms. Not so with HyperCard. A programmer's script is usually readily available to end user scrutiny, and even if HyperCard's "Protect Stack" feature is employed, it can be cracked. Within days of the first release of HyperCard (August, 1987), deprotect software began circulating through underground channels. The open nature of HyperCard's script is in concert with the basic philosophical tenants of its creators.

What programmers in other languages can hide by compilation -- terse and unreadable code, poor commentary, inelegant use of commands, strange variable names, fuzzy technique, and unconventional methodology -- hangs out in HyperCard's backyard for all to see. More, 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. You might hope that others will credit you for your work, but there are no guarantees that the HyperCard environment is populated solely with ethical good guys.

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. A tool like "Script Report" by Eric Alderman is handy for this, and will deliver a hard copy summary of all your script. Most serious programmers in any language environment care about the look of their code. They usually annotate it with appropriate remarks and make it readable by others and even themselves, knowing they might be required to make revisions months later. This kind of neatness is considered to be simply good programming form.

"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 100% 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% perfect, even before the software had a chance to compete on merit. Nowadays, developers have learned to delay public release of product, sometimes well past announced delivery dates, to ensure that it is as close to 100% bug-free and as accurately on-target as possible. In the school of hard knocks, they have learned that to delay and fix is a far better strategy than to prematurely release (a dangerous action too often driven by marketing desires to arrive in the marketplace ahead of competition or in time for a planned gala announcement).

Whether you are designing stacks for yourself or for others, heed this principle. Apple's own __Human Interface Guidelines__ (also available from APDA, Pub. #: KNBHIG) advise developers of any Macintosh software to "Test early, and test often!"