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.
- 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.
- 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).
- 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?
Without knowing a whole lot about the product I see it being a great tool that allows designers to whip out quick prototypes. At this point who knows what the code will look like in the final release. Maybe us devs will be able to pick up some of the MXML and reuse it. Does it dump everything into one massive MXML file, does it seperate style from the content?
We have all worked with WYSIWYG editors in the past (Ultradev, Dreamweaver, etc) and yes they get the job done but if you are building a large scale site/application you most likely had to go in and tweak or rewrite a lot of the code. I don’t think Thermo will handle things like multilingual views, advanced state logic, etc. In an MVC world I see Thermo MAYBE helping with the V. Only time will tell.
I agree with Scott, prototyping is a key, but missing, area in this business. Maybe the developer could extend Thermo with custom components and so the Interaction Designers can show to the clients what they want to achieve instead of creating hundreds of pointless wireframes.
I see it as a useful tool for the Graphics\Designer folks to quickly mock up usable prototypes that they can tweak and fine-tune before ever handing over to the developer. As it stands now, I (the developer) receive static images with notes and blurbs about how it’s “supposed” to work which I then have to develop from scratch. It would be great to actually receive something that remotely resembles a base application written in proper mxml (Fireworks is trying so hard to get there, but they’re not there yet).
And I’m totally with Greg on this — Susan is never happy and impossible to satisfy! I mean, how many pairs of shoes does one girl need?!?
Meh, I have a feeling it will appeal primarily to creative-executives, who feel compelled to wet their toes with Flash, because they know it will help them communicate with their developers (who always only have to implement just a tad of code), and they have a nagging idea that since they’ve figured out how to run a company, and might know abit of HTML, it can’t be much more difficult to “crank-out a Flash site”.
I’ll be happy to meet Thermo if it automates creating UI classes, with a basic strucure of event listeners for selected Sprites pre-written, and maybe even basic ‘selected’ state memorization. I’m just tired of typing, ‘package com.blah.blah { class Blah, .addEventListner(MouseEvent….etc’. Does that make me guy #1,2 or 3?
Thermo would probably make some graphic designers much more interested in Flex.
Thermo would be my ultimate prototyping tool for the quick prototypes to show team members and management. I can do a lot of it already in Flash and Flex now, but Thermo should make it a lot faster.
Or better yet, If Thermo is easy enough to use, I can mockup the design and then hand it over to a production assistant to make it “work” enough for a focus group or usability test. This will free me up for either UI design or building apps that exceed Thermo’s quick-build abilities.
I’ve been in many conversations recently with designers and developers about how AS3 and its structure is going to really decrease the number of designers that really want to try out and play with Flash without taking classes or reading code books – just to play around with it. The AS in the past, being so loose, allowed for a lot of improper set up and completely hacky stuff – mix that with the timeline and there was this huge wave in the late 90s of designers doing some amazingly cool things with code in Flash because you could just pick it up. This didn’t make the code practice correct, but expanded ideas. In my opinion, I wonder if Adobe might have realized this hence the new product? It may be as much just for the designer as a creative toy as it is supposed to be to streamline client projects / process.
Prototyping the same-old-thing… maybe. But I still think you need a “programmer” for anything more than just a walk-through type prototype. I too am scared of the code that’s going to get generated by interactive content assembled in Thermo. Turning a Photoshop document into MXML–now that’s awesome. Adding a bunch of hidden “gotos” all over the place… I don’t know. It’s a pipe dream to think the code generated won’t be immediately trashed by the developer. But, I’d be afraid of the stuff lingering.
Ultimately, I saw Thermo as simply a much improved design-view for Flex. Perhaps I’ll be proven wrong and for those who need moderately advanced interactive creations will pick up Thermo and take away the business of “real” developers.
My guess is Thermo will be one extra step the graphics folks can take to put the content into the form I want. But, even still, I’m not so sure that Thermo will assemble the MXML the way I want! I guess I could be more open minded, but..like I say: Thermo seems like an improved design view.
Hi folks,
These are all great comments. I posted an entry to my blog a few days ago that might help clarify the way we’re thinking about Thermo’s relationship to development:
http://www.rictus.com/muchado/2007/10/07/thoughts-on-thermo/
Our goal is *not* that a designer would build a complete app, with business logic and back-end integration, using Thermo. Conversely, our goal is *not* that a designer would build a toy prototype which would have to be completely torn apart and rebuilt by a developer.
Instead, our goal is that Thermo will allow the designer to create and own the portion of the app that s/he cares about–the visual design, the interaction design, and the user flow–and have that flow directly into production, where the developer can implement custom functionality, attach real back-end data, and hook up business logic.
In order for us to be successful at this, we obviously realize that the code Thermo generates has to be usable by a developer. Part of this will just be us being careful about making sure Thermo organizes and separates out code automatically to keep it clean without the designer having to worry about it too much.
Additionally, we’re planning to refactor the framework so that it is much easier to really maintain a separation between the stuff the designer cares about–appearance, layout, basic interaction, transitions–and the stuff the developer cares about. The stuff the designer cares about will be declarative MXML, so it can remain editable in Thermo. (Ely Greenfield had a great talk about this at MAX.)
Another part of our goal is to develop a set of tools and best practices for managing the touchpoints between what the designer needs to do and what the developer needs to do. The dummy data workflow from the demo is a good example of this. The structure of the dummy data that the designer works with essentially maps to the schema for the data the developer is going to hook up to. And the designer can continue to work with that design-time dummy data even after the live data is hooked up.
Hope that makes sense–please continue to post your thoughts!
nj
Adobe Flex team
My feeling is that any effort to bridge the gap between the designer and development process is a positive thing. I think the effort to bridge the gap between designers and developers is ultimately misunderstood by most developers. I also think the use cases exhibited in this post are a bit short sited.
Flex has been plagued by a lack of well designed applications. My opinion of Flex over time has been that it promotes mediocre work, due to it’s “rapid” development initiative. With tools such as the Flash Component Kit, and now the Thermo effort, we are now seeing a clear push to get Flex in tune with emerging media.
I get really itchy do discuss in detail how Thermo can be used but I see enough great comments to further pollute the discussion. But here are my 2 cents:
When a company delivering technological solutions, in this case Flex Framework and dev tools, is really trying to dedicate it self to optimize the workflow between designers and developers this is at least admirable. Can you think of any other big player on the market that actually even tries to do that and not just create designer tools that only a front end developer can pick up and use. I personally can’t. So let’s give the credit to Adobe for even trying to do that. It takes huge leap of faith to try and do something that a lot of other have failed or not even tried and if there is anyone that has a shot at succeeding its them. For anyone that has ever actually build a product and has an idea how much time, man power and money it takes to create a working product and not even know if you will be successful will know what I mean.
Great feedback all! Looks like everyone has a fairly consistent take on Thermo so far.
NJ – thanks for adding an “official” perspective. I’m looking forwards to seeing the code output as it matures.
Nick – mind elaborating? I don’t mind you saying the use cases are “short sited [sic]”, but it would make your statement a lot more meaningful if you provided some insight into why you think so.
Holy smokes you hit those persona’s dead on. I believe you and I must know the same Dan, Susan, and Greg.
Currently, I get the Flash prototypes from a Susan. I’m excited that Susan might be able to communicate what she is actually imaging a little bit better by using Thermo. My gut tells me that I will still probably program the thing from scratch in AS3, but I’m excited for a little better clarity of mind from her.
I see a possible use for Thermo that I didn’t see here. Thermo should provide a great way to implement better User-Centered Design. Getting a working prototype in front of the users before the developer (me) has touched it is fantastic. So in addition to the designer developer workflow we get the user involved with a “working” app sooner.
I’m completely mixed in my opinion. I also see this as mostly being a great way to speed up the design process, but I can’t imagine working on an app that has that much mxml clumped together. Personally as a flex developer, I like everything to be controlled, even adding listeners, by writing it out in AS, it sounds like it would be inevitable that I would need to go in there and change things around and group them into custom components, etc. I do hate converting PS files to MXML, that part of Thermo blows me away. I think it will work great as a flex super design view, but i think with creating functionality, it’s all or nothing. I know I don’t want to continue on a project that way(designer adding functionality). But then again, I have not yet seen exactly how the code will be written and like most people, I can’t help but to think of a dreamweaver type design mode project. I say, give me the photoshop file, I’ll do the rest!
Thermo *is* the progression of the current Flex design view. Adobe is taking it to the next level by adding tools with familiarity to designers and making it completely compatible with Photoshop and Illustrator. Because it’s such a change in work flow (and target user) it warrants becoming a new product – that and it now becomes its own money maker.
In the keynote Adobe mentioned that the same MXML can be worked on simultaneously by both the Flex developer and the Thermo designer. If thats the case, and you can somehow teach your designers to use versioning, it could be a great tool! As designers create a first run of MXML and commit often, I can restructure as they go and, as long as Thermo works at least as well as the Flex design view, The designer won’t notice much difference and can continue on happily creating (probably the wrong) components from their designs.
I like the idea of Thermo for one other exceptional reason: it will force designers to think about interactivity. Now they have to think about transitions, rollovers, what components actually exist in a real world, etc.
Ely Greenfield’s presentation on the Flex roadmap was certainly the right path for both Flex and this tool Thermo. If they spin it right, Thermo will be a successful tool.
xtyler
I share this mixed feeling about Thermo, but i also see it as a chance for better design/development integration. What i think is important here is, that Thermo in the end, will be just a tool. It will aim in helping designers and developers work together better. But it is just a helping hand. What is needed additionally is a change in the way designers and developers work together at the moment.
I guess designers, that want to get involved more deeply in creating a good user experience have to adopt a certain kind of structured workflow. For example, in order to create structured UIs in Thermo i think, this will already start in creatin structured PSDs that follow some basic rules, so that the resulting Thermo UI is inline with the agreement with the developers.
On the other hand, developers will have to be more open to the needs of the designers and have to be willing to accept some compromises in terms of the structure of the UI, that Thermo generates and i am sure, Adobe will never be able to build THE ONE UI structure, that all developers love.
In the end it is just a question of what is more important to our projects, the perfection of the code or the streamlined workflow (this will of course also have some impact on budgets, since streamlined workflows might cost less).
This reminds me a little bit on subversion, which is also ‘just’ a tool to help developers in working together on a project, but it does not elimate the need of developers having a basic agreement on how they want to work together. I think, this will be true also for Thermo.
If Thermo can finally make complicated skinning anything but the eye-gouging misery it is now, I’ll buy it.
I like the way thermo converts graphics into components. I like the way you can bind a scrollbar to a horizontal list by dragging a connector icon. I like how you can draw shapes and graphics with a graphic tool. I like how it has a layers view where you can hide or show layers. I like how it groups component skins into the layer groups.
I wish though, that these features were in Flex Builder. Or OTOH, I would like the features of Flex Builder in Thermo.
I don’t like that I have to go from Photoshop to Thermo and flatten the graphics out (I could be wrong about this). I don’t like the whole conversion process. When I want to change graphics how hard will it be? We have round trip code and design with MXML but will we have round trip with graphic assets? Can PS or AI pull that MXML file in and break out all the layers so you can modify it again?
I think advanced design view tools need to be in Flex Builder and/or advanced code tools need to be in Photoshop, AI (or Fireworks). I really like where Thermo is going, I just hope it will go 100% of the way there for those that don’t want to use Flex Builder.
If you read between the lines, I’m looking for an all in one tool (so that everything plays nice together and everything stays editable). My two cents. 🙂
Thermo together with new component model which Ely presented in Barcelona make sense to me, otherwise Thermo is just one more tool in Adobe bloated toolset. my 0.2$
Since I’m the bastard love child spawned from the fitful tryst twixt these thrain, I see this fitting into my workflow thusly:
Bang out some awesome eyecandy in Fireworks
Use the fancy Pages and Slideshow features to impress my poor bankrupted clients
Show them that I really can’t just launch their thing as-is because it doesn’t really DO anything yet
Forget to invoice them AGAIN
Import the shiny bits into Thermo and wire up with some ‘real’ interactivity
Show to clients, and try and convince them it gets even BETTER when we make REALLY work in Flex and CF
Have them refuse to pay one more red cent (even though they haven’t paid anything yet), and cave in to the fact that they really can’t be convinced to start over and budget the project for reals
Launch the half-baked Thermo project as-is, to the adulation & amazement of my three peevishly proud parents
Send the invoice