ScaleNine

Today I came across something interesting while trouble-shooting an issue with Patrick Hansen, a designer/developer at EffectiveUI. Patrick was creating skins for a Flex application using Flash. One Button skin had some very intricate and rich animated artwork that extended beyond the “actual” bounds of the skin. That is, the animation had artwork that was masked so it would only appear within the viewable area of the Button skin. Below is a simple example I made to illustrate what I mean.

Button skin artwork that extends beyond the bounds. Unmasked and masked.

The animation appeared fine in Flash, but when it was applied as a skin to a Button the skin shrank in size (see image below). This was because the Button took into account the artwork that was masked in Flash. This made total sense. To fix it I thought, “Well, we could just use the bounding box technique that has been outlined in several Flex Component Kit Tutorials.” Easy enough.

Button skin without a bounding box. The red is the “actual” bounds of the Button component.

If you’re not familiar with using a bounding box in Flash to define the bounds you’d like your Flash artwork to adhere too, the concept is simple. Basically, you create a box, make it a MovieClip (called “BoundingBox” or something), give it an instance name of “boundingBox” when it’s on the Stage and then use it to define bounds of the Flash content. Kinda like this:

Button skin with bounding box (red) applied.

We did all that without any issues. However, we hit a snag when we tried to apply the Button skin that had this bounding box to an actual Flex Button component. We were trying to apply the skin by embedding a skinClass through CSS like this:


Button
{
skin: Embed(skinClass="Button_skin");
}


The Flex application would just hang. The trick to getting it to work was to just use a ClassReference like this:


Button
{
skin: ClassReference("Button_skin");
}


Everything compiled fine when using ClassReference. The skin looked exactly as it did in Flash and used the bounding box correctly. Cool!

The scary thing is that “Skin Import Wizard” in Flex automatically uses skinClass and most designers who use Flash are probably used to working with masks and artwork that extends “beyond the bounds”. The thing is that to a designer or developer it could appear that the skin is the issue, but in fact it was just a matter of switching the Skin Import Wizard default of skinClass to use ClassReference.

Just to make sure it wasn’t a fluke I made a quick test (view source enabled). If you wanna make the app break, just switch ClassReference to skinClass as shown above. Am I just doing something wrong?

Everyone is getting excited as more details come out about Thermo. I’m sure the number of email requests to get on the “super pre-alpha” have flooded Adobe inboxes. The reason is that Thermo is looking to solve a huge gap in designer/developer workflow. This gap exists across pretty much every development workflow in various shapes and sizes, so it’ll be interesting to see what Adobe comes up with.

Thermo looks like a great tool, but it’s only half the story. The other part of the story (a big part) is what Flex 4 (Gumbo) is doing to make all the things in Thermo possible. You know, the code that’s generated behind the scenes as a designer is turns artwork into a working interface, adds transitions, etc. There’s a lot of work being done on Flex 4 to make Thermo look good, but each component, Flex 4 and Thermo, is vitally important.

If you were at last year’s MAX and saw Ely Greenfield’s presentation on “the flex roadmap”, then you probably know what I’m talking about. After MAX I tried to explain to people what I saw in his presentation, but it usually just wouldn’t come across. Now, on Adobe TV there’s a video of exactly what Ely was talking about. In the video he changes the way a component looks and acts all in a skin file. I assume this would be done by designer’s in Thermo so they don’t have to touch any code. This is also the same presentation that inspired Ben Stucki to create OpenFlux.

I showed this video to another developer and he asked, “Well, what will there be left for me to do? Create data and clean up Thermo code?” To him, making custom components was the fun part and now it seems part of that responsibility is falling on designers in Flex 4. The thing is, you can’t do everything with Thermo and Flex 4 out of the box, like turn a List into a spinning globe. I think things will definitely change to allow designers to have more control, but developers will now be freed up to do even more innovative things.

Things are definitely going to get interesting. Check out the video here.

The phrase “Designer/Developer Workflow” has rapidly become the second most spoken buzzword in the RIA space (besides RIA). At EffectiveUI we’ve put our own processes into place in order to make sure nothing is lost in translation as designers and developers collaborate to create a common vision. Of course, processes can only go so far with the available tools that currently exist, particularly on the design side. Throw in some tight deadlines, budgets, and client agendas and sometimes you have to compromise on some things, but the end goal is to create something the client and we are happy with.

I’m working in Flex pretty much everyday (I do have to sleep sometimes) and tools play a huge role in the way you operate throughout your day. From a design perspective, I’ve been trying to work in different Adobe applications, like Flash, Illustrator and Fireworks to create application designs from start to finish. This includes every part of the process, from wire frames, icons, “story boards” and all the way through to the final design.

What I’ve found is that none of the applications I work with provide the most optimal solution. There’s things in Fireworks that I want in Flash, things in Flash I want in Illustrator, etc. What ends up happening is I use 2-3 design applications to achieve the final result. I understand that each application has it’s own specialties, and that’s fine, but it really cuts into production time and how quickly you can iterate through application designs. Of course, that’s just the design phase.

After getting the design where I want it, I then have to bring that all into Flex. With the Skin Design Extensions and the Skin Import feature in Flex Builder the process is quickened. However, those solutions only get me 60% of the way there. There are additional skinning nuances that aren’t represented directly in Flex, there are still effects and transitions to be implemented and a slew of other things that I have to do to get the app looking and “acting” the way I want. In my case, I can play both roles to a certain extent, but this process is magnified when there is a hand-off from designer to developer.

Stories like mine aren’t anything new. In fact, I read emails, blogs and threads about these same frustrations. The good thing is that all players in the RIA space are pushing for a solution. We’ve all heard about the problems Adobe Thermo and the prospects of Flex 4 are going to address, but Microsoft is also addressing these same issues.

A while ago, a white-paper called “The New Iteration” landed on my desk. It basically outlines how XAML and Microsoft tools help facilitate a tighter collaboration between designers and developers. A little later, I read a blog post by Ethan Eismann, Design Lead on Thermo, that addresses some of the exact same things. Both use different terminology, but it all points to a common goal. In fact, as I was reading “The New Iteration” I tried swapping XAML out for MXML, Thermo out for Expression Blend, and Flex Builder for Visual Studio, and it still made sense.

At this point, there is still a lot of refinement going on. I don’t think anyone has the perfect solution yet, but the good thing is that we’re moving closer to it. I can’t wait until I can design applications for mobile, desktop and browser in one application and have it “seamlessly” translate into a development environment without loss of fidelity and not having the headaches to deal with when I have to make design changes. Less time needed for implementation of designs means more time to spend innovating, integrating usability testing, and further refining the processes we use. The result is an escalation in the number of ground-breaking user experiences.

I can live with that

With Flex 3 there are a lot of great new features to help streamline the implementation of your custom skins into your Flex or AIR application. One of them is the Flex Skin Design Extensions (SDE) for Flash, Illustrator, Photoshop and Fireworks. These were available during the beta releases of Flex 3, so you may already be familiar with it. However, since the full release of Flex 3 there have been some updates to the extensions and I wanted to point out a few tricks that may help streamline your skinning workflow a bit further. Also, if you’re new to skinning Flex apps, check out Narciso Jaramillo’s updated article about creating skins for Flex using Adobe Creative Suite 3.

Naming Conventions

If you look at the skin templates that come with the Flex SDE you’ll notice that each skin is named in a particular way. The naming convention works by specifying the component name, an underscore “_”, then the component skin part. For example, Button_upSkin, Button_overSkin, etc. They are named this way so when you import the skin through Flex Builder’s Skin Import Wizard the combo boxes that allow you to assign a skin state for each skin are “automagically” assigned to the skin state you specified in the skin template. This is good to know because you can use the same naming conventions when you’re making your own custom skins that may be created without using the templates provided. I typically make a single file with all my skins in it and use this naming convention frequently.

This method will work for a variety of scenarios. For example, if you need to add a background image to a certain container, you could use myVbox_backgroundImage and it will go through the Skin Import Wizard very easily. This will work for other “skinnable” parts, like borderSkin, upIcon, etc. Easy enough, right?

The other nice thing you can do with adhering to these naming conventions is skin “sub-components”. For example, the DateField component allows you to specify a textInputStyleName. You can assign skins to that text input by specifying the component name, adding a hypen “-” (Illustrator, Fireworks, Illustrator) or dollar sign “$” (Flash) with the sub-component name, then and underscore “_” and the sub-component skin part. So, in the case of the DateField, you could specify the borderSkin for the text input like this:

DateField-textInput_borderSkin (Illustrator, Fireworks, Photoshop) or DateField$textInput_borderSkin (Flash)

Notice I just used “textInput” and not “textInputStyleName”. This is because “StyleName” is appended to the sub-component name during the Skin Import process in Flex. For example, naming a skin asset in Flash “ComboBox$dropdown_backgroundImage”, publishing it and importing it using the Skin Import Wizard would produce the following CSS (Note: You’d have to add backgroundSize: ‘100%’ for the image to stretch.):

ComboBox
{
dropdownStyleName: “comboBoxDropdown“;
}
.comboBoxDropdown
{
backgroundImage: Embed(skinClass=“ComboBox$dropdown_backgroundImage“);
}

If you look at the skin template for the application your using you should see this naming convention used for the tab skins. You can use this same naming convention for other sub-components, like dropdown, verticalScrollBar, etc. Just naming your skin assets a certain way can really streamline the the skin production process.

Naming for CSS Design Mode Previews

Another new feature in Flex 3 is CSS Design Mode. While viewing CSS you can click on the “Design” mode button to see what your CSS looks like applied to a particular component. However, if you were to create a style class and switch to CSS Design Mode you won’t get an immediate preview. This is because you have to specify a component to preview the CSS against. A way to forego this step is to add the type of component you want the styling applied to to the class name. For example, if I had a class name of “blueButton” I could preview it as a Button component in CSS Design Mode by adding “Button” to the class name keeping the dot “.” of the class name like this:

Button.myButton
{
fillAlphas: 1.0, 1.0;
fillColors: #84B1F4, #1D4888;
borderColor: #07314F;
color: #FFFFFF;
}

This will work for pretty much any component, provide a quick way to preview the CSS styling on a component without having to specify it in CSS Design Mode and make your CSS a bit more descriptive. If you use the same styling across multiple components you may want to leave class names void of component specifications.

Other Resources

Designing Flex 3 skins and styles using Creative Suite 3 and Flex Builder 3
Flex 3 CSS Design Mode in LiveDocs

Ted Patrick is posting information this week all about Flex 3, codename:Moxie. Right out the gates he’s addressed what improvements have been made in regards to Designer/Developer workflow. There’s a lot of great features in there that I think will make that workflow a bit more seamless.

Some enhancements include the ability to preview your CSS styling in Design View, direct importing of skins, the ability to zoom/pan on your layout, visual preview of item renderers and a CSS outline view of your CSS structure.

Very nice!

Check out the posts:

Flex 3 - Monday: Designer/Developer Workflow

Flex 3 - Monday: Designer/Developer Workflow (CSS Design View)