Home
Subscribe
KSDD.com
ActionScript for Designers, Part 1
We have to tear down before we rebuild
If you're a Flash designer, there are probably a million reasons why you might be reluctant to go down the ActionScript road. I know, because I probably went through each of those reasons myself before I finally bit the bullet. But learning at least a little about ActionScript can really help you take your design work to the next level, so over the coming weeks I'll be showing you a few tricks that should help make the leap into ActionScripting a little less jarring. First, though, I'm going to have to address the skeptics.
Time for some history
For what may initially seem like selfish reasons, I'm writing this series for myself. Actually, I'm writing this for the me of about four years ago, in the foolish hopes of somehow transporting this information back in time so that I might have gotten off my lazy butt a little sooner. You see, back then I thought everything was just hunky-dory with what I was learning about the design side of Flash coupled with my pathetic little forays into interaction (pretty much the stop(); and play(); actions attached to frames and buttons via Flash's Normal Mode ActionScript panel). Woo-freaking-hoo, right?
While I had gotten to know a fair amount of Lingo during my heavier Director-using days, ActionScript seemed like a whole 'nother animal. First of all, ActionScript looked like JavaScript, and either one of which might as well have been Medieval Klingon to me (we're still talking the me of Y2K here). Second of all, Flash's Movie Clip paradigm introduced a huge and seemingly tangled web of roots, parents, and overall path silliness which didn't make a whole lot of sense to someone who hadn't cared about anything other than symbols and tweening up to that point (and frames on a stage in Director before that). So I came up with a whole host of excuses as to why I wasn't going to "go there" as far as ActionScript was concerned, all of which boiled down to some permutation of "I'm getting away with not knowing it right now, so that's good enough for me." Now, a favorite saying of mine (which I'm going to paraphrase) is that someone endures countless hardships to avoid a hard day's work, and since that saying certainly applies to me, it's only fitting that it took one such hardship to finally put me and "real" ActionScript together at last. Simply stated, I learned more about ActionScript to save my sanity. Here's the story:
A client of mine loved to drive me crazy. They didn't do it intentionally (they, like the vast majority of the clients I've had in both corporate and freelance life, were lovely people and ultimately very good to work for), but they could never seem to make up their collective minds about anything. A particular favorite was to pronounce a project "complete" and then decide, as the project was being subsequently wrapped up, that they were going to add three more sections or whatever else they would come up with to otherwise gum up the works. So, during the course of one particular CD ROM project, I made the conscious decision in the planning phase to insulate myself as much as possible from the insanity I just knew was going to bog down the tail end of the project. I had been using Flash for a while, even favoring it over Director on CD projects, so instead of "hard coding" section names, body text, images, and other very-likely-to-change items into the Flash movie, I was going to move as much as possible outside the Flash environment so when the inevitable shakeup occurred, I could swap out a few images in a directory and change a single text document and call it a day. Plus, it also gave the clients themselves the option to update things if they wanted, which is a huge selling point for a project even if they never end up doing so.
At any rate, it was over the course of that particular project that I really laid the groundwork for all kinds of cool ActionScript goodness that has followed since. Starting with the separation of design and content, which was the big thing in the aforementioned project, I've really learned to embrace the scripting of things that I would have otherwise "baked" directly into the Flash movie itself. This has opened up a whole new world for my Flash designs—one of true dynamic and interactive animation that can really change what the art of the possible is for those who traditionally consider themselves Flash designers. So, when I mentioned before that I'm writing this series for self-serving motives (that whole time travel thing), that's only partially true. I've talked to a lot of Flash folk in the last few years who, for whatever reason, have also shied away from embracing the geekier side of Flash just as I did, so hopefully we'll be able to overcome some of that reluctance together over the course of this series.
Now, I do have one disclaimer to ram through before I go any further. I'm going to write in it caps so as not to be misunderstood: I AM NOT A PROGRAMMER! It's quite likely that there are several techniques I'm going to go over that will be downright laughable to real programmers. I actually expect ridicule on that front, and invite folks better versed than me in the ways of scripting to tell me where I have erred and to set me straight. Anything to do things even faster or easier in the future is fine by me. But that's not the point. The point is that you don't have to be a programmer to have ActionScript help you out tremendously in your Flash designs, and even if you're not doing things 100% to accepted programming conventions and/or standards it ultimately doesn't matter as far as I'm concerned. After all, a lot of times what we're doing is just making some fancy eye candy, not curing cancer. Perspective is, after all, important in work as well a life. And, with that said, on to our last bit of convincing for today.
No Excuses
I'm sensing a bit of the "aww, shucks, I don't know about all this" vibe being sent out from the various corners of the globe that our readers hail from. Actually, what I'm sensing may be nothing more than the questionable leftovers I salvaged from the depths of my 'fridge that constituted my lunch, but no matter. In an attempt to bring everyone wholeheartedly on board with what's going on here, I'm going to bust down the remaining barriers between you and ActionScript bliss by directly addressing your assorted concerns. Having heard many of the various reasons why ActionScript is not worth learning come first from my own lips, and then from others over the years, I was able to distill everything down to just four primary excuses:
"My brain just isn't wired to learn things like that." Sorry to be so blunt, but that's crap. Working with ActionScript is just a means to an end; a way to solve a problem. You are already solving problems every day, whether you know it or not, so your brain is already wired correctly to attack ActionScript. Instead of making things look a certain way in Flash, we're just going to shift gears to make things act a certain way in Flash, and the transition between the two ways of thinking isn't quite the seismic shift you may have built up in your mind. Believe me, if I can do it, you can do it. ActionScript was a jumbled mass of indecipherable letters and numbers to me until I learned to look at it as problem solving. Starting simple and learning the basics (as we will here) will just create an incrementally taller set of shoulders to stand on to ultimately achieve some pretty cool things in Flash.
"I'll just get my programmer person to help me." I've been in situations when I've had access to a programmer and situations when I haven't. Obviously, this excuse only works for those of us who can call upon a friendly neighborhood coding maven to do the heavy lifting, but there are still several holes to be poked in this argument. First, and most obvious, your local programmer may not be around or available when you need them. The second problem is that what you want to do in Flash is not always easy to communicate to a programmer. In very general terms, programmers are used to adding specific functionality to a program, and when you want to do something that falls into the realm of eye candy instead of black and white usefulness, you don't always get back what you want or what will work in your movie even if the idea was communicated effectively. The last thing is it's a good idea to learn at least something about ActionScript anyway, because even if you have a dedicated programmer always at your disposal, you can help make both of your jobs easier by knowing what the art of the possible is for what you're trying to do. You'll know more about what problems your programmer puts on the table, and you'll be able to design your interactive Flash movies more effectively from day one if you're not putting people (including yourself) in a position of having to backpedal because some feature isn't doable when crunch time rolls around.
"ActionScript can't help me—I'm a designer." Uh, that you might be, but if you haven't noticed, a lot of design-oriented programs have some sort of scripting capability these days. LightWave has LScript, Mel for Maya, Expressions in After Effects and Combustion, need I go on? And many of these internal languages bear at least a passing resemblance to ECMAScript, which is the technical term for "pure" JavaScript and which also serves as the basis for ActionScript. So when employers and clients seem to be looking for folks who can do it all these days, you're more than likely going to have to add some sort of scripting to your repertoire to stay with the times, so why not start with ActionScript while you're already using Flash? Trust me, the time you spend getting to know ActionScript will pay off in spades as you make the transition to other languages with similar syntax.
"ActionScript is hard!" It only seems that way at first, Malibu Stacy. Take a look at Figure 1:
That may be alien to some of you, but take my word for it—it won't stay alien for long. If anything, once you get familiar enough with it, ActionScript has a tendency to make most things easier. You'll be able to write code once and reuse it, create and modify movie elements dynamically, structure content on the fly, move assets out of the Flash environment (making updates—either manually or automatically through server technologies—a snap), and more. You're more than capable of it—it just comes down to approaching it from a designer's point of view.
In our next installment...
While working with ActionScript doesn't sound quite as sexy on the surface as maybe the rest of the tricks in your particular bag do, I've hopefully by now sufficiently convinced you that learning more about ActionScript is well worth your valuable time as a designer. So when next we meet, we're going to get right down to business by breaking down Flash's path structure in an attempt to figure out how to get everything talking (and more important, listening and reacting) to everything else. While that may be an unusual place to start (as it doesn't have a lot to directly do with the actual nuts and bolts of scripting), it's a vital piece of the puzzle nonetheless. Until then, folks!
Got Feedback? to send an email. I'll do my best to answer. Really.