The demo happened to have a lot of bitmaps in it, since it was a CD cover browser, but Thermo will work with both vector and bitmap assets. The main difference between graphics in Thermo and in Flex today is that vector artwork in Thermo is expressed through bona-fide MXML tags, rather than opaque SWF symbols. In the demo, for example, Photoshop text layers came over as TextGraphic tags, and rectangle shape layers came over as Rect tags. Naturally, MXML graphics will also support complex Bezier paths, rounded rectangles, and so on, and will support importing from Illustrator and Fireworks as well as Photoshop.

For static graphics, you could argue it’s about the same. But few graphics in a Flex application are static. Much of the “rich” in RIAs comes from dynamic graphics–graphics that change in response to user gestures or dynamic data.

In Flex as it is today, developers have to create dynamic graphics by writing imperative ActionScript code. With MXML graphics, developers no longer need to recode the designer’s graphics in order to make them dynamic–they can simply modify the graphics at runtime through simple property access, data binding, the transitions/effects engine, and so on. Designers can continue to edit the graphics visually in Thermo without disturbing the developer’s code.

For example, suppose I draw a button skin in Illustrator that’s filled with a blue gradient, and we want to create multiple buttons with the same look but different colors. My developer can just import that as MXML, and then data-bind the gradient color to some style parameter. Voila–instant styleable skin, without writing a line of AS code. I can then edit the shape of the skin visually in Thermo, and the color style will continue to work, without my having to rewrite a bunch of Graphics method calls.

Now let’s say I want to animate that gradient color when I mouse over the button. Again, I can create this through declarative transitions written in MXML, rather than having to build the animation into an opaque SWF symbol. And again, because the transition is in MXML rather than ActionScript code, I can visually design that transition using the Thermo UI.

Thermo is being created for designers, but of course it won’t be successful unless its output can be easily consumed by developers. Thermo will definitely provide easy ways to factor the resulting code into separate files. For example, skins can be automatically put into separate output files and generalized into CSS rules. (Flex Builder 3 actually already has functionality for extracting inline styles into CSS, and we would certainly have the same functionality in Thermo.)

One example of code factoring that wasn’t obvious from the demo was that when Steven created a list from the individual CD covers, the item renderer for the list was actually created as a separate file. When he then double-clicked on an item in the list to edit it, it felt like it was being edited directly in place in the context of the larger application, but Thermo was actually making edits to the separate item renderer file behind the scenes. This is an example of how we can keep clean code separation without forcing the designer to understand the guts of Flex.

Definitely. Our intention is to make it so that developers can create components that are usable in Thermo the same way the built-in components are. Naturally, they will need to conform to certain rules and/or implement a certain API in order for those components to work well in Thermo, but our intent is to keep those requirements lightweight.

That’s not the goal of Thermo. One way I like to think about the designer/developer dichotomy (woo, alliteration!) was suggested by Rob Adams: developers deal with system logic, and designers deal with user logic. The two are not exactly the same, though they obviously intersect. Our goal is to make it so that designers can use Thermo to design the user logic of the application (along with importing and editing the visual design), and provide a clean way for that user logic to be hooked up to backend data and business logic by a developer.