A Sneak Peak at “Thermo:”
Adobe's Next Big RIA Innovation

– Steven Heintz, Product Manager, Adobe Thermo

 

 

 

 

 

Since the day it was first previewed at Adobe MAX 2008, it’s been obvious that the project codenamed “Thermo” is a highly strategic undertaking at Adobe. The team behind the new initiative consists of some of Adobe’s brightest minds — principal, senior people who have been responsible for many core technologies that have contributed significantly to the company’s market dominance over the last three decades.

 

The UIRC is pleased to present this in-depth interview with Steven Heintz, senior product manager for Thermo. What follows is one of the first public interviews held on the subject of Thermo. The interviewers are Juan Sanchez, experience architect at EffectiveUI and writer Jean Feigenbaum.

 

Sanchez: What’s your role on the Thermo team and can you tell us who the players are?

 

Heintz: I’m the senior product manager for Thermo. I’ve been involved with the product since the very beginning, since we initially pitched it to our executive team and started with early concepts. We actually have a very senior team assembled around Thermo — Mark Anders for example, our senior principal scientist, is known for starting the ASP.NET team at Microsoft. He led that team for about a decade at Microsoft, and then came to Macromedia right before the Adobe acquisition. Mark played a significant role in the architecture of Flex Builder, and is now fully focused on Thermo.

 

We also have a number of people from the early Dreamweaver 1.0 team, Flex 1.0 team and early Flash teams working on Thermo. So I get to work with an amazing group of people. My job is to coordinate the requirements and feature definitions, as well as a lot of other activities as we build this product from scratch in terms of engineering, marketing, and everything else around the project. It’s basically like starting a brand new company — within the larger Adobe organization.

 

Sanchez: What’s the new direction that Thermo will bring to Adobe?

 

Heintz: It is a very big project for us and will shape how people can leverage the Adobe technology platform — Flash, Flex and AIR, for an entirely new category of browser-based and desktop experiences. People used to think of Flash as just a mechanism for doing animation on the Web. But as Flash took on more interaction capabilities, it could deliver new experiences. The bar kept getting raised for design excellence and expected functionality delivered through those experiences.

 

As people take application expectations further with very rich, visual, interactive paradigms and concepts, we need to provide good design tools around those efforts. We also need to be able to bridge the process between how designers use Adobe design tools like Photoshop, Illustrator, Fireworks and Flash and how they work with developers who are adding the backend logic and functionality in tools like Flex Builder or by writing ActionScript.

 

Feigenbaum: Steve, why is Adobe investing so heavily into the rich Internet application space?

 

Heintz: In the last few years, we’ve seen a radical uptick in the number of rich Internet applications across all markets — from enterprise IT to consumer-facing sites. I think that people have really embraced the benefits of well-designed applications that break from the constraints of HTML, yet leverage the Internet for wide distribution.  These experiences behave more like rich client applications that used to run on the desktop.

 

I also think people are starting to understand the value of engaging visual experiences. We’re still seeing many organizations evaluating RIA technologies just now for the first time, embarking on the development of some projects that won’t come to market until the end of 2008, 2009 or later. We expect that trend to continue into for foreseeable future.

 

With the recent release of AIR, new opportunities exist for enterprise and consumer applications to run on the desktop using the exact same development models and technologies from Adobe such as Flex, Flash and soon Thermo. These technologies collectively make up a key part of Adobe’s technology platform strategy going forward. It’s important to Adobe’s success that we continue to make sure that our technology platform is the easiest for designers and developers to work with and to grow with.

 

Sanchez: Can you offer some insight about the importance of the designer/developer collaboration?

 

Heintz: Currently, designers in many organizations only play a role in the visual design aspect of a project and leave the interaction design aspect up to the developers. Flex has always enabled designers to customize the look of the framework using CSS. With Flex 3, we added much deeper integration with the Creative Suite tools, so now you can use Photoshop, Fireworks or Illustrator to draw custom skin artwork for Flex.

 

The next area we’re taking on is giving designers the power to design motion and interactivity much more directly. Today, what they have to do is this multi-step wireframe that shows all the little discreet steps along the way with a lot of words in the margins.

 

But at the end of the day — today — it’s the developer who applies those expressions in code. The result is that the interaction design ends up being dictated a lot more by the developer than the designer.

 

What we want Thermo to do is allow the designer to create the desired interaction or behavior and generate code that a developer can then leverage directly within a production project.

 

Feigenbaum: In Thermo, if a designer has a more immediate impact on the development aspect of a project, what measure of productivity gains might be realized?

 

Heintz: Here’s the process we see today: A designer creates a prototype that gets thrown away halfway through the project because its purpose has been served — that is, communicating intention. Also, designers and developers today spend a lot of time iterating: write some code, let me see what it looks like, “no that’s not what I want,” write some more code. That’s a big part of the RIA design process today. We’ve heard in some cases that well over half the time that goes into designing an RIA interaction is spent on that back-and-forth iterations between designers and developers.

 

I would say that Thermo saves on the ideation and concepting front as well. You will be able to open up Thermo and do low fidelity wire-framing to explore the very early stages of interaction design, and maybe add some motion and interaction to those wireframes as the next step. After you do your user studies on that and get signoff, then you could replace those low fidelity placeholders with higher fidelity visuals. At each of those steps, you’re getting closer to the final interaction design without having to throw things away at any point.

 

Sanchez: Do you think there’s a correlation between the smooth design-development collaboration and product innovation?

 

Heintz: When teams have the tools and methodologies to collaborate well, they have more time to spend on higher-level thinking. That scenario leads to product innovation.

 

In Adobe workflows, the common thread between designers and developers is MXML, which is based on XML. If you are a designer working in Thermo, you don’t even see the code unless you explicitly go to the code view. But every change you make, everything you define in Thermo is creating a well-formed Flex project in MXML in the background. When the developer opens the project in Flex Builder they can work with the high-quality MXML code.

 

Another difficulty in today’s designer/developer workflows is that typically the designer gets one shot to design the visuals and then hand them off. The developer takes the handoff and cuts up the images, decomposes them and tries to reproduce the designer’s intent through code. There’s very little opportunity for the designer to go back in and make changes. Typically, designers have to ask developers to make design changes and/or plug in new assets. This process does not make good use of the developer’s time or talents — having to plug new assets, change a font, a color, a layout. We want to enable the designer to iterate on their own ideas as the application development process progresses. Because Thermo understands MXML natively, designers can open up projects during development stages and continue to make some iterative design changes.

 

Feigenbaum: If I hire an agency to build a rich Internet application, what’s the business benefit if my agency is working in Thermo?

 

Heintz: Using Thermo in conjunction with the Creative Suite would provide the agency with faster time-to-market and higher quality results than any other competitive solution. We’d hope that by streamlining the designer-developer workflow, the agency would be able to spend more time on creating innovative interactions. You will see a greater degree of consistency from step to step throughout the development process. And, when you sign off on each step along the way, you will know that work is feeding into the next step and not being recreated. Overall, a more streamlined process will yield a higher quality product.

 

Sanchez: On a scale of one to ten, how would you rate the success of designer-developer workflows we have available today?

 

Heintz: Tough to do. I can tell you Adobe is always striving to make workflows smoother among all our tools. We’ve made big strides in product integration with Creative Suite 3 and with Flex Builder 3. Designers and developers can already leverage Photoshop, Illustrator, Fireworks or Flash to skin controls and individual pieces of an application or experience.

 

What we’re doing with Thermo actually falls into a whole different territory of interaction design by working with events and interactions from a design perspective. We are brining the Flex framework closer to designers without requiring them to learn code.

 

Feigenbaum: Do you see Thermo being a compelling reason for more developers to adopt the Flex framework?

 

Heintz: We actually think that Thermo is going to be a reason for a lot more designers and developers to embrace Flash as the medium for their project — and Flex as the framework for creating the experience.

 

The real reason behind Thermo is to get more people using the Adobe platform. The Flex Framework brings a new dimension to our technology platform, which people typically think of as Flash Player or AIR.  Flex provides structure on top of the player technology, and provides consistent scaffolding that many of our tools leverage. Going forward, you’ll actually see a number of our products and services, not just Flex Builder and Thermo, leveraging that framework as well. For example the new Photoshop Express service is built on the Flex framework and provides the rich experience people expect from a Photoshop product.

 

Feigenbaum: What is the Microsoft counterpart to Thermo, and what are the advantages of developing RIAs on the Adobe technology platform rather than the Microsoft platform?

 

Heintz: Microsoft is certainly coming out with some new technologies targeting the RIA space — Silverlight and some of the tools around it like Visual Studio, and Expression Blend. What we find today, though, is that designers have grown with — and are very fluent in — Adobe design and creative tools. The majority of web and RIA designers — regardless of technology choice — start with Photoshop, Illustrator or Fireworks today.

 

Thermo allows designers to take native projects from those core Adobe design tools, and move them into an Adobe designer-developer workflow. So, Adobe has a significant advantage in being able to work with the tools that the visual designers are already working with today. In addition, Adobe provides tools on multiple platforms while Microsoft tools run only on Windows. Most designers prefer working on Macs while developers tend to prefer Windows. We offer them the choice of platform and don’t force them into only one.

 

Advantage number two is about technology decisions that organizations make. The Flash Player being on 98% of Internet-connected desktops today means that there’s already a huge community around Flash, Flex and ActionScript development. You know that the content created with these Adobe technologies can be used and consumed by essentially all Internet users in the world. The next couple of years will certainly be interesting, but it will take Microsoft a long time to get that same penetration, if ever.

 

Lastly, on the designer tooling side, we have a strong pedigree behind designer-focused tools. What you’ll see in Thermo is that it feels like Photoshop, Illustrator or Fireworks — and not a “developer-ish” tool.

 

Sanchez: How strong a focus is there on using Adobe’s core design tools to build assets and then bring them into Thermo versus doing the design inside of Thermo itself?

 

Heintz: Heavy focus. What you’re not going to see in Thermo are the advanced brush and drawing tools that you’ve seen built up in Illustrator, Photoshop, Fireworks over the last 10 to 20 years. That type of power would never fit into a 1.0 product or anytime soon thereafter, and it’s not necessary.

 

Consider too, that there is no one tool that designers use for RIA design, be it Photoshop, Illustrator or Fireworks. Our Thermo workflows are really focused on allowing the designer to use the visual design tool of their choice, and to then move the static design comps into Thermo. Thermo becomes more of a compositing and integration tool, at least from the visual perspective, with a heavy focus on designing events and interactions.

 

This is pretty common paradigm with Adobe tools. For example, in print publishing, you would create assets in Photoshop or Illustrator and then bring them into InDesign. To change an asset, you work through a launch and edit workflow to make revisions that are automatically reflected in your InDesign file. Again, it’s one of the big advantages that Adobe has with our position in the design tools market and the developer market that competitive approaches just won’t be able to match.

 

Sanchez: When a designer brings assets into Thermo, does quality diminish during the conversion process?

 

Heintz: Well, there’s certainly going to be a difference in fidelity. Each of the design tools we’ve discussed certainly has its own specialized purpose. Illustrator was initially designed for print publishing and it can actually create a lot of things that the Flash Player doesn’t support. Complex gradients and opacity layers that you would expect from an application like Photoshop — a  photo manipulation tool — are also the types of things that people who work in the Flash medium will recognize as graphics that may not fully render in the Flash Player.

 

Since we know that cross-platform Flash is the delivery medium you’re targeting, Thermo will be rendering graphics at the fidelity and the capabilities of the Flash Player. At that point in the workflow you don’t want to see something that’s rendered higher than what your end users are going to see in Flash Player. We believe that things like layout, fonts and many other properties are going to be preserved in that import process. We’ll help the designer wherever we can when there are capability mismatches between a tool designed for print and a tool designed for Flash and the Web.

 

Sanchez: Is Thermo focused primarily on MXML-based applications or does it transcend beyond MXML?

 

Heintz: Thermo 1.0 will focus primarily on enabling creation of Flash and AIR content. What comes out of Thermo is either a .swf file that can run in the browser, an AIR project or MXML code that feeds into one of our developer workflows using tools like Flex Builder.

 

As well, you can use tools like Flex Builder to extend the content that you’ve created and move to a larger HTML/Ajax experience around your Flash or Flex content. We have technology that allows you to bridge an interactive Flex+Ajax experience on a single page. But again, Thermo is just focused on creating content for Flash or AIR.

 

Feigenbaum: Is the technology underlying Thermo built from the ground up? Or is it based on an existing Adobe technology, or on a technology that Adobe acquired?

 

Heintz: There are a lot of new metaphors in Thermo that were designed totally from the ground up. As seen in early Thermo demos, there really is nothing to compare it to.

 

That’s partially why we decided to talk about Thermo so early. We wanted to start a dialogue with customers about its new metaphors to make sure that what we do in version 1.0 is useful out of the gate. We don’t want it to be one of those products that isn’t useable in a production setting until version 2.0 or 3.0 later down the road.

 

There is a core piece of technology in Thermo that is actually shared between Thermo and our developer tool, Flex Builder. What we actually do with Thermo is leverage a “headless” version of Eclipse. It’s completely transparent to the designer. You would never know or even see any aspect of Eclipse, but from a technology perspective, some of that code is leveraged and shared between the two products so that projects look the same when opened in either Thermo or Flex Builder.

 

Sanchez: What other common Adobe workflows influenced the approach for Thermo?

 

Heintz: For version 1.0 of Thermo we really focused on the workflows that we commonly see around RIA creation. Those workflows primarily start with Fireworks, Photoshop and Illustrator for the visual design; Flash for animation content; and Flex Builder on the developer side.

 

Adobe customers expect workflow integration around all our tools. They expect to be able to copy/paste between products natively and have the products understand each other’s native file formats. Our users also expect to launch and edit assets in other Adobe products. This is why Adobe customers buy powerful suites of products that all work together.

 

Sanchez: It sounds like we can look forward to greater integration between the Creative Suite products with CS4?

 

Heintz: Our goal in every version is to increase the ability for the tools to work together, but especially on the Thermo/Flex side you’ll see a big step forward. We’ll talk more about that as we get closer to the CS4 release.

 

Feigenbaum: At the Enterprise level, do you see any relationship between RIAs built in Thermo and Adobe LiveCycle Enterprise solutions?

 

Heintz: Absolutely. Enterprise customers are seeing big value in interaction design because well-designed interaction means a) people enjoy using the system, and b) the cost of training is lower.

 

SAP is a perfect example of an enterprise customer that puts a very high emphasis on user studies and interaction design. Today, SAP is building a lot of their front-end UIs in Flex. Thermo is going to be a great tool for creating the interfaces for those types of applications.  Thermo will also be incredibly useful during the exploration process — the wire framing, the user study process, and then feeding that work right into development. We continue to be strong advocates in the enterprise space regarding the importance of design and usability.

 

Sanchez: Will we be able to build mobile applications in Thermo and Flex? There’s been some talk about Flex Light or Flex Mobile.

 

Heintz: It’s certainly something under investigation, but not something we have information on yet today.

 

Feigenbaum: Speaking of today, when can people start placing Thermo orders?

 

Heintz: We decided to talk about Thermo early so we make sure that we get it right in the first version of the product — similar to how we released Lightroom through a very long beta process. We believe that that was the right approach and we ended up with a 1.0 on the market that was exactly what people needed. We’re taking a very similar approach with Thermo. So you can expect to start seeing some betas available this year.

 

Feigenbaum/Sanchez: Steve, thank you very much for sharing so much interesting insight with our UIRC readers.

 

Heintz: Thank you guys!

About Steven Heintz

Steven Heintz is the senior product manager for a new product at Adobe codenamed “Thermo.”