<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Why Thermo scares me</title>
	<atom:link href="http://blog.everythingflex.com/2007/10/02/why-thermo-scares-me/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.everythingflex.com/2007/10/02/why-thermo-scares-me/</link>
	<description>Everything related to Adobe Flex and AIR</description>
	<pubDate>Mon, 21 Jul 2008 01:23:48 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: Narciso (nj) Jaramillo</title>
		<link>http://blog.everythingflex.com/2007/10/02/why-thermo-scares-me/#comment-4834</link>
		<dc:creator>Narciso (nj) Jaramillo</dc:creator>
		<pubDate>Wed, 03 Oct 2007 21:10:23 +0000</pubDate>
		<guid isPermaLink="false">http://blog.everythingflex.com/2007/10/02/why-thermo-scares-me/#comment-4834</guid>
		<description>@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</description>
		<content:encoded><![CDATA[<p>@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.</p>
<p>One thing that we didn&#8217;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: </p>
<p>(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.</p>
<p>(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.</p>
<p>(3) using constraints to express resizability can greatly reduce or eliminate the number of nested containers, which improves overall performance.</p>
<p>nj<br />
Adobe Flex team</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Keith Peters</title>
		<link>http://blog.everythingflex.com/2007/10/02/why-thermo-scares-me/#comment-4832</link>
		<dc:creator>Keith Peters</dc:creator>
		<pubDate>Wed, 03 Oct 2007 14:21:02 +0000</pubDate>
		<guid isPermaLink="false">http://blog.everythingflex.com/2007/10/02/why-thermo-scares-me/#comment-4832</guid>
		<description>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.</description>
		<content:encoded><![CDATA[<p>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&#8217;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.</p>
<p>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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: everythingflex</title>
		<link>http://blog.everythingflex.com/2007/10/02/why-thermo-scares-me/#comment-4831</link>
		<dc:creator>everythingflex</dc:creator>
		<pubDate>Wed, 03 Oct 2007 13:32:52 +0000</pubDate>
		<guid isPermaLink="false">http://blog.everythingflex.com/2007/10/02/why-thermo-scares-me/#comment-4831</guid>
		<description>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.</description>
		<content:encoded><![CDATA[<p>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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tbm</title>
		<link>http://blog.everythingflex.com/2007/10/02/why-thermo-scares-me/#comment-4830</link>
		<dc:creator>tbm</dc:creator>
		<pubDate>Wed, 03 Oct 2007 09:16:17 +0000</pubDate>
		<guid isPermaLink="false">http://blog.everythingflex.com/2007/10/02/why-thermo-scares-me/#comment-4830</guid>
		<description>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.</description>
		<content:encoded><![CDATA[<p>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.</p>
<p>It will never solve a truly bespoke realisation.. but maybe a good canvass maker.</p>
<p>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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Leggett</title>
		<link>http://blog.everythingflex.com/2007/10/02/why-thermo-scares-me/#comment-4829</link>
		<dc:creator>Richard Leggett</dc:creator>
		<pubDate>Wed, 03 Oct 2007 08:42:33 +0000</pubDate>
		<guid isPermaLink="false">http://blog.everythingflex.com/2007/10/02/why-thermo-scares-me/#comment-4829</guid>
		<description>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.</description>
		<content:encoded><![CDATA[<p>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&#8217;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&#8217;s not always the case, particularly with Flex devs. </p>
<p>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&#8217;s only possible in very few occaisions and it&#8217;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.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
