Archive for June, 2009

The second of our five part series focusing on Flash Catalyst has been released on Peachpit.com blog.  In this post we focus on where Flash Catalyst fits inside of the larger Adobe Flash Platform.  We review the upcoming changes to Flex 4 that were required to facilitate Catalyst and the workflow it brings to the Platform. For the designer, Flash Catalyst has long been sought  to help extend their static design vision into the world of interactive features. We explore this new workflow as well.   Read the post here

We are proud to announce that we are beginning work on a new book for Adobe Press that focuses on Flash Catalyst, Flash Builder and Creative Suite based projects and the development workflows these tools enable.  Our good friend, Doug Winnie (Group Project Manager at Adobe and web workflow expert), will be co-authoring the book with Aaron and myself.  As we write the book we will be making updates here on our blog about our progress and research.

In the meantime, Peachpit.com asked us to guest author a weekly series on Flash Catalyst.  Our first post, Adobe Flash Catalyst: Under the Hood—Part 1 Introduction is now on their site.  Make sure to subscribe, because each Monday a new post will be available.

With the release of Adobe’s Flash Catalyst and Flash Builder public betas the Twitter-realm and Blog-o-sphere have been all a buzz with excitement, skepticism and of course questions, questions, questions.  One issue that seems to be the hot topic for the day is the idea that Fireworks CS4 is being treated as a second-class citizen in the new Flash Catalyst world.  The root of this assumption starts with first screen you see in Catalyst, note that Fireworks is no where to be seen:

This apparent abandonment by the Flash Catalyst development team is being exacerbated by the fact that Fireworks is often mistaken for a Photoshop wannabe.  Non-Fireworks users assume that Fireworks is some kinds of ImageReady, not understanding how great, powerful, intuitive and useful the tool really is.  Because of this historical treatment, the Fireworks community is up in arms about how, once again, Fireworks is kicked to the curb in place of the 800 lb. Gorilla that is Photoshop.

The good news is that in reality, Fireworks has exactly the same support and workflow Photoshop does inside Catalyst. The first thing we need to do is get over the fact that just because Photoshop has an icon and import option that it has better support.  One of the file options for import is the FXG file format.  FXG is Adobe’s new XML based graphical description language that enables easier tooling, development and transport between applications.

Fireworks CS4 has the ability to export its content to the FXG format and this means that designers can easily import their design into Catalyst by, using Commands > Export to FXG.

This converts the file into the new format and then Catalyst can open the design and be used to create Flex based content.

Now, the current argument is that this extra step is a worse workflow then creating a PSD and just opening it in Catalyst. Let’s look at an example.  I create my design in Photoshop and then open the PSD in Catalyst and start working on my application.  I realize that the design is not quite right or needs to be seriously re-done.  I have to go back to Photoshop, using the original PSD, make the changes that are required, and then go back to the Catalyst project and choose File > Import Artwork.  At that point, I have to update the component linkage, skins, etc. in the project.

The Fireworks workflow is exactly the same.  If I need to make a change, I go into Fireworks, update the design, save as FXG and then import into Catalyst.  So, in reality Photoshop and Fireworks are on even footing, PSDs just gets a pretty icon Welcome screen of Catalyst. Yet, Fireworks support of FXG actually adds some interesting benefits.

First off, A few of you may note that Photoshop also has the ability to export its files as FXG.  In truth, Fireworks FXG export engine is far and away more superior then Photoshops.  For example, go into both tools, create a few basic shapes, slap on some gradients and then export the files as FXG.  In my example I named the files Fwks.FXG and PSD.FXG.

Go to the exported file directory and take a look.  First you will see two asset folders, in my case: PSD.assets and Fwks.assets.  These folders are generated to hold any bitmap or other exported non-vector based files created during the conversion process.  Take a look inside the directories and note that in the Fwks.assets is empty, yet in PSD.assets there are multiple images.

What is happening here is that Fireworks is able to covert its vector shapes into pure FXG code but Photoshop can only export them as bitmap images.  Right there, Fireworks wins.  We are deploying our content to the Flash Player, which is a very powerful vector rendering engine.  If we are creating vector content, shouldn’t we be able to leverage it?

This also means that since the layout is all vector for Fireworks we can hand the FXG to a Flex developer and they can easily import, update and also manipulate the FXG inside Flex. This support actually makes Fireworks a superior tool over Photoshop for generating designs and assets for Flex 4 and/or Flash Catalyst based projects.

Its unfortunate that Adobe didn’t do as good a job promoting this support in the initial launch, but we should give a lot of kudos to the Fireworks development team for creating such a powerful export engine for a “future” file format.