|< Day Day Up >|
Great work has been produced for many years by creative people working in team environments. Although Flash websites have come about only recently, you can learn from more traditional production methodologies. Film production, for example, is not a bad model to follow. Although film is quite a different industry, it has many similarities to Flash. Even more traditional software production can seem quite different from Flash website production; however, you can still learn from the knowledge gathered in that field. This hour you'll look at a few basic concepts and apply them to Flash. These are not original ideas, but how they're applied to Flash is unique.
It's very important that everyone involved in a project have clearly defined responsibilities. Not only does this prevent two people from doing the same work, but it actually prevents problems. The entire project should be analyzed as a series of tasks. Then the responsibilities should be divided up among the team members. Each team member can take on more than one task, but each task should involve only one team member. You can even change the roles during the project, but just make sure when you do that the new roles are clear to everyone involved.
Sometimes people think that the purpose of role definition is to help identify who is at fault when problems arise. This is a negative way to look at it. In a way, role definition can help identify the person at fault, but mainly it helps to solve the problem. It's too much to expect that problems can be prevented. Therefore, when one arises, having a clear idea who to address allows you to solve the problem without involving (and distracting) other team members.
Testing the System and Doing Full-Path Reviews
After you've defined roles, the next step you should take is to confirm that all aspects of the system are working. It's amazing how many problems this simple step can uncover. For example, if one person is supposed to record some narration and then send it to the animator, an actual test run should be performed. The test would involve the narrator recording some audio. (It can be anything it will just be a placeholder.) The narrator should make sure it's recorded the same way he will record the real thing. When the animator receives it, he should try to incorporate it. Next, the team can analyze the results. If there's a problem in the process, this is a great time to find a solution. Maybe the audio engineer has emailed the files incorrectly and the animator is having trouble importing them. You'll be glad if you find a problem earlier in the process instead of later. It's almost like a dress rehearsal. Just remember that everyone must act like it's a dress rehearsal not just a rehearsal and do everything as they will in the real project.
A similar step you can take early in a project involves a full-path review, which is simply a prototype of the entire project, but only a certain portion of it. It's important to flesh out a "full path" (that is, it's important to go all the way down one representative path). As an analogy, imagine that you're testing the process of preparing 20 envelopes. Each one needs to be addressed, sealed, and stamped. A full-path review would involve addressing, sealing, and stamping one envelope. You wouldn't, for example, address each envelope and then try to make a judgment of your process. Instead, you would just use one envelope and take it through the entire process.
If a Flash project has four sections that each have five subpages, for example, as a full-path test you should build one section all the way through, with its five subpages, instead of building one page for each section. Be sure to select the most representative section. If necessary, use two paths. The point is that you want to go deep, not wide.
Using Code Data Separation
The concept of code data separation is one of the most valuable in any kind of production environment. The idea is that you try your best to keep the code (the scripting and structure) separate from the data (the unique content). The more you can separate code from data, the more you can make changes to either without affecting the other. Imagine a company whose employees install wood siding on new homes. Naturally, they don't paint the wood until after it's installed. They keep the wood (the code, if you will) separate from the colored paint (the data). It makes perfect sense in this case, so certainly there's a way to apply code data separation to Flash. In fact, you already have on several occasions in this book. In Hour 19, "Linking a Movie to the Web," you used an external CSS file to define the text format. And, in Hour 20, "Designing a Website to Be Modular," you loaded external images and sound files.
Here's a specific case. Suppose you've created a very interesting tween that involves moving text from off the Stage into the middle of the Stage. The code, in this case, could be thought of as the motion. The data would be the actual text. In Flash, replacing the data (with no effect on the code) is quite simple. The following task demonstrates one feature that enables this type of separation. After you complete this task, you'll learn some more sophisticated techniques.
Try It Yourself: Use the Swap Symbol Technique As Applied to Code Data Separation
This task uses a built-in feature of Flash to demonstrate how the motion of an animation can be separated from the symbol being animated. Here are the steps to follow:
Swap Symbol provides a way to exchange the instance on the Stage with a replacement master symbol without losing any attributes of that instance. For example, in the preceding task, if you had added a tint color effect, scale, or anything, it would remain applied to the instance on the Stage; the only difference would be the master symbol to which the instance points.
In the previous task, you could have simply edited the master version of the text, which would have changed the data in every instance in the movie. Instead, the approach you took, as much as possible, separates the code of the tween from the data of the symbol. With planning, you can carry this to any extreme. Eventually, when you deliver your movie, the code and data will be connected. However, if you plan to separate these items, making changes will be easier because code and data are separated at this point.
Often when a client or art director wants to make a change, it can mean a lot of work for those involved. If you plan for such a situation, you can protect yourself against having to do extra work. Sometimes the extra work won't pay off (in the unlikely event that no one makes any changes). However, when it pays off, it pays off big. By using code data separation, you can keep the program as modular as possible. Recall from Hour 20 that the MovieClipLoader provides a way to combine and reuse image files among many movies. For instance, your site could use a separate .jpg file containing just a background image. You can include that image (the data) in several movies via the MovieClipLoader (the code). If you need to make a change to the background, you just have one file to edit. A change there will be reflected in each movie that loads the .jpg file. Imagine the amount of work you would have to do if you had to replace the same image in 10 different movies.
Code data separation is a great concept to keep in mind as you plan a site. Constantly ask yourself, "Can this content easily be separated from the structure?" Keeping code and data completely separated is impossible, but the more you can work in this mode, the better off you will be. Code data separation is valuable when you're working alone, but the potential productivity is even greater when you're working in a team environment. You can take advantage of Flash's modular features (discussed in Hour 20) to apply code data separation to team projects.
|< Day Day Up >|