My presentation in New York at the Flex seminar is now online. You don’t have to register, just fill in the info and hit submit. You can download the slides there, or at the bottom of this entry.
I’ve done this presentation 3 times this year, and it has changed a lot in the past 3 months. That was when I started experimenting with getting Flash content to work with Flex, ultimately coming up with the idea for my presentation. I’ve learned some new things since then, talked to some real people already doing this type of work, and refined the communication of the ideas. The most drastic has been my return to the design world via a consulting gig, which has greatly affected my views on the subject. All of my OOP purism and framework obsessions in the past few years in application development and programming has definitely compromised my perception of design. I usually expouse the feature set and thus potential, but usually find myself longing for real, and actual designer participation. The larger projects, the less designer participation. Even worse, the “designers” have been less of what I would call a true designer.
I wasn’t “walking the talk” as it were, and it was quite frustrating. Constrained IT budgets leaves the responsibility up to me to convey value of good design, and thus pitch to my employers the need, from a technical perspective, of why we need budget for an extra team member. I’d say all 3 of my attempts that I can remember failed.
I remember reading a blog posting from a Flash designer on LiveJournal about 8 months ago. I had read his posting on one of the Flash community groups there about how a lot of his former work was getting outsourced. He perceived a lot of the work done as comparable. I’m sure some subjectivity colored his perceptions, but his main point was that he couldn’t compete with the insanely low rates and was extremely frustrated.
I suggested he charge for the creative vision, and long, satisfied client list he would bring to the table. I’m not sure if that advice went anywhere. Not sure if it went anywhere.
My network of design talent is just insanely small. I’d say I have a very valuable network of friends and colleagues that greatly contribute to my success. Only 1 is a professional creative, and 2 can do design services if asked.
That’s pretty pathetic compared to the programming talent I know. It makes it even harder to identify an “A-Team”. Typically, I don’t have to and most clients and potentials ask me about the development talent I know; rarely if ever do their requests vary from that.
That doesn’t help me when I have the opportunity to make a positive impact on a project by recruiting design talent. I need to do another contractor post to garner talent, but I have a feeling I need to get into some different blog aggregators.
Anyway, back to the presentation bashing. First off, in seeing myself speak and answer an audience member’s question, I have failed to effectively communicate what states and transitions are, as well as their value to the various programming and designer camps. I need to work on that.
Second, after talking to some coworkers, I need to do some more compare and contrasts of methodologies. A lot of people don’t recognize all the painful alternate routes one can take when using Flash in Flex, and therefore it is not immediately apparent why my methods are valuable and hard won.
I need to show some of those ways as well as their pros and cons. The tradeoff will be less in depth explanation of what Flex 2 offers with regards to design. I think it greatly adds context but gotta trim the fat somewhere.
One subtle thing that needs to be modified is the attitude. In talking to some individuals, I’ve found the traditional Flash Development workflow used in Application Development doesn’t fly because it’s based on flawed assumptions.
The assumptions were “Designers are not allowed in the FLA. They hand over production art as a prototyped FLA, and the programmer implements.”
This same assumption translates to Flex as “The Designer cannot create usable MXML. They instead should provide, like Flash, a set of comps or even a prototype FLA like before.”
This is flawed logic. One team has successfully had designers create usable MXML that the programmers can later utilize, as-is. That’s huge. Let me say it again in case you missed it. A designer created some MXML that the programmer liked. !!!!!!!
Naturally this is just one company, but it’s a fantastic sign nonetheless. There are plenty of Flash designers that can navigate a programmers FLA and be extremely productive and have a great contribution to the project. However, the pretense was that the FLA was setup, from the start, by a programmer.
This, to me, was WAY more important in Flex because of the way Cairngorm works and the insanely large code-bases on some Flex projects. Having designers navigate package structures seemed like a no win situation. Apparently I’m wrong and glad to be so.
Furthermore, my comments on the Flex design view weren’t agreed with by some. I verbally bashed its representation of my apps. While I did recognize it is a phenomenal improvement over Flex 1.5, I criticized how it’s not entirely there yet and thus shouldn’t be considered an iron clad tool in the designer’s toolbox. Others had contention with this and haven’t experienced the frustrations I have. Apparently the way I structure my MXML either is not the optimal way, or my expectations are too high. Hopefully the latter.
Again, I think I need to trim some of the Flex design context… that or just breeze through those slides quicker. As long as the audience recognizes the capabilities, that’s fine; the actual implementation on some of those things like programmatic skins isn’t really that important.
My original test run was 1 hour and 40 minutes with 20 of that actual Flex Builder 2 and Flash 9 demoing of code. The Flex Seminar one, because of hardware issues, was condensed into 30 minutes. If I speed through some of the Flex CSS and Skinning, I think that will allow more time for IDE showcases of code that really drives the technical points home. I’ve gotten decent feedback, and none negative, on my Flash approach code-wise. Still, I need to finish some more sample code. The examples I’ve shown in the past have been received well when seen in context, but are definitely agency biased vs. typically software shops.
I’ll iron this stuff out by MAX.
I was just about to ask for the slides, but clicked the arrow pointing downwards on the video player.
Great presentation, it confirmed what I had been thinking for quite a while about the combination of Flash and Flex.
Good presentation. Two main points stuck out to me:
First was your statement that Flex apps all look the same. Adobe should take notice when people say this, because its one of the principal reasons (among many others) why Java failed as a front end. Its no longer ok for Adobe to do a Flash 7 style library with components that all look the same, and push the effort onto your customer base to actually do all of the customization. No matter how easy it is to customize their design, most programmers will simply slap in whatever component they need rather than coordinate with a designer to customize it. If Adobe really wants to differentiate Flex applications from each other, they need to create a simpler way to modify designs. And these components need extremely sexy animation capabilities built into them from the start. I don’t know how Adobe would pull that off, its just been my experience that the area of customization for components is something that wasn’t really taken advantage of in Flash. When they were customized it was usually just to change a color or a font rather than to add any real bling to them. You can see this in Flex apps now, the characteristic gray always seems to be present and people just really add in their own highlight or offset colors instead of creating a really sexy and unique look. Part of the problem is that programmers tend to drive the development of applications, which leaves designers scratching their heads as to how they should contribute. This is obviously less of a problem in traditional Flash websites, but as the need for technical functionality grows in a project the problem rears its ugly head.
The second topic of interest to me was the use of states and transitions. When I first read that Flex was going to support them I got so excited about what the potential was. Then I read Steven Webster’s article series about Cairngorm and something in that article struck me as being in contradiction with the way that Flex handles states. Steven’s article basically said that the model IS the state, and developers should resist the temptation to spread state around their application as a bunch of primitives or whatever. Instead you should bind your interface components to the model so that when backend logic updates the model, your UI automatically adjusts itself. This seems contradictory to Flex’s use of states as being explicitly defined in an mxml file (which naturally seems to want to find its way to the view and/or controller). I’d love to hear anyone else’s opinion on this as I’m still kind of mulling over how the two different styles would coexist, or if I’m interpreting Steven’s article incorrectly.
Thanks for the comments Chris!
Regarding state, the ‘state of the app’ is still retained in the model, yes, like Steven said. The Flex 2 implementation of states are actually the View’s representation of those states. This is better in 2 ways.
First, the same thing existed in Flex 1.5 / 1. If I wanted to show an ‘error state’ for my Login component, I had to either code it to create controls / colors / animations manually, or use a ViewStack with extra bindings for the new components the ViewStack implemented.
States in Flex 2 allow the same thing, only more efficient in that it uses the new DisplayList. If a component is removed from the DL, it isn’t rendered, thus doesn’t take system resources. A lot of us old skool Flash Developers would just hide or mask out components which was extremely inefficient. ViewStacks work the exact same way.
Furthermore, the interface Flex 2 has for states is really nice. The ViewStack one in Flex 1.5 was ok, but it’s just a lot nicer in Flex Builder 2.
Finally, I don’t have to use copious, spaghetti ActionScript to code transitions like I had to in Flex 1.5. In 2, the states mesh really nicely with the transition tags.
Again, this has NOTHING to do with application state. My Login needs to visually support an error state as dictated by my designer. The actual state of the application however resides in the model, and IT tells the state of the Login when to change.
Make sense or no?
It does, thanks for the clarification. I was (incorrectly) thinking that if you managed state in your model really well than you could remove the need for seperate interface components to keep their own individual state. But there is more than one definition of state in a complex app and ultimately the view will need states just to respond visually to user inputs (especially those that don’t result in a change in the model).