Flex


I realized a few months ago that, unlike pretty much everyone else I know, I don’t regularly use an RSS reader. Not that I haven’t tried—I used FeedDemon early on, and more recently tried out Google Reader—but never managed to form the habit of checking them regularly. Both of them are fine apps; the problem was with me. Every time I sat down and saw that I had a gazillion unread items in my hundreds of feeds, I didn’t know where to start. Eventually I just gave up trying to keep up.

Around the same time I came to this realization, Adobe AIR 1.0 was publicly released. I wanted to try to write an AIR app just for fun, and it occurred to me that I might be able to make something that would solve my RSS problem.

The result is Snackr, a ticker-like widget that lives on the bottom (or side) of your screen and scrolls random items from your RSS feeds. (It’s called “Snackr” because it lets you nibble on your feeds. Guffaw.) Here’s what it looks like on my desktop:

I’m actually finding Snackr really useful—it helps me keep up with blogs I want to keep up with, and also gives me a great smattering of items from sources I wouldn’t normally read regularly. Please try it out and let me know if you like it! (Of course, it’s still an alpha, so please expect bugs; there’s a list of known issues on the Snackr website.)

Snackr has also been really fun to write, and along the way I figured out some tips and tricks for doing various things with Flex and AIR. Some notes on that after the jump.

(more…)

Digg!digg this | del.icio.usdel.icio.us | 23 Comments

It’s been busy here in Thermo-land, as we work furiously (no really! we’re furious people!) to turn our vision into reality. I have a fun side project that I’m going to post about in a little bit once I get a few bugs worked out. In the meantime, here’s a video interview that Ryan Stewart, Thermo evangelist extraordinaire, did with me about designer/developer workflow in Thermo and Flex 4. It was our first video, so it’s a little blurry and off-center, but just pretend it’s artsy and edgy and you’ll be fine. (We did edit out the part where the siren went off when someone went out the wrong door in the cafeteria.)

Digg!digg this | del.icio.usdel.icio.us | 2 Comments

I’ve been so busy that I completely forgot to mention that my article on designing Flex 3 skins and styles using Creative Suite 3 and Flex Builder 3 went live on the Flex Developer Center when we launched Flex 3. Check it out for information on how to use CS3 with Flex Builder, as well as the new CSS Design View in Flex Builder.

Also, Juan Sanchez of ScaleNine, who built the CS3 Flex skin templates, has just posted some great tips and tricks for using the skin templates. Thanks Juan!

Digg!digg this | del.icio.usdel.icio.us | No Comments

The big day is finally here! Flex Builder 3 is shipping, and the Flex 3 SDK and AIR 1.0 runtime are available for free download. I actually hadn’t been keeping up with all the latest AIR stuff, so it’s been fun checking out all the great AIR apps that have already been posted.

We’ve also just launched the Adobe Open Source portal, a one-stop shop for all Adobe open source technologies, including Flex, BlazeDS, and Tamarin.

Download, design, develop, and enjoy!

Digg!digg this | del.icio.usdel.icio.us | 4 Comments

A number of people have written me over the past few months to mention that they’ve had trouble getting the Reflection component to work in various cases. I haven’t had time to look at each of the problems, but I do have an updated version of Reflector.as that may work better. If you’ve been having trouble with the original Reflector code, try this one out and let me know if it fixes your problem.

Digg!digg this | del.icio.usdel.icio.us | 12 Comments

A new face in the Flex blogosphere: Ethan Eismann. Ethan is on the Experience Design (XD) team at Adobe, working on the design of Thermo, and I’m sure he’ll have all sorts of interesting thoughts on design. Welcome Ethan!

Digg!digg this | del.icio.usdel.icio.us | 3 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 | del.icio.usdel.icio.us | 4 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 | del.icio.usdel.icio.us | 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 | del.icio.usdel.icio.us | 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 | del.icio.usdel.icio.us | 12 Comments

« Previous PageNext Page »