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.

Tweensy AS3 Library

A replacement for greensock in my workflow is pretty much unthinkable. Still this library packs some new thrills. Not only does Tweensy claim to be more efficient than TweenMax, it backs it up with some test cases. Have a look at the FX library for ideas on your next project.

in reference to: tweensy - Project Hosting on Google Code (view on Google Sidewiki)

RobotLegs in Flash CS4

Robotlegs is an as3 framework that has been gaining traction in the dev community lately. You can find a repository for it on github, and the demos make for a good test drive. It works in Flex or Flash with proper respective configuration.

Robotlegs demos will work fine in Flash CS4 as long as you do the following:

• Opt-Shift-F12 to open publish settings > click AS3 settings near the top > Library Path: add the bin directory that contains the robotlegs swc
• In the main Publish Settings panel, be sure to check Export SWC
• Use the root of the demo folder as your document root directory.
  

Other troubleshooting options may well go awry. The above bullet list will help you sync up Robotlegs and CS4. Good luck!

Considering the Flash 10 3D API

I'm back from a much needed vacation with a new lease on life.

Currently, I am looking into a 3D treatment for a UI in production. Where 3D meets Flash, there are plenty of established third-party 3D engines available from the open source community. To name a few:

Sandy 3d
Five3d
Papervision 3d
Unity 3d
and others...

With the advent of FP 10, Adobe now has their own, not quite 3d option.

2.5D

The Flash 10 3d api is known as a 2.5d option, since it involves perceptual transformations in a 2d environment rather than a bona fide x,y,z coordinate space. Aptly enough, it is also referred to as "Postcards in Space". It is fine for menus and presentations such as the one I'm looking into, where the scope of motion is limited to fixed options.

Planning it out

Putting together a 3d UI adds complexity to an already complex process. Thus it is necessary to break the process down into manageable steps. Here are the general guidelines I am following:

• Bitmapped planar polygons
• in a 2d mesh
• in a display object container
• perspective positioned relative to mouse position.
  

With this in mind, I can follow a process of assembly from top-down or bottom-up. Let's look at top-down.

1. Create xml-driven coordinate system to hold masked bitmaps as a 2d display object
2. Add each of these 2d display objects as a plane of a 3d cube
3. Render cube by mouse coordinates
   

or bottom-up

1. create 3d cube
2. wire up cube to mouse interaction
3. add complex content to faces of cube

In this case, I already have a sprite object built for top-down step 1, aka bottom-up step 3. I can scratch that off the to-do list. The question remains, how well would a proposed cube face handle a complex sprite?

First of all, there are different ways to present 3d objects in Flash 10. There is the use of a display object, with its properties of

• rotation x, y and z
• scale x, y and z

Another way is to use the newly-introduced vector data type to add a series of points to a graphics class, thus to draw polygons using a series of point data.

• beginShaderFill()
• drawGraphicsData()
• drawPath()
• drawTriangles()
• lineBitmapStyle()
• lineShaderStyle()

The latter method allows for precise polygon mapping with contour details intact. Some startling geometry can be plotted with the graphics API of Flash 10. Vector data and the graphics API is expertly detailed by senocular in his Flash 10 API primer.

Since my UI is effectively a cube with complex objects inside it, the former method will be the best for this effort. Incidentally, have a look at Lee Brimelow's recent tutorial on a Flash 10 API 3d image carousel. It's a good basic intro to the technique. Plus, it mentions a critical point of the implementation, the need to address z sorting. Did somebody say quaternion?

So, containers can use x,y and z positioning data. Furthermore, they may contain nested containers. Moving forward is now possible.