Developing WorkflowLab: An inside look at the Adobe Flash Catalyst and Flex 4 development process

Note: This article was created based on Flex 4 beta and Flash Builder 4 beta. Minor changes in the description and code may be necessary before it can be applied to Flex 4 and Flash Builder 4.

In early July, Shafath Syed and Doug Winnie of Adobe contacted us with an exciting idea and opportunity. They wanted to build an Adobe Flash Platform based tool to give people a better understanding of project workflows and how technologies can help the project lifecycle. The twist was that the tool needed to be built using Adobe Flex 4, Flash Catalyst, and Flash Builder, which are all still in beta, and the public alpha of this tool had to be ready for Adobe MAX 2009.

One of the more daunting yet intriguing challenges of this project was trying to determine the best way to adopt and apply all the new changes to the Flex 4 design and development workflow. Our team at DevelopmentArc has a long history with Flex, so we are quite comfortable with the existing workflows, features, and quirks of Flex 3 based development.

Yet Flex 4 and Flash Catalyst change the way we work, and many of the existing approaches need to be modified or even scrapped for better workflows that fit seamlessly in the new Flex paradigm. Unfortunately, best practices have not been solidified or defined by the community yet, meaning that we had to adopt theoretical development practices and experiment with them during this project.

This article examines some of the challenges we faced while designing and developing WorkflowLab and explains how we resolved them. Perhaps some of the ideas we tried will help you and your team build a successful project in Flex 4, or at least get our collective mind thinking about new and better ways to make Flex applications using these upcoming technologies.

Understanding the vision

For the first month of the project, we worked closely with Shafath and Doug on understanding what they wanted the tool to do, including defining long-term goals of the application, the 1.0 release feature set, and the acceptable capabilities for alpha.

During this time, Doug provided iterative prototype builds in Flash Catalyst to show off behavior, layout, and functionality that he envisioned the product containing. By having a working prototype and several in-depth conversations about functionality, we were able to define the project scope, determine what features could be achieved for the current schedule, and, of course, stay within our agreed upon budget.

Architecting the project

Once the schedule and feature set were defined, we officially kicked off the project on August 10, 2009. This gave us approximately six weeks to architect, design, develop, test, and release the alpha of WorkflowLab. We had to deliver a build each week until one week before Adobe MAX, when we had to deliver the final alpha build. The goal was to show iterative progress to Adobe’s internal teams, allowing time for them to test the developed functionality, design integration, and verify the content in WorkflowLab.

Knowing that we had a tight schedule, we did some initial architecture planning before the official kickoff. During that time, we read all the Flex 4 white papers and feature specifications to see what was new and how the Flex team envisioned the features being used.

We took this research and documented all the proposed WorkflowLab features, use cases, and specifications for the alpha release. By the end of this phase of the project, we had a very clear picture of what we needed to design and develop. Finally, we started an architecture document that defined proposed data models, actions, controls, and other functionality at a system level that would be required as a foundation for the entire application.

Using a development driven process

Due to the limited schedule, development of the application had to begin before design. This was an inherently risky decision because trying to apply design after development can often add significant overhead. Yet we felt there were two main aspects of the project that would allow this process to succeed.

First, we had to build a lot of system-level functionality, such as defining the WFX format (the native file format for WorkflowLab) and building file parsing, file saving, and undo/redo integration. All this functionality required almost no UI, and if UI did hook in, we were able to leverage DevelopmentArc’s Core Command/Action framework that allows any part of the system to access this functionality whenever and wherever it is needed.

The second aspect we took advantage of was the new skinning architecture of Flex 4. One of the most powerful new features in Flex 4 is the ability to separate logic from layout using the skinning framework codenamed Spark. Knowing this, we decided to build every view in the system as a skinnable container or component and apply a basic test UI skin that would later be replaced by the final design.

At DevelopmentArc, we have been huge proponents of the Flex code behind pattern, which is a Flex 1, 2, and 3 workflow that attempted to keep layout and logic separated. With the new skin system, this separation has become more elegant, and more importantly, the Flex team has given us more granular control of how things are added and removed from the base logic.

Because we took the time to define all the features and their functionality, we knew exactly what to build and what each feature would do. This enabled us to build all the logic in the base classes and create hooks into the test skins using the new architecture.

Integrating the user experience

As development was kicking into high gear, our user experience designer, Chris Stone, was sitting down to define all the user workflows for the application. Based on our feature specifications and Doug’s final prototype, Chris used Adobe InDesign CS4 to create clear diagrams that defined all the workflows a user could go through. This enabled him to then define the exact UI the tool needed.

When the workflows were presented, both the development team and the Adobe team were included in the review meetings to make sure everyone had a clear vision of what was being designed and therefore developed.

The development team also used the workflows to compare against the current feature set it was creating, and if required, the developers could make modifications to the stub UI or logic to make sure everything aligned. The developers also gave Chris feedback if any of the workflows were missing steps or feature requirements the team was working on.

Once the workflows were approved by Adobe, Chris began the wireframe process using InDesign and his base templates. The wireframes were used to determine basic UI layout and to vet all the features we had defined in the specification documents. Once again, the development team used Chris’s wireframes to verify functionality and, more importantly, began defining parts of the UI skin that would match the final design.

For example, the wireframe of the task view showed the Add/Remove task buttons in the task control bar. This enabled the development team to place two Spark buttons in the skin and define them as skin parts for the backing SkinnableContainer. The goal was that when the final design came in, the developers could just apply the design to the skin class with no direct impact on the backing logic.

Applying the design

Once all the wireframes were completed and approved, Chris began creating the final designs in Adobe Illustrator CS4. By using Illustrator as the design tool, Chris could hand off the AI files to the development team, who would then use Flash Catalyst to convert the design to skins.

Due to the complexity of the design, we felt it was best to break the design into parts, such as the main task view and the right panel. Using the copies of the same AI file Chris used to design the application, the developers moved elements from Illustrator into Catalyst. Once the designs were in Catalyst, skins were made of the different subparts, such as the Add Task or Download Trial buttons. The skins were then exported to a Flash Catalyst Library (FXPL) file and brought into Flash Builder. Once in Flash Builder, the skin files were copied from the FXPL project into the main WorkflowLab project, modified, and integrated into the WorkflowLab logic base.

Considering the integration of FXPL, we chose not to link our project directly to the newly imported FXPL because of a few factors. First, our FXPL skins often required modification in order for the skins to behave exactly as we required in the application. If we directly linked our WorkflowLab project to our FXPLs, any modifications would have been overwritten on the next import. During the first few iterations of skinning, the FXPLs were re-imported several times a day. By copying files from our FXPL into our main WorkflowLab project, we ensured all changes were saved.

Second, we had multiple developers working at the same time, which meant we could not share the same FXP file (Catalyst project) because it is a binary file. This also meant that we were generating multiple FXPLs, one for each Catalyst project. Trying to manage FXPs, FXPLs, skins, and projects via our code repository was too time-consuming, so we found it was faster to just copy the skins to the source project and check those into Subversion. This also ensured that the main WorkflowLab project had no dependencies on external projects outside of our DevelopmentArc core library.

Next, many of the skins we needed to create were dynamic, meaning they resized, such as the task bars, buttons, and scroll bars. Flash Catalyst does not support dynamic resizing yet, so we had to update our skins inside Flash Builder 4. We used Catalyst to generate the base FXG/MXMLG and then modified it to create the functionality we needed.

For example, the ScrollBar thumb needs to resize depending on the size of the scroll window. To do this, we used two FXG rects. The first rect has its top/right/bottom/left (trbl) set to 0. The inner rect’s trbl is set to 1. By setting these properties, the thumb can resize dynamically as the scroll window changes. Making these changes in the main project instead of a generated FXPL project prevents someone from updating an FXPL and accidently removing our customized functionality (see Figure 1).

Finally, Flash Catalyst does not currently support the ability to bring in Flash Builder 4 generated libraries or projects. Even though we created skinnable components, we could not place them in a shared library with Flash Catalyst. Ideally, we wanted to hand a Flash Builder 4 FXPL with our custom views to Flash Catalyst, skin the library, and then send it back over. In the future, this will be possible, but for now we had to work with Flash Catalyst only generated libraries.

How did it go?

During the development process, we hit multiple stumbling blocks. Many were due to the fact that these technologies are still in development. That is part of the challenge when developing on a shifting platform.

Some the challenges were caused by changed workflows or feature sets. Questions kept coming up: What component should I use? How does this new feature work? Am I doing this right? Once again, these are common issues when learning a new technology.

There were definitely moments when we found ourselves baffled, wondering why the tool was doing exactly the opposite of what we wanted it to do. Some problems were bugs, some problems were changes, and some problems were just our own misunderstanding of how a feature worked. As people heard our day-to-day stories of working with Flash Catalyst and Flex 4, they kept asking, “Well, is it better than it was before?”

For us, the answer is a resounding yes. Prior to this project, we would have told you that skinning a Flex application can be one of the most time-consuming steps of the process. Yet with this project, the skinning went exponentially faster than any project we have worked on in the past. Once the fully designed skins were made, we needed almost no logic changes beyond the adjustments we discussed earlier. In most cases, our development stub skins were simply replaced with the final skin, and the component worked as expected.

We can’t say it’s a smooth and seamless process yet, but the new system is by far faster and more powerful than before, once you learn it. We are definitely looking forward to the next project so we can tweak our workflows and watch how the platform evolves over time.