Will Thermo Be Too Hot for Axure?

With the advent of Thermo “some time next year” things are at last hotting up in the RIA design space.

Regular readers of this blog (if there are any such people) will know that I have been wondering for a long time in a somewhat Pooh-bearish way about the future of “The Designer” in the “The Development Process.”

While this is hardly a topic unique to this blog, my particular angle on it can be summed up by the following idea. Designers (by which I mean anyone who specifies a system that other people build) will get increasingly nowhere unless the tools they use to describe their designs work directly with the tools used to implement them.

For the past three years or so, UX people have been scratching their heads about how to approach RIA design. Wireframes are just about OK for synchronous, page-based interactions, but what’s a poor Designer to do when faced with Web 2.0 AJAX asynchronous madness? There have been several brave attempts to outline ways in which it might be done (some of them my own), but they all fall down for two main reasons: they don’t scale with the complexity (nice try, but no), and they don’t offer ways of passing the resulting artifacts on to developers or other designers to refine using their own tools.

For a while I tried to get the makers of Axure to see it my way, but I didn’t get very far. Axure is a nice tool – and I’m using it for real right now, but its philosophy is flawed. It assumes that Designers need to be kept separate from the build process. I think that’s an approach that spells failure. Despite moving slightly in the direction I wanted by introducing an API, Axure is moving down a blind alley in my opinion. I think Thermo (and to a lesser extent the Expression Suite) will prove me right.

Thermo looks like it might be the tool that covers the two big problems I mentioned above. It might be the as yet mythological “IDE for Designers” that I have wondered about. What’s perhaps most interesting about it is that it sits in the space that Microsoft have left between Expression Designer and Blend. That is, while Expression Designer can export XAML to Blend (and Visual Studio) it can’t import it back again. Not so with Thermo, which can both export MXML and import MXML that has been modified by Flex Builder (or by hand).

Of course, Thermo is aimed at making Flash/Flex applications, and traditionally there has been a suspicion of Flash as been somehow bad for user experience. But that’s in the lap of the Designer. Certainly, there would be nothing stopping you prototyping a page-based web app with Thermo. The fact that it would be built in Flex and not HTML may or may not be significant, depending on the production platform.

Which leads me to another observation. There is an alternative view on all this, and that is for Designers to keep up, they will have to be able to execute their own designs. However, this is not a view I can subscribe to, since the left and right sides of my brain are not sufficiently balanced for that. I find it hard enough constructing procmail recipes, let alone creating working applications in ROR. But perhaps people like me should watch their backs?

For now at least, I’m eagerly anticipating the arrival of Thermo while I fumble with Axure, wishing it did more.