I agree. Would like to see the capability to share the project, e.g. in a source code control system.
At the least, the import/export to/from Builder needs to be streamlined. It takes several clicks. At least in Catalyst it's just Save/Revert.
I had played around with some workflows back in the beta days.
Essentially you compile the catalyst project to a swc, developers can import that swc into their FB project, but they never edit it directly. Developers can extend the classes catalyst creates to add functionality. Designers can dump a new version of that swc whenever they feel like it, as long as they're not renaming or changing structure of stuff.
Has the other added bonus that a single developer project can import multiple designer catalyst projects.
Not sure if those scripts still work or not. It'd be great to get an "Export to SWC" option right in the tool.
Marc -- The SWC approach made sense before Panini/Burito. But now developers can make SkinnableContainers and hand them to designers in the project, defining what SkinParts and States the container requires. So there's a tighter integration between the two tools in the FXP file itself. I've been working with it since Max, and it's quite powerful, except that the UI for the round trip itself is cumbersome on the Builder side.
Creating the smoothest workflow possible between panini and burrito is extremely important to the entire team, and we have definitely heard resonate passing a fxpl/fxp back and forth should be more convenient.
Can you tell me more about what you'd like to see in the ideal case?
Can you tell us more about your workflow with both products? (ie, are you one person using both (designer and developer), or do you work on a team?)
What source control system do you use?
We're trying to gather as much feedback as we can and learn as much as possible about how our users want this to work so we get it right.
So please keep posting - and thanks
I’ve been working with Panini/Burrito/Hero full-time for a couple weeks now, building a proof-of-concept for how to use Catalyst in a workflow for creating wysiwyg editors.
I’m working solo on this project, in both Catalyst and Builder. I don’t touch any skins in Builder. So I roundtrip a lot as I work on different ideas for how the project should look. I expect this will be a typical workflow, if the tools enable it. At the moment it’s clumsy.
I have the project open in both tools. Imagine that I make a design change in Catalyst. Here’s what I do (OSX):
- Catalyst: Command-S (one keystroke)
- File Menu - Import Flash Builder Project (have to go to the menu, no hotkey)
- Click the Browse button (no hotkey. no filename is pre-filled, even if I’ve imported to this project before)
- Navigate to my FXP file (it doesn’t remember where I imported from before)
- Click “Open” or press Return
- Select “Overwrite existing project” (even though I’ve imported a file with the same name as the project, and overwritten previously, the “new project” option is still the default)
- Click “Finish” or press Return
- Click “OK” in the “overwite” dialog
Then, after I’ve made my change, here’s what I do:
- File menu - Export Flash Builder Project (have to go to the menu, no hotkey)
- Press Return (the last export file is pre-filled and the “Finish” button is highlighted already)
- Click “Yes” on the “already exists” confirmation dialog (“no” is the default)
- File menu - Revert (no hotkey)
- Click “OK” or press Return on the revert dialog (“OK is the default”)
As you can see, the Catalyst part of the workflow is one menu choice, which in the case of “Save” has a hotkey with no confirmation. The Builder part of the workflow is several steps.
The process is cumbersome enough that it’s difficult for me to convince others that we should adopt this workflow.
- GOOD: Prepopulate the Import dialog in Builder with the last file I imported. And if it’s the same file as before, and I overwrote the project before, then default to the overwrite option.
- BETTER: Give Builder “Re-export” and “Re-import” menu options, with hotkeys. Make “OK” or “Yes” the default on the confirmation dialogs. Then Builder handles import/export similar to Catalyst.
- BEST: Allow Catalyst and Builder to share the same project file location, so import and export are unnecessary. Then I just switch apps and hit F5.
- ULTIMATE: Make a Catalyst view in Builder (like the old Design view that nobody uses) so the developer can switch to the Catalyst toolset anytime they want
The “BEST” option above has other advantages:
- Much faster in Builder because no need to zip/unzip
- Easy to change just one component in Catalyst, even if Builder user has done work in parallel
- Catalyst user can use source code control, see version history on individual files, etc. (Obviously this would require a “refresh” F5 function in Catalyst, which would have to run the compatibility check on any file that changed.)
Some other notes:
- When importing an FXP file to a new project in Builder, sometimes the project’s name (i.e. in the Package Explorer) comes up as just “Project”. The project name can’t be changed. It’s used as the default filename for export. So you have to change the filename every time you export. It’s not clear under what conditions the name “Project” is used. But it should never happen. Builder should always name the project the same as the filename being imported.
- On the Import dialog in Builder, I see an “Import contents into existing project” option, but it’s always greyed out. That would be useful, it seems. Not clear how to use it.
- I’ve only done a 1-person workflow, which should be the easiest. It’s not clear how this would work if the designer and developer made changes at the same time to their respective files.
In general, I’m impressed with Flash Catalyst, and intend to continue working with it and push for its adoption more broadly in my organization.
I have been playing around with Panini to see if it's something we want to roll out to our designers and UX Developers (aka MXML developers) when it goes live.
My biggest objection at the moment is the high probability of desynchronization between concurrent work flows. It is very easy to break compatibility, and the binary import/export model makes it difficult to maintain updates through version control (we use Subversion). Granted it's still possible to convert the binary to source for version control, but it just seems like an extra step that shouldn't be necessary.
Ideally, there should be no difference between the ways Flash Builder and Flash Catalyst interpret/write/build MXML, just two different IDEs that achieve the same end result, one targeted at engineers, and the other targeted at creatives.
My 2 cents at least...
Actually it seems like one could have Catalyst and Builder share the same files quite easily. Catalyst keeps the project unzipped in a temp folder. On OSX it's a subfolder of "workspace":
~/Library/Application Support/Adobe/Flash Catalyst Panini Preview/workspace
I tried creating a Builder project using the temp folder as the project location. I was able to make a change in Catalyst then hit command-S to save. Then I went to Builder and hit F5 to refresh, and it picked up the changes.
Catalyst deletes the whole directory when you close the "file" (project) though, so it would be a little tricky to use this approach in your regular workflow.
Still, if Catalyst allowed power users to designate where it keeps its files, and didn't delete them, then we could really use the two tools in parallel quite easily, and hook them both up to Git/Subversion/whatever.
Ahh, very nice.
IMHO, the ability to specify a permanent project directory would add a lot of value, and seems like it would be an easy update.
V-Interesting thread, I find this this a nighmare at the moment
I have been using Catalyst/Panini from day 1 previews (respectivley)
Appologies for the long thread - just trying to explain routes/circumstances surrounding (a non ideal scenario)
Our working team is
1x Designer (AI>FC) Full time
1x Main Developer (FC>FB) Part time (each night)
1x Support Flex Developer (Mixture of FC & FB) - add hoc hours
1x Support PHP developer (creation of AMF WS) - now completed
Expanding to multiple developers (in 2011)
I write this as the 'x1 designer' and Project Manager
- the designer is 'currently' spending 70% of overall 'available' project time developing project
- the designer (also PM in this case) has lead functions for WS creation (from Open source product)
- the designer is leading app prototype accross various screens (Desktop/Mobile/Tablet/TV provision)
- the designer has an obsession with keeping interface UI/UX in same places on different platforms (Mobile/desktop/Tablet/TV) now 98% there (whilst utilsing additional screen space/not reinventing app UI/UX flox logic on different platforms) hard to explain....
- the designer is no doubt driving the developer mad with constant changes as he encounters issues to platform X solution on platform Y prototype (whilst developer is still trying to do platform X)
- developer is always playing catch up (due to time contstraints)
- Designer wishes in perfect world developer would have time to create custom skin components in FB 4.5 in order for the designer to then update-pass back (sadly in our case) main developers time is very limted
- Designer is now learning the bare basics of flex (eg flex in a week) after realising from looking through the FB projects prototype code - what a mess designer can make from progessing from AI>FC>FB (appose to) FB>FC>AI
Designers approaches to try and PM/Manage project/Complete
1. Built entire protype/projects in FC
- (1.1) Goal designer to build/feel/sign off on 'one platform' prototype
- (1.2) Completed tests on devices via compiling in FB 4.01 (and or) AIR Android (PAST)
- (1.3) used keynote (to assemble PDF file from AI assets) to test on ipad - considering using Indesign (in future) or Adobes (possible) forthcoming solution (it appears)
- (1.4) has realised Adobe fragmented tools - is getting out of controll (after using for over 10 years)
- Project (FC) quickly becoms a mess
- Developer tries to keep up with designers daily iterations (when they start at night) in our case
- FB code contains vast amount of 'mess/cheats' designer doesnt realise he is making to have working prototype on device
- FC becomes endless spagetti hacks (FB results in equal mess)
- Designer is looking through shared FB work thinking 'boy dont feel comfortable' trying to update this toggle btn to checkbox (designer now favours MVC approach!) but this is probably down to now actual understanding!
- Project needs re-write in FB (which is fine for prototype phases) in multiple platforms (as iterations wind down to hault)
- Designer is thinking there has to be a better way to manage this/save wasted work
2. Eight months(ish?) later (of countless methods/endless files)
- (2.1) Designer now creates x1 Graphics libs (AI) with all items organised as graphics Icons/components/etc
- (2.2) Creates individual components per file in (FC)
- (2.3) Passes seperate FXP (FC) files to Main developer
- (2.4) designer doesnt try and create logic/developer interprets/builds 'elegant' solution (in shared FC files)
- (2.5) designer still completes his FC builds (from his centralised FXPL) so can test on 'some' devices platforms/uncover issues between platform prototypes (to save developers time) and to aid understanding by developer (using shared files/screen shares) (even PDF files for tablet prototypes)
- (2.6) designer gets anoyed with export/import options within FC (without duplicating btnX btnX1)
Still niggly? (sure)
But seems to be working well, by just doing bare bones in FC (although) still can be improvements to designer wanting to update items (yes appreciate FB4.5) new approach (started by DEVELOPER) grrrr (smile)
C) Designer is now
- (3.1) Trying to create views/components in FB Directly (for either Flex Mobile / desktop usage) from one centralised set of components/graphics/other
- (3.2) Currently 'trying' to learn from 'flex in a week' crash course (which hurts his head at times!)
- (3.3) Is constantly referencing hero release notes - to understand what components/items can be re-used between (mobile/desktop) builds (eg) using reskinned checkboxes for use in Mobile/Tablet (and) Desktop
- (3.4) has watched countless developer/designer/envision sessions at Max to try and get his head around both sides of the fence to consider_ best workflow for multiple platform/form factors using same (scalable) UI/Components/items
- (3.5) Is trying to be able to learn flex 'enough' to make views or even 'basic' skinnable components inorder to pass them back to himself (smile) and find best workflow so developer remains un-effected, by updates, which happen in background
- (3.6) is pondering structures adaopted by Christian Cantrell (shared in his MAX session) for how he managed his project for multiple screens - contemplating best elements for similar shares goals/platform usages from multiple flex (non pure AS) projects!!!
Questions to Developers (or designers)
>>I was reading FXPL before stubmling on this post
Q1) Is this good practice for creating/updating of library assets for use between multiple flex (4.5) projects/platforms (seems logical to a designer) as the project needs to carefully create/reuse, assets/components for shared use between (mobile/tablet/desktop) and TV shortly...
Q2) Based on Workflow 5: Iterative development (multi-project/large team) any good practice points to share (inline with panini/bur..)
Otherwise (thanks Francis/Others for sharing your points)
Francis (FYI) - we are all working remotley on our project - so TEMP dir would be tricky without integrated SVN like suggested (or similar)
Great work Adobe -You ARE really are giving us 'choice' and the ability for non programmers to atleast prototype things/encouraged to learn basics of programming IDEs (not meant sarcasticaly)
PS: Go easy on me (I am only a dsylexic designer at the end of the day!)
what a mess designer can make from progessing from AI>FC>FB (appose to) FB>FC>AI
I think this is a key point right here.
It is very dificult to produce code in FC that does not need to be extensivly rewritten in FB. In my humble opinion, this is what's making the workflow the most dificult at the moment. If FC could produce code at least as well as the design view in FB, the efficiency of the work flow would be increased emensly.
Thanks for sharing your experiences. We haven't really used FXPL all that much. It sounds like it would be worth giving a try.