Flash Catalyst: Why I'm not so sure this is a good idea.

If you read this blog, you know I'm a Flash/Flex/Air type developer. I've been working with these technologies in one form or another since ActionScript was called Lingo, and I know where the FS in FSCommand comes from.

To make my point early on, I am having serious reservations about Catalyst. I saw a live presentation from Adobe yesterday introducing the Catalyst beta, in which I feel the presenter sidestepped my questions regarding how Catalyst was actually a step back, not forward. I've downloaded and played around with the tool, and while I think it's a remarkable GUI authoring environment, I believe that it is going to reintroduce a variety of workflow and stability problems that were finally getting solved with Flex.

Catalyst, which is marketed as, "Adobe® Flash® Catalyst™ is a new professional interaction design tool for rapidly creating user interfaces without coding.", is detailed at the Adobe Catalyst Beta web site.

Now the discourse:

As an independent, I've worked on teams of all kinds, every shape and size, in a variety of different business verticals: entertainment, media, financial, you name it. After a while, you get a notion of what works, and what doesn't. When I get pinged about a project, I've gotten pretty good at anticipating what I'm getting into based on the project description, who was involved before, and what the current state is.

One of my biggest nightmares in the ActionScript world is getting involved in a project where, "the code is already written, we just need some changes and fixes to be made." Naturally, I always respond with, "why can't the original developer do it?" The usual reply, "oh he's not available." This may be the whole project, or just a piece of it, but the result is the same.

I've come to know, that almost without variation, this actually means:

"We had some great visual concepts for this application we wanted. We interviewed a number of developers that talked about things like wireframes, functionality, and specs. It seemed complicated and time consuming, we wanted immediate gratification. We found a guy who had this great looking website, really good design, who said he knew Flash. So we hired him. It was going along great, really fast, but when we requested some new features, and changes to old ones, and integration of some new data, the developer turned out to be unavailable."

I have visions of this designer, who at best may have understood a handful of canned script procedures, furiously googling ActionScript samples, hunting down code scattered all over named timeline frames, looking at a library of unnamed assets that was allowed to get out of control, posting "can anybody help me" on the boards...

...and now the client wants an "expert" (vis a vis, "somebody else to share the blame") to come in and clean it all up. No documentation, no access to the developer, or at best a hasty email saying "it's all on frame 2 just look at the code", missing external assets, often not even a project that will compile.

This isn't a once-in-a-while scenario. I see it ALL the time. When I was making my bones as a contractor, I'd take these jobs. Now I avoid them like the plague, because they're losers. Why? Because the client will feel that because it used to work, or currently does but just not the way they want it to, it should be cheap and easy for an "expert" to get it running as required.

What they don't know is, the project is a disaster, there's virtually no unravelling it, and even if you can, huge portions of it will need to be rewritten anyway in order to get the extended features working properly...

...but, they cry, "Flash is a visual development environment. It's supposed to be easy to create interactive widgets. I don't understand why OOP, or documentation, needs to be involved with this at all. We're not looking for an application per se, we just want this little bit of video/playlist/data functionality, but instead of doing it this way, we need some changes. We need you to be flexible."

This is what happens when designers are put either in charge, or at the top of the process, of actually building software.

If you're a designer, you're probably insulted now. Stay with me, I think you'll see what I mean. If it helps to keep you reading, I have IMMENSE respect for a designer that understands how to work with a software developer. It's just that the overwhelming majority of "Flash" designer/developers don't, because they assume that coding is secondary to design. I know it for a fact.

If a coder makes comments about design, the designer will certainly not take it as authoritative. Why? Because a coder != designer. If you've taken it upon yourself to study both design and coding properly, more power to you. But in general, a coder may have some design ability, or a designer may have some coding ability, but the "some" is secondary, it's not a studied, practiced, primary skill.

Flash is not a design tool. I don't care what Adobe tells you, or what you've seen people do with the vector drawing tools. Flash is a tool used to build interactive, web-based software. Call them widgets, call them stand-alone components, call them "players", call it "a design-time scripting environment that builds interactive media", whatever. Those are euphemisms.

YOU ARE BUILDING SOFTWARE, and that ENTAILS SPECIFIC SKILLS.

No, Flash isn't for building operating systems. It doesn't have to be. An extension on the house for grandma, or a new hi-rise on the waterfront, are both "buildings" created through the process of "construction". You have to get permits, zoning, you need blueprints, good material, and a knowledgeable contractor with specific skills.

If you've ever watched BBC, there's a show called "How Not To Decorate". These two Brit designers ("the Lads") go into these nice homes that are atrociously decorated, and have them restructured to accommodate their design vision...THEN they add the design. I love this show because I see it as being directly analogous to software development. Do you see these guys selecting foundation materials, or trying to put cushions in the room before the builders say "ready"? Do you see them working without blueprints, only using their comps? Do you see them trying to find tools that build foundations without doing any digging?

No. You don't. They recognize their expertise, and work within the boundaries of their roles. They hire top-notch builders to explain to them what can and can't be done in terms of the design concept. They push the builders, but in the end, when the construction lead says say "not with this budget, not in this time, not in this space, not in this ground", they accept the limitation and rethink. They are integrated in the process, they attend the meetings when it makes sense, in fact, they are in charge. But they don't actually do the construction work. And in the end, they never get "pixel perfect" according to their original design vision; they work with the finished structure, rethink some of the concepts, and succeed. They don't say, "my comp shows this 10 inches this way. Tell the builders to tear down the wall and rebuild the room."

WHY does this basic, obvious, logical and sensible thinking, fall apart when it comes to Flash? There are so many bad examples to prove it, so many that Flash is easily maligned by all the "Web 2.0"--whatever that is--fanbois (apologies to Mr. O'Reilly) as being unstable and bulky garbage.

A few years ago, enter Flex. Adobe takes a stand: Flash development is about CODE, and that means, CODERS. I saw an Adobe presenter proclaim this vehemently in both the presentations I saw him give. The designers were up in arms; how dare you! I'm a designer, I don't want to have to learn about code. I want the tool to do it for me. You are ruining my livelihood!

No, we're not. We're simply giving you the opportunity to do what you do properly. Flex has a great workflow for this; finally, architects and coders were back to doing the construction. Designers were integrated where it made sense; they created assets based on areas of the project that are completed and stamped "ready" by the builders. They worked on the CSS and images in Photoshop and Illustrator, burned them up into vector images and/or swfs, or whatever, and placed them as static assets or libraries, ready to be applied to the finished components. It's a solid workflow.

The job boards are the evidence: enterprises are starving for Flex developers, because at last, it seems like we're getting some stable software out there. Flash isn't a toy after all, you just have to apply professional workflow, to any size project, to get it running. Architects and coders lead construction. Designers create vision and assets, which are integrated when the time is right. That's how you build things. Event "the Lads" know that.

Yesterday, the Adobe presenter said that Flex put code and development first, design second, and that they saw this is being "backwards"; the fix is Catalyst. Designers would once again be given a tool which, with very little or no code, they can use to take their designs FIRST, and THEN apply code, which is auto written.

He even went so far to say that the Flex developer can view the code, and edit it as necessary. Oh-my-gawd...say it isn't so. You are actually saying it's a good idea that I work with code whacked together by somebody that knows nothing other than how they want it to look, and maybe has a rough notion of how it should work? And that they should be doing this on their own in a completely different development tool?

Think of it this way: why doesn't Adobe create a tool that let's programmers auto-generate designs based on wireframe structures? Let us give designers .psd or .ai files with auto-generated and named layers, pre-sized assets, all the rest of it, and let them just clean it up as needed.

Why? Because it wouldn't work. Designers would shit all over it. And they'd be right to. But this is exactly what they did to developers with Flash, fixed with Flex, and are doing all over again with Catalyst. Designers are getting involved in more than design, they are now generating MXML...lots of it. And the Flex developer is going to have to deal with it.

I talked to two other experienced ActionScript coders, that work heavily with Flex, about this. They felt the same way; here we go again. Designers are going to throw stuff over the wall to us and we're just going to have to deal with it. If an event doesn't fire correctly, or a state change doesn't work, we're not going to be able to go back to the designer and say "rework the component". They'll say no, it's not their job. And the client, as usual, will side with the designer, because...designers aren't coders. That's your job, Mr. Flex OOP guy.

Adobe has caved; this is 180 degrees from what they were saying maybe three years or so ago. Once again, they're marketing immediate gratification via Catalyst. Designers will latch onto it because they can make text fields change color when a button is clicked, and the assets will look exactly how they want, but they won't really understand what the tool is generating, because Adobe is telling them not to worry about it, let the Flex guy sort that out.

With all that said, my predictions:

- Catalyst will flood the field, once again, with designers fronting themselves as developers, and when a serious ActionScript guy on the project says, "this stuff is useless, the designer needs to rework the component", everybody will say...no man, that's your job.
- I will end up using Catalyst, because I'll frequently tell a designer, "just send me the assets, I'll rebuild the component". So, Adobe's notion that designers will use Catalyst, developers Flex, is misguided. Exactly as I am frequently forced to crack open Flash to fix these things, so I will be forced to crack open Catalyst.

Can Catalyst be used productively? Sure, if a team discusses the tool with the designers and specifies how exactly it's to be used. Unfortunately, in the world of independent development, that rarely happens. Marketed and prescribed workflows are rarely adhered to in all but the most well-funded, tightly controlled, corporate projects. I've seen startups collapse and corporations throw away piles of money because of this, and I don't think it's entirely their fault. They're being misled into thinking that software development is a commodity skill that should be cheap and on-demand. Design, on the other hand...now that takes something special, that's an art.

Ugh. Once again I'm going to hear...

...we had this designer come in, he used Catalyst, so all the code is written. There's a few fixes though, and we need some changes made to extend the functionality...

...and once again, now that I don't need to deal with that BS anymore, I'll hang up.