Introduction

Designer-developer workflow (D-D workflow) in conjunction with Rich Internet Applications (RIA) has become one of the most talked about buzzword in the Flash community in the last few years. It created a lot of debate and uncertainty on how designers and developers were going to work together.  Now that Adobe's Flash Catalyst is public (since the release at the Adobe MAX conference last year), and that we have had a chance to play around with the tool, I believe it’s time to open a discussion on how the direction the D-D workflow should be heading based on my experience.  In this article I will talk about how Flash Catalyst (FC) should be used to allow designers and developers to work together.

In the last couple of years we witnessed RIA slowly moving to mainstream and the next challenge is to create RIA GUIs that have more animation and interaction, as well as applications, that don’t look like the traditional Flex halo ‘look’.   In order to achieve that we need to find a way for designers and developers to work together in parallel taking into account each other’s needs.

Don’t underestimate the complexity of creating a workflow; it’s an important yet complicated problem. How do we combine an artistic vision and story telling with the requirements of productive software development? How do we allow designers to take their ideas and turn them into interfaces that developers can code around? How can we create User Experience that it addresses usability as well as integrates some more complex animation?

Adobe’s release of Flash Catalyst soon, when it rolls out of beta, will be a powerful additional tool that will help developing applications that look unique as well as provide more animation between states.  Flash Catalyst enables developers and designers to increase their creative productivity and leverage their existing skills to create more interactive and better designed Flex application.   It also facilitates collaborating in a team when creating Flex applications. Designers can create their graphics using Adobe Photoshop CS4, Illustrator CS4, or Adobe Fireworks CS4, and Developers can then convert these graphics into a Flex application by importing the native files into Catalyst, while keeping the layers intact. Catalyst acts as a bridge between Flex Builder and CS4.

This article is based on my experience working with Catalyst and is based on creating production grade applications as well as listening and talking to many people in the Flash community.

The vision of Catalyst of creating a seamless round-trip workflow between Adobe Creative Suite, Flash Catalyst and Flash Builder may not be materialized right away but it’s inspiring and I believe it will change our D-D workflow. 

Flash Catalyst interface was built primarily for the designer and the IDE is similar in look and feel to Flash Professional and Photoshop.  It allows designers, to some extent, to quickly jump in and start using the tool in a familiar environment, writing ActionScript code.  However, part of Catalyst capability such as states, transitioning, Head-Up Display (HUD) and components are not as familiar to the designers as layers and artwork and they require training as well as experience and a different mind set.

There are different ways to work with Flash Catalyst and I would like to cover my view on how Flash Catalyst can be used and change the designer and developer workflow I am aware of the fact that the FC software is still in Beta and is improving and by the time the software will be released it will allow better integration between designers and developers, however I believe that many of the challenges and points I am raising will still be valid and applicable in the next few years.

Developers are from Mars, Designers are from Venus

You must have heard about the theory of left-side right-side of the brain. The claim is that a person who is "left-brained" is said to be more logical, analytical and objective, while a person who is "right-brained" is said to be more intuitive, thoughtful and subjective.

The theory was developed from the work Roger Sperry, a Nobel Prize winner, did in regards to medicine back in 1981. Roger discovered that the human brain has two different ways of thinking. One (the right brain) is visual and processes information in an intuitive and simultaneous way, looking first at the whole picture then the details. The other (the left brain) is verbal and processes information in an analytical and sequential way, looking first at the pieces, then putting them together to get the whole.  Although recent research has shown that things aren't black and white or simple as once thought, it’s reasonable to assume that designers usually have a stronger right brain and developers have a stronger left-brain.  That makes a difference in how they process information and even work.

By creating a designer and developer workflow we almost need to somehow have the right side of the brain and the left side of the brain to work together.

The challenge begins with the current RIA development cycle.  Currently the development is more developer centric, since the designer is only responsible for creating the pixel discipline, and the designer is usually not involved in any of the Flash experience. It becomes challenging to create Flash applications, since the developers need to be able to juggle between all the application disciplines such as converting .psd/.ai files into MXML, handling data, testing, services, coding, transitions, states and many others responsibilities.

Many developers find it hard to skin a Flex 2/3 components and the level of effort to control every aspect of the component as well as interactivity is high which led to many applications using the “out of the box” components, which makes many application to look like “Flex”.

Adobe is aware of these challenges and has been working in the last few years to close that gap by creating Flash Catalyst tool. Flash Catalyst reflects Adobe’s continual commitment to the Flash framework and the community and can help achieve a new design centric workflow, but it wont happen over night.

Flash Catalyst not just a designer tool

Before I start talking about the designer-developer workflow I want you to switch your mind set.  I am not sure if we should think of Catalyst as a designer tool.  If that’s the case then all the Flex developers are actually designers. 

Wait… before you start arguing, let me explain.  Part of creating RIA applications is the need to create the view which includes skinning components, CSS, states, transitions, effects etc.  Although it would be great to give all these disciplines to a designer that can do all that work for the developer, I think it’s a little bit of wishful thinking, if not a bit naïve.

Looking on the designer-developer workflow before Flash Player 10 and Catalyst; developer would get a composition from a designer and convert it into code. That process, to many, was a painful process that requires creating CSS classes as well as creating custom components, which took a lot of effort on complex components.

Let’s go even further back in time.  When Flash was first introduced back in 1996 it was intended to be used mostly by web designers as a basic editing tool with a timeline and other movie editing familiar tools. Flash slowly got adopted by developers as ActionScript 1.0 was introduced and the ability to add code to drive the animation was possible.  My point is that the tool should serve our needs and I would avoid putting labels on the product.

Secondly, I believe that although the tool is portrayed as if it allows seamless and effortless round tripping integration between CS4 and Flex, in reality, the round trip is not as seamless as described.   I believe that should lower your expectations before using the tool and you wont be disappointed.  At the end of the day if the tool saved you days of work and helped you skin and create interaction of your application while utilizing a designer to be more involved, then the product is a success and helped improve the workflow between designers and developers.

Don’t assume designers will adopt the technology right away.  Designers are busy just as much as developers and many are not as thrilled to adopt to a new tool that will require them to put more time and add to them more responsibilities not to mention learn more skill and change how they think of an artwork.  There is still a learning curve and round tripping should be improved for better integration. 

While that happens you should enjoy the tool and get designers more involved.  I will show you how to do just that.

RIA Designer-developer workflow utilizing Catalyst

By utilizing Flash Catalyst, the experience, such as animation between different states, can be done quicker in Flash Catalyst instead of handling these tasks in FlashBuilder or importing them into Flash Professional or other techniques that were in common use up until FlashBuilder 4.  It allows the designer to be more involved with the interaction and choreography of the application, in addition to having responsible for the visual appearance.

Once the work is completed, the artwork file can be provided to a developer, which can integrate it into the application and add business logic, data and services. As the project continues, designers can help modify the appearance and interaction and Flash Catalyst can convert these into code.

It’s hard to give exact instructions on how a team should behave since it’s a matter of scope of the project, size of a team, back-end technologies, methodologies used to manage the project and many other factors.  However, to give more clarity I will show an example of designer-developer workflow using Flash Catalyst.  Take a look at Figure 1.  It shows an example of a workflow between designer and a developer building RIA application.  Let’s examine these steps.

Step 1 - Preparation

The workflow diagram shows that we have the business side, designer and developer all working in parallel. 

Figure 1: Designer-Developer workflow diagram

The business side needs to provide the business requirements for the project and any other documents such as workflow, iterations, timeline, etc. 

These documents can come very handy.  For instance, the workflow document can be used by the Quality Assurance (QA) team to test the application as well as for the designers and developers to understand the functionality of the application.  Another example is that the business requirements can be used by the developer to create unit tests and ensure all the business requirements are met in full.

Parallel to the business side team working on the documents, the designer can start creating the artwork.  It can be a designer or designer team, which can include a graphic designer, art director, UX designer and other members can start working on taking the wireframes and bringing them to life.  During that process the designer can consult with the developer and the business side to see what is possible and the level of effort required to see if it is possible to bring ideas to life under time constrains.

While the art team is preparing the artwork the developer or development team can start by setting version control, continue integration, unit testing and so on.  The developer’s can add a framework, prepare any documents that are required such as Technical Requirement Document (TRD), UML diagrams and others as well as start creating Proof Of Concept (POC) to ensure certain parts of the application can be done and find any road block at an early stage.  It depends on the methodology implemented by the team, preference and other factors.

Step 2 - Converting Artwork and Interactions into Code

At the second step, the artwork needs to be converted into code and any chorography should be implemented.  I believe that the developer, rather than the designer, should convert the artwork into code.   Creating one project file (FXP) will make it very hard to integrate correctly into an existing application.  For instance, think about an RIA application you have built in the past.  The approach was not to create one document that holds all the different components, but to create custom components and use them all either as one project or create modules to load the ones you need to optimize your application. 

Working with Catalyst should not be any different than that approach.  In fact, I found that the best approach is to identify the different views you would like to break your application into custom components instead of trying to create one Catalyst application. Additionally, it will be hard or even impossible for a team of designers to work on a single catalyst file.

What I mean is that you would figure out how you would like to split your view and create Catalyst projects based on that.  For instance consider the following use-case: you have an application with a login form and than a list component that shows results. You can break the application into the login component and the list component.  You should create two Flash Catalyst projects and each project can holds the states and the transitions between each state.

Your assumption should be that you would have to change the Catalyst’s code and adjust it instead of assuming that the code Catalyst will spit out production grade code.   Another assumption I believe you should make is that you will not be able to port the code back into Catalyst or it will be difficult since it’s very likely that the code the Catalyst generated will have to be modified.

Another point I would like to talk about is states and transitions.  RIA is known for the richness in media, effects, transitions and the ability to make changes to the application without refreshing the browser.  In fact, Adobe is working on a collaborative scriptwriting tool for film called Story (http://labs.adobe.com/wiki/index.php/Story), which will enable the online pre-production workflow.  To create a compelling experience we need to think about the entire experience rather than the pieces that make the application work.  The user gets to the application and we need to figure out the usability as well as the choreography.  Let’s think about creating a movies clip in Flash Professional.  We can create a timeline and a movie.  Although Flash Professonal is richer and allows better choreography of animation, Flash Catalyst will enable us to take RIA one step further since we can create visual animation for component easier than was done before using only coding.

Although I am recommending for the developer to use Catalyst to convert the artwork into code, the designer will stay very involved in the process and can provide assistance when states are missing graphics and elements converted into images. 

Flash Catalyst uses Flash Player 10’s new drawing API and allows keeping vector graphics, however, certain things will convert the vector into images, such as certain drop shadow.  It’s best practice to avoid vector turning into images as much as possible.

Using the FXG rather than images can give you a much better and crisp look to your applications, not to mention decrease the size of your SWFs (if image embedded) or increase performance since the FP10 drawing API is faster than loading external images during run-time.

Step 3 - Integration of Code into Application

Once the work with Catalyst is completed, files can be imported.  The format is FXP (Flash XML Project), which Flash Builder 4 recognizes.  There are many ways to use the FXG component such as inherence and composition. You can use them as is, or use the presentation model.  Personally, I found the best approach to be the presentation model. Here are some of the advantages of using the presentation model:

1. You can tie it well with unit testing.
2. The component is loosely coupled.
3. You can replace the view more easily.
4. It integrates well with MVC pattern and the new Flex architecture.

There are many types of implementations so I am not going to go into detail but the idea is to have a ‘clean’ view that doesn’t have any code so you can easily make changes to the view and follow the Flex 4 and Catalyst architecture of separating pixels from the plumbing.

By doing so you will be able to exchange the components and skins more quickly than having a component that holds code and visual components.

I recommend importing the FXP project as a separate project and slowly copy paste the components, skins and assets into your existing project ,placing them in a namespace that matches your application’s framework.

During this process you will find that you have to make all kind of changes to the code such as:

1. Refactor code to be more readable.
2. Rename skins and components to names that make more sense.
3. Adding id property for components
4. Make changes to states and transitions and properties to better fit business requirements

Additionally, you often may find that you need to replace a component to better work with your data.  For instance, replace DataGrid with List component or add a custom button that was left out, or, while integrating the application you may find that pieces are not making sense and they need to change.  During that process the designer can help and provide any assets necessary.  You may also need to get the business side involved in order to adjust docs or get in touch with the client to provide additional information.

Step 4 - Refactor

As you create different FXP projects there are cases where you are using very similar components and skins and you want to avoid that and try to refactor so you take into account reusability, which is of the building blocks of Object-Oriented programming.  For instance, because a button label is different you should not have two button skins.  You should adjust the skin so it can handle these two instances and remove one skin, which will make your application smaller in size and more optimized.

Conclusion

I believe that Flash Catalyst is a valuable tool and will change designer-developer workflow.  I believe that it will be an integrated part of the development cycle and you will find it hard to work without it, mainly since it will save you valuable development time.

The designer can create the pixel and adjust the pixel as you need to make changes. So while you may be the one converting the pixel into code, you can work with the designer to make the changes as you need them. For instance, you may notice that adding a shade to a vector graphic in Illustrator will convert the graphic into an image in Catalyst that doesn’t happen all the time except in certain cases. You can work with the designer and have these images adjusted.  As you work with the designer you can show him/her how you are working with Catalyst so the designer can slowly take over some of Catalyst work when he/she is ready.

I am sure that as Catalyst rolls out of Beta the round tripping and integration with FB4 will be easier.  Meanwhile, have fun and enjoy the tool when you can :)

Read more from Elad Elrom.