design + development = flash workflow

At Barefoot, we do a lot of Flash application development, everything from interactive Web sites with video to Flash based games. Flash projects typically take more time than traditional Web projects, simply because of the robust nature of the medium. Flash introduces motion and statelessness. Flash can certainly be more engaging than "page" based sites. However, because Flash adds more complexity, and usually time, it also adds more need for a solid workflow amongst team members.

No workflow process is ever complete. They seem to be constantly evolving, partially due to the fact that the technology is constantly evovling. Our workflows revolve around the team members and who starts the project files off. We have experimented with designers starting the project or developers starting the project. Let me explain further. One approach is to let the designers create the FLA and all of it parts, including layout, animation, and some interactivity, then handing off to the developer to tie everything together. The other approach has the developer architecting the application, creating the setup, pieces, and logic, and then handing off to the designer to work their magic on the individual pieces.

A couple of factors are key to the decision. Is your application going to practice Object Oriented Programming theory or more specifically a design pattern like MVC? Or is your application going to use procedural code where you could easily add logic along the timeline during key events, matching up with any motion or animation?

Here are some common scenarios and reasons why you would choose one workflow over another. If you were building a game, you would probably decide to practice OOP. Because of this reason, it would make sense for the developer to start with the project, architect the solution, set up the Classes, and any corresponding symbols. The designer could then work with the library symbols and add any graphics and motion to the piece. A key factor in the ability to do this is specifying the Class for any given symbol in the library, using either the "linkage" property and assigning the ActionScript 2.0 Class or through a process known as registering the object with a class.

However, say you were creating an online product demo. This demo, doesn't really have a lot of interactivity, more like events will need to fire during certain times throughout the demo. Because of this, procedural code can certainly fit the bill and may make development of the application easier. This scenario may lend itself to the designer initiating the project and identifying where logic needs to be added. Our designers know to create an actions layer and identify the first frame where all code will be added so hand off to a developer is very straight forward and logic can be added to this frame in functions and simply called throughout the movie.

Team members and their understanding of Flash is also very important. At Barefoot we are very lucky to have designers that also know a very good amount of ActionScript. Because of this we can be flexible in the workflow we choose.

Choosing one workflow for all projects may very well be impossible, so narrowing down the choices to just two may make agency life a whole lot easier. The more familiar your workflow becomes the faster you can deliver for your clients, bring new team members into the fold, and minimize the debugging in the middle.

Michael Krisher, Senior Developer, Barefoot