Prerequisite knowledge

Some previous experience with Flash Catalyst or Flash Builder will help you make the most of this article.

User level


Adobe Flash Catalyst CS5.5 and Adobe Flash Builder 4.5 have a host of new features that enable workflows for building engaging and expressive Flex applications. The workflow you use will depend on the kind of team you have and the size of the application you are building. Your first option is to use Flash Catalyst as a wireframing tool.  As a wireframing tool, you can rapidly create application layouts, choreography and interactions.  If your goal is simply a wireframe then you might stay exclusively in Flash Catalyst CS5.5.  If you are planning to develop the wireframe further into an interactive prototype, you’ll likely include Flash Builder 4.5. When working with Flash Builder, Flash Catalyst is a great tool for visual creation of Flex Spark skins.  The Spark Skinning architecture was introduced in Flash Builder 4.  For an in-depth look at Spark skinning check out this article by Flex SDK engineer Ryan Frishberg.

In a single-person or small team workflow, Flash Builder and Flash Catalyst can easily package your project for quick roundtripping.

A larger team can structure applications to leverage the power of Flex Library Project (FXPL) files. FXPLs are collections of components, skins, and assets, but they have no concept of application state.

Creating wireframes and prototypes

Flash Catalyst CS5.5 is a powerful tool for creating wireframes. It can help you conceptualize application flow at a high level and demonstrate choreography from one to screen to the next. Figure 1 illustrates a workflow for creating wireframes and prototypes that includes Adobe Illustrator or Adobe Photoshop for editing art.

If a wireframe is your end goal, the roundtrip workflow with Photoshop and Illustrator may not be needed. Flash Catalyst CS5.5 introduced a Common Library panel (see Figure 2), which contains Spark-based Flex components and Placeholder components designed specifically for creating wireframes.

Asset roundtripping between Flash Catalyst CS5.5 and Photoshop CS5.1 or Illustrator CS5.1 is very similar to roundtripping in Flash Catalyst CS5. You can import PSD or AI files at any point in the process and edit any part of the design in its native tool. By incorporating design assets, you can extend the wireframe to create a high fidelity interactive prototype.

You can quickly and easily convert a wireframe in Flash Catalyst to a high fidelity prototype using the new Replace With feature. This feature enables you to select objects in your wireframe and replace them with high fidelity artwork, components, or skins, while preserving as much information as possible.

The single-person or small team workflow

If your team consists of just you (or you and one other person), then FXP roundtripping between Flash Builder 4.5 and Flash Catalyst CS5.5 is for you! Figure 3 illustrates this much requested feature.

In this workflow, after creating your wireframe or high fidelity prototype in Flash Catalyst you simply save the FXP file and import it into Flash Builder 4.5. Once in Flash Builder, you begin adding business logic, connecting to data and web services, adding advanced layouts, and stubbing out custom components.  Flash Builder 4.5 features a Flash Catalyst compatibility checker.  When you import an .FXP file from Flash Catalyst or create a Flash Catalyst compatible project in Flash Builder, the compatibility checker is automatically turned on.  After reviewing and handling any compatibility warning shown in the Problems panel, you have two options. If you are working with someone else, you can export a FXP file and hand off the project. If you are working by yourself, you can use Flash Builder 4.5 to launch Flash Catalyst (see Figure 4) and continue working. 

When you invoke the Edit Project in Flash Catalyst command, Flash Builder will package up all the required parts of your project and launch Flash Catalyst to open the project for editing. Once all edits are complete, simply save your project in Flash Catalyst, return to Flash Builder, and choose File > Flash Catalyst > Resume Working On Project In Flash Builder.

The multiperson workflow

For a large team with a multiperson workflow, project structure becomes much more important. When multiple people are working on a project, passing a single project file around can represent a significant bottleneck. This is where Library Projects are particularly useful. Both Flash Builder and Flash Catalyst enable you to import and export Library Projects to support a multiperson workflow (see Figure 5).

The multiperson workflow may start in Flash Catalyst with a wireframe or high fidelity prototype. It may also start in Flash Builder as a developer-driven Flash Catalyst compatible Flex project. For example, in a developer-driven workflow, the developer would create a Flash Catalyst compatible Flex application in Flash Builder 4.5 with several supporting Library Projects. One of these Library Projects would contain custom components to be skinned in Flash Catalyst. This Library Project can be exported as an FXPL file and edited in Flash Catalyst. (Flash Catalyst cannot open a FXPL file directly; instead a new blank Flash Catalyst project must be created and then the FXPL can be imported). Any ActionScript-based components that extend SkinnableComponent will appear in the Skinnable Component list in Flash Catalyst. In this workflow, you can assign art to custom defined SkinParts. Once skinning is complete, the designer exports the library from Flash Catalyst and it is merged back into the Library Project in Flash Builder. This enables the designer to update the visuals in multiple iterations while development continues on the application.

Where to go from here

The workflows covered in this article are merely suggestions; your workflows will depend on the needs of your team and your project. For example, even if you are working in a small team, you may find that your project requires a large project architecture and that the FXPL-based workflow is more appropriate. The workflows discussed above were organized in terms of team size, but the real driving factor may well be the size and scale of the application under development.