Flash Authoring QE
Adobe
Jen deHaan's blog
flashthusiast.com
webvideoblogger.com
Macromedia Flash designers and developers must structure applications in a way that is intuitive and beneficial to themselves as well as other people working on the same project. This is particularly important in FLA files with lots of assets. When you follow best practices, everyone on the design and development team can understand the file structure and can work more efficiently. This document helps formalize the Flash development process.
Because it is common for more than one designer or developer to work on a single Flash project, teams benefit when everyone follows a standard set of guidelines for using Flash and organizing FLA files. The sections in this document outline the best practices for organizing and structuring your Flash files, maintaining version control, optimizing for output, and making the best use of behaviors, screens, and video. Some sections of Flash Help (Help > Getting Started in Flash) or the Flash 8 LiveDocs (see Using Flash) cover best practices when using the Flash authoring tool.
Note: For information about ActionScript 2.0 coding conventions, see ActionScript 2.0 Best Practices. It complements this document.
The following guidelines encourage consistency for people learning how to use Flash. Adopt best practices at all times, whether you are a designer or developer, or working alone or as part of a team:
Consistent techniques and the following guidelines help people learning Flash, or people working effectively in team environments. Consistent methods help you remember how you structured your document when you work by yourself, particularly if you have not worked on the FLA file recently. These are only a few of the reasons to learn and follow best practices. You are bound to discover many more when you read these best practices and develop your own good habits.
These guidelines relate to the following software:
Creating FLA files that are consistent makes it easier to work with Flash on a regular basis. It is not uncommon to forget where you have placed particular elements, or what object instance code is placed on. Therefore, follow these guidelines to help you avoid frustrating issues.
Frames and layers on a timeline are two important parts of the Flash authoring environment. These areas show you where assets are placed and determine how your document works. How a timeline and the library are set up and used affect the entire FLA file and its overall usability. The following guidelines help you author content efficiently, and let other authors who use your FLA documents have a greater understanding of how the document is structured:
Name layers. Give each layer an intuitive layer name, and place related assets together in the same location. Avoid using the default layer names (such as Layer 1, Layer 2), because it can be confusing to remember or locate assets when you are working on complex files. Clearly describe the purpose or content of each layer or folder when you name them in a FLA file. This helps users to quickly understand where particular assets are found in layers or folders.
If applicable, place your layers that include ActionScript and a layer for frame labels at the top of the layer stack in the timeline. For example, it is a good and common practice to name the layer that contains your ActionScript actions.
Using scenes is similar to using several SWF files together to create a larger presentation. Each scene has a timeline. When the playhead reaches the final frame of a scene, the playhead progresses to the next scene. When you publish a SWF file, the timeline of each scene combines into a single timeline in the SWF file. After the SWF file compiles, it behaves as if you created the FLA file using one scene. Because of this behavior, avoid using scenes for the following reasons:
There are some situations where few of these disadvantages apply, such as when you create lengthy animations. If you create lengthy animations, you might find it adventageous to use scenes. If disadvantages apply to your document, consider using multiple FLA files, movie clips, or screens to build an animation instead of using scenes. For more information on using screens, see Working with Screens in Flash Help or the Flash 8 LiveDocs (Using Flash > Working with Screens).
When you save your FLA files, it is important to consider using a naming scheme for your documents. Most importantly, use a consistent naming scheme. This is particularly important if you save multiple versions of a single project.
Some problems might occur if you only work with one FLA file and do not save versions during the process of creating the file. It is possible that files might bloat in size because of the history that's saved in the FLA file, or corrupt (as with any software you use) while you are working on the file. If any of these unfortunate events occur, you will have other versions of your file to use if you save multiple versions throughout your development.
You might also encounter problems when you create an application. Perhaps you made a series of changes to the file, and you do not want to use these changes. Or, you might delete parts of the file that you want to use later in your development. If you save multiple versions while developing, you have an earlier version available if you need to revert.
Use intuitive names for your files that are easy to read, are not cryptic, and work well online. Do not use spaces, capitalization, or special characters. Only use letters, numbers, dashes, and underscores. If you save multiple versions of the same file, devise a consistent numbering system such as menu01.swf, menu02.swf and so on. Many designers and developers choose to use all lowercase characters in their naming schemes, because some server software is case sensitive. Many Flash designers and developers adopt a naming system that uses a noun-verb or adjective-noun combination for naming files. Two examples of naming schemes are as follows: classplanning.swf and myproject.swf.
It is good practice to save new versions of a FLA file when you build an extensive project. The following are different ways that you can save new versions of files:
Note: SourceSafe on Windows is the only officially supported version control software that integrates with the Project panel. You can use other version control software packages with FLA documents, but not necessarily in the Project panel.
You can use several options to save a file: Save, Save As, and Save and Compact. When you save a file, Flash does not analyze all the data before creating an optimized version of the document. Instead, the changes you make to the document are appended to the end of the FLA file's data, which shortens the time it takes to save the document. When you select Save As and type a new name for the file, Flash writes a new and optimized version of the file, which results in a smaller file size. When you select Save and Compact, Flash creates a new optimized file (removing the undo history) and deletes the original file.
Caution: When you select Save and Compact, you cannot undo any changes you made before you saved the file. If you select Save when working with a document, you can undo prior to that save point. Because Save and Compact deletes the earlier version of the file and replaces it with the optimized version, you cannot undo earlier changes.
Remember to frequently use Save As and type a new file name for your document after every milestone in your project if you are not using version control software to create backups of your FLA file. If you encounter major problems while working on the document, you have an earlier version to use instead of losing everything.
There are many software packages that allow users to use version control with their files, which enables teams to work efficiently and reduce errors (such as overwriting files or working on old versions of a document). Popular version control software programs include CVS, Perforce, Subversion, and SourceSafe. As with other documents, you can use these programs to organize the Flash documents outside Flash.
One of the most important aspects about programming is consistency, whether it relates to variable naming schemes, coding standards, or where you place your ActionScript code. Code debugging and maintenance is dramatically simplified if the code is organized and adheres to standards. Formatted code that follows an established set of guidelines is easier to maintain, and easier for other developers to understand and modify. For information on ActionScript coding conventions, see ActionScript 2.0 Best Practices.
It is important to understand where to put your ActionScript: Should it be in the FLA file, should it be put on the server in an external AS file that you "include", or should it be a class written using ActionScript 2.0? After you know the scope of your application, you should understand is how to structure your project's code. For information on choosing an ActionScript version, and how to organize and write that code, see ActionScript 2.0 Best Practices.
A general guideline for code placement is to put all your code in as few places as possible, whether you put it inside a FLA document or in external files. Organizing your code in one place helps you edit projects more efficiently, because you can avoid searching in different places when you debug or modify the ActionScript. The following sections provide more information about where to put your ActionScript.
Whenever possible, put your ActionScript in a single location. If you put code in a FLA file, put ActionScript on Frame 1 or Frame 2 in a layer called actions that is on the topmost layer in the Timeline. Alternatively, you might put all of your code in ActionScript (AS) files. Some Flash applications do not always put all your code in a single place (in particular, when you use screens or behaviors). For more information on organizing ActionScript in an application, see "Organizing Files and Storing Code". For more information on design patterns, see "Using the MVC Design Pattern".
Despite these rare exceptions, you can usually put all your code in the same location (on a frame, or in AS files). The following are the advantages of this process:
Avoid attaching ActionScript to objects in a FLA file, even in simple SWF files. Attaching code to an object means that you select a movie clip, component, or button instance; open the Actions panel; and add ActionScript using the on() or onClipEvent() handler functions.
This practice is strongly discouraged for the following reasons:
Some Flash users might say it is easier to learn ActionScript by attaching code to an object because it might be easier to add simple code, or write about or teach ActionScript this way. A significant problem exists because most people learning ActionScript need to know how to write the equivalent code, which is not difficult. The contrast between two styles of coding can also be confusing to people learning ActionScript, and requires students to learn two coding styles and forms of syntax, which is why consistency throughout the learning process has advantages.
Attaching ActionScript to a button called myButton_btn looks like the following ActionScript, and should be avoided:
on (release) {
//do something }
However, placing ActionScript with the same purpose on the Timeline looks like the following code, which is encouraged:
myButton_btn.onRelease = function() {
//do something };
For more information on ActionScript syntax, see Syntax and Language Fundamentals in Flash Help or the Flash 8 LiveDocs (Learning ActionScript 2.0 in Flash > Syntax and Language Fundamentals) as well as ActionScript 2.0 Best Practices.
Note: Different practices apply when using behaviors and screens, which sometimes involves attaching code to objects. For more information and guidelines, see "Comparing Timeline Code with Object Code" and "Organizing Code for Screens".
Behaviors are prewritten code snippets that can be instantly added to parts of a FLA file. The introduction of behaviors has added to the complexity of determining best practices in Flash, because the way some behaviors are added does not follow typical and ideal workflows. Many developers usually enter ActionScript code either into one or several frames on the main Timeline or in external ActionScript files, which is a good practice to follow. However, when you use behaviors, sometimes code is placed directly on symbol instances (such as buttons, movie clips, or components) instead of being placed on the Timeline.
Behaviors are convenient, save substantial time, and can be useful for novice Flash and ActionScript users. Before you start using behaviors, take a close look at how you want to structure your FLA file:
If you carefully plan a document that uses behaviors, you can avoid problems that could be created by decentralizing your ActionScript code.
Planning a project and organizing a document or application cannot be underestimated, particularly when you are creating large involved projects or working in teams. This is why the placement of ActionScript code—often what makes the project work—is important.
Many developers do not place ActionScript code on symbol instances, and instead place their code on the Timeline (timeline code) or in classes. Because Behaviors add code to many locations in a FLA file, it means that your ActionScript code is not centralized and can be difficult to locate. When code is not centralized, it is difficult to figure out interactions between the snippets of code, and it is impossible to write code in an elegant way. It can potentially lead to problems debugging code or editing files.
Flash has features that make it easy to work with behaviors in a document and with decentralized ActionScript code. If you use behaviors, try the following features when working on your project:
Knowing when to use behaviors is the most important guideline. Carefully consider your project and whether behaviors are the best solution for you, which can be determined by answering the questions that follow. Consider different ways of structuring your projects, as well as the different options and features available in Flash.
If you have a FLA file with symbols, you can select one of the instances on the Stage, and then use the Add menu on the Behaviors panel to add a behavior to that instance. The behavior you select automatically adds code that attaches to the instance, using object code such as the on() handler. You can also select a frame on a timeline, or a slide or form in a screen-based FLA file, and add different behaviors to a frame or screen using the Behaviors panel.
You need to decide when you need to use behaviors instead of writing ActionScript. First, answer the questions in the introductory section "Behaviors Conventions". Examine how and where you want to use behaviors and ActionScript in your FLA file. Then, consider the following questions:
The main difference between a FLA file with behaviors and a FLA file without behaviors is the workflow you must use for editing the project. If you use behaviors, you must select each instance on the Stage, or select the Stage, and open the Actions or Behaviors panel to make modifications. If you write your own ActionScript and put all your code on the main Timeline, you only have to go to the Timeline to make your changes.
Use behaviors consistently throughout a document when they are your main or only source of ActionScript. It is best to use behaviors when you have little or no additional code in the FLA file, or have a consistent system in place for managing the behaviors that you use.
If you add ActionScript code to a FLA file, put code in the same locations where behaviors are added, and document how and where you add code.
Note: If you are using a screen-based FLA file, see "Screens Conventions" for more information on best practices and screens.
For example, if you place code on instances on the Stage (object code), on the main Timeline (frame scripts), and also in external AS files, you should examine your file structure. Your project will be difficult to manage if you have code in all of these places. However, if you logically use behaviors and structure your code to work in a particular way surrounding those behaviors (place everything on object instances), at least your workflow is consistent. The document will be easier to modify later.
If you plan to share your FLA file with other users and you use ActionScript code placed on or inside objects (such as movie clips), it can be difficult for those users to find your code's location, even when they use the Movie Explorer to search through the document.
If you are creating a FLA file that has spaghetti code (code placed in many locations throughout the document) and plan to share the file, you should notify other users where your ActionScript is located in the FLA file. This ensures that other users immediately understand the structure of the file. Leave a comment on Frame 1 on the main Timeline to tell users where to find the code and how the file is structured. The following example shows a comment (on Frame 1) that tells users the location of the ActionScript code:
/* ActionScript placed on component instances and inside movie clips using behaviors. Use the Movie Explorer to locate ActionScript */
Note: It is not necessary to use this technique if your code is easy to find, the document is not shared, or all of your code is placed on frames of the main Timeline.
Document the use of behaviors if you are working with a complex document. If you keep track of where you use behaviors, you might have fewer headaches in the long run. Depending on the size of the application, you could create a flow chart, list, or use good documentation comments in a central location on the main Timeline.
Screens let you organize and develop applications using a unique way of arranging assets, which can dramatically reduce the time to write an application. You can use screens with or without using the Timeline. The process that's used to organize documents might seem logical to some developers, or make more sense for certain screen-based projects; for example, if you have to create an application that follows a linear process or has multiple states, such as one that requires server validation or multipart forms that a user must fill out and send to a database. You can also use classes that are built into screens to quickly and easily add additional functionality to your application.
Like the Behaviors guidelines, there are issues with how to organize and structure projects built with the screen-based authoring environment. Screens provide an intelligent and easy to use framework to control loading, persistence of data, and state using classes.
Some developers build applications with all their ActionScript code in a centralized location. Other designers and developers, usually newer to Flash, might use a more visual approach to writing a screens document.
There are three places you can place code in a screen-based application:
Because code can be placed in many different locations, you must consider the type of application you're writing and what it requires in the way of ActionScript code. As with behaviors, you should use ActionScript consistently in screen-based applications.
The difference between screens and behaviors is that the ActionScript code that behaviors add is much more complex than most of the behaviors available for a regular FLA file. Screens are based on complex ActionScript code, so some of the code used for transitions and changing slides might be difficult to write yourself, in which case behaviors are useful and might outweigh any drawbacks.
You might use either behaviors or ActionScript that attaches directly to screens, combined with either a timeline or an external ActionScript file. Even if you attach code directly to a screen, it is more acceptable and easier to use than in regular FLA files for the following reasons:
If you use behaviors placed on screens (or other instances), remember to document the location on Frame 1 of the main Timeline. This is particularly important if you also place ActionScript on the Timeline. The following code is an example of the comment you might want to add to your FLA file on Frame 1:
/* ActionScript is placed on individual screens and directly on instances in addition to the code on the Timeline (frame 1 of root screen). ... */
New Flash users frequently like the visual approach of placing ActionScript code for a particular screen directly on an object. When you click the screen in the Screen Outline pane, you see the code that corresponds to the instance or the name of the function that's called for that instance. This makes navigating an application and associated ActionScript code visual. It's also easier to understand the hierarchy of the application while in the authoring environment, and much easier to find code attached to screens than it is to search for object instances that have code attached to them.
You can organize your screen-based FLA file by writing external code and not having any code in the document. When you use external ActionScript code, try to keep most of it in external AS files to avoid complexity. Placing ActionScript code directly on screens is acceptable, but avoid placing ActionScript code on instances on the Stage.
You can create a class that extends the Form class. For example, you could write a class called MyForm. In the Property inspector, you would change the class name from mx.screens.Form to MyForm. The MyForm class would look similar to the following code:
class MyForm extends mx.screens.Form { function MyForm() { trace("constructor: "+this); } }
A screen-based document, when published, is essentially a single movie clip on the first frame of a timeline. This movie clip contains a few classes that compile into the SWF file. These classes add additional file size to the published SWF file compared with a nonscreen-based SWF file. The contents load into this first frame by default, which might cause problems in some applications.
You can load content into a screen-based document as separate SWF files onto each screen to reduce the initial loading time. Load content when it is needed, and use runtime shared libraries when possible. This approach reduces what the user needs to download from the server, which reduces the time that the user must wait for content if they do not have to view each different part of the application.
The use of video in Flash 8 has improved from earlier versions of Flash, and the number of websites using FLV has dramatically increased over the years. There are many options to make edits to video before you import video into a FLA document, or load FLV into a SWF file. There are also greater controls for video compression in Flash 8 and Flash 8 Video Encoder. Compressing video carefully is important because it controls the quality of the footage and the size of the file. Video files, even when compressed, are large in comparison with most other assets in your SWF file.
Note: Remember to provide the user with control over the media in a SWF file. For example, if you add audio to a document with video (or even a looping background sound), let the user control the sound.
Before you import video into Flash, consider what video quality you need, what video format you want to use with the FLA file, and how you want it to download. When you import video into a FLA file (called embedded video), it increases the size of the SWF file that you publish. This video starts progressively downloading to the user's computer whether or not they view the video.
You can also progressively download or stream the video at runtime from an external Flash Video (FLV) file on your server. When it starts downloading depends on how you structure your application.
Note: Video progressively downloads from the server like SWF files, which is not actually streaming. Even dynamically loading content has distinct advantages over keeping all your content in a single SWF file. For example, you will have smaller files and quicker loading, and the user only downloads what they want to see or use in your application.
You can display external FLV video using a component or a video object. A component makes developing applications with FLV video easy, because the video controls are pre-built, and you only need to specify a FLV file path to play the content. If you need to keep your SWF file the lowest possible size, you can display video in a Video object and create your own assets and code to control the video. You can also consider using the FLVPlayback component in Flash Professional 8, which has a much smaller file size than Media components (Flash MX Professional 2004 and later.)
Remember to give users a certain amount of control (such as the ability to stop, pause, play, and resume the video, and control volume) over the video in a SWF file. For more information on using video in Flash, see Working with Video (Using Flash > Working with Video) or About Using FLV Video (Learning ActionScript 2.0 in Flash > Working with Images, Sound, and Video > About Using FLV Video) in Flash Help or the Flash 8 LiveDocs.
You might need certain kinds of flexibility over your video, such as manipulating the video with animation, or syncing various parts of it with the Timeline. In these kinds of scenarios, you should embed your video in the SWF file rather than loading it using ActionScript or one of the Media components.
If you need more control over a video instance than the Video class allows, a best practice is to place video inside a movie clip instance. The video's Timeline plays independently from a Flash Timeline, and you can best control timelines by placing the content inside a movie clip. You do not have to extend your main Timeline by many frames to accommodate for the video, which can make working with your FLA file difficult.
You can export FLV files from Flash Basic 8 and Flash Professional 8 authoring environments. After you import video into your document, it appears as a video symbol in the library. To export the video as FLV, select the video and then select Properties from the Library options menu. Click Export in the Embedded Video Properties dialog box to make your export settings.
Flash Professional 8 includes the Flash 8 Video Encoder and the FLV QuickTime Export plug-in. The QuickTime Exporter compresses video from third-party video editing software such as Apple QuickTime Pro and Adobe After Effects. You can also use Flash 8 Video Encoder, which is a stand-alone application that you can use to create FLV files. Because you have a lot of control over the export settings, the quality of the FLV file that is created using either of these tools is better than video exported directly from Flash.
When you compress video, remember the following recommendations:
When you put FLV files on a server, they use the FLV MIME type video/x-flv. If you have difficulty viewing FLV files after you upload your files, check that this MIME type is set on your server. FLV files are binary, and some applications that you build might require that the application/octet-stream subtype is also set. For more information, read the Flash Player specifications.
For more information about FLV files on a server, see About Configuring FLV Files for Hosting on a Server in Flash Help or the Flash 8 LiveDocs (Learning ActionScript 2.0 in Flash > Working with Images, Sound, and Video > About Using FLV Video > About Configuring FLV Files for Hosting on a Server).
It's possible to create an application and then run into problems once you upload it to your server.
Note: For Flash Player and FLV compatibility, see About Using FLV Video in Flash Help or the Flash 8 LiveDocs (Learning ActionScript 2.0 in Flash > Working with Images, Sound, and Video > About Using FLV Video).
/video/water.flv), try using absolute paths (such as http://www.helpexamples.com/flash/video/water.flv). If your application doesn't work as a relative path, but does work as an absolute path, you then know that you need to correct the relative path.Projects in Flash introduce a way for members on a team to work together on a single Flash application or project. A project file remembers each of the files it contains, and lets you incorporate some SourceSafe capabilities into your applications, which helps you keep backups of modified files.
Note: Flash Professional 8 (and earlier) does not support SourceSafe for version control on the Macintosh.
You can group multiple files into a single project file using the Project panel in Flash Professional 8. This helps simplify application building, where managing related files could get complex and confusing. You can define a site for your work, create a Flash Project file (FLP), and then upload everything to the server so that a team can work on the project.
Version control lets you check files in and out of your repository, and check that only one person is working on a file at a certain time. Other benefits include the ability to revert to older versions of the files, so if your FLA file becomes corrupted or spontaneously stops working, you can revert to an older (working) version.
Version control features help you ensure that you use the correct current files when authoring, and that certain files are not overwritten. When multiple authors work on the same project, you can check that only one person has the file checked out and, during that time, another person cannot overwrite the file.
You can typically use your current source control software with Flash, but you might not be able to integrate it with the Project panel. Microsoft Visual SourceSafe is currently supported. Other software programs can manage and control your Flash documents, but you probably cannot integrate them with the Project panel. For more information on projects in Flash, see Creating and Managing Projects in Flash Help or the Flash 8 LiveDocs (Using Flash > Working with Projects > Creating and Managing Projects).
There are certain ways that you can organize your project's workflow. The following sections describe the best practices to follow when working with Flash projects and version control. For more information on using version control in Flash, see Creating and Managing Projects in Flash Help or the Flash 8 LiveDocs (Using Flash > Working with Projects > Creating and Managing Projects).
Assign an administrator to the project. This individual is responsible for creating and maintaining the project's structure. For example, documents are split up logically using folders to combine similar files. Typically, several authors work on one Flash project. The administrator confirms changes that are made to the project's structure, which encourages project stability.
Caution: The administrator is the only person who changes the project file and structure.
The project's administrator defines the site, and creates the Flash Project (FLP), main FLA document, and any subdirectories for the project's assets. These directories might include media, images, or classes that dynamically load into the project. The administrator uploads everything to the server. The administrator also creates a clear structure for the project, and communicates how it works and where to add additional assets (such as class and image files) to everyone who is working on the application.
Authors on a Flash project do not change the project root, directory structure of the project, or the site. This includes adding, removing, or changing subdirectory names, or adding additional subdirectories to the project on their local computer. If individual authors change the site or project structure, the local files are out of sync with those on the server. This causes problems in the application, such as class path and missing file errors, and so on. Individual authors can copy assets to the subdirectory files that the project's administrator creates.
Each author on a Flash project selects File > Open from Site, selects the name of the site, and then selects the project's FLP file. Then the author updates the project with any missing files. This ensures that the author is working with the latest version of the site. When the author selects Yes, all the project files download to the author's local computer, so the structure on the local computer matches the structure on the server.
When the project's structure needs to be changed, authors check in all their files. The project's administrator checks out all the files to make any necessary changes. After this is done, each person working on the project deletes the root folder of their own local copy of the project. Each individual author should use File > Open from Site to download a new copy of the site. This helps reduce errors when working with the project from accidentally using legacy files, and reduces similar versioning problems.
The best way to create different Flash applications depends on the application you create and the technology that you are using to build the application. You can refer to guidelines that can help make the application process easier. You also need to make several decisions.
An online application lets a user influence a website by interacting with it. For example, the application might collect information from the user (such as a username and password for a registration), information might be added to the site (such as in a forum), or the user might interact in real time with other site visitors (such as a chat room or interactive white board). Results from the server often appear in the SWF file, depending on the interaction. These examples are applications that involve the user and different kinds of server interaction. However, a website that does not use visitor information or data is not an application (for example, a portfolio, cartoon animation, or static informational site). Flash applications involve an interactive process between the user, a web application, and a server. The basic process is as follows:
Your ActionScript processes the data so the application can use it. When you build an application, you must select a protocol for transferring data. The protocol alerts the application when data has been sent or received, in what format the data is transferred, and how it handles a server's response. After data is received in the SWF file, it must be manipulated and formatted. If you use a protocol, you do not have to worry about data being in an unexpected format. When you are transferring data using name/value pairs, you can check how the data is formatted. You need to check that the data is formatted correctly, so you do not end up receiving XML formatted data and vice versa, so the SWF file knows what data to expect and work with.
Applications depend on user interaction with the SWF file. Frequently, it depends on the user entering data into forms, such as using combo boxes, buttons, text fields, sliders, and so on. You might create custom input devices, use the UI Components included with Flash, or download third-party components. You might collect data in a series of pages (sometimes each one is a screen) that are contained within the single SWF file, which the user submits to the server. Flash provides many ways you can enter and format data in Flash applications. This flexibility exists because of the capabilities you have with animation and creative control over the interface, and error checking and validation you can perform using ActionScript.
Using Flash to build forms to collect data has several benefits:
Tip: If you want to save information that you collect from the user, you can save it in a shared object on the user's computer. Shared objects let you store data on a user's computer, which is similar to using a cookie. For more information on shared objects, see SharedObject in Flash Help or the Flash 8 Live Docs (ActionScript 2.0 Language Reference > ActionScript Classes > SharedObject).
You must typically process information before you send it to the server, so it's formatted in a way that the server understands. When the server receives the data, it can be manipulated in any number of ways and sent back to the SWF file in a format that it can accept, which can range from name-value pairs to complex objects.
Note: Your application server must have the MIME type of its output set to application/x-www-urlform-encoded. If that MIME type is missing, the result is usually unusable when it reaches Flash.
There are many ways to send data to a server and receive data using Flash. Table 1 shows you several options.
| Send Data | Description |
|---|---|
LoadVars.send
|
Sends name/value pairs to a server-side script for processing. LoadVars.send sends variables to a remote script and ignores any response. LoadVar.sendAndLoad sends name/value pairs to a server and loads or parses the response into a target LoadVars object. |
XML.send
|
Sends XML packets instead of name/value pairs, otherwise similar to LoadVars. |
MovieClip.getURL |
Enables you to send variables from Flash to a frame or pop-up window. |
| Flash Remoting | Enables you to exchange easily complex information between Flash and ColdFusion, ASP.NET, Java, and more. You can also use Flash Remoting to consume web services. |
| Web services | Flash Professional 8 includes the WebServiceConnector component that enables you connect to remote web services, send and receive data, and bind results to components. This lets Flash developers quickly create Rich Internet Applications without having to write a single line of ActionScript code. It is also possible to consume remote web services using WebServiceClasses, which can require writing complex ActionScript. |
Try to validate any information you retrieve before you send that data to a server. This reduces strain on the remote server, because it does not handle as many requests when users do not fill in required fields. You should never solely rely on client-side validation in any application, so there must also be server-side validation.
Even if you build a simple registration or login form, check that the user has entered his or her name and password. Perform this validation before sending the request to the remote server-side script and waiting for a result. Do not rely only on server-side validation. If a user enters only a user name, the server-side script has to receive the request, validate the data being sent, and return an error message to the Flash application, stating that it requires both the user name and password. Likewise, if validation is performed only on the client side (within the SWF file), it might be possible for a user to hack the SWF file and manage to bypass the validation, and send data to your server in an attempt to post the bad data.
Client-side validation can be as simple as making sure that a form field has a length of at least one character, or that the user entered a numeric value and not a string. If you try to validate an e-mail address, for example, check that the text field in Flash isn't empty and contains at least the at sign (@) and dot (.) characters. For the server-side validation, add more complex validation and check that the e-mail address belongs to a valid domain.
You must write ActionScript code to handle the data that loads into the SWF file from the server. After you finish loading data into a SWF file, the data can be accessed from that location. It's important to use ActionScript to check whether the data has been fully loaded. You can use callback functionsor listeners to send a signal that the data has been loaded into the document.
When you load data, it can be formatted in several ways. You might load XML, and in this case, you must use the XML class methods and properties to parse the data and use it. If you use name-value pairs, the pairs turn into variables and you can manipulate them as variables.
You might receive data from a web service or from Flash Remoting. In both cases, you could receive complex data structures, such as arrays, objects, or record sets, which you must parse and bind appropriately.
An important part of application development is expecting and handling errors. No matter how simple your application might seem, there are always users who manage to enter data or interact with the SWF file in an unexpected way. Your application needs to be robust enough that it can anticipate certain errors and handle them accordingly.
For example, if you expect users to enter a numeric value into a text field, check that the value is numeric before you try and store or manipulate the value using code. If the value is not numeric, it is likely that the code will fail or return an unexpected result because the application cannot handle this result. Even if the user enters the data in the proper data type, you might have to validate that the data is usable before processing it. For example, if you did not check the validity of an integer before trying to perform a mathematical function, you might discover that your code fails when you try to divide a number by zero, which returns the numerical constant Infinity.
One of the best ways to perform error handling in Flash 8 to use the try-catch-finally blocks that let you throw and catch custom errors. By creating custom error classes, you can reuse code throughout your application without having to rewrite error handling code. For more information on throwing custom errors, see Error in Flash Help or the Flash 8 LiveDocs (ActionScript 2.0 Language Reference > ActionScript Classes > Error). For more information on try-catch-finally blocks, see Try...Catch...Finally Statement in Flash Help or the Flash 8 LiveDocs (ActionScript 2.0 Language Reference > ActionScript Language Elements > Statements > Try..Catch..Finally Statement).
After you decide on a protocol for transferring data, you must consider how to organize your SWF files, their assets, and ActionScript. How you organize and execute your application depends greatly on its design, size, and requirements. There are guidelines to help your overall success. The following are some of the primary things you must consider before you start:
When you develop an application, try to store your server-side code and files in a logical directory structure, similar to those in an ActionScript 2.0 package. Try to arrange your code this way to keep it well organized and reduce the risk of the code being overwritten. For larger applications, encapsulate client-server communication and services in classes.
When you use classes, you benefit in the following ways:
Many Flash developers implement the MVC (model, view, controller) design pattern when they build applications to separate the logic and data of the application from the user interface. This section defines how the design pattern works, and provides an overview of how and why you might use it for your Flash applications.
The MVC design pattern is used to separate the information, output, and data processing in the application. The application is divided into three elements: model, view, and controller; each element handles a different part of the process.
Each part of the model is built as a self-contained component in the overall process. If you change one part of the model (for example, you might rework the interface), it reduces problems because the other parts of the process do not usually need modification. If your design pattern is created correctly, you can change the view without reworking the model or controller. If your application does not use MVC, making changes anywhere can cause a rippling effect across all your code, which requires many more changes than if you were using a specific design pattern.
There are other reasons why MVC is valuable for some applications. An important reason to use the pattern is to separate data and logic from the user interface. By separating these parts of the process, you can have several different graphical interfaces that use the same model and unformatted data. This means that you can use your application with different Flash interfaces. Perhaps the application has a Flash interface for the web, one for Pocket PC, a version for cell phones, and perhaps an HTML version that doesn't use Flash at all. Separating data from the rest of the application can greatly reduce the time it takes to develop, test, and even update more than one client interface. Similarly, adding new front ends for the same application is easier if you have an existing model to use.
Only use MVC if you build a large or complex application, such as an e-commerce website or an e-learning application. Using the architecture requires planning and understanding how Flash and this design pattern work. Carefully consider how the different pieces interact with each other; this typically involves testing and debugging. When you use MVC, testing and debugging are more involved and difficult than in typical Flash applications. If you build an application in which you need the additional complexity, consider using MVC to organize your work.
Security is an important concern that you need to address when you build applications for the Internet. There are dishonest users who might try to hack your application, whether you build a small portal site where users can log in and read articles or a large e-commerce store. For this reason, there are several steps you can consider to secure your application.
You can post data to HTTPS for data that needs to be secured. You can encrypt values in Flash before sending them to a remote server to be processed. For example, you could find a Flash library that lets you encrypt your sensitive values using an MD5 hash to help distract casual prying eyes. However, this solution means that your server-side application code must decrypt the data after it is received or compare the encrypted version of the data against an encrypted password that is stored in a database to see if they match.
Caution: Never store any information or code in a SWF file that you don't want users to see. It is easy to disassemble SWF files and view their contents using third-party software.
Perhaps the most obvious security measure for your application to add is a cross-domain policy, which prevents unauthorized domains from accessing your assets.
Screen readers are complex, and you can easily encounter unexpected results in FLA files developed for use with screen readers, which is software that visually impaired users run to read websites aloud. Flash applications must be viewed in Internet Explorer on Windows, because Microsoft Active Accessibility (MSAA) support is limited to this browser. A screen reader is software that lets your visitors hear a description of the contents of web pages. Text is read aloud using specially designed software. Obviously, a screen reader can only interpret textual content. However, any descriptions that you provide for the overall SWF file, movie clips, images, or other graphical content are also read aloud. It is important that you write descriptions for the important images and animations so that the screen reader can also interpret these assets in your SWF file. This is the SWF file equivalent to alt text in an HTML web page.
Freedom Scientific JAWS for Windows is one of the most common screen readers available; version 4.5 and later is compatible with Flash Player 6 (6.0.21.0) and later. Window Eyes by GW Micro is another one of the most commonly used screen readers, and version 4.2 and later is supported by Flash Player 6 (6.0.21.0) and later. Accessible content is interpreted differently by each of these screen readers, and might also behave differently on different players. You can download free but time-limited demo software from the following websites:
Note: Flash Player 7 (and later) does not work with all screen reader technologies. It is up to the third-party software provider to handle the information provided by MSAA.
Flash Player uses Microsoft Active Accessibility (MSAA) to expose Flash content to screen readers. MSAA is a Windows-based technology that provides a standardized platform for information exchange between assistive technologies, such as screen readers, and other applications. Events (such as a change in the application) and objects are visible to screen readers by using MSAA.
Making a website accessible involves several different criteria:
Historically, many online presentations (such as videos) provide alternate ways for visually impaired visitors to access the content. An example of this would be a textual description of a video. However, Flash provides textual information directly to the screen reader. Although this usually means you need to make additional settings or ActionScript adjustments in a FLA file, you do not have to create a completely separate version.
Parts of your SWF file can be exposed to screen readers. Text elements (such as text fields, static text, and dynamic text), buttons, movie clips, components, and the entire SWF file can be interpreted by MSAA-compliant screen readers. The following sections discuss how to work with Flash and screen readers.
Section 508 is legislation in the United States that provides guidelines for making information accessible to people with disabilities, such as vision impairments. Section 508 specifically addresses the need for websites to be accessible in several ways. Some websites, including all federal websites, must comply with these guidelines. If a SWF file does not communicate all of the information to the screen reader, the SWF file is no longer Section 508-compliant.
Many nations have specified standards and guidelines (such as the Web Accessibility Initiative) to follow to create accessible websites, or follow guidelines established by other organizations. These standards and guidelines do not offer much assistance when working with Flash content, but describe what factors you must address when you create accessible HTML websites, and some of this information applies to Flash.
Because of the highly visual nature of some SWF files, the layout and navigation of the page can be complex and difficult for screen readers to translate. An overall description of the SWF file is important to communicate information about its structure and how to navigate through the site's structure. You can provide this description by clicking the Stage and entering a description into the Accessibility panel. You could also create a separate area of the site to provide this description or overview.
Note: If you enter a description for the main SWF file, this description is read each time the SWF file refreshes. You can avoid this redundancy by creating a separate informational page.
Inform the user about any navigational elements that change in the SWF file. Perhaps an extra button is added, or the text on the face of a button changes, and this change is read aloud by the screen reader. Flash Player 7 and later supports updating these properties using ActionScript. This means that you can update the accessibility information in your applications if the content changes at runtime. For more information on updating accessible properties at runtime, see Creating Accessibility with ActionScript in Flash Help or the Flash 8 LiveDocs (Using Flash > Creating Accessible Content > Creating Accessibility with ActionScript).
Designers and developers can assign descriptions for the animations, images, and graphics in a SWF file. Provide names for graphics so the screen reader can interpret them. If a graphic or animation does not communicate vital information to the SWF file (perhaps it is decorative or repetitive), or you outlined the element in the overall SWF file description, do not provide a separate description for that element. Providing unnecessary descriptions can be confusing to users who use screen readers. For more information on assigning names and descriptions, see Using Flash to Enter Accessibility Information for Screen Readers in Flash Help or the Flash 8 LiveDocs (Using Flash > Creating Accessible Content > Using Flash to Enter Accessibility Information for Screen Readers).
Note: If you divide text or use images for text in your SWF files, provide either a name or description for these elements.
If you have several nested movie clips that serve a single purpose or convey one idea, ensure that you do the following:
Note: Do not type a description in the Description field of the Accessibility panel for instances (such as text) that the screen reader reads aloud.
It is tempting to use a wide array of colors in a Flash SWF file. It is possible to use all these colors in an accessible SWF file, but you must make some decisions about it. For example, you must not only rely on color to communicate particular information or directives to users. A color-blind user cannot operate a page if it asks to click the blue area to launch a new page or the red area to hear music. Offer text equivalents on the page or in an alternate version to make your site accessible. Also, check that there is significant contrast between foreground and background colors to assist users who have difficulty seeing particular colors, to enhance readability. If you place light gray text on a white background, users cannot easily read it. Similarly, small text, which is commonly found in many Flash websites, is difficult for many visitors to read. Using high-contrast and large or resizable text benefits most users, even those without impairments.
The reading order and tabbing are possibly the two most important considerations for making accessible Flash websites. When you design an interface, the order that it appears on the page might not match the order in which the screen reader describes each instance. There are ways you can control and test reading order, as well as control tabbing in the SWF file.
Screen readers sometimes read assets in an unpredictable order. The default reading order does not always match the placement of your assets or the visual layout of the page. If you keep the layout simple, this can help create a logical reading order without the need for ActionScript. However, this isn't always possible and doesn't necessarily work as expected. You have more control over the order in which your content is read if you use ActionScript. For more information on controlling reading order using ActionScript, see Creating Accessibility with ActionScript in Flash Help or the Flash 8 LiveDocs (Using Flash > Creating Accessible Content > Creating Accessibility with ActionScript).
Because the default reading order is not predictable, use ActionScript and test the reading order in your SWF files.
Caution: Do not miss ordering a single instance in your SWF file, or the reading order reverts to the default (and unpredictable) reading order.
Visitors who rely on screen readers to describe a site's content typically use tabbing and keyboard controls to navigate around the operating system and web pages, because using the mouse is not useful when the screen cannot be seen. You should offer intelligent tabbing control in accessible SWF files using the tabIndex and tabEnabled properties with the movie clip, button, text field, or component instances. In addition to tabbing, you can use any key press actions to navigate through the SWF file, but you must communicate that information using the Accessibility panel. Use the Key class in ActionScript to add keypress scripts to the SWF file. Select the object for which you want to use the keypress script, and add the shortcut key in the Shortcut field on the Accessibility panel. Add keyboard shortcuts to essential and frequently used buttons in your SWF file.
Note: Avoid invisible buttons in accessible SWF files, because screen readers do not recognize these buttons. (Invisible buttons are buttons for which you define only a hit area, the clickable region, for the button.)
Similarly, give your users control over the content of the SWF file. Many SWF files have a rapid succession of information, and screen readers frequently cannot keep up with this pace. It is simple to resolve this problem by handing control of the process to your user. Provide controls for the SWF file, letting the user step through the file at their own pace using buttons, and letting them pause the process if necessary. Users with screen readers might interpret the content at a slower pace than other users, so giving control to the user is important in these cases.
Many SWF files contain audio, video, and narrations, because it is easy and robust to deliver this media using Flash. When you provide audio narrations or video that contains speech, it is important to provide captions for those users who cannot hear. You can use text fields in Flash, import video that contains captions, or even use an XML caption file. You can use video cue points to specify when a text field should update text information at runtime. For information on using captions in Flash, see Accessibility for Hearing-Impaired Users in Flash Help or the Flash 8 LiveDocs (Using Flash > Creating Accessible Content > Accessibility for Hearing-Impaired Users).
For information on using Hi-Caption SE and the Hi-Caption Viewer component, see the Flash Professional 8 Third-Party Extensions product page. This third-party extension lets you create captions that you save in an XML file and load into the SWF file at runtime, among other advanced controls. Alternatively, you can use cue points and a text field to display caption information.
With the extensibility layer in Flash 8, developers can create extensions that enable advanced authoring with little effort. This enables third-party companies to develop extensions that involve accessibility. You have several options for validating your SWF files or adding captions.
For example, a validation tool can look through your SWF file for missing descriptions. It checks to see if a description is added for a group of instances, or if text has a label for the instance, and tells you about any problems. The tool also examines the reading order in your SWF file, and finds all instances that must be specified. Reading order can be specified after the SWF file is analyzed using a dialog box.
For information on the currently available third-party extensions, see the Flash Professional 8 Third-Party Extensions product page.
It is strongly advised that you test any SWF file that is intended for use with screen readers. Test your SWF files when each new version of Flash Player is released, including minor revisions, such as Flash Player 7 (7.0.19.0). In addition to testing the SWF file with different Flash Players, also test the SWF file with both Window Eyes and JAWS for Windows screen readers. These two screen readers handle SWF files differently, so you could get different results for the user experience.
Note: You do not have to test different browsers, because the technology used to expose SWF files to screen readers (MSAA) is supported only by Internet Explorer on Windows.
To test your sites with a screen reader:
When listening to your SWF file using a screen reader, Ask yourself the following questions:
Many opportunities exist for creating interactive and engaging advertisements using SWF files. Adobe recommends that you follow several guidelines when you produce Flash advertisements, based on standards set up by the Interactive Advertising Bureau (IAB).
It is recommended that you use the Interactive Advertising Bureau (IAB) guidelines to set dimensions for your Flash advertisements. Table 2 lists the recommended Interactive Marketing Unit (IMU) ad formats measurements.
| Type of Advertisement | Dimensions (pixels) |
|---|---|
| Wide skyscraper | 160 x 600 |
| Skyscraper | 120 x 600 |
| Half-page ad | 300 x 600 |
| Full banner | 468 x 60 |
| Half banner | 234 x 60 |
| Micro bar | 88 x 31 |
| Button 1 | 120 x 90 |
| Button 2 | 120 x 60 |
| Square button | 125 x 125 |
| Vertical banner | 120 x 240 |
| Leaderboard | 728 x 90 |
| Medium rectangle | 300 x 250 |
| Square pop-up | 250 x 250 |
| Vertical rectangle | 240 x 400 |
| Large rectangle | 336 x 280 |
| Rectangle | 180 x 150 |
When you create a new FLA file from a template (Select File > New and click the Templates tab), you see many of these sizes.
Optimize your graphics as much as possible. For more information on optimizing graphics and animations, see "Optimizing Graphics and Animation". Make your SWF file banner advertisements 15K or smaller. Create a GIF banner advertisement in Flash that is 12K or smaller. Limit looping banner advertisements to three repetitions. Many websites adopt the standardized file size recommendations as advertising specifications.
Use the GET command to pass data between an advertisement and a server, and do not use the POST command. For more information on GET and POST, see getURL Function in Flash Help or the Flash 8 LiveDocs (ActionScript 2.0 Language Reference > ActionScript Language Elements > Global Functions > getURL Function).
Note: Remember to provide control to the user. If you add sound to an advertisement, also add a mute button. If you create a transparent Flash ad that hovers over a web page, always provide a button to close the advertisement for its entire duration.
Several leading advertising networks now support standardized tracking methods in FlashSWF files. The following guidelines describe the supported tracking methodology:
Add a script to the button. This script executes when a user clicks the banner. You might use the getURL() function to open a new browser window. For example, you might add the following to Frame 1 of the Timeline:
myButton_btn.onRelease = function(){
getURL(clickTAG, "_blank"); };
You might add the following code to Frame 1 of the Timeline:
myButton_btn.onRelease = function() { if (clickTAG.substr(0, 5) == "http:") { getURL(clickTAG); } };
The getURL() function adds the variable passed in the object and embed tags, and then sends the browser that is launched to the specified location. The server hosting the ad can track clicks on the advertisement. For more information on using the getURL() function, see getURL Function in Flash Help or the Flash 8 LiveDocs (ActionScript 2.0 Language Reference > ActionScript Language Elements > Global Functions > getURL Function).
Assign clickTAG code for tracking. This code tracks the advertisement and helps the network serving the ad to track where the ad appears and when it is clicked. The process is the standard way of creating an advertising campaign for a typical Flash advertisement. If you assign the getURL() function to the banner, you can use the following process to add tracking to the banner. The following example lets you append a variable to a URL string to pass data, which lets you set dynamic variables for each banner, instead of creating a separate banner for each domain. This means that you can use a single banner for the entire campaign, and any server that is hosting the ad can track the clicks on the banner.
In the object and embed tags in your HTML, you would add code similar to the following example (where www.helpexamples.com is the ad network, and adobe.com is the company with an advertisement):
<EMBED src="your_ad.swf?clickTAG= http://helpexamples.com/tracking?http:// www.adobe.com">
And you would add the following code in your HTML:
<PARAM NAME=movie VALUE="your_ad.swf?clickTAG =http://helpexamples.com/ tracking?http://www.adobe.com">
For more information on advanced tracking techniques, see the Rich Media Advertising Center. You can also download the Rich Media Tracking Kit, which includes examples and documentation.
To learn more about and download the Flash Ad Kit, which helps you deliver integrated and sophisticated advertisements, see Building and Deploying Rich Media Ads with the Macromedia Flash Ad Kit.
Ensure that your SWF file ad works on the most common browsers, and, in particular, the ones that your target audience use. Some users might not have Flash Player installed or they might have JavaScript disabled. Plan for these circumstances by having a replacement (default) GIF image or other scenarios for these users. For more information on detecting Flash Player, see Setting Publish Options for the Flash SWF File Format in Flash Help or the Flash 8 LiveDocs (Using Flash > Publishing > Publishing Flash Documents > Setting Publish Options for the Flash SWF File Format). Be sure to give the user control of the SWF file. Let the user control any audio in the ad. If the advertisement is a borderless SWF file that hovers over a web page, let the user close the advertisement immediately and for the duration of the ad.
For the latest information on Flash Player version penetration for different regions, go to the Macromedia Flash Player Version Penetration page.
SWF file performance is important, and you can improve performance when you create your FLA document—from how you write ActionScript code, to how you build animations. This section provides guidelines and practices that help improve the performance of your SWF file at runtime.
For more information on code optimizations for Flash Player, see ActionScript 2.0 Best Practices.
The first step in creating optimized and streamlined animations or graphics is to outline and plan your project before its creation. Specify a target for the file size and length of the animation that you want to create, and test throughout the development process to ensure that you are on track. If you are creating advertisements, for example, length and file size are extremely important.
Avoid using gradients, because they require many colors and calculations to be processed, which is more difficult for a computer processor to render. For the same reason, keep the amount of alpha or transparency you use in a SWF file to a minimum. Animating objects that include transparency is processor-intensive and should be kept to a minimum. Animating transparent graphics over bitmaps is a particularly processor-intensive kind of animation, and must be kept to a minimum or avoided completely.
Note: The best bitmap format to import into Flash is PNG, which is the native file format of Macromedia Fireworks from Adobe. PNG files have RGB and alpha information for each pixel. If you import a Fireworks PNG file into Flash, you retain some ability to edit the graphic objects in the FLA file.
Optimize bitmaps as much as possible without overcompressing them. A 72-dpi resolution is optimal for the web. Compressing a bitmap image reduces file size, but compressing it too much compromises the quality of the graphic. Check that the settings for JPEG quality in the Publish Settings dialog box do not overcompress the image. If your image can be represented as a vector graphic, this is preferable in most cases. Using vector images reduces file size, because the images are made from calculations instead of many pixels. Limit the number of colors in your image as much as possible while still retaining quality.
Note: Avoid scaling bitmaps larger than their original dimensions, because it reduces the quality of your image and is processor-intensive.
Set the _visible property to false instead of changing the _alpha level to 0 or 1 in a SWF file. Calculating the _alpha level for an instance on the Stage is processor-intensive. If you disable the instance's visibility, it saves CPU cycles and memory, which can give your SWF files smoother animations. Instead of unloading and possibly reloading assets, set the _visible property to false, which is much less processor-intensive.
Try to reduce the number of lines and points you use in a SWF file. Use the Optimize Curves dialog box (Modify > Shape > Optimize) to reduce the number of vectors in a drawing. Select the Use Multiple Passes option for more optimization. Optimizing a graphic reduces file size, but compressing it too much compromises its quality. However, optimizing curves reduces your file size and improves SWF file performance. There are third-party options available fo