Publishers of technology books, eBooks, and videos for creative people

Home > Blogs > Adobe Flash Catalyst: Under the Hood - Part 3 Design Integration Workflows

Adobe Flash Catalyst: Under the Hood - Part 3 Design Integration Workflows

In Part 3 of this continuing series, guest authors James Polanco and Aaron Pedersen show how Flash Catalyst eases the designer's task of creating user elements for a Flex project.

James Polanco and Aaron Pedersen are the guiding geniuses behind the Web development firm, based in San Francisco. James and Aaron are working on a book for Adobe Press on integrating Adobe Flash Catalyst and Flash Builder 4 (both just released as public betas) into the Web designer/developer workflow. Throughout June, they'll be posting a weekly series of items that takes a peek "under the hood" of these innovative tools. Check back each Monday for a new installment!

Adobe Flash Catalyst: Under the Hood—Part 3 Design Integration Workflows

By James Polanco and Aaron Pedersen

In our previous posts (which you can find here and here) we have started to look at the potential designer and developer workflows that Flash Catalyst enables. In this post, we will examine these workflows in more depth and review how Flash Catalyst can be used to integrate a design into a Flex project.

The first step of this new workflow is to use Flash Catalyst to open and then convert design files from Illustrator, Photoshop, and Fireworks (using CS4 versions or later and saving as FXG) into Flex projects. Catalyst takes the design files, examines the layers and assets in the files and then converts the assets into MXML and MXMLG (MXML Graphics).

Before we explain what MXMLG is we should look at how current design content is rendered and developed in Flex. In Flash or Flex, if a designer or developer wanted to render vector content (outside of using Flash Professional) they would have to use ActionScript’s drawing library. For example, this is how you would create a green 200x200 rectangle in ActionScript:

However, this is not how most designers think of creating graphics. Requiring users to write ActionScript to do this kind of design work severely restricted who (and what) could create and read this content.

To solve this challenge, Adobe has created two new languages: MXMLG and FXG. MXMLG is a new addition to the Flex MXML language set which enables developers and designers (and their tools) to create graphical representations in an XML-based declarative language. FXG is a file type that wraps the MXMLG syntax. The simplest way to look at it is like this: FXG is MXMLG and MXMLG is FXG. The difference between the two is really just where the code is written, in a file or in MXML.

Back to our rectangle example, we would write it in MXMLG (and FXG) as this:

This code draws the exact same rectangle as the ActionScript version. The benefit of writing it in this new syntax is that its now easier to read, and more importantly, tools such as Flash Catalyst can both parse and write this code with ease.

Now, going back to our designer workflow, Flash Catalyst reads in the design file and then converts all the layers and assets into the MXMLG format. Once the content has been translated into MXMLG, it adds the code to a base Flex Application MXML file and our design is imported into Flex.

This conversion is just the first step for the Flash Catalyst user. At this point, all we have done is taken a static design file and converted it to a static Flex file. If we compiled our Flex code and launched it in a browser, it would be similar experience to exporting our design to a single PNG file and opening it in a browser. It looks nice but there is no interaction.

The next step is to take our newly created Flex design assets and convert them into Flex components and UI (user interface) skin files. A Flex component is a UI element that provides a defined set of functionality and graphical display abilities, such as a button or a data list.

Let’s examine components in a bit more detail. A button is a very common UI element in applications. It handles user interactions such as mouse clicks or rollovers and it also provides both visual and programmatic feedback.

For example, when the user rolls the mouse over the button we can change the look of the button to inform the user that their mouse is over the button and that they can interact with it. When the user clicks the button we can also change the look so that the button appears depressed. Each of these looks, are called States. A button component has four distinct UI States: Up, Down, Over and Disabled. Developers can also tie additional logic into the Button so that when the user clicks on the button the application can show a dialog or submit a form.

In previous versions of Flex, changing the look and feel of a button took a lot of code and work to meet the design’s needs because the skins (design assets) and logic were all intertwined within the ActionScript code. This meant that if you wanted to change the Up state of the button or you wanted to fade from the Up to Over state as the user rolled over the Button, the developer would have to take the static assets (for Up and Over) and then integrate them into the code.

The new Flex component architecture now separates logic from design and this is a very powerful and important change. By separating logic from the look and feel we can now update and change the design without having to edit the ActionScript code to support the new changes.

This is implemented by creating a separate skin MXML file that defines the look and feel for each state using MXMLG, MXML Effects and MXML States. The MXML application code then tells the Button which skin file to use to render out the UI. Now that the UI definition is separated in an external file we can easily change the Up state or the fade effect from Up to Over in the skin MXML file, which saves the developer from having to write any ActionScript.

This separation also enables better tooling support. Flash Catalyst can read and write skin files automatically, and provide intelligent and easy to use UI controls to the user so that they can change the look or timing of an animation effect or UI element without having to write a line of code.

Returning back to our imported design file, the next step in the workflow is to define what parts of our design are components and which of these assets represent the components different states. In the next post, we will examine this process in detail and show some basic examples of how to convert assets into components.

Here are the other posts in this series:

Part 1: Introduction

Part 2: The Platform

Part 4: Converting & Skinning Components

Part 5: The Transport