As you've probably heard already, Adobe demoed a new product called Thermo at the MAX Chicago Sneak Peeks session. In brief, Adobe describes it as a "RIA Design Tool", which makes it easier to build fully functional Flex applications from design concepts. If you haven't already, you should check out part 1, part 2, and part 3 of Aral Balkan's video of Mark Ander's demo of Thermo.

After watching the demo, and having a brief chat with Mark, one of the foremost questions I had was "Who will really use this tool?" Adobe is currently touting it as a designer tool, but I have enough experience in RIA development to know that I don't want designers actually building applications.

As a way of answering this question for myself, and hopefully providing some useful feedback to Adobe, I decided to create user personas for the three types of people I see using Thermo. These are based purely on what I saw at the demo and a large dose of wild speculation. I've completely invented features (and in some case non-features) to highlight things I'd like to see, and challenges I think Thermo will face.


  1. Dan, the "find me in the yellow pages" RIA creator. This guy (or small company) is the same dude that used to do Flash intros with code from FlashKit, and was making low-budget sites for small businesses using DreamWeaver way before it output decent HTML. His resume lists 20 technologies, 4 image editing suites, 3 HTML editing tools, 6 programming languages, 4 video editing tools, inDesign, and two 3d packages, but he isn't really proficient with any of them. He still hasn't upgraded from Flash 6 because he can't live without "normal mode". He doesn't care what the underlying code looks like as long as it sorta works. He's scared out of his tree by AS3, but thinks AIR might be worth looking at because it looks neat, and might let him snag a couple more projects per year.

    Dan's not a dumb guy, he's just trying to get his job done without having to think too hard. He also represents a huge market. He's going to like Thermo because it lets him take assets he creates in his familiar tools (PSD, AI), and wire them up easily into something that impresses his clients. He's not going to touch the code, or even look at it, except to copy it into a forum somewhere looking for help, or to paste in a snippet he found somewhere that makes the buttons pulsate. If he can't figure out how to make something work after doing a quick search on google, he has no problem telling his client it's technically impossible.

  2. Susan, the interactive designer. Susan probably works at a mid to large sized interactive firm or agency. She's a savvy interactive designer, who understands the general capabilities and limitations of the Flash platform. She's a master on the timeline, and uses basic AS1 scripting to wire up demos and prototypes that communicate a project's flow to the client and developers. Developers quietly curse her when handed the prototype FLA because she's awesome at making it look like everything is working, but the structure is all wrong and needs to be rebuilt from scratch.

    She's going to dig how easy Thermo makes it to take her design assets and build a prototype or storyboard with them. She'll start out loving how easy it is to build transitions in Thermo, but will quickly get frustrated because they don't provide the same control as a timeline, meaning that she still has to jump back into Flash frequently. She's going to get really mad if there isn't an easy way to get her timeline assets out of Flash and into Thermo. The developers she works with will be ecstatic that she's using Thermo because its innate separation of presentation and business logic makes it easy for them to build off of her prototype files (after stripping out all the business logic).

  3. Greg, the interactive developer. He's been doing Flash for awhile, and picked up some Flex in the past year. He knows his way around ActionScript, and is picking up AS3 and MXML quickly. For Greg, Thermo is the appetizer before his main course of FlexBuilder 3. He takes assets from designers (or prototypes if he's working with Susan, whom he dated briefly last summer before a messy breakup about WoW), and uses Thermo to build and skin his components, prep the layouts, and wire some initial UI functionality. He thinks anyone that "builds apps" completely in Thermo is a n00b, and he's probably right.

    Greg likes that Thermo simplifies some of the boring work of UI development, so that he can focus on the real brains of the application he's building. He's also happy that it makes it easy to tweak the UI to the designers' satisfaction, and grudgingly admits that parts of the prototypes that Susan creates are useful. He gets pissed off when he receives "pixel perfect" prototypes from Susan, and then has to figure out how to translate them into a liquid (resizable) layout. Greg is naturally distrustful of anyone's code but his own, but he's glad that Adobe put in the time to make sure Thermo generated code that is readable, organized, efficient, non-redundant, and adheres to best practices. If it didn't, he'd chuck it, and just start from scratch in FlexBuilder. He's also psyched that FB and Thermo play well together, and he can reopen his FB projects in Thermo when the damn designers decide to change the graphics (again!).

The one market I don't want to see using Thermo is the one that Adobe currently seems to be promoting. I do not want to see professional interactive designers building applications with Thermo. I guarantee they will get it 80% of the way done (the last 15% of which will be through sheer hackery), then run into functionality that they simply can't implement in Thermo. At that point they will hand the now bastardized code over to some poor code monkey like Greg, with the expectation that they can "quickly plug in" the last 20%. The reality is that the developer will either waste a ton or time wading through the gencode (regardless of how good it is), or will simply scrap most of it, pull it into FB, and start coding from scratch. This will lead to the same des/dev friction that I think Thermo should help relieve.

What do you think? How do you see Thermo fitting into your workflow?