Applying Productivity Techniques

 < 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 Items

In 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:


Create a new file and save it as source.fla. Draw a box around the text HOLDER. Select everything and convert it to a symbol. Name the symbol Background and select Movie Clip, but before you click OK, make sure to set the default registration point to the top left, as shown in Figure 23.3. This will make registration easy if the size needs to change (new contents in the clip will only grow also said to "bleed" to the right and down).

Figure 23.3. When creating a symbol, you can select any of nine points around which the symbol will be registered.


Select the instance of Background that is on the Stage and copy it. Start a new file (by pressing Ctrl+N) and then use Save As to save the new file with the name user.fla.


While in the new user.fla file, paste. Open the Library (by pressing Ctrl+L) and notice that Flash copied the Background symbol into user.fla's Library. (Make sure you're looking at the Library for user.fla; it's possible to have the Library from source.fla open as well.) Select the Background item and from the Library's options menu select Properties. (Alternatively, you can right-click or use control+click on the Macintosh to access the item's properties.) If the dialog box is not expanded already, expand it by clicking the Advanced button. The dialog box should look as shown in Figure 23.4.

Figure 23.4. A Library item's Symbol Properties dialog box can be expanded to show advanced settings that include authortime sharing options.


Notice in the Source section that the original source.fla is listed. Flash knows from where you copied this item. Select the option Always Update Before Publishing, which basically means "Recopy the original symbol (in source.fla) every time I test or publish this movie."


At this point the programmer or animator can use the Background symbol in user.fla as needed as if it were the final version. Scale it, position it in the center of the screen, and then make a tween in a new layer on top of it.


Now, let's say you want to see what happens when the graphic artist replaces the original Background in source.fla. Simply open source.fla and edit the master version of Background. Make a clearly visual change (pretend you're the artist putting finishing touches on the image). Be sure to save source.fla.


When you return to user.fla, you still see the old Background. However, just use Test Movie, and you see that the new version of this symbol is copied into the file. When you're done testing the movie, you should also notice that the change remains.

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 Conventions

As 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 > 

    Sams Teach Yourself Macromedia Flash 8 in 24 Hours
    Sams Teach Yourself Macromedia Flash 8 in 24 Hours
    ISBN: 0672327546
    EAN: 2147483647
    Year: 2006
    Pages: 235

    Similar book on Amazon © 2008-2017.
    If you may any questions please contact us: