Adobe Flash Catalyst is a new software to design interfaces. It is clearly different than other software because of its purpose : to fill the gap between design software (such as Photoshop or Illustrator) and the development software of these interfaces (FlashBuilder).
Despite a release date due to first semester of 2010, Adobe offers a beta version of this software ; probably to answer to the recent release of SketchFlow by Microsoft.

Until now, the style, the appearence and the graphics elements was passed to the development team via a Flash library (SWF file) and a style sheet (CSS file).
But a prototype made with Catalyst can be directly converted to a development project, what is very interesting to us.

This second article follow the one about design of interfaces and talks about the collaboration between the designers and the developers through Catalyst :

1. Code from the prototype
2. Designer/developer workflow
3. Best practices
4. Conclusion & links

1. Code from the prototype

Indeed, Flash Builder, formely called Flex Builder, can convert a Catalyst file into a Flex project.
This projet will be the same as the protype (since Catalyst use Flex), and could implement the needed features.

However, the generated project is not at all oriented for the development :

• Some constraintes of Catalyst force a component layout which does fit the development needs.
• Some components will be coded with Flash Builder (ex : a dynamic menu).
• In general, the object-oriented programmation mecanismes (especially the inheritage) are not used.
• Catalyst does not produce a code which can be integrated in architecture such as Cairngorm.
• Catalyst does not take in consideration any server response.

The project generated from the prototype should be seen as a canvas for the future developments. The structure of the project will evolve a lot, because the goals of a prototype are not the same of a development project.


2. Designer/developer workflow

The work of conception and development are not sperated : the conception can evolve and can impact the development. Therefore, in big projects, it is easier to divide an application in features group, which are mastered easily.
However, Catalyst cannot divide the prototype into features group. If the prototype integrates a new feature after the development started, this one will be manually passed to the development project.



On the other hand, the look & feel can be changed in the prototype and passed to the project via Catalyst.
An approach consists in creating a library of components from the prototype, then creating a project which uses it : this is an handy way to allow the designers to modify the look a posteriori. For example, changing the look of a button. About this, you can read the nice article of Marc Hughes.
However, this approach needs a big amount of work, and obliges the developer to follow the Catalyst way, which is not oriented for the development.

But thanks to the new architecture of the Flex components, the look of its is fully separated from the rest. Why not isolate these files and allow the modifications of its only through Catalyst, whereas the rest is totally alterable with Flash Builder ?

Here is an Adobe AIR application which will do so : download Catalyst Plus

Among the Flex components, only the look of the buttons, lists, textfields and scrollbars can be changed with Catalyst. Here is an example to show how to change the look of a button and passed this change to the development project :

However, it has been announced that the others components could be changed in the final version of Catalyst. For the moment, the look of such components can be changed this way :

But the layout could not be changed and the added states will be ignored.


3. Best practices

Here are a few best practices which appears when using Catalyst and Flash Builder :

• Layers and components shoudl have explicit names (ex : ‘SkyBackground’ ou ‘CancelButton’).
• Before creating a component, it is important to set any element in the right look, otherwise it will be needed to do so for each state.
• The ‘big’ components (ex : a screen) should be created first, then ’smaller’ ones (ex: a button) to avoid from losing the interactions of its every time.
• Components should be reused (ex : a button can be reused several times).
• The skin should not have interactions (otherwise, it would contain code, which is bad for the Flex architecture).
• Vector elements should be used instead bitmap one, because it can be easily change subsequently.

4. Conclusion & links

A Catalyst prototype can be passed to the development team. But after the developments started, it become difficult to passed any change of the prototype. On first look, its direct concurrent, SketchFlow by Microsoft, would suffer from the same problem.

Thus, in case of complex projects, which combine simultaneous conception and development, Catalyst shows its limit (for the moment at least). But it seems also very important to improve the way we work and communicate, to favor a more efficient collaboration between designers and developers.

Links

• Catalyst
• the forum of Catalyst
• Flash Builder
• Adobe TV “Flex improves designer/developer workflow”
• Marc’s Musings “Why I like my proposed Catalyst workflow”