A Morsel on Flash Professional Projects in Flash Builder

Flash Builder is so very great to use. Such a time saver for the stuff I work on, especially in conjunction with subversion. Having a repository view of a remote SVN server, being able to update and commit, not to mention the ease of 'diffing' in the Eclipse SDK. Best thing ever.

Lock down FB and SVN and you will find varying project types to choose from: Flex Project, Flex Library Project, or Flash Professional Project. Please join me in considering the good and bad of the Flash Professional Project.

Here are the things I like and don't like about managing a Flash Professional Project from FB.

The Likes:

• The .project configuration file
• can be saved to SVN, so you can open all your resources quickly at later date
• allows you to select .as files from within Flash Pro and have them open in FB for a better coding experience ( still better even thoughh Flash Pro now completes code)
  

The Dislikes:

• The .project configuration file
• because collaborators with whom you share the Flash Professional Project, since the .project file is generally only usable in one particular configuration, will find it distracting
  
• Two environments (FB and Flash Pro) means 2x the path configuration. Yes, you have to path to libraries and swcs twice. Once in FB, and once in Flash Pro.
• Frequent quickly appearing and then disappearing phantom publishing panels, due to the need for FB to remain synchronized with Flash Builder. I'm on Mac and this is one of the more disturbing issues.
• The fact that you must create and save a .FLA as a precursor to starting a new Flash Professional Project, then associate the .FLA with the new Project, and then add the new document class back to the .FLA. Far better to have the .FLA generated through FB and configured according to initial project values.

Seems like the nays have it this time. I find it works better to use subclipse to manage FLAs without converting them into Flash Professional Projects. The only tiny caveat to this approach is that you must open the associated .as files directly from FB rather than via Flash Pro.

It remains to be seen what Flash Builder "Burrito" adds to this mix.

ASDocr to generate ASDoc HTML documentation

Rather than use the command line tool ASDoc that ships with the Flex SDK, I'm trying out ASDocr released on the Grant Skinner's site, gskinner.com.

It's handy, just be sure to update your Air to the latest 2.x version (presently 2.5.1) and be sure also to grab the latest ASDocr, as several are linked from gskinner.com

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/

What to expect and not to expect from FXG in Fireworks CS5

Fireworks CS5 support of FXG includes the following graphical elements:

Fireworks CS5 to FXG 2.0 Direct Mapping Support:

• Filter Mappings: Blur, Blur More , Inner Shadow and Drop Shadow;
• Blend Mode Mappings: Normal, Layer, Multiply, Screen, Lighten, Darken, Difference, Add, Subtract, Invert, Alpha, Erase, Overlay, Hardlight, Colordodge, Exclusion, Hue, Saturation, Color, Luminosity, Colorburn and Softlight;
• Gradient Mappings: Linear and Radial gradients; Mask Mappings: Alpha and Clipping masks;

(see a Fireworkszone.com article for more details on this)

Some weak points in the developer workflow that a product like FXG/Catalyst could help:

• Image/asset optimization of static design to ensure
  
  • fidelity of vector assets is maintained
  • optimization of bitmap assets is ideal
  • portable and round-trippable file type
  • AND: created objects can be referenced directly in MXML

FXG thus far addresses only the second point to satisfaction.

Regarding point one, vector data is frequently lost. A previous example in this blog is a scenario where textures are employed in a FW png, and the png is exported for external use. The resultant FXG loses the textures entirely when they should be reproduced from pattern data in Fireworks and incorporated into FXG.

Moving to point three, portability and round-tripping are decent. Lacking is a return from Flash back to FW, which has been pledged as an advance for CS6, but for that you have to wait.

Finally, point four addresses the ability to build an FXG and then reference the baked-in assets from Flash Builder, using AS3 and MXML. This in my opinion is the great missed opportunity of FXG. The markup created in FXG gives none of the naming and referencing functionality you would expect.

Put plainly, I can take an entire multi-page FW CS5 file from design, ensure the layers are correctly named and organized, and then export it into a data-rich FXG, a format loaded with individual vector and bitmap data. Disappointingly, once I move that into Flash Builder there is no built-in means to explicitly reference the assets and manipulate them in AS3 or MXML. To do that, you have to open the FXG up and hand-edit it.

Here are some details from Adobe's own Adobe Flex 4 document entitled "Using FXG."

To convert this example to MXML graphics:

• Remove the tag. This example does not contain any elements.

• Remove the block.

• Move the two Illustrator-specific namespaces to the application’s root tag:

  xmlns:ai="http://ns.adobe.com/ai/2008"
  xmlns:d="http://ns.adobe.com/fxg/2008/dt"

• Remove the FXG-specific namespace:

  "http://ns.adobe.com/fxg/2008"

• Add the “s:” prefix to all elements.

• Because the “d” and “ai” namespace definitions are intact, you do not have to remove the attributes specific to these namespaces. The attributes type and userLabel, for example, appear on the tag from the original FXG file. To further simplify this example, though, you could remove them because Flex ignores anything in those namespaces.

  For example, this:

  Becomes this:

A startling omission? Yes, rather. That is a substantial defeciency of this format IMO and one that will hopefully (certainly) be addressed in the future.

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.