Practical Explorations of Catalyst Workflow, Pt 2

dFurther into Catalyst, here are some details on its workflow implementation:

Catalyst is procedurally similar to IDE-driven Flash Development. In particular:

• Imported objects are cut and pasted without regard to underlying code in the process of assembling and producing usable components
• Graphics in Catalyst are nameless and instance-less and may well be duplicated many times in random fashion in the process of assembling components, resulting in a code-behind of untold and unmanaged complexity (until the developer gets a hold if it, that is)
  
• Much like Flash circa v3, you can paint yourself into a corner if your work process is too design-centric. You must have an architectural view of what you are creating and scale it in anticipation of the final structured product. If you do not start with this view, unless it is a very simple project, you may get into a jam.
• While Catalyst is a presentation tool, development and usability duties fall within its boundaries as well. One example is the need to create transparent hit-areas for buttons; this is a matter of function, not display.
  

Following on this, Catalyst in its current 1.0 state is more hybrid tool than design platform. The workflow role that it encapsulates is akin to that of a Flash web designer in a pure IDE environment.

The user must have an awareness of the developers' needs as well as graphical manipulation and timeline skills. A team member utilizing Catalyst would need equal measures of feedback from both dev and creative teams to be effective. Furthermore, upon the Catalyst user is placed the expectation of creating hierarchical, logical structures almost entirely from the mouse and clipboard.

As version 2.0 aka Panini moves to release, it will be interesting to see what's next.