Many designers coming from a print background run into significant issues when moving to the Web by failing to grasp or acknowledge the differences between the media.

Even though Web sites may closely resemble print documents, particularly as both are made primarily of text and images, the Web is nonetheless as different a design medium from print as is video. Designing a television commercial would necessarily require a different design approach from designing a printed brochure. The same is true for Web sites.

For example, when a document is printed, it will always be precisely the same size. A designer of an 8½ × 11 newsletter knows that the document will always be those dimensions, and thus can plan exactly what size font to use and how big graphics should be.

On the Web, however, designers have no control over the size and resolution of the user's monitor. While Catalyst projects are at a fixed size, you cannot predict how much of a document will appear on a user's screen without scrolling, or how big or small the fonts may appear due to the user's screen resolution.

The project you design will eventually end up running in Flash Player. While a static design will certainly work, you can and should plan to leverage Flash Player's powerful animation capabilities in your application. After all, if you are not going to have any interactivity, there is little reason to use Catalyst and Flex at all: Your design would likely look the same in HTML and would possibly be quite a bit easier to create.

What separates Flex applications from their HTML counterparts is the interactivity and animation offered by Flash Player.

As you design, consider state transitions and how they might enhance your design. Think about what elements might be enhanced by the addition of action sequences. Plan to take advantage of a button's built-in states, and design Up, Down, and Over appearances for them.

Catalyst makes adding video and audio to a project a matter of a few clicks. Both, if used appropriately, can dramatically enhance the user's experience in your application.

While leveraging Flash Player's capabilities can enhance an application, it can as easily detract from it. Use animation when appropriate, but do not use it merely because you can. Be sure that audio, video, and animation add something to the experience and are not in the project "just because."

Illustrator, somewhat unfortunately, makes it very easy to create projects with hundreds of layers with generic names such as Path or Group. When designing for print, these meaningless layer names are usually not a reason for concern, since the printer does not need to worry about working with the layers.

When designing for Catalyst, however, many layers with meaningless names can create headaches, as the layer's purpose might not be as clear when working in Catalyst as it was in Illustrator. Also, there is a possibility that while you understand what the layers represent, another designer or developer who need to work with the Catalyst version of the document will not. Be sure that you name your layers appropriately. Group layers logically and give the groups meaningful names.

Follow the same rules once you start working in Catalyst. Rearrange and rename any layers from Illustrator that were not grouped or named well initially. As you create new layers and sublayers, get in the habit of immediately renaming them.

Once you complete your work in Catalyst, you will likely be handing the project off to a Flex developer. While in an ideal situation the developer will have been involved in some way from the beginning of the design process, in many real-world situations the developer may be seeing the project for the first time when it is opened in Flash Builder.

Your Flex developer will not see or need to deal with layer names — keeping them organized will merely help you. The developer, however, will spend a considerable amount of time working with the components you create. Therefore, be sure to rename components as you create them. The developer may not inherently understand the meaning of the components or the roles they play in the application if the components do not have meaningful names.

An application that contains several forms named CustomComponent1 and CustomComponent2 will be much more difficult to work with than one with forms named ContactForm and SubscriptionForm. Follow the same rules with states, another element with which your developer will spend considerable time.

When you create a component from a layer in Catalyst, both the component and the layer will be given the same name. However, they are different elements, and either can be renamed later without affecting the other.

Remember that component and state names cannot contain spaces, and that the case you use will matter to your Flex developer. Most name components using Pascal casing, whereby the first letter of every word is capitalized, such as FirstName or MagazineTitle.

State names generally use camel case, which capitalizes the first letter of each word other than the first: homeState or subscriptionState.

If your role is and will remain a designer, it will likely be a waste for you to invest a large amount of time in learning Flex. However, you need to understand that as a Catalyst designer, you are designing for Flex. Just as a print designer can only get better at his job by understanding how commercial printers work, you will find that having an idea of how Flex works will help you better understand Catalyst and better understand the needs of your developer.

If you skipped over the chapters late in this book that covered those topics, go back and read them. I didn't write them with the idea of turning any designers into developers; rather, I intended to give designers a foundational knowledge of the technologies for which they will be designing.

Unless you are the sole designer and developer, the single most important key to the success of your project will be communication.

If you are a designer, you likely have a very different background from your developer and almost certainly will have a different approach to the project. Any time you are unsure if something you are doing will adversely affect the developer's job in finishing the project, you should communicate with her to see what you can do to minimize or avoid that impact.

As a Flex developer, you may be as intimidated by Illustrator and Photoshop as designers who specialize in those programs are of Flex and programming. You need not become an expert in either, but gaining a basic understanding of how they work and what they can and cannot do will help you work better with the files you get from them.

If, as a developer, you skipped over the early chapters in this book on those tools, go back and read them. I didn't write them to convert developers to designers but rather to give developers an idea of what those programs can do.

Many Flex developers have traditionally treated design as a sort of afterthought, believing that the functionality of an application was more important than its design.

In fact, neither function nor design is more important than the other: The best applications are those in which the design attracts users and aids them in accomplishing tasks, while obviously the functionality allows them to do those tasks.

When working in Catalyst, and even more so when working with a separate designer, carefully plan the application and its design. This will greatly reduce the number of design revisions that must be made and reduce the potential conflicts and frustrations between the designer and the developer.

Once you open and begin modifying a project in Flash Builder, neither you nor the designer will be able to open and continue modifying that design in Catalyst.

Inevitably, however, design changes will need to be made. Your designer can open a backup copy of the project in Catalyst, make the changes, and then send the changed project to you to be merged into your existing project. These changes will most likely be contained almost entirely, if not completely, in the skins and visual components.

Your task merging the changes will be made much easier if you refrain from altering these files in Flash Builder. That way, when you are merging the projects, you will know that any changes to the skins will be the revisions from Catalyst and can rest assured that merging those changes will not break anything that you have done in the project.

As a developer receiving a design from a designer, the more you communicate with your designer, the better off you both will be.

If, in the initial design and planning phase, you see elements of the application that will be difficult to implement, speak up then. As the design progresses, stay involved so that you can deal with issues as they arise, rather than waiting for a finished but largely unworkable design to be delivered to you.

After you receive the project, continue to communicate changes you make to your designer. If she needs to make further changes to the Catalyst project later, she can have a good idea as to what you have done and how that might impact the decisions she will need to make.

Optimize graphics right away when you import art into Catalyst. Optimized graphics are not only easier to work with, but also make Catalyst run more efficiently. Keep in mind that optimized graphics cannot be altered at run-time in the application; that is, your developer will not be able to write code that changes the graphic dynamically while the program runs in Flash Player. Therefore, any graphics that might need this capability should not be optimized, but all others should.

Convert objects to components before adding them to states. As much as possible, group elements into custom or generic components. Elements that do not make sense as components should be grouped into logical sets.

When setting up states, first define the location, visibility, and appearance for each element in the state. Then specify the transitions between that state and other states in the application. Finally, define the interactions on the components that will trigger the state changes.

You do not need to define a separate component for each element if those elements all serve the same basic purpose.

For example, rather than defining a separate text input component for each field in a form, you can define a single component and then reuse it. Doing so will not only minimize the file size of the project but will also make working with the project in Flash Builder easier.

Duplicate states can be copies of the original state as of the moment the new state was created. Any changes to the elements of a state after duplicate states are created only effect that state.

Changing an element on a state that exists on another state will cause a transition to be created for the change. If you alter something on a state and need that alteration to carry through to other states, be sure to choose Modify

Particularly when defining interactions and transitions, preview the project frequently to make sure you are getting the effects you want.