Gumbo & Adobe Flash Catalyst @ BAADAUG
Last night I was able to attend the BAADAUG meet-up and check out presentations by Deepa Subramaniam and Peter Flynn on the upcoming Flex 4 (Gumbo) and Flash Catalyst beta releases.
The big news is both apps should be available as a public beta in a couple of months. Catalyst still has about a year to go for full release, while Gumbo is slated for release later this year.
The biggest change coming to Flex 4 is Spark. Flex v1-3 all used something called Halo, which was the primary architecture for Flex components where styles were deeply (and frustratingly) tied to components. Spark builds on top of Halo to provide a separation of component logic and visuals.
Why is this a big deal? This is the foundation of the upcoming Flex/Catalyst workflow. By separating the visuals (skins, transitions) of a component from the logic (functions, data), it’s possible to apply skins to a component without being a super-programmer. Currently in Flex, a designer would have to programatically rewrite components to create new and interesting interfaces. In one extreme case, styles are so deeply rooted it’s impossible to change something as simple as font weight without rewriting the component from scratch. Thus, Spark is a huge boon and blessing for the Flash platform and opens the door for something like… Flash Catalyst.
Digging a little deeper, while Spark is already available in Gumbo’s frequent release builds, it’s not finalized. The critical issue at this point is naming and namespace. Currently, all of the new classes had a “Fx” prefix, such as “FxList” or “FxListSkin”, which many developers find confusing or garish. The new solution is to use a namespace, such as <fx:List> instead of <mx:List>. The new namespace(s) have not been determined yet, but should be in place by the time the beta is released.
With Flash Catalyst there’s bad news and good news. The bad news is Catalyst is now being marketed as a concept / layout / prototyping application, rather than the designers’ GUI for Flex. What this means is code generated in Catalyst can be imported into Flex, but not the other way around. The critical difference is that once the design code is generated and implemented, a designer cannot use Catalyst to go in later and make final design tweaks – it can only be modified from within Flex.
The good news goes back to the whole Spark architecture and how graphics are newly charged. In both Flex and Catalyst are FXG graphic primitives – basic shapes (rectangle, star) that can be easily assigned as a textArea, button, control area, etc. Catalyst also takes advantage of Flash CS4 “2.5D” animation (i.e. pseudo-2D as 3D rotations, etc).
Finally, Spark skins are all state-driven which means that skins are more than graphics – they also contain transitional (animation) elements. One of the most revolutionary features of Catalyst is the new timeline for transitions between states wherein Catalyst auto-predicts required transition for each element. The example given was a small search box, with a textfield and search button, that transforms to a result panel with a textArea. Once the transition was assigned from state to state, Catalyst knew which elements must fade-in and fade-out (buttons, result textField), and which ones change shape (the outer box & border) and had all of these tweens laid out and ready in the timeline.
Smart stuff.
So, give it a couple of months. I got Flynn’s card, and asked about interviewing him when Catalyst is released. My goal will be to translate programmer-speak into designer-speak and help Flash designers and animators migrate more easily into the Flash platform.
