This article is sponsored by Adobe.
The workflow between designers and developers is a crucial aspect of developing rich-client applications. In this interview with Artima, Shafath Syed, Adobe's group product marketing manager, and Steven Heintz, Adobe's principal product manager, discuss the differences in how designers and developers approach rich-client application development, and how Adobe's Flash Builder 4 and Catalyst tools can make their interaction more effective.
Shafath Syed: If you take a step back, you will see that the Adobe Flash Platform is a complete system for developing applications, content, and video. The Flash Platform consists of a number of different components: tools, frameworks, clients, and servers. The tools include FlexBuilder, as well as the Flash authoring tool. And we are now adding Flash Catalyst to the tools as well.
The clients include the Flash Player that allows you to run content, applications, and video within the browser, and AIR that allows you to deploy those things outside the browser.
In addition to the Flash Platform, our design and development tools are tightly integrated with our Creative Suite products. They are also integrated with our server products and LifeCycle ES (Enterprise Suite). The combination of the Flash Platform with our development tools and Creative Suite gives you a lot of flexibility and capability developing both enterprise applications behind firewalls, as well as customer-facing Internet applications.
We're currently investing in our tools in three areas. The first one is in increasing productivity. Especially in the current economic environment, companies are focused on the bottom line: They have limited resources, limited budgets, and limited time to develop applications and content.
We've found that you can gain a lot of efficiency when tying the development and design side aspects of developing applications. Flash Catalyst, a new tool for the Flash Platform, enables developers and designers to become very efficient in working together on rich-client solutions.
Second, whatever you're developing, it's not enough to just develop a front-end. You need to be able to tie into back-end systems: enterprise back-end systems or services, such as Internet services for location databases, for example. We're investing in making it a lot easier to integrate with those systems out there.
Third, we're investing in giving you the ability to create expressive applications that are visually compelling to people. Not only applications that are visually appealing, but also applications that are intuitive to use and don't require someone to read a manual to learn how to use them.
Frank Sommers: Why are you renaming Flex Builder to Flash Builder?
Shafath Syed: Flex currently refers to two things: the open-source framework, and our developer tool, FlexBuilder. Our new releases include a new version of both the framework and the tool. The new framework is Flex 4, but we are changing the name of the commercial product to FlashBuilder.
The FlashBuilder name is more consistent with the naming of our other development tools for Flash: Flash Catalyst and Flash Professional. It also positions FlashBuilder as the development tool for the Flash Platform, whether you're using the underlying Flex framework, or using pure Flash content.
The name change to FlashBuilder also allows us now to focus the Flex brand on the open-source product. We think there's a lot of value behind the Flex framework, and the fact that it's open source. The Flex framework is also the basis for the other tools, FlashBuilder and Flash Catalyst.
Frank Sommers: Why is there a need to have two separate tools for developing rich client content for the same platform?
Steven Heintz We believe you do need multiple tools, because developers and designers have different ways of working with a visual IDE. Developers are comfortable working with code, using a text editor. Designers, on the other hand, have different workflows and working models that they're comfortable with.
There is a difference in roles and backgrounds. Developers think about application development from the model up. You think about the data, what the UI widgets need to look like, and you move upwards to the user experience from there. Designers think about shapes and colors and gradients. They start with sketching out with broad strokes what the experience is going to look like. That's why the different tools. That's why we didn't put the design tools in Catalyst inside of FlexBuilder as well.
In a lot of workflows, designers then sort of throw those artifacts over the wall to a developer. The developer then has to cut up the design, and adapt the designer's intentions to the code. At that point, it falls on the developer's shoulders to implement the designer's intentions, including user interaction and expressiveness.
We're trying to change that with Catalyst. We're building our products architecturally where you can just continue to open up the same project in either tool. That said, developers tend to be quite territorial, as they start to fold in their frameworks, and do very specific things: they're responsible for checking out the code from source control, doing tests before checking things back in, and so on.
The workflow we're enabling with the initial version of Catalyst, along with FlashBuilder, is that the designer creates the interaction design for the UI, hands it over to the developer, and the developer then starts working on it in FlashBuilder. Every time a designer makes a change after that, she just hands over a file to the developer. The developer can then do a couple of diffs, and then merge those diffs in, and then check the changes in. The control still lies with the developer initially. It more closely maps the workflows that's actually practiced, and makes it more effective, in fact.
Frank Sommers: How does Catalyst compare with other designer-focused Adobe tools?
Steven Heintz We describe Catalyst as a professional interaction design tool. It allows you to create both application interfaces as well as content. When we talk about content, we're speaking of event-driven content: When the user clicks on something, the application does something. It looks and feels like a design tool. It's something a designer starts to draw in, or bring raw artwork into, to start to compose an interface. It's a different way of thinking about creating an application experience.
With Catalyst, we are enabling the designer to play a much bigger role in the implementation of interaction design. In that way, we're making user interaction a design discipline as opposed to just placing something on the developer's desk.
In this paradigm, the designer is not only working in terms of the design tools, but also at the full capabilities of the Flash platform. With Catalyst, we make sure that the designer can exercise all the capabilities of the Flash platform: 3D effects, animations, transitions. That will also allow developers to take advantage of all those capabilities to a greater extent.
Designers are creating two kinds of content with Flash Catalyst. One is a high fidelity, interactive prototype, something that's practically ready to be published, except that all the data may be baked into it. Another thing Catalyst can create is a Flex project. As the designer is working, in the background MXML code is being created, and a Flex project is being generated. That project, in turn, can be handed to a developer using Adobe FlashBuilder and can then be extended in that tool. It can be hooked up to back-end data and services in FlashBuilder, for example.
In Catalyst, we also have a timeline. This timeline, however, is very different from Flash Professional's keyframe-based timeline for expressive animation. Catalyst's timeline is based mostly on what a user experiences in terms of the various application states. For instance, we have timelines for transitions, coming in and out of scenes, or control sliders.
Frank Sommers: What are some of the technologies that enable this sort of integration?
Steven Heintz What enables this is our big investment in the Flex 4 framework. We rethought all of our components, from button on up. With previous versions of Flex, when you dragged a button component, for instance, everything that made up that component was part of that and became part of your project. If you wanted to change the look of that button, you did that as kind of an afterthought. You brought in some images, and you replaced the default view with something else.
In Flex 4, we separated out our definition of components. The base piece includes the behavior, the logic. That's what the developer hooks up to, knowing that the button has clicks, or knowing how a list or a scroll bar behaves. But we've taken out into a separate file the skin for that. That skin file defines not only the visual look, but also the interaction design: how it feels when it goes from one state to another. Because that's all in a separate file, it can be iterated on separately without being disruptive to the developer's mainline code.
Have an opinion about Flex in enterprise applications? Discuss this article in the Articles Forum topic, Developer-Designer Intercation in Rich-Client Construction.
Flash Builder 4 Beta
Flex SDK 4 Beta
Flash Catalyst Beta
Frank Sommers is Editor-in-Chief of Artima.
This article is sponsored by Adobe.