What's exciting in Adobe Thermo?

20 Mar 2008 - 7:35am
6 years ago
13 replies
625 reads
Oleg Krupnov
2008

There's currently a lot of buzz about the forthcoming release of Adobe
Thermo. We all have read the article about the product and watched the
"sneak peek" video of the product's presentation.

It looks like everybody is very excited about the tool. I am curious to
discuss it and hear opinions. What is the coolest, the most useful thing
that you expect from Thermo?
--
View this message in context: http://www.nabble.com/What%27s-exciting-in-Adobe-Thermo--tp16177473p16177473.html
Sent from the ixda.org - discussion list mailing list archive at Nabble.com.

Comments

20 Mar 2008 - 9:58am
SemanticWill
2007

While I admit that I am pretty excited - I am Very weary of offering an
opinion. I think it is intellectually dishonest to offer an opinion on
something I have not used. It would be like people who have opinions about
books they haven't read or movies they haven't seen. When it is out - and we
have a chance to play with it might be a better time to offer a review.

That said - it will completely reinvent the way interaction designers work.
This is the kind of revolutionary gestalt in product design which will usher
in a new zeitgeist the fall out of which can only be described is epic!

Just kidding :-)

On Thu, Mar 20, 2008 at 8:35 AM, Oleg Krupnov <oleg.krupnov at gmail.com>
wrote:

>
> There's currently a lot of buzz about the forthcoming release of Adobe
> Thermo. We all have read the article about the product and watched the
> "sneak peek" video of the product's presentation.
>
> It looks like everybody is very excited about the tool. I am curious to
> discuss it and hear opinions. What is the coolest, the most useful thing
> that you expect from Thermo?
> --
> View this message in context:
> http://www.nabble.com/What%27s-exciting-in-Adobe-Thermo--tp16177473p16177473.html
> Sent from the ixda.org - discussion list mailing list archive at
> Nabble.com.
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>

--
~ will

"Where you innovate, how you innovate,
and what you innovate are design problems"

---------------------------------------------------------------------------------------------
Will Evans | CrowdSprout
tel +1.617.281.1281 | fax +1.617.507.6016 | will at crowdsprout.com

20 Mar 2008 - 10:49am
Oleg Krupnov
2008

I agree, and so I'm not asking what the product itself feels like, but what
you expect it to be, in context of your work, and in a more specific way
than just "WOW" :)
--
View this message in context: http://www.nabble.com/What%27s-exciting-in-Adobe-Thermo--tp16177473p16181825.html
Sent from the ixda.org - discussion list mailing list archive at Nabble.com.

20 Mar 2008 - 1:33pm
Jack L. Moffett
2005

Oleg,

I saw a live demo given by Narciso Jaramillo at Interaction 08 and
blogged about it here:
http://designaday.tumblr.com/post/26687818

Jack

On Mar 20, 2008, at 11:49 AM, Oleg Krupnov wrote:

> I agree, and so I'm not asking what the product itself feels like,
> but what
> you expect it to be, in context of your work, and in a more
> specific way
> than just "WOW" :)

Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

The public is more familiar with
bad design than good design.
It is, in effect, conditioned
to prefer bad design, because
that is what it lives with.
The new becomes threatening,
the old reassuring.

- Paul Rand

21 Mar 2008 - 7:32am
Charusmitha Ram
2008

Oleg,
What is most compelling to me, as an Interaction Designer, is that Thermo
would allow me to do rapid prototyping using some very simple interactions.
I usually create my wireframes in InDesign and publish them as PDFs. Thermo
would save a lot of time and effort when I need to create these click-thrus.
I also think this is very useful for high fidelity prototypes.
Whether or not the built-in interactions are scalable enough for actual
development needs is yet to be tested. But at this point it looks quite
promising as a prototyping tool.

- Smitha Ram

On Mar 20, 2008, at 11:49 AM, Oleg Krupnov wrote:

> I agree, and so I'm not asking what the product itself feels like,
> but what
> you expect it to be, in context of your work, and in a more
> specific way
> than just "WOW" :)

22 Mar 2008 - 12:07pm
Dan Harrelson
2007

Smitha makes some good points. I agree that from what I've seen of
Thermo, it will be a good prototyping tool. It's time that we get some
decent tools for mocking up real interactions that have movement. It's
such a pain that so many of us have to use "flat" tools like InDesign
or Visio or Illustrator or Photoshop or Graffle or, or or.

I think that Thermo will position itself as the high fidelity
prototyping tool. Given the likely high price-point and the expected
high-end feature list, I doubt that it'll be the tool we reach for to
draw a quick box and arrow. Thermo will probably be the tool we reach
for when it's time to spend a couple of hours designing something more
interactive.

I am also looking forward to better design tools than are available in
Flex Builder. I find that the GUI design palette in Builder is what
I'd expect from a tool aimed at developers. You quickly find yourself
in the code view working on MXML or ActionScript. Thermo will allow
designers, and possibly even developers to accomplish many of the same
interactions without diving into code.

If they get it right, Adobe will be able to offer us a great workflow
as well. We'll be able to pull in assets seamlessly from Photoshop and
Illustrator. We'll also be able to round trip an RIA between Flex
Builder and Thermo. Yes, I foresee that Flex Builder will remain in
the ecosystem.

<plug>
What I'm most excited about is getting the Thermo team from Adobe up
on stage during my workshop at UX Week this August. http://www.uxweek.com/workshops/beyond-wireframes-making-interactive-sketches
</plug>

...Dan

On Mar 21, 2008, at 5:32 AM, Charusmitha Ram wrote:

> Oleg,
> What is most compelling to me, as an Interaction Designer, is that
> Thermo
> would allow me to do rapid prototyping using some very simple
> interactions.
> I usually create my wireframes in InDesign and publish them as PDFs.
> Thermo
> would save a lot of time and effort when I need to create these
> click-thrus.
> I also think this is very useful for high fidelity prototypes.
> Whether or not the built-in interactions are scalable enough for
> actual
> development needs is yet to be tested. But at this point it looks
> quite
> promising as a prototyping tool.
>
> - Smitha Ram

23 Mar 2008 - 5:38pm
Oleg Krupnov
2008

When I watched the video of Thermo presentation at MAX, I noticed that the
biggest WOW and applause always happened when the presenter right-clicked a
graphical object and selected the "Convert Artwork to" menu and the artwork
magically turned into an interactive control. This discussion thread also
supports me in thinking that this is the greatest deemed value of Thermo,
because using Flex as a platform for further development is not so
unquestionable. (I also agree that the output WYSIWYG code, as always, is
not suitable to be used in production)

Without taking sides and for the sake of objectivity, I'd like to give
Thermo an alternative view. My background is in development rather than
graphic design, so I'm not an expert in tools like Photoshop, Illustrator
and Fireworks, and so the ability to turn graphics into controls doesn't
impress me that much. Furthermore, it seems a bit like a bottom-up solution.
It's like first to write down text in MS Paint and then use complex OCR
software to recognize the hand writing and take the characters to the word
processor. If one needs text, why don't he just open the word processor and
type? If one needs a text input field or a button, isn't simpler to enter it
as a text input field or a button in a tool that natively understands
controls as opposed to graphics?

Another problem I am foreseeing is the set of supported interactions. It's
certainly premature to judge by the scope of the "CAT" menu I saw in the
video, but it is also logically understood that each magic requires its own
incantation, with implementation complexity growing exponentially, and so
the scope will be most likely limited to a set of widely used controls. You
won't be able to prototype an innovative or a non-standard control, such as
an editor of something, or a complex view of something, or dashboard etc.
(And in my projects, there is often one or more such controls.) We arrive at
the same old deficiency of all widget-based prototyping tools - you can only
prototype trivial things, that are self-understood and do not need to be
prototyped (but simply documented), and you can't prototype what needs to be
prototyped, i.e. new interactions.

Thermo allows your prototypes to look hi-fidelity and pixel-perfect, but
that's another point I'm questioning, because many times I read that when
the prototype looks too detailed the stakeholders lose the overall picture
and start making minor remarks, and also when the prototype looks almost
finished, so the customer thinks it is :) That's why people invented
wireframes, didn't they?

Aside from specifics of human perception, isn't it just taking more work to
create a pixel-perfect prototype before the idea is ever tested? And if you
feel sure enough to draw a hi-fidelity mockup, why would you need to test it
afterwards? In my understanding, mockups are to be separated from
wireframe-like prototypes, because the recent show the visual design and the
latter demonstrate interactions.

In the aftermath, Thermo appears to only be good at supporting and
advocating the historical use of professional graphic apps (also made by
Adobe BTW :) as the primary tools among interaction designers. This is what
the presenter started his presentation with: "designers don't work like
developers, they tend to draw a picture of the application and then give it
to the developers to implement, so what we wanted to do was making it easier
for the designers to actually build the application". This seems to be the
main idea of Thermo.

Another feature I really liked is the dummy data, but it didn't appear easy
to use at the first glance.

As I said, I'm not taking sides and just want to enrich this discussion with
alternative opinions. Would be glad to hear your comments!

Oleg.
--
View this message in context: http://www.nabble.com/What%27s-exciting-in-Adobe-Thermo--tp16177473p16242176.html
Sent from the ixda.org - discussion list mailing list archive at Nabble.com.

23 Mar 2008 - 9:33pm
Jack L. Moffett
2005

On Mar 23, 2008, at 6:38 PM, Oleg Krupnov wrote:

> Without taking sides and for the sake of objectivity, I'd like to give
> Thermo an alternative view. My background is in development rather
> than
> graphic design, so I'm not an expert in tools like Photoshop,
> Illustrator
> and Fireworks, and so the ability to turn graphics into controls
> doesn't
> impress me that much. Furthermore, it seems a bit like a bottom-up
> solution.
> It's like first to write down text in MS Paint and then use complex
> OCR
> software to recognize the hand writing and take the characters to
> the word
> processor. If one needs text, why don't he just open the word
> processor and
> type? If one needs a text input field or a button, isn't simpler to
> enter it
> as a text input field or a button in a tool that natively understands
> controls as opposed to graphics?

No, it isn't—not because of the widget itself, but because of the rest
of the design: layout, color, graphics, etc. The tools (or code) used
for implementing a UI do not make it easy to design a UI. It takes
longer to create a screen in Dreamweaver than it does in Photoshop.
This is why designers choose to use WYSIWYG software for graphic
design, as opposed to, say, authoring XML and XSLT.

> Another problem I am foreseeing is the set of supported
> interactions. It's
> certainly premature to judge by the scope of the "CAT" menu I saw in
> the
> video, but it is also logically understood that each magic requires
> its own
> incantation, with implementation complexity growing exponentially,
> and so
> the scope will be most likely limited to a set of widely used
> controls. You
> won't be able to prototype an innovative or a non-standard control,
> such as
> an editor of something, or a complex view of something, or dashboard
> etc.
> (And in my projects, there is often one or more such controls.) We
> arrive at
> the same old deficiency of all widget-based prototyping tools - you
> can only
> prototype trivial things, that are self-understood and do not need
> to be
> prototyped (but simply documented), and you can't prototype what
> needs to be
> prototyped, i.e. new interactions.

First, I think this is a judgement that shouldn't be passed until we
have a delivered product. You may be right. On the other hand, the
ability to easily assign controls to show, hide, and move layers will
be a powerful way of prototyping many interactions.

> Thermo allows your prototypes to look hi-fidelity and pixel-perfect,
> but
> that's another point I'm questioning, because many times I read that
> when
> the prototype looks too detailed the stakeholders lose the overall
> picture
> and start making minor remarks, and also when the prototype looks
> almost
> finished, so the customer thinks it is :)

Don't blame a tool for improper use. If you find yourself in such a
situation, don't show a pixel-perfect prototype. That doesn't absolve
the need for pixel-perfect prototypes in other situations. There have
been times that the developers I worked with requested high-fidelity
mock-ups of specific interactions within an application so that we
could get sign-off from a particularly difficult customer and insure
that everybody was in agreement. Furthermore, I'll use Thermo to make
low-fidelity prototypes too. I've been known to scan my sketches into
Photoshop, chop them up into pieces, and animate them in Director as
initial concept interaction sketches. Thermo would be perfect for this!

> That's why people invented wireframes, didn't they?

No, I don't believe wireframes were invented to show to stakeholders.
I would say that wireframes were invented as a means by which one
could figure out the information architecture of a website or
application before any specifics of the visual design were worked out.

> Aside from specifics of human perception, isn't it just taking more
> work to
> create a pixel-perfect prototype before the idea is ever tested?

Who says the pixel-perfect prototype has to be created before the idea
is tested?

> And if you
> feel sure enough to draw a hi-fidelity mockup, why would you need to
> test it
> afterwards? In my understanding, mockups are to be separated from
> wireframe-like prototypes, because the recent show the visual design
> and the
> latter demonstrate interactions.

Personally, I have never separated the visual design from the
interaction design, but then my undergraduate degree is in Graphic
Design. Regardless, I often don't have the chance to do interactive
prototypes because of the amount of time it would take to do them. In
fact, I rarely have the opportunity to test anything before it is in
code. Thermo would significantly shorten that amount of time, and I
would theoretically be able to create prototypes more often.

> In the aftermath, Thermo appears to only be good at supporting and
> advocating the historical use of professional graphic apps (also
> made by
> Adobe BTW :) as the primary tools among interaction designers. This
> is what
> the presenter started his presentation with: "designers don't work
> like
> developers, they tend to draw a picture of the application and then
> give it
> to the developers to implement, so what we wanted to do was making
> it easier
> for the designers to actually build the application". This seems to
> be the
> main idea of Thermo.

Yes, I agree. There are many of us who work in that manner, and I'm
betting that most of us have been wishing for a tool like this for a
long time.

> Another feature I really liked is the dummy data, but it didn't
> appear easy
> to use at the first glance.

Actually, in the demo I was given, it looked like this was very easily
done. It was equivalent to the ease by which a graphic was turned into
a widget. This excited me too.

Jack

Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

You could design a process to catch
everything, but then you're overprocessing.
You kill creativity. You kill productivity.
By definition, a culture like ours that
drives innovation is managed chaos.

-Alex Lee
President, OXO International

23 Mar 2008 - 8:59pm
Anonymous

I agree.

For desktop applications where typically new controls are created, and/or
where rich object models are manipulated through interaction, Thermo isn't
going to help prototyping (or it would be unwieldy to do so). For
simple web form applications it might form a prototyping environment,
remains to be seen.

I think bringing motion/transition to static design screen states would be
the sweet spot for interaction designers. The idea would be to take
Fireworks and add flash-like animatability. The key point is that the goal
is not creating flash video or a flash application. The goal is better
documentation through motion. Unfortunately, roundtrips between Flash and
Fireworks are basically impossible and nobody wants to roundtrip really.

As many interaction designers do, I typically use Fireworks frames such
that each frame is a static state of the application in a unfolding
scenario. A design might include 5-30 of such states for a given scenario
through the application. If I could give these states life, by a moving
mouse cursor and inserting clicks and transitions from one state to another
in time that would be a killer ap. (details: typically a transition point
in a scenario has a frame pre-click, a frame for hover, and a frame for
post-click with associated changes in the application mocked up).

With "Fireworks Thermo edition" (who has time to transition to another
tool), I could document very powerful scenarios in a short clips of
5-6 screen states with a live running time of ~30seconds. Most training
videos for a feature are this length, and Ixd documentation would be
similar. This type of documentation would be powerful because it would
allow developers and marketing types to get a living picture. We all know
that static visuals put text out of business well moving visuals will put
static visuals out of business. Interaction designers need to cement
behaviors, and behavior is best demonstrated by moving visuals. There are
two ways to get compelling motion: 1) you build the thing and show them 2)
you make a better visual fiction. Thermo should go in the latter
direction. Let designers make compelling fiction with moving pictures.

Thermo shouldn't try to make the designer convert everything to
controls/components, it would help more to be keep the designs as visual
design mockups and "controlify" certain elements. This is some weird
hybrid to be sure. Working outside Fireworks to transform to
UI controls, bind sample datasets or wire-behaviors is really a outside my
core goals, and taking me into the dev direction. The cost is too
high. I need a way *to animate what I have designed within Fireworks, so
it is communicated effectively and compellingly.*

Navid

On Sun, Mar 23, 2008 at 6:38 PM, Oleg Krupnov <oleg.krupnov at gmail.com>
wrote:

>
> We arrive at the same old deficiency of all widget-based prototyping tools
> - you can only
> prototype trivial things, that are self-understood and do not need to be
> prototyped (but simply documented), and you can't prototype what needs to
> be
> prototyped, i.e. new interactions.

...so what we wanted to do was making it easier
> for the designers to actually build the application". This seems to be the
> main idea of Thermo.

> As I said, I'm not taking sides and just want to enrich this discussion
> with
> alternative opinions. Would be glad to hear your comments!
>
> Oleg.
> --
>

24 Mar 2008 - 11:46am
Andrei Herasimchuk
2004

On Mar 23, 2008, at 7:33 PM, Jack Moffett wrote:

> The tools (or code) used
> for implementing a UI do not make it easy to design a UI. It takes
> longer to create a screen in Dreamweaver than it does in Photoshop.
> This is why designers choose to use WYSIWYG software for graphic
> design, as opposed to, say, authoring XML and XSLT.

This is not always true. There are some stages where doing the work
in Photoshop is faster, but there's definitely stages where hand
coding something is significantly faster. The real measure I think is
across the entire process. The entire process must be faster for the
tool of choice to have any real merit.

My biggest fear with Thermo -- and to be honest, with any prototyping
tool that dictates a development environment, like Axure -- is that
it will do to interface design what PowerPoint did to presentations.
In that the tool itself becomes the driving force behind the thinking
for the interface design, weakening the work. That the tool becomes
the means to the end, instead of designing whatever is needed, then
figuring out which tools to use and how to use them to build the
prototype and ultimately the final product.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

24 Mar 2008 - 12:20pm
Jack L. Moffett
2005

On Mar 24, 2008, at 12:46 PM, Andrei Herasimchuk wrote:

> This is not always true. There are some stages where doing the work
> in Photoshop is faster, but there's definitely stages where hand
> coding something is significantly faster. The real measure I think is
> across the entire process. The entire process must be faster for the
> tool of choice to have any real merit.

Yes, I certainly agree.

> My biggest fear with Thermo... is that it will do to interface
> design what PowerPoint did to presentations... the tool becomes the
> means to the end, instead of designing whatever is needed, then
> figuring out which tools to use and how to use them to build the
> prototype and ultimately the final product.

That has always been a risk with the use of any software for design.

Jack

Jack L. Moffett
Interaction Designer
inmedius
412.459.0310 x219
http://www.inmedius.com

The public is more familiar with
bad design than good design.
It is, in effect, conditioned
to prefer bad design, because
that is what it lives with.
The new becomes threatening,
the old reassuring.

- Paul Rand

24 Mar 2008 - 12:37pm
Andrei Herasimchuk
2004

On Mar 24, 2008, at 10:20 AM, Jack Moffett wrote:
>
>> My biggest fear with Thermo... is that it will do to interface
>> design what PowerPoint did to presentations... the tool becomes the
>> means to the end, instead of designing whatever is needed, then
>> figuring out which tools to use and how to use them to build the
>> prototype and ultimately the final product.
>
> That has always been a risk with the use of any software for design.

This is certainly true. I guess though, my fear here is that with
certain software tools, one is using the tool to replicate an old
process. XPress, InDesign, Illustrator, Photoshop, these were all
tools used to replicate in digital form what designers had long done
in graphic design.

But since so many who design software interfaces these days lack the
ability to code behaviors themselves, they will be at the mercy of
the tool they use to create the prototype of those behaviors and
workflow, and as such, the end result will tend to be more based on
what the tool can deliver and not what is the correct way to make the
product work.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

24 Mar 2008 - 12:37pm
Andrei Herasimchuk
2004

On Mar 24, 2008, at 10:20 AM, Jack Moffett wrote:
>
>> My biggest fear with Thermo... is that it will do to interface
>> design what PowerPoint did to presentations... the tool becomes the
>> means to the end, instead of designing whatever is needed, then
>> figuring out which tools to use and how to use them to build the
>> prototype and ultimately the final product.
>
> That has always been a risk with the use of any software for design.

This is certainly true. I guess though, my fear here is that with
certain software tools, one is using the tool to replicate an old
process. XPress, InDesign, Illustrator, Photoshop, these were all
tools used to replicate in digital form what designers had long done
in graphic design.

But since so many who design software interfaces these days lack the
ability to code behaviors themselves, they will be at the mercy of
the tool they use to create the prototype of those behaviors and
workflow, and as such, the end result will tend to be more based on
what the tool can deliver and not what is the correct way to make the
product work.

--
Andrei Herasimchuk

Principal, Involution Studios
innovating the digital world

e. andrei at involutionstudios.com
c. +1 408 306 6422

25 Mar 2008 - 2:08pm
Narciso Jaramillo
2006

Hi folks,

Great discussion! Let me briefly address some points that have come
up in this thread.

First, it's definitely the case that the Thermo demo we've been
doing emphasizes a visually-high-fidelity starting point. This is
largely because one of our main goals with Thermo is to allow
designers to do work on the real, production user interface, not just
prototyping. In the production workflow, starting with the real visual
design and keeping it pixel-perfect as it goes through the pipeline is
very important. However, we understand that that's not the main goal
of interaction designers who want to use Thermo for prototyping, and
we plan to make Thermo usable for low-fi prototyping as well, using
the built-in drawing tools and components.

On the subject of components, there were two sides of the coin
mentioned on this thread. One side pointed out that if I know I
mostly want to create a prototype using standard components, it would
be cumbersome to have to draw everything first and then make
components out of them. To that end, we're planning tol make it
possible for users to drag out stock components and customize
them--you won't be forced to start with artwork if you don't want
to.

On the other hand, if we're *too* focused on the built-in
components, then you can't really build custom behavior. Our goal is
that you don't have to use built-in components in order to express
behavior--you can just start with your graphics and create fully
custom components with their own custom states and
transitions/animations. (While we didn't explicitly show "Create
Custom Component", the simple rollover behavior we showed for items
in the CD list was a simple example of a fully custom component.) I
believe this is the workflow that Navid Sadikali was mentioning, and
we plan to support that in Thermo.

Finally, it's definitely a fair point that there's only so much
complex behavior you'll be able to build through the UI; there will
always be a point past which someone will need to write code to build
the real behavior. Our goal is to give designers the tools to
communicate to the developer what they want, to allow the developer
to reuse as much of what the designer has created as possible (e.g.
specific animation timings/easings), and over time to increase the
ability of the designer to express more and more complex behavior. We
may not be able to do everything in 1.0, but we're hoping to get
feedback from IxDs on all the kinds of things they *would* like to
do, and try to make that possible in future versions!

Thanks,

nj

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=27392

Syndicate content Get the feed