Hey piercer, in 1.0 it's just a one-way workflow from Flash Catalyst into Flash Builder. We're still committed to making the round trip between FC and FB work, but in 1.0 we're focusing on a round-trip workflow between Catalyst and the CS tools. Part of the reason is that in our user testing we found that developers are still the ones who control the outcome of the project and end up checking in and out code. So for 1.0 when a designer wants to make a change they'll use that original FXP file, give it to the developer, and the developer will merge changes into the actual project.
Oh Dear :-(
I received this email from the design team today - they didn't know it was me that made the post, and I gree with them
Thanks for the info, downloaded the two apps today and gave them a spin.
Creating a project in Catalyst and importing the FXP into Flash Builder seems to works fine.
However exporting a FXP file from Flash Builder and then opening it in Catalyst does not work for me. Also this post suggests that it's a one-way workflow so far:
Do you know anything about this? Since it would prevent designers from updating projects it's very much a make-or-break feature.
I reiterate the point - really crucial to us - we were expecting MUCH more - its very much a make-or-break feature.
You state that
"but in 1.0 we're focusing on a round-trip workflow between Catalyst and the CS tools"
BUT the Catalyst/Flash builder touted selling point is that is a developer/designer workflow NOT a designer/designer worflow. We have had a one-way workflow for ages, and this was supposed to fix that - really really dissapointing...
OK, so how does a developer 'merge in' a changed FXP?
Well thats very disappointing.
I was hoping that I could import my subclasses of SkinnableComponent into FC, and then the "Convert Artwork to Component" would list my SkinnableComponent. I'm not expecting FC to figure out which pieces of artwork to assign to which SkinParts, but that's where the designer comes in (like for creating ScrollBars).
If this was inplace, I was imagining you could have a FlexZenGarden (like CSS Zen Garden). Where people post their unskinned application (Component libraries) and designers could import, create, and publish skins showing off the power of Gumbo's Skinning. How awesome would that be!?
Will this workflow be supported in the future? (If yes, when?)
Is there a bug on bugs.adobe.com/jira I can vote up for this?
I believe the "merge" is manual.
I agree with you. This is not true workflow because it doesn't go both ways. It's a deal breaker for us too.
We have had a one-way workflow for ages, and this was supposed to fix that - really really dissapointing...
As a designer, what one-way workflow has existed prior to Flash Catalyst? I know that in the past, I would hand off Photoshop or Illustrator art to a developer and then try to explain to the developer how I wanted the comp to "work". Then the developer would have to manually do all the skinning on their own. Now, with Flash Catalyst, the one-way workflow is that I can hand off code with all the interactions and skinning already set - I'm not giving the developer a PS or an AI file -- I'm giving them an FXP file.
I do agree that should more design changes be necessary, I either have to pay the developer to do them, or, I have to update the art on my own, generate a new FXP file and send that to the developer, where they have to add in the code again. I agree that sucks -- but we know that Adobe is getting there -- just not in 1.0. But it's the goal.
The huge failing with catalyst that it was supposed to allow a developer and designer to both work on the same project in a seamless manner - at least that is how it is hyped up to be. Unfortunately, given a functioning application (graphics mixed in with code from developers, not designers), then a designer can NOT edit some graphics files/layout in Fc and immediately see the changes reflected in that application.
With Flex Builder 3 the Flash the designer can, and so in many way Fc provides less of a workflow than we currently have.
In case you're wondering how to do it in Flex Builder 3 and Flash, then I will explain.
1) Create a 'theme' for you application - can even be a separate project!
2) In Flex Builder 3 add all the assets; fonts, flas, images etc for the theme.
3) Create a css file for the theme, that imports all the required assets, and have it automatically compile into a swf (see the option in the drop-down when you right-click on the css file.
4) Make application load theme at runtime (easy-peasy)
5) then you have the following flow
Edit theme -> run application -> observe application running with new look and feel -> Edit theme...
Note that here we are running the actual application not the 'fake' one inside Fc. The developers can change the application and the designer will immediately see that changed functionality when they are testing their theme - this is a proper 1-way (pretty much 1 1/2 way) process.
There is an issue with this workflow. It does not allow the designer to alter the layout/transitions of an application without sitting with a developer. However thats a far smaller problem than having to rely on a developer to use an as yet unspecified procedure for manually 'merging' in a changed FXP file every time the designer wants to see what changes their graphical work has made to a fully functioning application.
It is this 'layout' issue that I, and I believe many other people, thought that Fc would solve (and if it did we would be over the moon). However it seems to have made it more difficult for the designer to see their changes in a running application and has not addressed the issue atall.
I hope that explains it