« AIR Derby Winners | Main | Thermo is the talk of the town »
Why Thermo scares me
| By Rich Tretola | October 2, 2007 |  Print This Post
|
 (No Ratings Yet) Loading ... | 135 views |
Those of you who were at the keynote this morning saw a very cool demo of the Thermo project which is a Rich Internet Application design tool. Basically, the demo took a layered image file and imported it, broke it up into individual asset images and wrote MXML code behind the scene. It also went a step further and allowed the designer to convert text field and scroll bar mock ups into Flex components, using the pieces as the new skin for the MXML component.
So the demo was very impressive and really made it simple for a designer or anyone who doesn’t generally code to create a RIA.
Here is why this scares me. While I was watching the demo, all I could think about was the tons or image assets that were being embedded which would bloat the SWF file pretty quickly. But more importantly as a developer who may be working with the designer, I would be scared at to the code that would be given to me to enhance with back end data, etc. I can only assume that this would be one giant MXML file and I would then be working hard to break out the code into an MVC architecture.
So, although I have only seen a brief demo of Thermo, I can only assume that this product will make a designers life easier but will probably cause me to make a large contribution to purchases of Pepto Bismol. Just my 2 cents. 
Topics: Announcements, Flex 3 (Moxie), Flex Tools, Thermo |
October 2nd, 2007 at 3:31 pm
I’m totally with you. Code generation on that large of a scale scares me. On the other hand, Adobe makes good products, so maybe they’ve got this one done in a way that makes it work from both ends.
October 2nd, 2007 at 3:43 pm
Hi Rich–thanks for the thoughts about Thermo! Making sure that it will work well for both designers *and* developers is definitely first in our minds. We will definitely make it easy to refactor the design up into multiple MXML files. In fact, in the demo, at the point where Steven selected the CD covers and converted them to a List, Thermo automatically created a separate file for the item renderer and put the data-bound CD cover image into it.
And you’re definitely right that designers and developers will continue to need to make choices about whether they want to create and use their source artwork as bitmaps or vectors, making tradeoffs for file size, fidelity, runtime modifiability, performance, etc. Thermo will work with both bitmaps and vectors, so you have the freedom to choose the format for any individual piece of artwork.
Thanks,
nj
Adobe Flex team
October 2nd, 2007 at 5:03 pm
Thanks for your comment NJ. I know that it was kind of unfair to point out possible issues before having all of the facts and I am glad to know that you are keeping code separation in mind as you develop the product. It certainly is an amazing piece of work and I look forward to what will come next.
October 2nd, 2007 at 6:15 pm
Well there’s one thing that excites me about Thermo is the proof-of-concept workflow. Developers are insanely costly, and what causes alot of scope creep is just the inability for people to visualize a workflow.
So, having a tool that can be used by technically oriented (but not savvy), e.g. MIS and technical project managers to build functional POCs that they can use to lock down the workflow and requirements….. and then bounce that over to development as “here’s a really close idea of what we want” - should minimize the back and forth, as you’re able to get everyone on the same page before development begins.
October 2nd, 2007 at 6:19 pm
Having only seen the footage available and the stuff on labs I’m with you on this. Thermo looks great for quick prototyping, but I can’t see it filling gap for end apps.
Its a bit the same as importing PSD’s into Flash. Its a great feature in theory, but I’ve actaully found it takes less time to just export the items you want from PS at the quality required for each, than try to manage that when using the Flash import manager.
As we all know a whole load of filesize can be removed by creating the designers graphics with code.
October 3rd, 2007 at 4:42 am
At first I was also a little scared by this. But if you look at how it is at present, as Tink mentions there, you have to export layers out of Photoshop (which is a skill in itself unless your designer is ultra neat and doesn’t have a thousand layers with adjustments and masks). This means you are expecting your developers to be extremely savvy with Photoshop, luckily a lot of Flashers are, but that’s not always the case, particularly with Flex devs.
At the very least this tool takes some of that pain away, even if it is not a round trip processes, it should still help to provide assets that you might otherwise have had to spend a lot of your own time generating. As for generating the assets with code, that’s only possible in very few occaisions and it’s always a decision that has to be made on a per case basis. Sometimes it can really hinder a project to find you are creating a circle with code, when you need to then go apply a gradient to it, because what we then find is instead of giving a designer a structured FLA, it instead shifts the creative changes back on the Flash developers already busy role.
October 3rd, 2007 at 5:16 am
one more of the manyf tools into a broadening market of digital production. If it can at least manage to be a bridging tool for developers to create a canvass from the designers work then it will do its job. and i guess if your good at flex and mxml.. you can get paid a fortunate to sort out all the problems designers will have with this tool.
It will never solve a truly bespoke realisation.. but maybe a good canvass maker.
It may have been shown off prematurely for the sake of max. i dont doubt this could be a feature rich application.. or even actually merge with flex as the design view.
October 3rd, 2007 at 9:32 am
My hope is that it will be released as an Eclipse plug-in like Flex Builder, so that I can run both in parallel in the same Eclipse install.
October 3rd, 2007 at 10:21 am
I think Thermo could be very awesome. Of course the demo, of taking a full application mockup, importing the whole thing and converting it to a full app, as-is, was done for the WOW factor, but probably won’t be the actual workflow for real life situations. I imagine you might get the full mockup, and grab pieces of it - make the scroll bar, make the image list, etc. and export them out and pull them into your app.
My argument has always been that skinning and styling UI components should be the easiest thing you do with them. Thermo seems like it could make that a reality.
October 3rd, 2007 at 5:10 pm
@Keith: You could certainly import individual skins into Thermo instead of importing a full comp. However, I think the comp import workflow is actually important, because it preserves the pixel-perfect layout that the designer intended. That can tend to get lost if the developer tries to recreate the layout piecemeal.
One thing that we didn’t show in the demo, but which we already have in Flex 2 (and greatly extended in Flex 3), is the ability to create resizable layouts using constraints instead of nested containers. In this model, you start with an absolutely-positioned layout, then add constraints that express how you want items to resize as the application size changes. There are several advantages to this for both designers and developers:
(1) the designer can start with a pixel-perfect layout (either imported or created in Thermo) without worrying about resizing, then add the resizing behavior later.
(2) if the designer wants to do a major layout change, s/he can just move items around and redo the constraints, instead of having to break up and recreate a bunch of nested boxes.
(3) using constraints to express resizability can greatly reduce or eliminate the number of nested containers, which improves overall performance.
nj
Adobe Flex team