< Day Day Up > |
When you understand some productivity methodologies and their benefits, you need a way to apply this knowledge to Flash. For example, exactly how do you allow separate team members to work on the same project? That's what you'll learn in the remainder of this hour. You'll learn to use built-in Flash features as well as some general techniques that are not specific to Flash but are valuable nevertheless. Using Shared Library ItemsIn Hour 20, you saw two ways to share Library items. Basically, one main file's Library items can be shared among many other "user" files. If a change is made to the Library file, that change is seen in all the user files. If runtime sharing is used for the Library items, visitors to your site download those items only once. You can probably imagine how the productivity of shared Library items can help in a team environment. A common issue in website creation is that an enormous amount of work is needed to create the artwork for a site. While the principal artist comes up with the graphics, the assembly person (animator or programmer) just sits and waits. Then, when the final graphics are complete, the project must come together in an instant. Shared Library items can help by letting the assembly people use a placeholder (or proxy) graphic, which allows them to work even while waiting for the graphics from the principal artist. The following task walks you through a scenario so that you can get the idea. Try It Yourself: Use Shared Library Items to Start Assembling a Movie Without Final Graphics In this task's scenario, you'll use a shared Library item in order to let the assembly people start working before the artist is finished creating the graphics. This technique is called authortime sharing because everything is copied into your movie upon export before runtime. Imagine that the programmer wants to start working, but the graphic artist hasn't finished creating the graphics for the background. The artist can create placeholder graphics (really, Library symbols) that can be replaced later. Here are the steps to follow:
The cool thing about the scenario you explored in the preceding task is that several files can use the same background. If the graphic ever changes, you just need to re-export all "user" files that use the symbol, and it will be updated automatically. In the case of Swap Symbol, you need to swap every instance used. Authortime sharing is much easier than runtime sharing, so it's more appropriate when you expect graphics will be replaced. By the way, the other shared Library feature (runtime sharing) differs from authortime sharing in that with runtime sharing you would only need to re-export the shared.fla file instead of every user file. (Runtime sharing has other advantages and disadvantages, as discussed in Hour 20, but it's worth thinking about how this task would be different using runtime sharing.) Using Documentation and Naming ConventionsAs you build a large, complex project, documentation is important. All media elements should be clearly identified and, if necessary, an accompanying paper document should detail how everything works. Think of documentation as an instruction manual. It can be used by any team member to quickly view an entire project. If documentation is well done, someone outside the project could study it and then begin working on the project. Not only does a clear paper trail help other team members, but even when you're working solo, documentation can help you sort through your own project if you need to revisit something you built in the past. Documentation doesn't actually need to be on paper, either. You can include notes right inside your Flash movie. For example, because Guide layers don't export with the movie, they're a great place to include notes or maybe just a quick explanation of the more complex features involved in that file. Even the process of creating documentation will help you sort out how a project works. Specifically, a basic set of documentation includes a text description of every file used in a project. You could have a folder that, by the name you give it, explains what's contained. For example, a folder's name could be sounds. Perhaps it contains .swf files with audio that's loaded into the main movie via the MovieClipLoader. Every file dedicated to a project has a purpose and if a file doesn't have a purpose, maybe it should be deleted or archived. You just need to explain each file. Really great project documentation would also include a description of the process. Although something as vague as "create the animation and be very careful to make it look good" may be too general, you don't need to be really specific, either. It's a balance between being clear and being so detailed that you're creating more work for yourself than it's worth. Common sense can help you make this decision. However, realize that if you have to revisit your own work at a later time, you're going to value such documentation. Documentation should be done during the project not at the end. The incentive to sit down and document a project that's complete is lost because the project is done. When you reach logical milestones, you should document what you just finished. Think of it as protection. Imagine that you could be audited and you want everything in order, just in case. One way to document as you go is by using careful, strict naming conventions. Symbol names are important because they enable you to sort Libraries alphabetically. If each team member precedes the name of the symbols he creates with his initials, you can quickly sort items based on author. You could also decide to precede symbol names with the section where a given asset is used. This is the technique that is used in the lesson file found under Window, Common Libraries, Learning Interactions (see Figure 23.5). All the assets for the DragDrop section have names that start with DD_, assets for the HotObject section start with HO_, and so on. You can use whatever makes sense for your project; it just takes a little bit of organization. Figure 23.5. A Library is organized automatically when you use folders and a consistent naming convention.Naming conventions are a set of rules you apply to the names that folders and files are given. You can specify a convention without specifying each filename. For example, your naming convention could specify the following: SectionNumber_SubSection.swf. With this convention, for example, for Section 2, Subsection 3 the name would be 2_3.swf. This convention can accommodate any numbers that arise. In addition to the names given to symbols in the Library, the instances used on the Stage have names, too. Instance names have little benefit for documentation, but naming conventions can still be critical. If, for example, you have three instances of a symbol named box initially, the instances don't have unique names. If you name them box_1, box_2, and box_3, you could have a script that sets properties for one box at a time. For example, the following code sets a selected box's x position to 10: function move(boxNum){ _root["box_"+boxNum]._x=10; } Naturally, boxNum needs to be either 1, 2, or 3. "box_" + boxNum dynamically changes to box_1 if boxNum is 1. This idea brings up a lot of scripting issues that are beyond the scope of this hour, or even this book. However, you should be able to see how naming the instances in such a logical manner makes more sense than naming them boxOne, boxTwo, and boxThree because it would be harder to dynamically address any one of the instances. Documentation and naming conventions are just good housekeeping. Even if they seem like a lot of work during a project, they can actually save a lot of time not just when there are problems, but also when you want to make structural changes or track progress. Often you can complete a large project with no regard to documentation or naming conventions; you'll just be more be efficient in that case. |
< Day Day Up > |