Working With Dean: Flex Designer Developer Workflow

Introduction

I learn something new every project, and this one was no different.  The one I want to talk about today is that designers can do a lot more in the designer developer workflow than I’ve previously experienced them doing.

I work with a Visual Designer named Dean.  His job is understand the needs of the client, translate those to the application, and create visual designs for it.  He then needs to repeate this process via iterations.  He discusses with the client how the application should work, how the GUI works to accomplish user stories, and why it works that way.  This is a 2 way street as the client’s input is taken into account as well.  He also adjusts the GUI for my needs.  As the the engineer responsible for creating our application, I’ll run into challenges that I couldn’t have foreseen.  I’ll then give Dean a call, explain my challenges, and discuss ways to solve it.  Sometimes these are compromises, sometimes these are just me getting clarifications on how things are supposed to work.

Context: Flash Designer Developer Workflow

From my experience in agencies, that’s how designers are supposed to work.  Icing is if their designs are kick ass, because then you get more excited to make it work.  The caveat back then were their FLA’s.  I’ve never, ever, had success with designers and FLA’s.  A FLA is the binary file used for the Flash IDE.  It contains all of your graphics, sounds, fonts, animations, and sometimes video and ActionScript.

For agency work, a lot of times your design assets would arrive in a FLA.  The designer would sometimes create a shell of the entire site.  The FLA could of been used as a prototype in meetings to help discuss with the client, and/or perhaps the designer was creating the real design in Flash to ensure it’s what they wanted.  Bottom line, whatever I ended up getting FLA wise from a designer, I never used their FLA.

Instead, I’d create a FLA of my own, and port over the design elements I needed from the designer’s FLA.  Developers and Designers use FLA’s in different ways.  Additionally, Designers and Developers amongst their own kind use FLA’s in many different ways.  The main reason Flash Developer Certification never lasted long at Macromedia/Adobe was because there were so many ways to develop Flash content.  This is also why I never let designers touch my FLA; they’d end up breaking something, and both of us would have a hard time figuring out why.

The net result was a process of:

1. Designer gives me FLA
2. I create my FLA, and incorporate graphics from Designer’s FLA as needed
3. If design changes, Designer sends a new FLA
4. I update my FLA with new graphics/animations from Designer’s FLA
5. repeat

Copying and pasting Symbols from FLA to FLA, or moving them from Library to Library, has worked pretty well since Flash 4.  With the advent of source control into many developer workflows, this only solidified this workflow for me since you cannot tell what changed in a binary FLA from revision to revision.  Instead, a developer would leave a comment for each source control commit (hopefully).

The above applies to image assets as well.  If a designer gives me a Photoshop PSD, an Illustrator AI, or a Fireworks PNG, I’m usually the one that breaks out the image assets I need, and imports into the FLA the way I need them.

Flex Designer Developer Workflow

In Flex, things are slightly different.  First off, there is no FLA.  Flex is just like traditional web development.  All of your files are in a folder, and it’s up to you to organize them, and check all of them into source control.  While some Flash projects required multiple FLA’s, at least FLA’s were self-contained.  In Flex… no such luck.

As such, Designers currently have no way to easily play in their own design sandbox, like they could using their own FLA.  I’ve read on blogs of some designers capable of using Design View in Flex.  That may work for simple form based projects that utilize the Flex components with minimal skinning and heavier usage of styles… but I don’t get to work on those projects.  The Design View still doesn’t correctly visually represent your application.  My projects are usually the same as the old Flash ones: Designer has crazy cool ideas, and some utilize the Flex components, others do not.  The justifications for not using the standard GUI controls for Flex, even if the Designer is fully aware of Flex’ repertoire, is that it’s the best GUI solution for the user.

What this means is that you lose fidelity of the Designer’s vision, and thus must revert to more primitive ways to communicate the design.  Tools such as Photoshop, Illustrator, and Fireworks create wonderful designs, but they are not interactive, nor do they communicate application flow like Flash does.  Thus, you’ve taken a step back in workflow.  This results in more mistakes, more false starts, and generally more communication problems for the entire team, not just the Designer and Developer.  Time and money lost; software is hard enough, zomg!!!

Now, Dean did a few things on this project that did help.  The first was he created a master application example in After Effects.  This did a few things.  It really helped sell the client on the original design.  It also served as a great reference point for me to recognize how a transition worked, or how functionality worked.  I’d refer to it often.  Additionally, we all used it as a communication tool since we’re all remote.  Over the phone, we’d go, “Scrub to 1:37… see that fade on the top left?”, etc.  Worked a heck of a lot better than referring to multiple flat wireframes and design comp PDF’s.

As you may know, After Effects is a video compositing tool.  What this means is the output is a video file.  Unlike Flash, there is no access to the individual design elements that made the animation.  So, you can’t crack open an animation and see how the designer did it, and thus determine if it’s worthy to be used as is, or be re-created yourself.

For that, Dean created a skin file.  Skin files done in Flash are different than traditional FLA’s used as the basis of a Flash application.  Skin files are created soley for the purpose of using the skins in a Flex application.  Flex has the ability to embed Skins created in Flash, and use them as design elements for Flex components.  You typically do this via CSS.  In fact, this is exactly how the skins for the Flex SDK 2 and 3 were created.  You can actually go crack open this FLA in the Flex SDK and change to your hearts content.

Now, in the past, I’d usually do this.  Whether given a Photoshop comp or a Flash file, I’d create a new skin FLA file, create all the skins for export, and embed in Flex via CSS.  From my consulting, this is usually because Designers don’t have a clear picture of what Flex is capable of, nor how to design for it.

Not Dean.  He knew exactly what he was doing.  In fact, the expectations of the Project Manager were far and ahead of what I was used to.  Apparently on some projects, Dean has actually mocked out Flex projects himself, creating the CSS and MXML with states/transitions himself to illustrate how things are supposed to look and work.

Naturally, alarm bells went off.  I did the MXML, but definitely had him handle the CSS with regards to fonts.  For the same reasons I cited for Flash FLA’s, I don’t want Designers creating MXML I’m not going to use.  Sometimes I don’t even use MXML, but instead create many ActionScript classes to make the component.  It’s more effective for the Designer and I to talk out how things work, or for the designer to create a sample FLA/MOV of how things should look.  The way you create MXML and ActionScript, like Flash, is very personal and there are 2 opposing goals; the Designer wants to communicate concepts, and the Developer wants to create encapsulation.

Conclusions

There are 2 important things here I want to emphasize.  Dean created the skin FLA, and Dean handled the fonts in CSS.  That alone is amazing.  I’ve never had a Designer do that with me in Flex.  It makes my job immensely easier, and faster.  The fact that not only can we start the project with prepped assets, but as we iterate we can easily update those assets… that’s huge.

I’d like to think that I’m only lucky to be working with a great team at Enablus… but f that.  You suckers don’t get off that easily.  Instead, I recognize it as a maturation of Designers and Developers working on enough Flex projects together that Designers recognize the capabilities of Flex and how it works.  That’s just wonderful.  On the flip-side, I now have high expectations of the designers I work with.

Beware.  If you don’t like it, blame Dean for his pimpness.

How Flash Catalyst Changes the Flex Workflow

How does Flash Catalyst fit into this work flow?  The theory that I’ve read goes something like this:

1. Designer does their usual discussion, sketches, wireframe, design comp iteration routine.
2. Designer takes design comps (Photoshop, Illustrator, and/or Fireworks) into Flash Catalyst, and creates Application screens, states, and GUI controls.
3. Designer skins each GUI control, or creates controls from design assets.
4. Designer creates states and transitions of the application.
5. Saves as FXG.

From here, the developer can:

1. Open the FXG in Flex Builder
2. Add the necessarey code.
3. If the design changes, the Developer can use a diffing tool to merge in the changed FXG XML.

And that, ladies and gents, is complete bs.  I’m certainly not working that way.  I’ll do the same thing that’s worked for years in Flash:

1. Create my own Flex project.  Create all the framework classes I’ll need, package structure, and data model.
2. Create a new Flex Project for the Designers’ FXG Flash Catalyst file.
3. For the graphics XML I can use verbatim, great, I’ll use it and add code around it.
4. For the majority, however, I’ll code custom components.  A lot of the FXG I’ve seen from Flash Catalyst seems to ignore the best practice of putting styles into a single CSS file.  So, I’ll make a case by case judgement on which components can be used verbatim, and which need to have configurable styles with the Designer’s design as the defaults.
5. Anytime the Designer has an updated FXG, I’ll replace the FXG project I created from the Designer’s original FXG.  I’ll then either merge in the new assets and FXG I deem necessary, otherwise I’ll just refer to my updated and separate, FXG Flash Catalyst project for visual reference.

Like in Flash, Designers created MovieClips without a care in the world about how’d you actually code that stuff.  Sometimes, MovieClips weren’t the best way to go about it.  They shouldn’t care, either.  They should be able to design their vision how they see it.  It’s then up to us engineers to code it.  If we need to compromise and iterate, so be it, that’s how it works.  Done deal.

Flash Catalyst is no different.  The FXG a Designer creates via Flash Catalyst probably isn’t anything close to what I’d actually use in production code.  If they update their original file, fine, I’ll merge in manually the FXG, or parts of the FXG, I deem necessary.  It’s the same exact work flow I and others have used for years in Flash.

It’s important to realize that this is still a great thing.  We now have a native design format with a working tool for Designers to work natively in Flex.  We didn’t have that before, and we soon will.  I just think everyone’s ideal of Designers creating FXG that’s usable out of the box is complete rubbish.

…at least for the projects I do.  Again, some use the native Flex components, and some don’t.  So yes, I’ll use some FXG natively with no changes, but not all. And the keywords here are “not all” meaning, I cannot use the FXG verbatim from Catalyst, nor do round trip.  Regardless, I still think that’s ok as a version 1 for Flash Catalyst.  However, if Adobe can pull off CSS file support in Flash Catalyst with Font embedding, then hell yeah, I’ll bitch a lot less.  Pixel fonts for the epic win.  High bar for Adobe.