In this series of articles I will attempt to guide you, the readers, to better design and development techniques. These are by no means strict guidelines, nor are they industry standards. These are simply the lessons I have learned in Flash design and development over the past few years. Tutorials are great, but also serve as a crutch for people to avoid learning the important rules of their profession. I cant think of anything better than sharing lessons I have learned while working with clients and other web studios.

For those wondering what my qualifications are... I started as a desktop systems developer using C and Visual Basic in conjunction with MS SQL Servers. I made the jump to web design using HTML and CSS. Which brought me to Javascript and ASP. From there I got into Flash development which also took me to design using Photoshop. In the past years I've worked with clients like Warner Bros, Atlantic Records, and ego7.

So lets get started! There are some pretty basic ground rules, or "Rules of Engagement", if you will. These are fundimental basics, like Flash pre-school.

Know your tool
Knowing your tool is the absolute most important aspect of any trade. I cant begin to tell you how many young guns come through this industry thinking they are going to make it big using Flash and honestly dont have a clue of what Flash can really do. They either see it as, "for designers to make things move", or "that cool thing I heard about in wired magazine".

When I was in college, and yes I went to college late in life, I had a professor that was easily in my top 10 list of developers. The guy was just a genius. Flash 5 was just about to be released and we were discussing it. He said he had looked at it and told me, "Flash is for designers that cant program". Needless to say a year later, he was teaching Flash development. Okay, so the moral of the story is, he glanced over Flash and made an assumption. He assumed Flash wasnt capable of data processing and things of that nature, because he didnt bother to learn the tool. You dont have to be a Flash developer to learn what it can do. You can simple ask existing Flash developers, read articles in tech magazines or sites. Read a blog, I hear they are extremely popular these days. Its a simple matter of knowledge and the information is out there and easy to access.

Rule of Engagement : Know what your tool can do before you set out to master it.

Dont Use A Crutch
Dont use tutorials as a crutch to lean on. When I was tinkering with Video Game Design, yes I tried that out as well with no success what so ever. I dont remember who said, or where I exactly I read (so to whoever said it, thank you).  It simply said,

"dont rely on tutorials to get you by. Chances are you will run into many situations which no one has writen a tutorial for..."
These are words to live by and this goes back to "knowing your tool". Search through the forums and you'll find at least a few hundred people asking for a tutorial on something very specific. Unless its an mp3 player, video player, or photo gallery you're more than likely out of luck. Lets says your boss comes to you and says, "I want a function that attaches a clip from the library, aligns it to the lower left corner of the stage, and silently tracks all mouse clicks.." Whats the first thing most people do? They usually go to a forum and ask, "how do I do xyz..is there a tutorial for this?" I've seen it hundreds of times in different forums. <shameless plug>Fortunately, Asctionscript.org has a great bunch of people that will make every effort to help</shameless plug> With that being said, you should first analyze what you need, break it down to its simplest form, press "F1" in the Flash IDE and look up the methods you'll need. If you dont know where to begin, then by all means ask in the forum, but please do not rely on the hope that someone wrote a tutorial for it. I'm not saying tutorials are useless, they are a great learning tool. What I am trying to convey is that you shouldnt rely on them for your needs.

Rule of Engagement : Rely on your knowledge, not a tutorial.


To sum things up, know what your tool can do and learn it. Once you understand these points the door will be wide open for your twisted little mind to create and conquer.

So you're a Flash developer you say? A few things to always keep in mind since Flash has moved to the Object Oriented Programming world.

Let Them Go!
All too often "Flash developers", I put that in quotes for a reason, tend to think the old methods work best. Why is this? Mostly due to the fact that these "Flash developers" are fairly new to the game. They were taught the old methods and its all they know. Here's a good rule of thumb, when a new version of Flash is relased the first thing I do is check for deprecated code. This is true with every language. As they progress, the older, slower, and bulky methods are left behind in favor of newer and more efficient ones. In Flash this is a serious issue. I see people ask questions like, "why does Flash give me an error when I use 'add'.." Its simple, 'add' is deprecated! You would have known this had you looked (sounds mean I know). There are a bunch of functions, methods, and operators that have been deprecated in Flash 8. For those wondering, here is a list I compiled :
http://www.actionscript.org/resources/articles/555/1/Deprecated-Syntax-as-of-Flash-8/Page1.html

Alrighty, now you have a list of deprecated syntax, so lets never use those again. With that said, though the following are not yet officially deprecated, we should avoid them all the same:

setProperty(), getProperty(), onClipEvent()

Just let that syntax go. Pretend it never existed and you're life will be so much easier. Here's simple Flash 'dont'. Dont ever use ClipEvents. They are old methods that dont apply anymore.


To Class Or Not To Class?
This is an interesting area when it comes to Flash and its developers. I see a trend of where developers are turning everything into a class. As we all know the class had many benefits and uses, but lets face it people, not everything is class worthy. I see this a lot, developer writes a class for a button, which contains the onRelease. All I can think to myself is, why? Why would you do that. To me, thats like strapping bricks to your shoes and trying to cross the street. I simply cant understand why developers do some of the things they do. Before you write a class, please oh please, consider if its necessary. If you're unsure, chances are it doesnt need to be a class.


Object Oriented?
Here's another little point to consider. Flash has become Object Oriented which offers so many benefits. Again, its also misunderstood and abused. A very simple truth, placing code in an external .AS file is NOT Object Oriented Programming. External .AS files simply offer better code organization. Again, it is NOT Object Oriented Programming, so please, stop claiming it is. This drives me completely insane when I see/hear other developers claim their application is Object Oriented when in reality its just an .AS file being imported. Understanding what Object Oriented Programming is will help you survive the ever changing Flash world. This also related to "knowing your tool".

So, thats basically it in a nutshell. Follow that advice and you'll be golden. Some of it was very general and for good reason. Its a starting point, good for beginners and intermediate developers, maybe even an expert or two. Always remember, in our industry things changed daily, so always be aware of the changes.

Thats that for now, stay tuned for more in Part 2. Catch you in the forums.