| Regardless of whether today's multimedia authors have had formal technical training, they can't do their jobs without programming. |
Ivett became a programmer when she recognized interactive multimedia as a logical evolutionary stage of her career in graphic design and art direction. "I had no idea what I was getting into," Ivett reports from her computer-jammed Go2Media studios in Los Angeles. "I started out like everyone else who came from the design side: first, you just make pretty screens and classy menus. But right away I wanted to make interesting things happen. I was building interactive press kits for local bands, and I wanted to put little games in them. Before I knew it, I was spending most of my time looking at the syntax manual for Director's Lingo language."
Ivett's story is far from atypical among today's new media authors, tens of thousands of whom have become stealth programmers. They come to authoring as marketers, trainers, designers, and educators--not computer science grads. But regardless of whether they've had formal technical training, they can't do their jobs without programming. The authoring tools they use, however, rarely refer to it as programming; most vendors recognize the non-technical background of the typical multimedia developer and position their products as "codeless," "no-programming-required," or "point-and-click." The near-ubiquitous Macromedia Director uses "scripting." Euphemisms, though, can't hide the truth: interactivity requires programming.
That's the bad news. The good news is that by learning a few basic elements of programming, even those authors whose VCRs--years beyond warranty--still flash 12:00, can nonetheless go beyond the capabilities of their authoring tools to infuse their projects with the interactivity they need.
| Authoring tools rarely refer to it as programming; most vendors recognize the non-technical background of the typical multimedia developer and position their products as "codeless," "no-programming-required," or "point-and-click." |
Programming is about getting a computer program--in this case an interactive multimedia piece--to do what you want under variable, user-driven conditions. If you remove the variable, user-driven requirement, then you really just have a multimedia slide show or self-running demo, neither of which requires programming. Programming is where you define the nature of the interactivity: the logic for how the program should behave, based on what the user does and doesn't do.
Unfortunately, programming is the one authoring skill which comes naturally to no one. Even if we can precisely define the logic of the interaction--a difficult skill in itself--communicating it to the computer is fundamentally different from any human-human or even human-animal communication. As humans, we communicate with others through several channels including words, body language, and voice. If any of them fail, the combination of gestures provides enough redundancy to ensure the message comes across.
At dinner, for example, holding a slice of bread and a butter knife while looking longingly at the grape jam just out of reach will probably get you what you want without your even having to speak the same language as the person across the table. This explains why phone conversations and especially email are more prone to misunderstandings than live communication: there's not enough redundancy.
Communicating with a computer is tougher than with another human for several reasons: a computer can't process any of the redundant information, it has rigid syntax (to a parent, a child's "cookie want" and "want cookie" are identical; not so for a computer), and worst of all, it is utterly lacking in common sense. If you're visiting a friend's home and your friend suggests, "put the water on for tea," you understand the complete set of instructions collapsed within "put the water on," including locating the kettle, finding the water faucet, putting the kettle under the faucet, filling the tea kettle (but only to a specific point), turning on the stove to a specific setting, and placing the kettle on the burner.
This breakdown doesn't even begin to reveal all the underlying assumptions about how to recognize what a stove or faucet or kettle looks like, or the more basic assumptions that a kettle and stove are even involved, to the most basic of all: how one might actually move toward them. The extraordinary volume of knowledge required to perform even the simplest task explains why we still don't have personal household robots like those in The Jetsons, let alone an intelligent agent like Star Trek: The Next Generation's Commander Data.
Unlike their science-fiction concocted counterparts, the computers we use today for multimedia are, at their core, binary. Today's computers understand only one concept: something is either this or that. You can think of it as any pair--1/0, true/false, left/right, on/off, black/white. So to talk directly to the circuits of a computer requires speaking in a language of ones and zeros. The earliest programmers painstakingly did just that, flipping switches to represent each state. Fortunately for those pioneers, the computers weren't being asked to do much more than calculation. But over time and as computers evolved, attempts to bring the communication at least a little closer to human language resulted in "higher-level" languages. Higher-level--as opposed to lower-level, i.e., closer-to-the-guts-of-the-machine--languages are those which allow the programmer to write in one language and use another program, called a compiler, to translate the more human-like instructions into something the computer can understand.
On a continuum of low to high, assembly language is higher than ones and zeros but definitely inhuman. It's still used today, especially by arcade-game programmers who are tweaking for even the subtlest of speed gains, but it's definitely not for authors. Assembly language is followed up the continuum by modern programming languages like C, C++, and then Java. Still farther up the ladder from basic binary code are Visual Basic and Prograph. Four generations removed are those command sets often called scripting languages, which live only within a specific tool and include those within database programs, spreadsheets, and many authoring tools such as Macromedia Director, Strata's MediaForge, and Asymetrix' ToolBook. Most scripting languages are fairly similar in syntax, and most are more English-like than the lower-level C++ and Java.
In Lingo, for instance, performing a conditional test is fairly straightforward, as follows:
If the left of sprite 2 > 640 then put "Your object is off the screen" into field "message display"
At the highest end is the point-and-click or dialog-box programming found in tools such as IconAuthor, Authorware, ClickWorks, Click and Create, and QuarkImmedia. Although today's scale ends with these tools, research labs such as Apple's Advanced Technology Group, Xerox Park, and MIT's Media Lab have been exploring the holy grail of end-user programming. The efforts at Apple, for instance, resulted in earlier tools such as the ground-breaking HyperCard and the more recent programming-by-example Cocoa (available in beta at Apple's Web site).
| Communicating with a computer is tougher than with another human for several reasons: a computer can't process any of the redundant information, it has rigid syntax, and worst of all, it is utterly lacking in common sense. |
Bytecode compilation, though, may offer the best compromise for today's cross-platform world. bytecode compilation lets the author create a single file which can run on many different platforms, because the final machine-specific translation happens at run-time on the end-user's machine. Java-enabled browsers such as Netscape 3.0, for example, perform the final down-to-machine-level translation for Java bytecodes. Macromedia's run-time technology allows Director-authored programs to have their byte-codes translated for each machine as they are playing back, either as a standalone program or in a Shockwave-capable Web browser. C++ programs, on the other hand, must be fully compiled in advance, one for each specific platform. MTropolis files in version 1.1 must still be generated separately for Windows and Macintosh, a destination mFactory says is required to improve performance on each machine.
| The trade-off for ease of use and faster development time in authoring is nearly alwasy performance and flexibility. |
Fortunately, the lowest-common-denominator machine for most multimedia today is much more powerful than it was in even in the not-so-distant past in which MYST was released. The result of increased processor speed and RAM on the end-user machine is that authors can get acceptable speed within many high-level authoring tools for all but the most arcade-fast games.
Another speed improvement today comes from the extensible architecture of the newer authoring tools, or from newer, faster iterations of old standbys. Authors can build, say, 95 percent of a program in a tool like Director or mFactory's mTropolis, and then buy or write a tiny piece of code--most likely compiled for each platform in C++--just to do one particular run-time task fast. You could, for example, perform some text searching and database capabilities using Director's Lingo language, but there are third-party database objects for Lingo, known as Xtras, which allow you to do it much faster. So despite the tendency among conventional programmers to dismiss authoring tools in favor of "real" languages, the speed gap is closing and experienced authors have learned to exploit the core strengths--development speed, reduced errors, cross-platform conversion--of these tools and minimize the weaknesses to make authoring tools a profitable, effective alternative to conventional languages.
With speed becoming less of an issue as machine power increases, functionality and flexibility are the most significant trade-offs a developer must consider when choosing an authoring tool over a lower-level language. In general, the easier and higher-level the tool, the less flexible it is. In a language like C, or even a scripting language like Lingo, you have individual words and a syntax for structure, and you're free to compose your own sentences to say what you want. But in the highest-level authoring tools with their point-and-click, dialog-driven interfaces, all of the sentences you are allowed to say have been effectively pre-built, and you have little recourse but to hope that whoever pre-fabricated them has anticipated your needs. The most robust "codeless" authoring tools are simply those with more choices, i.e., more precomposed sentences to choose from, and more variable options within those sentences.
A dramatic exception to the "language-is-flexible-but-hard, dialogs-are-easy-but-hobbled," rule is mFactory's mTropolis authoring tool. As one of the newest-generation authoring tools, it was built from the ground up to be object-oriented [See Kathy Kozel, "The Object of Object-Oriented Authoring," CD-ROM Professional, Volume 9, Number 9 --Ed.], and supports a level of granularity that is as flexible as a language but as easy and error-free as choosing from a dialog box.
| But in the highest-level authoring tools with their point-and-click, dialog-driven interfaces, all of the sentences you are allowed to say have been effectively pre-built, and you have little recourse but to hope that whoever pre-fabricated them has anticipated your needs. |
Together, instructions with variables are strung together to create recipes called algorithms. These algorithms perform simple or complex functions as the program runs, and most authoring-tool programming is nothing more than coming up with algorithms, and then knowing how and when to invoke or "call" them. For example, an algorithm for getting the user's name and then using it in a sentence might go something like the following:
set userName = the text of field "input"You can then build the display area window and the text fields (one which you name "input" and another named "display") without any programming, by dragging things to the display stage. In Authorware, you would still need a little code, but it could all be created without having to remember and type the code by simply choosing the appropriate functions and variables from a scrolling list. In mTropolis, you would also make all your choices from dialog boxes, and would only have to type in a name for your variable and the word "Hello."put "Hello " & userName into field "display"
| The way in which programming instructions are defined and carried out in an authoring tool can vary wildly, but the basic issues are always the same--sequential, conditional, and looping instructions, based on user interaction and variables. |
A typical error for most beginning programmers is assigning way too much common sense to the computer. In the "Hello User" example referred to earlier, one of the lines read as follows:
When user has finished typing in the field, read what's in the fieldNew programmers often view this as an acceptable statement, but only after trying to implement it do they realize they must ask, "Just how does the computer know when the user has finished? At what point in the programming of the interaction do you actually fire off the instructions to get the user's name out of the field?" In human interaction you'd know--the user would put down his or her pencil and you could probably surmise from body language, vocalization, or even by looking at what's on the paper that clearly he or she was finished.
But the computer has no way of knowing what it means for the user to be finished typing unless it is given something specific to look for. For an author, there might be several options. You could have the program retrieve the name after a specific number of characters have been typed, but that would be ludicrously restrictive (e.g., "Oh, I see you've entered 14 letters and nobody ought to have a name longer than that anyway"). The program also might retrieve the name after the user has pressed the Enter key, but that would assume the user understands data entry conventions, an assumption most new media authors consider risky. In the end, the author might decide the safest way is to use the ENTER key as a signal that the user is done but to put up some type of "Click When Done" button as well, just in case the user is unfamiliar with data entry.
Since most errors occur in the logic flow of the programming, the trick to good programming, according to Go2Media author De Ivett, is "thinking through as many possibilities as you can and planning the responses. You can never do too much up-front planning." This planning should not just mean considering things the end-user might do; it's also about thinking through the possible outcomes of a particular algorithm. For example, suppose you want to generate a random number between 100 and 200. Now suppose the random number function in your authoring tool generates a number between 1 and whatever number you supply, as in the following:
set myRandomNumber = random(100)which will return a number between 1 and 100. To generate a random number between 100 and 200 seems simple, as follows:
Set myRandomNumber = random(100) + 100Or is it random(100) + 99? Or is it random(99) + 100? The answer is random(101) + 99--easy enough to think through--but a surprising number of expert-level programmers on the DirectL email list for Lingo got this one wrong. And if you had actually implemented any of the slightly wrong formulas, you might run it dozens or even hundreds of times and get a valid answer. It's only when the random function returns an edge number (101 or 200) that the error appears.
According to developers, far more errors in authoring tool programming are caused by failure to think through the problem than by syntax errors or system bugs.
| According to developers, far more errors in authoring tool programming are caused by failure to think through the problem than by syntax errors or system bugs. |
Although variables in most authoring tools and programming languages come in a variety of types, including text (usually called "strings"), numbers (integer and floating point), lists (often called "arrays"), and more, not all tools force you to create type-specific containers. In Lingo, for example, you can create a container, put anything you want in it, and change the contents of any variable freely from one type to another. But MediaForge, Authorware, and mTropolis, for example, have specific variable types and won't allow a variable to change from one to another except under certain conditions. The relative merits of type-enforcement (referred to as "strong typing") are debated among authors, since it can be thought of as either a safety feature or major annoyance, but regardless, the key is in knowing exactly how variables work in the authoring tool you're using.
The most likely use of variables in any multimedia program is to test one or more values, and then take a particular action based on the result of that test. This is often referred to as "conditional branching" or "if/then tests." For example, you might build a simple marketing piece with a special animation sequence which plays before each sub-topic in the program. But user testing has shown that users were annoyed by having to sit through the animations each time they switched between menus, so you've decided you only want the animations to play the first time the user visits a particular sub-topic.
A typical strategy would be to create a set of variables, either as separate variables or as items in an array, for each sub topic, and then initialize, modify, and test them as the program runs. In English, the logic might read as follows:
set subTopic1 = 0, set subTopic2 = 0, set subTopic3 = 0
Another common programming structure is used when you want something to happen more than once. "Loops," as most tools refer to them, come in two main flavors: "repeat with" and "repeat while." Repeat with is used when you have a specific number of times you want to perform a set of instructions, such as the following:
Move the graphic 4 pixels to the right and do it 10 times.Most modern programming and scripting languages use similar structures, referring to the loop as either a "repeat" or "do" loop. In Lingo, repeat with loops are written as follows:Take this list of 10 variables and check each one for a value of "green."
Repeat with counter = 1 to 4In Lingo, the counter variable is automatically incremented, but in some languages the counter must be explicitly incremented by adding another line of code inside the repeat loop, which says "set counter = counter + 1."set the locv of sprite aSprite = (the locv of sprite aSprite) + 4end repeat
The other kind of loop--repeat while--is more like a combination of a conditional test and a loop; rather than running a set of instructions a fixed number of times, the loop is run as long as some variable value is tested and found to be true or false. For example, you might want to repeat a sound loop as long as the user is rolling the mouse over a specific hot spot. In Lingo, this function could be programmed as follows:
repeat while rollover(3)Strangely, mFactory's mTropolis does not have a built-in loop structure, although it's certainly possible to set up messages which fire repeatedly, thus creating a loop effect. Mtropolis developers refer to this unofficially as a "message pump," but mFactory has announced that it will add a message pump loop to it's modifier palette in a future version.if not soundbusy(1) then sound playfile 1, "SongLoop.aif"end repeat
Together, variables, conditional branching, and loops allow authors to craft the interactivity that can personalize a multimedia program at run-time, giving it the potential for an intimacy with the end-user not possible with any other media. Not using the programming features of an authoring tool (or choosing an authoring tool without programming capabilities) is like attaching $25 speakers to your $10,000 stereo and setting it to mono: a complete waste of the technology-enabled opportunity to generate a compelling, dramatic experience. Besides, it can't be harder than resetting your VCR clock.
Aimtech Corporation (IconAuthor)
20 Trafalgar Square,
Nashua, NH 03063-1987;
603/883-0220; Fax 603/883-5582;
http://www.aimtech.com![[LiveLink]](/file/36067/SIGCAT 97 - Conference on Convergence.ISO/Docs/webcd.gif "[LiveLink]"){kind=small}
Apple Computer, Inc. (HyperCard, Cocoa)
One Infinite Loop,
Cupertino, CA 95014-2084;
408/996-1010; 408/974-6412;
http://www.apple.com
Corel (Click & Create)
Corel Corporation,
1600 Carling Avenue, Ottawa,
Ontario, K1Z 8R7, Canada;
613/728-8200; Fax 613/761-9177;
http://www.corel.com
Macromedia (Director, Authorware)
600 Townsend,
San Francisco, CA 94103;
415/252-2201; Fax 415/626-0554;
http://www.macromedia.com
mFactory (mTropolis)
1440 Chapin Avenue, Suite 200,
Burlingame, CA 94010;
415/548-0600; Fax 415/548-9249;
http://www.mfactory.com
Pitango, Inc./Scitex America Corporation (ClickWorks)
Eight Oak Park Drive,
Bedford, MA 01703;
617/275-5150; Fax 617/275-3430;
http://www.scitex.com/pitango
Quark (QuarkImmedia)
1800 Grant Street,
Denver, CO 80203;
303/894-3459, 800/788-7835; Fax 303/343-2086;
http://www.quark.com
Kathy Kozel, an EMedia Professional contributing editor and regular columnist for Author, Author, is a multimedia developer based in Thousand Oaks, California.
Comments? Email us at letters@onlineinc.com.
 Home Page |
 |
 |
 |
 |
Copyright © 1997, Online Inc. All rights reserved.
info@onlineinc.com
[This site created for best results under Netscape.]