Showing posts with label workflow. Show all posts
Showing posts with label workflow. Show all posts

Monday, November 8, 2010

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.

Wednesday, September 15, 2010

Fireworks CS5 to Catalyst CS5

I've been testing out workflow models for the handoff and development of creative assets. A recent advent in the process is Adobe Catalyst, an application offering an intermediary step between design and development.

While that is an oversimplification, the conceptual center of this new workflow is the FXG or Flash XML Graphics filetype. FXG has been prominently positioned in Adobe CS5 to concisely describe graphics. In part, this is achieved by leveraging MXML to describe mathematically-reproducible graphical elements. The remaining visual information is stored in an autogenerated subdirectory in the form of PNGs.

This helps to conserve visual fidelity as well as minimize file size. FXG represents a bold attempt to organize vector and bitmap graphics into a meaningful and portable divisional structure. The language is itself a form of XML that can be dropped into the Flash pipeline and referenced as namespace objects.

All this sounds great, and hopefully the details will fall into place. On that note, here are some instances where the details are still lacking. Some tests follow in the Fireworks to Catalyst workflow.

Here are some Fireworks objects with fills and textures chosen from Fireworks preselected options.



Here are those objects imported into Catalyst.

As you can see, they are not the same. At issue are textures that only render with certain complex gradient fills, and not with others or with solid fills. In particular see column 2 rows 1 through 3.

In row 1, a grid texture is combined with a silk gradient fill. FXG faithfully captures this combination.

In row 2, a DNA texture is combined with a linear gradient fill. FXG translates the gradient to xml markup but ignores the texture.

In row 3, a DNA texture is combined with a silk gradient fill. FXG captures both.

Moreover, note that FXG generally fails to preserve the objects' textural information, despite the fact that texture is a standard option in the Fireworks toolset.

In summary, there are anomalies that must be worked out before a Fireworks to Catalyst workflow can be reliably implemented within Adobe CS5.