Think of something that you wish Authorware could do but it doesn't?  Let the our good friends at Macromedia know via the wishlist.

Please let us know if you find any of the materials on this site inappropriate or offensive. Please include the url and why the material should be reviewed.

Comments and questions about the site are also welcome. Please no Authorware questions, use the AWARE list.

OK, I guess I can't keep my big mouth shut after all. Not too long ago (yes, after the advent of 3.0), I was asked to come in and help an organization that had a huge deadline looming. They had tried to do it on their own, having had only an introductory class in Authorware, during which the instructor (not well known for his Authorware prowess) had recommended the use of GoTos.

They called me only after they got desperate. None of their code was working as it should. Things were erasing when they shouldn't, not erasing when they were supposed to, and other strange things were happening. And even thought they were using Pentium 100s, everything was "running so slowly!" My client contact complained bitterly about how bad Authorware was - how slow it was - how etc.

When I looked at the source code, I saw the GoTo function being used dozens of times (I looked at the number of references and there were over 50 in one small file).

I proceeded to structure the code in a way that took advantage of Authorware's strengths, meaning using the standard Erase options that come with interactions, with their feedbacks, with Framework icons and their pages, and so on. We got rid of all of their GoTos not by consciously seeking them out to destroy them but just by restructuring the code in a way that made more sense.

The GoTo function differs from the Navigate icon in one important way: the Navigate icon can jump ONLY to a page attached to a Framework. This forces you to structure your code in a way that makes more sense, which often means using the power of the Framework icon. It means you organize your Framework pages so that when you later need to change your code, it is well organized, more efficient, and easy to modify.

Since a GoTo icon can go ANYWHERE, this becomes both its greatest strength and its biggest weakness. Its strength for obvious reasons, its weakness because it encourages poor coding techniques. I have used the GoTo function maybe twice in Authorware in the past 6 1/2 years.

After cleaning up their code, it suddenly became much faster in delivery. The complaints about Authorware's slowness suddenly became muted.

And please, let's not continue the farce that Authorware coding is not programming. This is more true now than ever with the advent of truer scripting. Call it scripting or call it programming, I have still found that a programmer can run rings around a non-programmer in getting a project finished on time and in a way that makes the files easy to maintain and change in the future when needed. Do we really want to forget past projects every time we start a new one? Do we want to recode the same feature set every time we start a project because we can't figure out our own code or someone else's code from a previous project? That does not do well for budgets and schedules.

Even before we had repeat loops and if then else constructs, Authorware still required programming skills. Just because you use icons instead of command lines does not mean that you don't need to learn about functions, variables, looping techiques (whether you use a Decision icon or a repeat loop), conditional statements (using the old IF or the new), and so on. These are the first things you learn in programming classes. No one can do anything of any major consequence in Authorware without at least a basic understanding of programming techniques. Many Authorware developers may not call themselves programmers, but whether they like it or not, they are learning programming techniques when they learn to create Authorware code. Not to mention the fact that learning these techniques allow you to create files that are efficient (read: fast), maintainable and shareable.

I have met too many new clients who have felt frustrated (and in some cases angry) at Macromedia's marketing claims which at times have insisted that no one need know programming to create wonderful Authorware-based training or presentations. They had been taught that all they needed to do was to send their artists or instructors to a couple of Authorware classes and they would somehow be able to start immediately creating sophisticated courseware.

They become my clients after reaching a moment of crisis. The beauty of Authorware is that there are things you can do without using a lot of functions and variables, so one gets seduced into thinking he or she will never need them (except of course for the wonderful GoTo) function. Suddenly, after working on the project for several months, the deadline is three days away, nothing is working right, and they call for the Calvary. The Calvary comes in and works day and night to get the course in a somewhat presentable form for the deadline, then spends the next several weeks undoing the bad coding techniques they have taught themselves through the project in the absence of any real understanding of programming.

This isn't someone talking who just sits back and writes books about Authorware - this is someone who, like most of you, is out in the trenches often trying to fix messes that others have created through no fault of their own. They were victims of the claims of others. Their only fault is in trusting too much.

I love Authorware. I have used it for six and a half years now and have found nothing that brings me more pleasure in creating the kinds of applications I'm asked to code. It has its faults - but so does everything else. However, I doubt I would be able to make Authorware do the things I can get it to do or do it in a way that leaves the files so usable afterwards if not for my computer science background and for all that I learned about programming lo these many years.

If you're still reading this, thank you for listening to my fourteen cents worth.