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.

Flash Catalyst and Flash Builder workflow

More workflow explorations incorporating Adobe Flash Catalyst. Among the hopeful tests and discoveries, a stark word of caution is a rare gem. Here is one from an article authored by Adobe's Andrew Shorten (italics mine):

It is not possible to re-open a Flex project in Flash Catalyst once you've imported it into Flash Builder. (The product teams will investigate this option for a future release, but it will not be available in the first release of Flash Catalyst.) To overcome this limitation, consider the other workflows in this article, in particular workflow 3, which extends the approach used here to support iterative development.

Workflow 3 incidentally outlines the use of 'Compare Project With Version' > [previous version] as a means of reconciling different code versions. This represents great hardship in a round-trip and, in light of just how different the versions would be, is IMO not a viable solution.

Further on this, a detailed blog entry regarding 'catalyst jailbreak for flex developers' is exploratory and non-committal in tone as it explores Catalyst integration. Here is a further obstacle to a Catalyst workflow that extends from a different angle on the quote above:

An important note: There isn't a place to set the ID on Flash Catalyst components. When a designer converts artwork to a component and then exports a custom component with multiple text inputs, say a registration form, none of those text inputs contain ID's.

And further:

...when the design changes and it does, the one way Flash Catalyst generated code has no knowledge of your so called ID's. The design has changed and all or nearly all the components are anonymous again. So the developer has to manually find and add the ID to each text input, radio button, button, each time the design is updated etc.

While there are workarounds, there is not yet a clean workflow to utilize.

Flash Catalyst Panini, you are up next.

Flash Builder 4 Workflow from Catalyst to Flex

Skin vs SparkSkin Classes in the Flash Builder 4.1 SDK

Seems the difference between the two is that SparkSkin adds some extensions that would likely not be used in the creation of a custom Spark Skin. Therefore, you can pretty much just use the Skin class if you are developing a custom implementation.

Here are a couple of resources with limited info on the topic:
http://forums.adobe.com/thread/465734?tstart=0
http://unitedmindset.com/jonbcampos/2010/06/02/the-difference-between-skin-and-sparkskin/