So far, I have to say I agree with all the points made. I am a fairly experienced Flex 3/Flash Cs4 developer and a designer with over 10 years experience with Illustrator and Photoshop.
I tried to do a relatively simple project with the beta. I concede that the "designer" part, creating the interface in AI and bringing it into FC, was impressive. And playing with the elements in FC to simulate how we want the app to work was also nice, and the SWF file from that raised everyone's expectations.
But integrating this into a "real" Flex project and workflow is far too much labor. It is far faster, better organized, and compact for me just to replicate the design from scratch in Flex/Flash Builder than to use the code generated by FC.
I understand this is beta 1, and from what I understand you put the initial work into the designer part of things. But I surely hope the developer part is dealt with quickly, or you will have another GoLive on your hands; something that had a nice UI for "designers who don't code" but got a reputation for creating bad code.
It's not that what is created by FC is bad code, it's quite ingenious. But care must be taken to understand the way Flex developers work. The product needs to be the same or less work for m, not more.
I couldn't agree more. My thoughts exactly, and very eloquently put. Thanks
A collection of thoughts from our company was posted in the private forum, but figured why not post some of it here as well? It is more of a harp on flashbuilder, but does talk about the workflow between the two.
Workflow of catalyst<->flashbuilder:
I think the new Data/Services window in Flash builder is cool and will help create rapid prototypes and quickly make designs something usable, but it isn't all that useful and definitely doesn't create maintainable code.
First, any enterprise level application built in Flex is typically built on some sort of framework, whether that be homegrown, Cairngorm, PureMVC, Mate, etc...
Since those are typically MVC frameworks, you can immediately tell where this is post going. There are several issues with dragging an introspected service onto a button when thinking about one of the MVC framework models, but the main point I want to harp on it this: It goes against the separation of view and model.
In the video http://labs.adobe.com/technologies/flashbuilder4/tutorials/php2 at the 5 minute mark, you can see an example of this. The service and responder are auto-generated in the view itself. Sure, you can re-factor this and move stuff around (only in the case of cairngorm that uses the (imo) terrible service locator architecture), but what if we don't want the grid fed with data directly from a server technology anyway?
What if we have a layer on the front-end that is strongly typed that is fed to our views and we have a translation mechanism (or even using the RemoteClass metadata that maps back-end objects to front-end classes) that we then feed to the data grid or view? It seems to me that the better option would be to allow dragging of typed classes or properties/methods to a component rather than a service. With this setup, it doesn't matter what server technology you use, your application is using strongly typed dto/vo/class objects that are populated using whatever you want.
Then, for example, lets say you wanted to move away from the enterprise version of MySQL because you were tired of shelling out $10,000 a year, or some massive, stupidly expensive oracle database, but the server technology you are using doesn't really support another data base or index type of technology. If you find a different server technology that supports what you want to move to in terms of of a data store, you would have to change all of these auto-wired places in the front-end to the new technology that you decided to use. Instead if you had a layer on the front end that all of your views used, the change of a sever technology wouldn't have as big of an impact.
Or what if you wanted to pull data from the local disk in the case of an AIR app? You can't just drag a service to a grid in that case, but in every case, you can still deal with strongly typed objects built in Flex/Flash builder. Why go through all of the hassle of setting up direct auto-wiring from a back-end service to the front-end view? What use-cases made this an acceptable practice?
Lets shift gears and talk about a framework like Pure MVC for a moment and I'm going to assume you know how the framework behaves.
Lets say we have an idea for an application and it is going to have 2-3 main functions. We are going to have a search feature that will find employees based on all fields about the employee, and the standard CRUD operations to handle adds, deletes, and edits.
With pure mvc, all the view really needs to do is dispatch a bubbling event and the pure mvc system takes care of the rest. Don't you see the power here? A designer using catalyst can simply get a listing of current functions a system has and dispatch the corresponding system event! The view almost becomes a black box to the developer!
I say almost because the developer needs to wire the resulting action of that event, whenever it occurs, back to the view for feedback. In the case of pure mvc, the actor would be a mediator, but a generic system in the view that handles other system events could be built to auto feed the view!
For example, lets say we search for employee "Bob". The view dispatches an event that maps to the search feature in the system passing with it the parameter "Bob". The system could send an event that returns details about Bob or a "Not found" message, or whatever needs to happen. The view would then receive this (Via mediator in pure mvc) and render it however it wishes. If this response was strongly typed in Actionscript, the designer would know what properties would be available about the employee and could create renderers for those properties.
Finally, to summarize, I think there are two situations that need to be planned for with catalyst/flash builder that they currently don't handle when it comes to enterprise applications using some sort of MVC framework:
1. The designer is driving the direction of an application being built from the ground up.
In this case, no back-end system exists and as part of the design phase, the developer could write some strongly typed objects to be used in catalyst for the designer to work with, while the back-end guys can concurrently write services and whatever else they need to do without having to worry about coordinating with the designer.
2. The designer is coming up with new/different ways to visualize a system that is already in place.
In this case, either some sort of strongly type objects already exist, or could easily be created based on the existing services that the designer could then use to do what he does best.
The connection point between the two in either case comes when the strongly typed classes are fed the data from the services.
I don't disagree with this one bit; however, I doubt FC is aimed at an advanced audience. It's pretty obvious for all the reasons you state and then some.
However, who IS it aimed at?
I would think in many cases the place I work would have been ideal. We have an art director who designs interfaces for new RIAs and updates designs of existing ones. She is not a developer at all, and works with Photoshop and some Illustrator. I am the only RIA developer, working with Flash and Flex. I have a background in design and so am very adept with PS and AI. So I need to translate her designs into applications. On the surface, sounds exactly like the people in the demo/commercial videos, except I doubt at first she would even be able to work with FC; I myself would probably need to perform the translation from flat design to prototype in FC. So all I have gained is more work.
Problem is, as I said earlier, there's little to gain in this case so far from FC. I wasted 2 days working with FC on her latest design. I got it into FC from AI and made it into a snazzy SWF in less than an hour. The remaining time was figuring out how to get it into the Flex workflow, since it was a repeating screen, and therefore needed to be a component with dynamic text fields and such. I have since scrapped it entirely and am just going from the ground up in FB4.
What WOULD be helpful is to be able to use FC to create skins for FB4, since it is now skin-driven. It would be handier to just be able to take her carefully thought-out and colored design layout and make it my Panel skin (for example). That alone would save hours.
It has always been a holy grail to allow designers to mock up technical things. The marketplace is littered with failed products that promised to fill this gap. Art directors will NEVER be able to use a product like FC. It's a fantasy, and a persistent one. One only needs to look, as I said earlier, at GoLive. In its last iterations it was intended to be a transparent page layout tool to make html pages. The last version looked almost like InDesign. However, it remained too technical for art directors, and did not produce code necessary to work with a larger production workflow.
I wish Adobe would really take a look at how people actually work; we could use innovative tools to make the process smoother and faster, but so far FC is not there.