The Adobe Edge newsletter has a new Thermo video up. It’s the same demo we did at MAX, but it’s higher-quality and easier to watch than the YouTube version. Check it out!

Digg!digg this | | No Comments

Nahuel Foronda just posted a cool example of a button skin that uses states in order to create a color animation on mouse over. The skin is written almost entirely in pure MXML, with a little bit of AS just to attach the filters to the button label. This really shows the power of using declarative states to implement a skin instead of having to write a bunch of procedural code, and as Nahuel points out, when we add graphics tags to the framework it will become even more powerful.

One modification that might be interesting would be to see if he could use an MXML transition to create the color animation instead of using Darron Schall’s AnimateColor component. I bet that would work, but haven’t tried it myself yet.

Digg!digg this | | 4 Comments

“Well,” you may be saying, “Thermo looks great and all, but what do I do in the meantime?” The good news is that we have some nice improvements coming in Flex Builder 3 that help automate the visual design workflow, and you can try them out in the Flex Builder 3 beta that we posted to Adobe Labs last week.

In Flex 2, if you wanted to style components using CSS, you could use the Flex Style Explorer to experiment with the styles, then cut and paste the CSS into a Flex app. If you wanted to skin components with custom graphics, you could use my Developer Center article on creating skins using the Creative Suite tools, but you would likely still need to edit some of the CSS by hand.

The new design features in Flex Builder 3 help automate both of these workflows. Here’s a quick summary:

Flex Skin Design Extensions for CS3. These actually aren’t a feature of Flex Builder 3 itself, but rather a set of extensions for Photoshop, Illustrator, Fireworks, and Flash that make it easy to create skins for Flex components. Essentially, we’ve taken the templates from my Developer Center article and integrated them into the CS products through a “New Flex Skin” menu command in each tool, adding the ability to create individual component skins as well as a whole template, and to create multiple variations on a single component. We’ve also created a one-step “Export Flex Skin” command for PS/AI/FW that automates the manual export steps from the article.

You can download beta versions of the skin design extensions from Adobe Labs. Thanks to Juan Sanchez of ScaleNine for building out the new templates for us!

Flex Component Kit for Flash. For Flash, we’ve gone one step further, and redone the skin template entirely to use multi-state symbols using the Flex Component Kit for Flash. If you’re not familiar with the Kit, it allows you to build components and skins in Flash that can be used in Flex applications–participating in layout, sending and receiving events, building states and transitions on the timeline, and more. In the case of skins, this means you can build animations between the different states of a component–for example, between the up and over states of a button–using the Flash timeline.

Import Skin Artwork. In my dev center article for Flex 2, we provided a pre-built CSS file that worked in conjunction with the skin templates to glue the template artwork into your Flex application. If you wanted to create multiple variations of a component, you had to do this by hand, and if you wanted to only skin certain components, you’d need to edit the CSS file manually.

In Flex Builder 3, we’ve automated this process with File > Import Skin Artwork. Now you can just point at a folder of bitmaps or a SWC exported by the CS3 skin design extensions, and Import Skin Artwork will automatically write all the CSS code to glue those skins into your app. You can even create multiple styles for a given component using the CS3 “New Flex Skin” commands, then import them as separate CSS class styles. And if you have fully custom components that expose their own skin properties, you can build skin templates for those components that can be imported using Import Skin Artwork by following a simple naming convention.

CSS Design View. This is really the heart of the new design features in Flex Builder 3, and it works with both the skinning and styling workflows:

  • If you’re following the skinning workflow from the previous features, then the CSS Design View will let you visually customize things like font styles and scale-9 grids for the imported skins. Previously, you had to do this by hand in the CSS.
  • If you’re doing pure styling, you can use the CSS Design View like a beefed up version of the Flex Style Explorer, to create global, component, or class styles, preview them directly in Flex Builder, and write the code directly into your Flex application.

Accessing the CSS Design View is simple–just open any CSS file, then click the “Design” button to switch to Design View.

If you want to see some demos of these features, here are some resources:

  • We showed off a number of these features at Flex Camp in SF a couple of months ago; you can watch the videos of CS integration and skinning workflow (boy, I hate the sound of my voice in this video!) and CSS Design View and other FB3 features. (Update: forgot to put in a link to the second part of this originally.)
  • The Flex Builder team put up writeups and video of Import Skin Artwork and the CSS Design View (but not the CS3 extensions or the Flex Component Kit for Flash).
  • Peter Flynn also gave an excellent talk on this topic at MAX, but there’s no video of that up yet–I’ll post a link when it becomes available.

Download the Flex Builder 3 beta, give the new features a try, and let us know what you think!

Digg!digg this | | 14 Comments

Well, Thermo caused quite a buzz at MAX, and needless to say, we’re very excited about all the reaction. If you weren’t at MAX, you can see Aral Balkan’s video of the Thermo demo up on YouTube: part 1, part 2, part 3.

Since we did the demo, I’ve been semi-obsessively searching MXNA for blog posts about Thermo, and among the generally positive responses, people have also posted a number of questions and concerns. I thought I’d address some of these here, to help clarify and amplify what we showed in the demo. (Sorry–no spoilers about release dates or other features here!)

The demo showed Thermo creating a lot of bitmap graphics. Will Thermo applications be large and bitmap-heavy?

The demo happened to have a lot of bitmaps in it, since it was a CD cover browser, but Thermo will work with both vector and bitmap assets. The main difference between graphics in Thermo and in Flex today is that vector artwork in Thermo is expressed through bona-fide MXML tags, rather than opaque SWF symbols. In the demo, for example, Photoshop text layers came over as TextGraphic tags, and rectangle shape layers came over as Rect tags. Naturally, MXML graphics will also support complex Bezier paths, rounded rectangles, and so on, and will support importing from Illustrator and Fireworks as well as Photoshop.

Why is it useful to have graphics tags? Why not just import graphics as SWFs or bitmaps as in earlier versions of Flex?

For static graphics, you could argue it’s about the same. But few graphics in a Flex application are static. Much of the “rich” in RIAs comes from dynamic graphics–graphics that change in response to user gestures or dynamic data.

In Flex as it is today, developers have to create dynamic graphics by writing imperative ActionScript code. With MXML graphics, developers no longer need to recode the designer’s graphics in order to make them dynamic–they can simply modify the graphics at runtime through simple property access, data binding, the transitions/effects engine, and so on. Designers can continue to edit the graphics visually in Thermo without disturbing the developer’s code.

For example, suppose I draw a button skin in Illustrator that’s filled with a blue gradient, and we want to create multiple buttons with the same look but different colors. My developer can just import that as MXML, and then data-bind the gradient color to some style parameter. Voila–instant styleable skin, without writing a line of AS code. I can then edit the shape of the skin visually in Thermo, and the color style will continue to work, without my having to rewrite a bunch of Graphics method calls.

Now let’s say I want to animate that gradient color when I mouse over the button. Again, I can create this through declarative transitions written in MXML, rather than having to build the animation into an opaque SWF symbol. And again, because the transition is in MXML rather than ActionScript code, I can visually design that transition using the Thermo UI.

The text field that was created in the demo seemed to have its skin specified inline. Will Thermo create large single-file applications? Will the code be huge?

Thermo is being created for designers, but of course it won’t be successful unless its output can be easily consumed by developers. Thermo will definitely provide easy ways to factor the resulting code into separate files. For example, skins can be automatically put into separate output files and generalized into CSS rules. (Flex Builder 3 actually already has functionality for extracting inline styles into CSS, and we would certainly have the same functionality in Thermo.)

One example of code factoring that wasn’t obvious from the demo was that when Steven created a list from the individual CD covers, the item renderer for the list was actually created as a separate file. When he then double-clicked on an item in the list to edit it, it felt like it was being edited directly in place in the context of the larger application, but Thermo was actually making edits to the separate item renderer file behind the scenes. This is an example of how we can keep clean code separation without forcing the designer to understand the guts of Flex.

It’s great that you can turn graphics into buttons, scrollbars, etc., but what about custom components? Will Thermo work with components created by developers?

Definitely. Our intention is to make it so that developers can create components that are usable in Thermo the same way the built-in components are. Naturally, they will need to conform to certain rules and/or implement a certain API in order for those components to work well in Thermo, but our intent is to keep those requirements lightweight.

Thermo seems geared towards letting designers build a complete Flex application. Does that mean you expect designers to create business logic as well?

That’s not the goal of Thermo. One way I like to think about the designer/developer dichotomy (woo, alliteration!) was suggested by Rob Adams: developers deal with system logic, and designers deal with user logic. The two are not exactly the same, though they obviously intersect. Our goal is to make it so that designers can use Thermo to design the user logic of the application (along with importing and editing the visual design), and provide a clean way for that user logic to be hooked up to backend data and business logic by a developer.

That’s all for now. Please feel free to comment (or post in your own blogs) if you have more questions about Thermo–naturally, we can’t answer all of them at this point, but we’re really interested to hear your thoughts!

Digg!digg this | | 5 Comments

I ran into Nahuel Foronda of AS Fusion at the MAX party, and he told me about a new site he’s working on, Fill Colors. It’s like the CSS Zen Garden, but for Flex skins. There’s a few interesting skins up there currently, and they’re running a contest to get more. So, if you’ve wanted to make a crazy beautiful Flex skin, now’s your excuse!

Digg!digg this | | 3 Comments

We’ve finally taken the wraps off Thermo–yay! We just showed a demo at the MAX day 2 keynote, and it went great. For those not at MAX, we’ve posted some info and screenshots on Adobe Labs.

I’ll post more thoughts on Thermo soon, but for now I need to grab lunch and go talk to customers at the Flex booth. Stop by if you’re here!

Digg!digg this | | 12 Comments

I’m about to hop on a plane for Chicago to attend MAX 2007. I’m always excited to meet real customers, experience their enthusiasm, and find out what we can do better.

But this year, I’m extra excited, because we’ll be unveiling the new project I’m working on, an RIA design tool codenamed “Thermo”. Mark Anders let slip a little information about in in his blog, but we’re keeping it under wraps until we show it at MAX. I’m sure I’ll be talking about it a lot more once we’ve unveiled it!

In the meantime, to tide you over, I wanted to point out something else exciting that we’ve released in time for MAX: My good friend and colleague Rob Adams has just published the first part of the Flex Interface Guide (FIG) on the revamped Flex Developer Center. I’ll let Rob describe its purpose in his own words:

The FIG describes (and in some ways prescribes) the kinds of RIAs that we intend folks to build with the Flex platform. Good RIAs. Great ones, even. RIAs that are as well designed as Adobe XD showcase apps such as the Tour Tracker and some of the best customer applications like Yahoo! Maps and Picnik. By articulating the design principles and practices behind these applications, we hope to make it easier for Flex designers and developers to learn how to design their own applications to be as good or better than these.

But the FIG is more than just advice. Articulating what we think makes a great RIA helps us understand what we need to do to make building such RIAs even easier in the Flex framework than they are today. If a best practice we discuss in the FIG is more difficult to achieve in Flex than you’d like, we’re going to take that really seriously and make it easier as soon as we possibly can. One way we’ll do that is by revving the Flex framework and tools, but another, faster way is by releasing components and sample code on the FIG site itself that developers can pick up an use to easily implement many of the FIG design idioms.

So far we’ve posted the first half of the “Designing for Flex” series, which describes the general principles of the FIG, along with an initial set of components that exemplify some of the ideas in the FIG. Over the next few months Rob is going to roll out the rest of the series, and introduce a more specific set of practical guidelines that you can use directly when designing Flex applications.

I think Rob has done a great job distilling and articulating the collective wisdom of the Adobe design team, and am excited to see how people respond to the FIG. Check it out and let us know what you think! And, if you’re at MAX, come to the BOF that Rob and I are hosting on the FIG on Monday night–check the conference schedule for details.

Digg!digg this | | No Comments

The Flex team has started posting some free components on the Adobe Flex Exchange. The first one up is an auto-completing text input component. I haven’t looked at it yet, but it looks like it works the same way as a normal TextInput, with the addition of a dataProvider property that you can set to give it the list of possible completions. You can also specify a custom filter function that lets you implement other kinds of matching against the completion list (the default is to find entries with the user’s typed string as a prefix). Check it out!

Digg!digg this | | 3 Comments

Hi! I haven’t posted anything in awhile because (besides my usual laziness) I’ve been travelling a lot lately, visiting customers as part of our user research for the next version of Flex and Flex Builder. We did a mix of watching people work and showing them some early feature concepts, and as always, both parts were very enlightening.

This post is about a simple but useful Flex component I wrote recently: the “self-labeling” text input field. Instead of labeling a text field the usual way, by putting a label to the left of the field, you can put the label inside the text input field itself (in a light gray color); when the user clicks in the field, the label automatically goes away. It’s a nice way to conserve real estate and make the UI less visually noisy. Here’s an example:

(The search box at the bottom is another little component that uses the self-labeling text input field. In this case, the borders of the actual field are hidden, so it blends into the surrounding container. I implemented it in AS for no particularly good reason—it could easily have been an MXML component with a tiny bit of script.)

You have to be a little careful when choosing to use this type of field, because the user can’t actually see the label when they’re typing in it, or when the field is already filled in. So it’s best used when:

  • the field’s meaning is obvious from context (e.g. the caption under a photo), or
  • there’s an icon associated with the field (as in the search box above), or
  • the form is very familiar, and the meaning of the fields is obvious even when they’re filled with actual content (as in the address example above; a username/password form would be another possible example).

Here’s the source code. Using the SelfLabelingTextInput is simple—it’s just like a TextInput with one extra parameter, label, that sets what the field should show when it’s empty.

Hope you find this useful!

[Update: Per Stacy Young’s suggestion, I made it so the label also gets set as the tooltip for the field, so you can figure out what the field is even if it has content in it.]

Digg!digg this | | 17 Comments

Brian Riggs of the Kiwi project has worked out a way to load graphical Flex skins at runtime. This could be useful if you want to create different themes for the same app without compiling them all in at once, or if you want to create an app like WinAmp that other people can skin without recompiling your source code.

Digg!digg this | | 6 Comments

« Previous PageNext Page »