Welcome back for part 2. In the first tutorial I went over how to set up your project, create a PV3D object to attach, and call the functions that will attach this object to your marker (if you haven’t read part 1 yet, check it out below). In part 2, I will go over how to listen for when the marker is detected (and undetected). We will also look at how the animation is triggered and stopped.

Now that we have the basic setup, the next step is to animate our PV3D scene. For almost all Flash animations, I use TweenLite or TweenMax, they are really great tweening engines with a lot of features. The best part? They are free. Back in MainDisplay.as, I set up public functions that would animate the various objects I had set up earlier. Working from our previous example variable of “_introFlash1″, here is the initial animation function that gets called (obviously this is just the start of the animation for example purposes. Yours can be as complex as you want):

public function startAni():void {
TweenLite.to(_introFlash1, .5, {alpha:1, onComplete:nextAni});
TweenLite.to(_introFlash1, .5, {scale:1, overwrite:0});
}

Just a simple scale in and alpha in, from the starting values we set previously. Another nice thing about this tween class is that it is easy to call an “onComplete” function when the animation finishes. In this way you can trigger sequential animations easily. Fun stuff. At this point you can also write your function to stop the animation. It basically reverses the stopping animation by tweening back to the original values:

public function stopAni():void {
TweenLite.to(_introFlash1, .5, {alpha:0, onComplete:aniDone});
TweenLite.to(_introFlash1, .5, {scale:.01, overwrite:0});
}

Ok, now that those functions are ready, we want to set up our listeners that check to see if our marker is detected. If it is, then we attach our PV3D object and animate it. When I first set about doing this, I had it set up so that the animation would play while the marker continued to be detected. However, this sometimes caused the animation to not play smoothly. What I ended up doing was making it so that once the marker was detected and the object attached, the detection would stop and the animation would play through. Once the animation was done, the marker detection would start up again. Another issue with the marker detection was that it tends to be very sensitive. Although you can adjust this sensitivity somewhat, I still found it to be too twitchy – the instant the marker was undetected it would fire an undetection event, even thought he marker was still clearly still there. To remedy this, I set a timer that gets triggered by the undetection event. This way there would be some needed wiggle room to give the user a more consistent experience. Let’s take a look at how these listeners and timers come into play. But first, let’s set up our custom events. In most AS projects, you will find it helpful to create custom events and this one is no different. So create a new Actionscript file (I named mine “FlarEvents”) and declare your new events:

public class FlarEvents extends Event {
public static const SCENE_ANIMATED_IN:String = “scene_animated_in”; //fired when scene has finished animating in
public static const SCENE_ANIMATED_OUT:String = “scene_animated_out”; //fired when scene has finished animating out
public static const FLAR_DETECTED:String = “flar_detected”; //fired when the marker is detected
public static const FLAR_UNDETECTED:String = “flar_undetected”; //fired when the marker is undetected
public function FlarEvents(type:String,bubbles:Boolean=false,cancelable:Boolean=false) {
super(type,bubbles,cancelable);
}
}

Back in “FlarSpace.as”, we first declare some variables:

private var _played:Boolean = false; //tells if the animation has played
private var _detected:Boolean = false; //tells if the marker has been detected
private var _undetectTimer:Timer = new Timer(0, 8); //sets a timer for when the marker is undetected

Now to set up some listeners:

this.addEventListener(Event.ENTER_FRAME, mainEventListener);

This listener is our main listener that renders the PV3D scene and constantly checks to see if the marker is detected. Let’s check it out.

private function mainEventListener(e:Event):void {
_capture.draw(_myVideo); //constantly redraws the video feed from our webcam
try {
//the _detector.getConfidence() comparison value (0.6 in my file) is the threshold the FLARtoolkit uses to detect
//the marker via the webcam. Try adjusting this value to make it more or less sensitive.
if (_detector.detectMarkerLite(_raster,128)&&_detector.getConfidence()>0.6) {
_detector.getTransformMatrix(_trans); //get the 3d position our marker
_mainContainer.setTransformMatrix(_trans); //set our PV3D object to the position of our marker
_renderer.renderScene(_scene3D, _cam3D, _viewPort); //render our PV3D scene
this.dispatchEvent(new Event(Events.FLAR_DETECTED)); //dispatch the FLAR_DETECTED event into the event flow
_detected=true; //marker has been detected, set _detected to true
}
//this checks if the detection falls below a certain threshold, I had good luck with 0.3.
//It also check to verify that the animation has played.
if (_detector.detectMarkerLite(_raster,128)&&_detector.getConfidence()<0.3&&_played==true) {
_detected = false; //we have lost the marker, set _detected to false
_undetectTimer.start(); //start the undetection timer
}
} catch (e:Error) {
}
}

The second two listeners listen for two of the custom Events that I created.

this.addEventListener(Events.FLAR_DETECTED, flarDetected);
this.addEventListener(Events.FLAR_UNDETECTED, flarUndetected);

Let’s take a look at the functions that are triggered by these events:

private function flarDetected(evt:Event):void{
this.removeEventListener(Events.FLAR_DETECTED, flarDetected); //remove the FLAR_DETECTED calling event listener
this.removeEventListener(Event.ENTER_FRAME, mainEventListener); //remove the main event listener
this.addEventListener(Event.ENTER_FRAME, aniEventListener); //add a new event listener to listen for the starting animation to finish.
_main.startAni1(); //call our public function to start the animation back in our MainDisplay class*.
//*Remember, _main is our instantiation of this class that we added to our _mainContainer FLARBaseNode object in part 1.
}
private function flarUndetected(evt:Event):void{
this.removeEventListener(Events.FLAR_UNDETECTED, flarUndetected); //remove the FLAR_UNDETECTED calling event listener
this.removeEventListener(Event.ENTER_FRAME, mainEventListener); //remove the main event listener
this.addEventListener(Event.ENTER_FRAME, aniEventListener); //add a new event listener to listen for the ending animation to finish.
_main.stopAni1(); //call our public function to stop the animation back in our MainDisplay class.
}

What we are doing is removing the main event listener and setting up an alternate animation event listener. Here is what that looks like:

private function aniEventListener(e:Event):void{
_renderer.renderScene(_scene3D, _cam3D, _viewPort); //continue to render our PV3D scene
_mainContainer.setTransformMatrix(_trans); //set our PV3D to the last position of our marker
}

We are still triggering two of the behaviors in the main event listener: to make sure our PV3D object continues to be rendered, and place it at the last marker position. What’s missing is the constant marker detection, which tends to slow the animation down as mentioned above.

Now let’s take a look at the undetection logic. First, add a listener to the timer that is triggered when the timer ends:

_undetectTimer.addEventListener(TimerEvent.TIMER_COMPLETE, undetectTimerDone);

Then simply start the timer when the undetection event occurs (this is in our main event listener).

_undetectTimer.start();

And finally, the resulting function:

private function undetectTimerDone(evt:TimerEvent):void{
_undetectTimer.stop(); //stop the timer
_undetectTimer.reset(); //reset it for later use
this.dispatchEvent(new Event(Events.FLAR_UNDETECTED)); //dispatch the FLAR_UNDETECTED event into the event flow
}

By providing a delay in firing this event, we can ensure that it isn’t fired too quickly.

Ok, almost done. As of now we have the animation event listener taking care of the rendering and we are playing our animation. When the animation finishes, we want to turn the main event listener back on so that our object can once again be attached to the position of our marker. A couple of new event listeners should do the trick:

_main.addEventListener(Events.SCENE_ANIMATED_IN, aniIn); //listen for our custom event that is triggered when the initial animation finishes
_main.addEventListener(Events.SCENE_ANIMATED_OUT, aniOut); //listen for our custom event that is triggered when the ending animation finishes

And the corresponding functions:

private function aniIn(event:Event):void{
_played=true; //set out played variable to true
this.addEventListener(Event.ENTER_FRAME, mainEventListener); //start our main event listener back up again
this.removeEventListener(Event.ENTER_FRAME, aniEventListener); //remove our animation event listener
this.addEventListener(Events.FLAR_UNDETECTED, flarUndetected); //re-start the FLAR_UNDETECTED event listener
}
private function aniOut(event:Event):void{
_played=false; //set our played variable to false
this.addEventListener(Event.ENTER_FRAME, mainEventListener); //start our main event listener back up again
this.removeEventListener(Event.ENTER_FRAME, aniEventListener); //remove our animation event listener
this.addEventListener(Events.FLAR_DETECTED, flarDetected); //re-start the FLAR_DETECTED event listener
}

These functions should be pretty self-expalnatory, and are called from our MainDisplay class, like so:

this.dispatchEvent(new Event(Events.SCENE_ANIMATED_IN)); //intro animation is done, dispatch the SCENE_ANIMATED_IN event into the event flow
this.dispatchEvent(new Event(Events.SCENE_ANIMATED_OUT)); //ending animation is done, dispatch the SCENE_ANIMATED_OUT event into the event flow

By structuring your project like this, you can keep all of your PV3D objects and animations in one file and all of your FLAR detection and listeners in another. They are simply linked together via event listeners. I hope this helps you with your next project. Happy coding!

Jersey Boys 3D

This project began when we found out that our client was going to be printing some paper fans to give away at Jersey Boys shows throughout the country. They were looking for something interesting to put on the fans, a link to a new site that fans would visit. We came up with the idea of printing a marker on the fans that could then be used at a specific website in order to produce a 3d, augmented reality image via the user’s webcam. We got the go-ahead on the project and the fans were sent for printing. The timeline was set and work began.
Click here to view the final project online and try it out for yourself. Read on to learn about our design process and setting up the project in AS3.

Before doing any coding or asset creation on the project, we started with storyboards in order to come up with ideas of what we wanted to happen when the viewer held up the fan to their webcams. We ended up doing two versions and then combining ideas from both into one. Here is the final storyboard we used, along with description text and arrows to indicate movement (yes, we went old school and hand-drew the graphics):

Storyboard for Jersey Boys 3d project

After walking the client through our storyboard, we got the ok to build it out. Now the real work began. We started by looking into the technologies that we would be using in the project. We had done some work with Papervision (http://blog.papervision3d.org/) in the past so we were familiar with how it worked. We made sure we had the latest version of Papervision 3d (via SVN here) and set up our file structure for the project. Next we downloaded the FLARtoolkit files, available here, the technology we would use to attach our 3d Flash movie onto the marker on the fan in 3d space. After downloading and placing these files into our project, we got to work.

We start by creating an Actionscript file that would handle the attachment of the 3d object to the marker. So fire up Flash or Flex and start a new Actionscript file (I am naming mine “MainFlar.as”). First things first, the imports.
To start, import all of the flash classes we will need (be sure and change the paths to match the class structure of your project):

import flash.display.BitmapData;
import flash.display.Sprite;
import flash.events.Event;
import flash.media.Camera;
import flash.media.Video;
import flash.utils.ByteArray;
import flash.display.StageQuality;
import flash.filters.ColorMatrixFilter;
import flash.utils.Timer;
import flash.events.TimerEvent;

Next, all of the Papervision 3D classses:

import org.papervision3d.lights.PointLight3D;
import org.papervision3d.materials.shadematerials.FlatShadeMaterial;
import org.papervision3d.materials.utils.MaterialsList;
import org.papervision3d.objects.primitives.Cube;
import org.papervision3d.render.BasicRenderEngine;
import org.papervision3d.render.LazyRenderEngine;
import org.papervision3d.scenes.Scene3D;
import org.papervision3d.view.Viewport3D;
import org.papervision3d.objects.DisplayObject3D;
import org.papervision3d.events.RendererEvent;

And finally, all of the FLARtoolkit classes:

import org.libspark.flartoolkit.core.FLARCode;
import org.libspark.flartoolkit.core.param.FLARParam;
import org.libspark.flartoolkit.core.raster.rgb.FLARRgbRaster_BitmapData;
import org.libspark.flartoolkit.core.transmat.FLARTransMatResult;
import org.libspark.flartoolkit.detector.FLARSingleMarkerDetector;
import org.libspark.flartoolkit.pv3d.FLARBaseNode;
import org.libspark.flartoolkit.pv3d.FLARCamera3D;

Ok, now we need to create 2 files in order for the code to have something to detect: 1) the pattern file. This is a .pat file that is basically a representation of the marker you are using. They are online services that will generate this file for you when you upload your marker file, here is one. There is also an air app to do this, available here. 2) The “camera_para.dat” file. This is a binary file that is used to calibrate your webcam. For this you should be fine just using the one that comes bundled with the fLARtooolkit.

Back in our MainFlar.as file, we now need to embed these 2 files for use in the project, and create classes for them (don’t forget to change the paths to match those of your project):

[Embed(source="../assets/pattern/marker.pat",mimeType="application/octet-stream")]
private var _MarkerPattern:Class;

[Embed(source="../assets/camera_para.dat",mimeType="application/octet-stream")]
private var _CameraParameters:Class;

Ok, now to set up your variables (these will be explained below):

//vars for the camera to capture the video stream
private var _myCamera:Camera;
private var _myVideo:Video;
private var _capture:BitmapData;

//FLAR vars that will detect and attach our marker
private var _cameraParams:FLARParam;
private var _markerPattern:FLARCode;
private var _raster:FLARRgbRaster_BitmapData;
private var _detector:FLARSingleMarkerDetector;
private var _cam3D:FLARCamera3D;

//PV3D vars
private var _scene3D:Scene3D;
private var _viewPort:Viewport3D;
private var _mainContainer:FLARBaseNode;
private var _renderer:LazyRenderEngine;
private var _trans:FLARTransMatResult;

//our PV3D Display Object that contains all of our 3d objects
private var _main:MainDisplay=new MainDisplay();

Ok, now that that is set up, we need to create a Papervison 3D object that we can use to attach to the marker.
I used a MainDisplay class (see above) that extends the DisplayObject3D PV3D class. That way I could add various elements to my display and have one central class to keep everything in. I separated each element I would need into a separate class that I would then add to the MainDisplay class. For example, I created  a Flashbulb class that creates a spotlight at a specific size. I added a public function that would then return this object to my MainDisplay class. Here is the code for the Flashbulb class:

public class Flashbulb{
private var _flashbulb:Sphere;
private var _colorMaterial:ColorMaterial;
private var _glow:GlowFilter;

//Initialization
public function Flashbulb() {
super();
_colorMaterial=new ColorMaterial(0xFFFF00);
_glow = new GlowFilter(0xFFFFFF, 1, 10, 10, 4, 3);
_flashbulb=new Sphere(_colorMaterial,10, 10,20);
_flashbulb.useOwnContainer = true;
_flashbulb.filters = [_glow ];

}
//function to return this object to my MainDisplay class
public function getBulb() {
return _flashbulb;
}

}

Back in MainDisplay.as, I declared the variable for the new Flashbulb object and called the function that would return this object:

private var _Flash1:Flashbulb = new Flashbulb();
private var _introFlash1:Sphere=_Flash1.getBulb();

Then I added the _introFlash1 object to my MainDisplay.as file, placed them in their proper position and set their initial properties (which would be animated later):

this.addChild(_introFlash1);
_introFlash1.x=100;
_introFlash1.z=200;
_introFlash1.y=100;
_introFlash1.scale=.01;
_introFlash1.alpha=0;

Another advantage of using this method was that it allowed me to create multiple instances of the Flashbulb object for use in MainDisplay.

Back in FlarSpace.as, I was ready to setup my camera, initialize the FLAR settings and add the MainDisplay to my marker.
First I called a findCam function that looked for the user’s USB class video camera (the preferred camera for accessing the viewer’s webcam). If it wasn’t found, it would get whatever camera the user has installed and attempt to use that.

private function findCam():void{
for (var i:int = 0;i<Camera.names.length;i++) {
if (Camera.names[ i ] == “USB Video Class Video”) {
_camIndex = i;
_myCamera=Camera.getCamera(String(_camIndex));
} else {
_myCamera=Camera.getCamera();
}
if (i== (Camera.names.length-1)){
setupCamera();
}
}

}

Once a camera was found, I called the setupCamera function. This function sets up the camera and attaches it to my video object:

private function setupCamera():void {
//these dimensions shoudl match those of your main swf
_myVideo=new Video(640,480);
//look for camera object, if one is not found, display warning
if (_myCamera==null) {
addChild(_warning);
trace(“no camera”);
}
//this sets the resolution and framerate of the camera
_myCamera.setMode(320, 240, 15);
//attach the camera to your Video object and add it to the stage
_myVideo.attachCamera(_myCamera);
this.addChild(_myVideo);
}

Next, I initialized the FLAR settings in the following functions.
The first function sets it up to use the marker pattern that I had embedded earlier:

private function setupFLAR():void {
_cameraParams = new FLARParam();
_cameraParams.loadARParam(new _CameraParameters() as ByteArray);
_markerPattern=new FLARCode(16,16);
_markerPattern.loadARPatt(new _MarkerPattern());
_trans = new FLARTransMatResult();
}

The next function sets up the bitmap data that would allow the camera to detect the marker:

private function setupBitmap():void {
_capture=new BitmapData(640,480);
_capture.draw(_myVideo);
_raster=new FLARRgbRaster_BitmapData(_capture);
_detector=new FLARSingleMarkerDetector(_cameraParams,_markerPattern,80);
}

Once I had my camera and marker all set up, it was time to set up my PV3D scene and bring in my PV3D Display Object (the “_main” var  above that was typed to the MainDisplay class I created earlier):

private function setupPV3D():void {
//initialize PV3D vars
_scene3D = new Scene3D();
_cam3D=new FLARCamera3D(_cameraParams);
//initialize the FLARBaseNode container
_mainContainer = new FLARBaseNode();
//attach the FLARBaseNode that will attach to the marker to our PV3D scene
_scene3D.addChild(_mainContainer);
//initialize the PV3D Renderer
_renderer=new LazyRenderEngine(_scene3D,_cam3D,_viewPort);
//initialize the PV3D Viewport and add it to the stage
_viewPort = new Viewport3D(640,480);
this.addChild(_viewPort);
//this is where we attach our _main (MainDisplay object) to the FLARBaseNode
_mainContainer.addChild(_main);
}

That’s it for Part 1. In Part 2, we will set up the listeners that listen for when the marker is detected (and undetected). We will also get into how the animation is triggered and stopped. Tune in soon for Part 2, thanks for reading.

Still from live feed of CMM video on Nasdaq screen in Times Square 6-25-09.

A client of ours, Sarah Fey, came to us with a rush video animation job. When we found out the video would be displayed on the huge Nasdaq video billboard in Time Square, we couldn’t pass it up. To watch the final video and footage from the live feed, click here. To learn more about the process of producing the video, read on…

The video was for a new company called Medidata. The client gave me approved storyboards that showed frames from the animation and approximate time codes of when animations would happen. I set up a new After Effects project and got to work. This video was a little different than other videos I have worked on due to the quirks of the Nasdaq billboard. For one thing, the video is taller than it is wide, unusual for a video. Even stranger, the video needed to be submitted to Nasdaq as 1280×720 HD video, a completely different aspect ratio than the actual screen. To account for this, Nasdaq recommends first building the video in the middle area of a 1280×720 comp. Then, scale the width of this comp 237% to make the edges of your comp go to the edges of the screen. This video will look very distorted but when it is put in the Nasdaq system, it will be re-scaled to appear correctly.

The other issue is that 3/4 of the video is partly covered by a series of windows. On the final output, these windows are masked out, so whatever is in those places on the video will be blank. This presents a challenge to text, because you want to make sure that your text is large enough to be readable even if parts are masked out by the windows. Nasdaq provided me with a handy template that you can use to see where the windows will be in the final output, and adjust your text accordingly.

The first thing I did after setting up the comp at the correct size and putting in the window overlay was to bring in all of the elements. The client provided me with the images of the doctor and their logo to use. For the text, I decided to do that within After Effects instead of using images for two reasons: 1) Text will appear sharper and can be scaled without loss in resolution and 2) Will be much easier to change in case the client decides to change to wording partway through.

From there, I began to lay out of the elements at their proper entry points on the timeline. Once that was done, I took stills from different points in the video and put them up on an HTML page so that the client could see how the video was looking. Once those were approved, I went to work on the actual animation (having done most of my recent animations via Actionscript in Flash, it was interesting to go back to timeline animation). So I got to work keyframing all of the elements, previewing them, tweaking etc. Although I had an idea of when the animations should start and stop, I always find they change slightly when you start watching the animation and get into the flow of it. My favorite part was doing the cascading wall of “data”, in which instances of the word “data” will fall from the top of the screen and eventually fill the entire screen. I used a particle effects generator to give it a random feel, and adjusted the settings until it looked like I wanted.

After a couple of revisions and some more timing adjustments, the video was completed, rendered and sent to Nasdaq. We were able to capture some of the live stream of it running in Times Square, very exciting to see it at its full size. You can check out the full video and the Nasdaq capture here. Thanks for reading!

We have been currently working on a desktop application with customized components. As you may be aware without Flash Catalyst the work flow for creating an application with customized components can be time consuming and very demanding. You can customize the components using Flex Style Explorer or customize the templates offered in Illustrator, Fireworks, Flash or PhotoShop. However, Adobe is now bridging the gap between design and development to make it easier. Flash Catalyst Beta has just been released. Is it a disappointment or not? There are many opinions out there. In this post we will review some of the advantages of Flash Catalyst and what it has to offer.

1. Faster Work Flow - Creating a more successful work flow and saving time is money. Let the designer and developer do what they do best. This is amazing because Flash Catalyst helps tie everything together. The designer can be working on making a change to the design while the developer is developing the back end.

Flash Catalyst facilitates the designer in many ways:

• Gives the power to create a visual appearance for an application.
• Offers pre-defined visual components to work with while designing an application.
• Gives the freedom to arrange the components and create a unique interface.
• Offers the ability to create a customized appearance without a headache.
• Gives the designer written code with behaviors without having to know any code.

Flash Catalyst facilitates the developer in other ways. Like:

• Gives the freedom to focus on what they do best which is writing code, connecting data and communication services.
• Offers the ability to build and run the application with a totally customized look.

2. HUD – You may be asking what is the HUD. This is a new feature offered in the Flash Catalyst interface. The HUD is the Head-Up Display. It helps assist you the user while you are creating different projects in Flash Catalyst. How? When you have a component or anything on the stage selected in Flash Catalyst the HUD tells you what is selected and options with different things you can do with it. When you are first learning Flash Catalyst it can be very helpful and save time in general. You can move the HUD to any location so it does not have to get in your way.

3. Timeline – The timeline may be confusing at first. You may have been intimidated by the timeline in Flash but they have a different kind of timeline in Flash Catalyst. The timeline allows you to create specific interactions and transitions. The timeline in Flash Catalyst is different because it does not deal with a specific object that moves along the time timeline over the application like in Flash. You do not have to worry about easing in and out. The timeline allows you the user to create and time smooth transitions. The different kinds of animation it offers is smooth, fade, move, resize, rotate and 3D transitions. The user can control when they happen with the timeline.

4. Wireframes – A large part of developing and designing an application is selling the design to the client. You do not want to get half way through the development and find out that the client is unhappy with the design or functionality of an application. In Flash Catalyst the designer can create the application with transitions and show it to the client. This paints the big picture for the client without all of the development time. Some clients need to see the big picture to completely understand the final product they will receive. In Flash Catalyst you can create wireframes or the application. Apply transitions and show the client. They can tell you their likes and dislikes before it is even handed off to the developer. This will help while working with your clients and developers.

5. Illustrator, Photoshop, Fireworks – If you are designer you are probably comfortable designing with one of the above programs. I like to work a lot in Illustrator. I can create an Illustrator file with all my customized components and bring it into Flash Catalyst and then back to Illustrator to make changes. The back and forth process is very helpful. The first time I did this it felt like a miracle that would have never happened. Magic? It is so simple, right? Their are some negatives. Nothing is ever perfect. Hopefully, all of the bugs will be worked out in the next release.

Thanks to Flash Catalyst making customized skins just got easier. We will be developing and designing with Flash Catalyst/Flash Builder in our upcoming projects. We will keep you updated as we dive deeper into the newest Beta release and let you know if Flash Catalyst is all they say it is. Hopefully, it will not be a disappointment.

If you have not downloaded Flash Catalyst or if you would like further information check out the following links:

Download Flash Catalyst at: http://labs.adobe.com/technologies/flashcatalyst/

:: Click for the Flash Catalyst Help Document ::

We had been waiting in eager anticipation through the first half of this year for it to finally arrive. All indications were that we would be well adjusted to our new work flow by the time summer rolled around for sure, enjoying all the new tooling and features of Flex 4, round tripping some super-duper new skins with our design team via Catalyst, and improving our productivity on the whole. But as winter gave way to spring, our excitement began to wane until I had all but forgotten about the coming of this new generation of Flex. When suddenly, with almost no warning whatsoever, it was upon us… the new Flash Builder 4 beta, code named ‘Gumbo’.

Adobe’s newest attempt at reconciling its past branding snafus, is to name their new flagship IDE ‘Flash Builder’ which for me just seemed like a bad mashup of its progenitors’ names. And this at a time when the development community had fully embraced the Flex application paradigm and branding, and to a great extent, so had the better informed end users of Flex applications. I personally thought that Flex Builder had a much more appealing ring to it as well, but hey, that’s just my personal opinion.

But how easy it is to be critical, and from what I can tell (despite the obligatory growing pains) this release is going to be a great big step forward for our team. Allow me to elaborate some..

We at curious minds have recently been working on some pretty snazzy AIR apps over the last few months, and in the process gotten very adept at skinning our components and integrating our designers’ work quickly and effectively. (There are a few of our  blog posts relating to these topics that are quite informative if you are interested). According to Adobe, Catalyst is going to give us even more flexibility (not a pun) and better integration than before. Our designers are going to be able to create Flex apps directly in Catalyst, and our developers can import them and get down to business integrating the UIs with data and application logic. Finally, we’ll actually be able to work in the same environment, and on the same app simultaneously! I know that for certain developers (myself very much included), this is going to make life a great deal easier, allowing us to focus on the things that we are actually good at doing. This is probably the best feature of Catalyst as I see it. The fact that the work will now flow both directions between designers and developers, instead of the ‘uni-directional’ limitation that seems to pervade our current system.

Another feature that I’m completely gaga over in ‘Gumbo,’ is the integrated network traffic monitor. What a huge help this tool is going to be in the development/debugging process! With inline tree views of XML and AMF server response data, this HTTP monitor is going to cut a lot of the nasty trace style debugging right out. Also, being able to jump directly to the line in your code that originated the RPC request is a great feature of this tool.

All in all, I am really excited about diving into the new IDE. I’ll post up a full report once we get a little better situated with our new software, and as always, look for great tutorials on the new generation of Adobe design/development tools.

Often in programming, what seems to be a simple task can trip you up. Yesterday I was trying to embed the font Helvetic Neue LT Com Bold 77 in a css style sheet for a project of ours. After about 20 minutes of trying different methods to get the project to compile without any errors, I came across the following method:It turns out that with a font like the Bold 77, The typeface is already bold, so there is no need to put the fontStyle:Bold directive in the css declaration. In fact, since 77 bold already contains no bold style, and declaring it as such will throw an error. 

Font Book on mac is a great app. Using the app’s ability to intropect on the font, you can see all of the information in each font on your computer. The most important information you can get out of Font Book is the full font name attribute. The key here is to embed the full font name attribute in the flex application. Just like this:

@font-face
{
     src: url(‘path/to/embed.swf’);
     fontFamily:”Helvetic Neue LT Com Bold 77″;
} 

The important thing here is that if you arre unsure of what font faces are included in any particular font, just use the full font name alone, and dont mess with anything else. 

For Flex Builder 3 apps, we like to use the Flash Embed method of getting the font transcoded into the Flex App. The resulting file size is much lower. Just be sure to embed only the characters that you are going to need, and not the entire set.

Currently, we are working on building a new desktop application. It all begins with good planning and beautiful design. Here are four steps with tips that will help designers design a successful application.

1. Structure
The application design should organize the user interface purposefully. All elements of the design should have meaning and be useful. The structure should be based on a clear and consistent model that is recognizable to user. The application structure should be organized so that related things are together and separate unrelated things. The structure is concerned with the overall user interface architecture.

• Planning the Structure
  A good way to keep the application design organized and structured is to plan ahead. Start by writing an outline of all of the functionality of the application. Then create simple wire frames for the whole application. This will save you time and allows the designer, developers and client to see the big picture.

2. Simplicity
The application design should be simple. The design should make common tasks simple to do and communicate clearly to the user. Here are a few design tips that can help create simplicity:

• Consistent Design – One of the biggest mistakes with designing an application design is creating elements that are not consistent. Keeping a consistent style throughout all elements within the application will make an user-friendly application with a successful design. The application design should use consistent component styles and behaviors. Creating consistency through out the application will reducing the need for users to rethink and remember.

• Choosing Color – Color should be used sparingly in applications. The problem is that some users may be color blind. If an application uses color to highlight something on a screen, then you need to do something else to make it stand out if you want these people to notice it. The colors in the application should use contrast and be used consistently throughout application.
• When deciding on a consistent set of colors to be used throughout the application do not forget about branding. If the application is for a company that has branded colors use the branded colors. If you are starting from scratch you have more freedom. The application should not look like a rainbow of colors. Think of three to five solid colors that you will use throughout the design.  For example, on the following application design the branding of this company uses red and black. Throughout the application we have used different percentages of black to white. Here are the percentages of black colors we used:
  100%, 90%, 85%, 60%, 40%, 30%, 10%, 0.
• For the highlight and rollover color the application uses  a gradient with a bright red and regular red. On the down state it uses a regular red and a dark red gradient.

• Typography – For readability you should pick a sans-serif typeface with a regular/roman/medium size and a bold that is easy to read. For a general size of the font for readability you should not go below 12px for text. 12px to 14px is easy to read for labels, data grids, text inputs, and any additional content. Panel labels and titles should be larger than the main text so they stand out.

3. Visibility
The application design should keep all needed options and materials for a given task visible without distracting the user. Good designs do not overwhelm users with too many alternatives or confuse them with unneeded information. Crowded screens are difficult to understand and are difficult to use. Here are a few tips on creating a strong sense of visibility:

• Determine Hierarchy – The visual hierarchy of the application design is important for the user. Think about what is most important and least important. The most important items should have the most emphasis and the least important should have the least emphasis. If the hierarchy and layout is designed properly the users eye should move around the application from the most important to the least important. If you do not have strong hierarchy this may make the user confused. Hierarchy can be achieved by creating contrast, size, positioning, and color.

• Spacing & Alignment – Do not waste space. In application design space should be used wisely. Align fields effectively. When a screen has more than one editing field, you want to organize the fields in a way that is both visually appealing and efficient. This example uses labels that are left justified and the edit fields are left justified. This is a clean and efficient way to organize the fields on a screen.

4. Feedback
The application design should keep users informed of actions. This can include errors or a changes of state in the application. Use clear and concise language familiar to users. Expect the users to make mistakes. The application design should create a user interface that the user can recover from their mistakes.

If you are looking at this error in your flex compiler, make sure that the DisplayObject that you are trying to add to the stage is subclassing UIComponent and not UIMovieClip. The two are nearly interchangeable, yet the UIMovieClip needs specific bounds.

Happy Coding!

Bowen and Company website, design by Florio Design

I finished a Flash animation for a client in which the background color of the movie fades from brown to white. The client liked it but decided that he would like the background of the browser (behind the embedded Flash movie) to change as well.

I figured the best solution would be to make the Flash movie full browser. So here is the solution that I came up with:

I set the Background (CS3) or Stage (CS4) color of the Flash movie to brown and drew a white box on the stage, converted it to a MovieClip and named it “wBox”. I moved the layer with the white box underneath my main MovieClip (named “mainMC”) in the Timeline. Now I would need to code some Actionscript that would make the white box expand to fill the browser, while the main content above would remain at a fixed size and center horizontally on the screen.

Here is the code I used:

//set the stage position
stage.align = StageAlign.TOP_LEFT;
//do not let any of the stage scale (keeps main MC at fixed size)
stage.scaleMode = StageScaleMode.NO_SCALE;

//add stage resize listener (this is called when the browser or flash movie is resized)
stage.addEventListener(Event.RESIZE, resizeHandler);

//create function that is fired when resize is triggered
function resizeHandler(event:Event):void {
position();
}

//call resize function at start of movie
position();

//this is the function that stretches the white box to fill the browser and horizontally centers the main MC.
function position() {
wBox.width = stage.stageWidth;
wBox.height = stage.stageHeight;
mainMC.x = (stage.stageWidth/2)-(mainMC.width/2);
}

At the appropriate time in the animation, I faded the white box, revealing the brown bg below.
I like using the TweenLite class, I find it is more stable than the built in AS Tweening engine. You can download it here.
Here is the fade code for the white box:

import gs.TweenLite;
TweenLite.to(this['wBox'], .5, {alpha:1});

Ok, so now the background is changing color no matter what the browser size so call it done, right? Not quite. If you were to scale the browser past the dimensions of the Flash movie, no scrollbars would appear. Not good for small screens, laptops etc.

Basically, I wanted the Flash movie to be at 100% of the browser unless it was scaled to less than its original size, after that the browser’s scrollbars would take over. The method I had used in the past to accomplish this didn’t work in this case because of the fading bg color, so I looked for a new solution.

I came across a simple Javascript method that was exactly what I needed. It embeds your Flash movie at 100% width and height, but also passes in a minimum width and height parameter. If the movie is scaled past this minimum size, scrollbars will appear.
Here is the link to the Javascript source.
You will also need to download swfobject.

Here is the way to use the embed code:

<script type=”text/javascript” src=”js/swfobject.js”></script>
<script type=”text/javascript” src=”js/swffit.js”></script>
<script type=”text/javascript”>
swfobject.embedSWF(“ani.swf”, “ani”, “100%”, “100%”, “9.0.0″);
swffit.fit(“ani”,900,700);
</script>
<div id=”ani”>swf</div>

Hope this helps with your full browser Flash implementations!

 Introduction to a Classic OOP Design Pattern

Throughout my career as a developer I have had the occasion to use the Factory Method Pattern when appropriate, and grown to rely on it extensively in recent months as several projects have dictated. I find this pattern to be extremely useful in creating a loosely-coupled application architecture, which (as we’ve all been indoctrinated) is the cornerstone of well designed apps. It is my hope that this introduction will illuminate this pattern for the uninitiated. Even if you don’t find an immediate application for the Factory Pattern, just understanding the ‘why’ and ‘how’ of this design can be important in grasping the importance of the “open-closed” principle, and will help you to write better code. 

Let me start off by giving the standard text-book definition of the pattern:

The Factory Pattern “…define[s] an interface for creating an object, but allows the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses.” 

Chances are that many readers out there will be quite familiar this manner of verbiage. However if you need a quick primer, this more or less states that this pattern can be used when you have the need to create objects of a varying types, and whose types cannot be known before runtime. One quick aside, I’m going to call these objects ‘products’ as real life factories generally produce things called products, and it is always useful when dealing with abstractions to think in more concrete terms. The situation I’ve just described is common if the product you need to create depends on configuration settings, or more likely, responses to user interaction. 

Let’s step through a likely code example together to light a proverbial fire under this otherwise sterile illustration. I’ve chosen a product that I’m currently pretty enthused about… guitars. Now everybody knows that there are about int.MAX_VALUE types of guitars in the world, and any guitar player will tell you that you can never have too many of the darn things around. So it wouldn’t be a stretch to envision an app that queries a customer for his/her desired guitar characteristics, makes up a request for said guitar, and sends it off to a guitar factory object to do the construction of the desired guitar object, right? A superlative example if I do say so. 

For the sake of simplicity, we’re going to limit the types of guitars available to the user to ‘electric’, ‘acoustic steel-string’, and  ’acoustic nylon-string’, each of these types having unique properties, and the inherent need to be constructed in different ways. They are all guitars, however, and thus share certain properties common to all guitars. We can logically represent this commonality by defining an interface called IGuitar. IGuitar might look similar to the following:

public interface IGuitar{
function lookPretty():void;
function soundIncredible():AwestruckListener;
}

These are all of the things that our guitars need to be able to do, else we call them canoe paddles, or bits of kindling, or perhaps worse. Each guitar class that implements this interface is responsible for providing the necessary details about how it does ‘lookPretty’ and ’soundIncredible.’ Now, you might ask how we are going to build all of these different types of guitar in one factory. The key to this trick is all in the implementation of the IGuitar Interface. Here is our GuitarFactory code:

public class GuitarFactory {
    public static function buildGuitar(guitarType:String):IGuitar {
     switch(guitarType) {
            case ‘electric’:
                return new ElectricGuitar();
                break;
            case ‘acoustic steel_string’:
                return new AcousticSteelStringGuitar();
                break;
            case ‘acoustic nylon_string’:
                return new AcousticNylonStringGuitar();
                 break;
                  default:
                        trace(guitarType + ‘ ain’t no guitar I’ve ever heard of.’);
              }
        }
}

You’ll notice that the buildGuitar method returns an instance of IGuitar, which gives us the flexibility to return any type of object that has implemented that interface. This is crucial if we intend to add more and varied types of guitars to our custom guitar shop application. For instance, we could easily add bass-guitars, balalaikas, cavaqhinhos, or any other instrument that has agreed to meet the requirements set forth in the interface. 

This example is perhaps a bit pedestrian, if not corny, but you get the idea. The main point to take away from this is the idea that you can defer creation of a given type of object until it becomes necessary to build it. This gives you a great deal of flexibility in your application, and can be extremely handy in a host of situations. Check it out for yourself.