ActionScript.org Flash, Flex and ActionScript Resources - http://www.actionscript.org/resources
Better Design and Development Part 2.
http://www.actionscript.org/resources/articles/577/1/Better-Design-and-Development-Part-2/Page1.html
Chad "Cota" Workman

http://www.chadworkman.com & http://www.plaguestudio.com

Skills include: Photoshop, Flash, ASP, PHP, MS SQL, MySQL, VB, C/C+

Developer and Designer

 
By Chad "Cota" Workman
Published on March 26, 2007
 

Part 2 in my series of "Better Design and Development". Its not required that you read part 1, but it helps. For those skipping part 1, this article is simply the lessons I've learned over my years in this industry.


Re-Introduction
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.

Start at the beginning!
The page title should give you a good idea of what I mean. I use this term a lot, "Far too often", get used to it cause its true. Far too often flash beginners try to do too much and get ahead of themselves. Try to stick to this road map.

Think, think, and think some more!
When your client and/or boss comes to you with a project and project specs your first reaction should not be what code to write. The absolute first thing you should do is plan it. I cant begin to tell you how many people just jump into the code, blaze through it, and realize none of it will work, because they have to back track and re-work the entire thing. Why does this happen, its simple, you didnt think it through. Moral of the story, think!

When you find yourself with a new project think about it. Plan for everything. Grab yourself a piece of paper and write it out. Draw yourself a make-shift flow chart. It doesnt have to be anything official. To this day, I have never put together an official flow chart, its always just a few scrap papers with shapes, lines, and descriptions. It helps to visualize what you're about to work on. This also allows you to see all the pitfalls that may pop up once you start coding the project. I cant stress this enough, think think think think think think think, and think some more. Once your brain is exhausted and you've cursed at your monitor for an hour, you're ready to move on.


Think Beyond the Scope
After you've thought about your project until you can no longer stand it, consider its scope. By now you have an idea of what functionality you'll need, where you'll need, and how you have to deal with data. Thats great, now sit back and do some more thinking. Every project will have a scope. By this we mean, what it needs to do, etc. Think beyond that, because I can promise you that your project manager, boss, or client will come to you and totally change things on you. If you consider the project functionality and ask yourself, how can I extend that, then you'll be set. The moral of this story is to always leave your functions open for growth, or scalability as the nerds say. If your project is a video player system and they only tell you to make a play and stop button, then plan for a pause button down the road. It happens on every project. You start building it and they come to you with "updates". God I hate the updates. It makes you want to grab your keyboard and bounce it off your bosses head. Now, if you thought beyond the original scope of the project, the urge to pummel your boss might not be so bad, you might not even have it. Also consider the possible functions and requirements that were not initially mentioned. It will save your life, or at least your bosses life.

The Unknown
There will be an "X" factor in every project. You will always hit a roadblock that you didnt see in your planning stage, assuming you bothered to plan. These things happen, but how you deal with them is key.


Show no Fear!
Show no fear in the face of adversity. Such a nobel thought and holds true in your industry. Lets face it people, its just code! Code is nothing more than instructions made of words and symbols. Honestly, it isnt rocket science, so dont be afraid of it. You're bigger than it is!


Face First into a Wall
When you hit that roadblock take this advice. Step away from the computer and go scream at the wall. Get your frustrations out before you try to solve it. Once you have all that out of your system, come back and try to solve it. You'll find it easier once you have all that out of your system. Guess I'm the Doctor Phil of Developement, but seriously, it helps a lot. No roadblock is perminent.

Dont be afriad to ask for help. You've been looking at your code for hours, days, or even weeks. Its all become one long line to you, but to someone else, the problem may be obvous. With that said, ask for help. There is no shame in it. I have 2 or 3 other Flash developers that I always ask to look at my code and tell me where the problem is. Use your resources. Its a lot like raising a child, yea I've done that twice already. Dont be afraid to leave your baby project in the hands of a friend for a few hours while you go out to play. Trust me, it helps more than you'll ever realize. Plus, they're friends of yours, they're going to hear you complain about it anyway, so let them see the actual problem.


Leave Time
Always leave yourself plenty of time on a project. When that "X" factor shows itself, you dont want to be caught behind a deadline that fast approaches. If you have a project that you think will take you 3 weeks, tell them 4 weeks. Leave yourself enough time to address the "X" factors that come up. This prevents you from stressing yourself out and looking incompetent. Nothing worse than missing a deadline, especially when freelancing. This one is just so simple, leave extra time for issues and breathers.

Re-Concluded
I know the points in this article kind of jump around alittle, but thats the nature of our industry. The underlying message is that you have to process information at random times from random areas. Its not always presented in a linear, organized manner.

Hope you enjoyed this read as much as I enjoyed writing it. In the upcoming installments we will get into technical details, so happy Flashing. See you in the forums!