I read a lot of developer blogs and one of the themes I run across the most from the Ajax crowd is their top reasons I hate Flash lists. It’s almost always: not open source, not indexable by search engines, requires plugin, and use for obtrusive advertisements.

I’ll grant that they have a decent, not great, case for each of these except for the last one. On that one I’m going to have to say that it is their technology that is creating most of the annoying adds on webpages today. I see so many of those floating DIVs animating across my browser page that I want to disable JavaScript. Of course I don’t because I’d be shooting myself in the foot.

To be fair most of the annoying adds on webpages today are simply animated GIFs which have been around for ages. After that we get those stinking floating DIVs that seem to be everywhere. And occasionally we get a floating Flash movie that gets in the way of what we’re trying to do.

At least the Flash ads are usually entertaining and attractive instead of the crappy looking DIVs. It’s a small consolation.

If you’re an Ajax Developer with your own top reasons to hate Flash then remove annoying ads from your list or at least add a note that floating DIVs are just as annoying and way more numerous.

I would have to say that getting my head around how listeners work in Actionscript might have been the toughest aspect of AS for me. But, once you get used to it, just like everything else, it’s simple to use.

To create a listener you need three things:
1-you create an object - new object().
2-you tell that object what to do when an event happens - event handler.
3-you get the object to listen for the event - addListener.

Here’s a real world analogy: suppose you want to make a phone ring when someone calls you.

First, (#1) create a phone.

var myPhone:Object = new Object();

Next, (#2) tell it what to do when a phone call comes in

myPhone.onCallRecieved = function():Void {
makeTheRingSound();
}

And finally, (#3) tell it to listen for an incoming phone calls.

phoneNetwork.addListener(myPhone);

This last part, (3) might be the most confusing aspect so I’ll go into it with a little more detail.

Think of it this way: there’s a phone network out there that everyone is connected to. If someone uses their phone to dial your phone number then your phone will ring. Obviously you have to have a phone, the object (#1) and your phone must know what to do when it receives a phone call (#2). But there’s a little more to it isn’t there. You can’t just buy a phone and turn it on. First, to get it to work you have to register it with the network and tell it what your phone number is. That way when someone dials your number the network can determine who is listening - your phone - and send you the message.

If you hadn’t done this last step then when someone dialed your number the network would still get the event but it wouldn’t know who to tell. Once you register with the network then it will know to broadcast an event to you when your number is dialed.

So once again, you have the object - phone - the thing in your phone that acts when it receives an onCallReceived event and finally you tell the network to let you know when someone dials your number.

General form of a listener:

Here is a very simple example of a listener in Actionscript. Use the arrow keys on your keyboard to move the ball up/down, left/right. The longer you hold down a key the faster/slower it will move. So holding down on the right-arrow for a few seconds will make it move right and then holding down the left-arrow for a few seconds will slow it back down. At any time you can hit the spacebar to stop the ball and return it to the center. (Note: you must click on the SWF - black square - to give it focus so that it receives the keyboard input.)

Here’s the code that makes this all work (download zip)

Here is what’s happening above. An object is created - listener. And that object is told what to do if it gets an event called onKeyDown. And finally we tell the Key class to notify our listener when the onKeyDown event happens.

Suppose you had a Flash movie that doesn’t have any of this code. What happens when we press a key then? Well, the Flash player knows that a key was pressed and it - the Key class - looks to see if any objects need to be notified. If there are no listeners then obviously it doesn’t send any notifications.

The onKeyUp is the other event that the Key class can notify an object about. Since our listener is receiving all the events that pertain to the Key class then it gets those notifications as well. However, we don’t have any code that tells our listener what to do about it so nothing happens.

You might ask yourself, “why don’t mouse events work the same way?” That’s because the Flash developers thought that it would be so common to have mouse events associated with MovieClips and buttons that they made it simple to use. Basically, things like MovieClips automatically listen for mouse events so all you need to do is supply the code for what you want to happen, as such:

myClip.onRelease = function():Void {
// do things when someone clicks and
// releases the mouse on this MovieClip
}

That’s the #2 part of our example above. Steps #1 and #3 are done for us to make our life/coding simpler.

There are all sorts of other classes that broadcast events that you might want to listen for. If you’re using the movieClipLoader class you might want to know when something has completed loading, or with a video that is streaming into your movie you might want to know when it has completed playing. You can also use a listener to tell when the stage has changed size, or when a webcam has changed it’s status. The list goes on and on. In fact, that’s what you want to look for in the Flash help files - on. Pick a class in the Actionscript Classes folder and look for methods that begin with on. Those are the events that it broadcasts so that you can write code to manage what happens when the event is triggered.

I would have a hard time picking an answer If I were asked, “Of all the work that you’ve done for the EXG team (Entertainment eXperience Group) what are you the most proud of?”

The Lenzer RIA is, dare I say, perfect. It took a lot of work to get it polished just right but I don’t see any flaws with it. It works as well as what MTV has but my version is dynamic and navigable.

The Rapter360 is just plain brilliant work if I may say so myself. I did a pretty good job of using the MVC (Model View Controller) design pattern for this and it has really paid off.

And then there’s the Zune Demo. This is the demo that was used to show off the concepts behind the Zune MP3/video player before it had a name. It started out simple enough as a small part of a PowerPoint presentation and then grew more and more into the centerpiece of the presentation. It was shown off to MTV executives, WarnerBrothers, FOX, and countless others. It was even presented to Bill Gates - he liked it.

This was also the project that required the most teamwork. There were constant requests for additions and modifications coming from all corners of Microsoft. Those requests were filtered by the EXG team manager, Russ Glaser, and then handed to the project manager Jeremy Hutton. Then myself and three graphic artists took on the job of meeting those requests. All the while I was at the center of it making sure everything worked together.

Essentially the presentation is a main page (shown here) that is a gateway to various interactive presentations of the Zune devise and it’s family of hardware and software.

Here is a sample of some of the issues that had to be solved.

• It had to run full screen. The background would stretch to fill the screen which is easy enough. Then comes the issue of centering the presentation on the desktop. Again, not a problem. It just required a little math. But it had to run smoothly at resolutions from 800×600 up to 2500×1600. That took some work. To accomplish something like that we had 4 versions of the interface at various resolutions. The appropriate version was dynamically picked based on the size of the desktop by creating a screenResize listener. It worked flawlessly which was very important because this would be presented in rooms where we had no idea what the hardware would be capable of.
• Some of the presentations were fairly simple timeline based animations. But, they had to run backwards and forwards in case the presenter wanted to back up. You know, Flash doesn’t really run timelines backwards but I found a way to do it and made it simple enough that the other artists working on the project could use it without supervision, freeing me up to work on other things.
• The one presentation that I was responsible for - aside from the integration of everything - was of the the Zune devise itself. The hardest part of this is that it began as something fairly simple but had features added on so many times that it grew into something with dynamic navigation and content. Looking back on it I’m amazed that I was able to extend the simple original demo to serve all those requests and not break down. It was almost a daily activity of looking at some new request and thinking, “How am I going to get this to work with everything else?” I always came up with something.

On more than one occasion someone from the marketing team would drop by and tell me that they received compliments on the demo itself from some executive and they wondered if they could get the name of the company that did it. I’m sure they were surprised to discover that it was done in-house.

In the end I’d have to say that while it wasn’t my favorite project to work on it is what I’m most proud of because there was a lot riding on it and I managed to incorporate every single request that got to me, on time. And it worked flawlessly which is what you want when you’re showing off a demo in front of Bill Gates.

The Captain is the Zune.net homepage hero that rotates between 3 adds. It uses the same basic approach as all the other RMIs I’ve done for Xbox.com and Zune.net. That would be using my XO class to load and parse the XML, the main class that manages the loading/positioning of all the external files and the user interactions with the app.

The only real difference between the Social RMI and the Captain is that the Social doesn’t use an OOP approach. That’s because one of my co-workers is entering the world of Actionscript so I helped him create it with the tools that he understands. We still used my XO class for the loading and parsing of the XML. After that he wrote functions on a frame to do the work necessary work of managing the positioning and interactions of the external files. He had never before created an RMI type application so this was a good introduction to a Flash app that doesn’t rely the on timeline.

The video navigator for the Xbox.com homepage is quite similar to the Lenzer RIA on Zune.net. They both have horizontal scrolling and a reflection. Since I did the Lenzer first that made everything much easier for this app. I wrote a class for doing the reflection so that was already done. I also have a class that makes using the movieClipLoader much easier.

There are only two things that are unique here. The easing of the horizontal scrolling had to be just right. The designer had something very specific in mind for the movement. So the code for sliding gets it parameters from the XML so we could tweak the motion just to his liking.

The only tricky part was getting the images to wrap around as they scroll. If you play with this app you’ll notice that there are three groups of four images. If you keep scrolling in one direction you’ll cycle back through the groups. There’s a pretty simple solution for keeping things in order so this turned out to be a pretty straight forward project that only took about 10 hours to finish.

(first published as a comment at Anne 2.0: Towards Hybrid Ajax/Flash/Java Browser Apps)

When people talk about the future success of Ajax and Flash they take it from the developer’s POV and ask questions like: is it open source, need a plugin, etc. Those questions will have very little to do with the success of either platform. It’s always about the bottom line and that’s cost of development and support.

If the ACME company wants a RMA then they probably don’t know the difference between a socket and a vector shape. They take their idea to a few different design/development firms and say, “how much and when?”

I don’t do Ajax development so I can’t say how long it might take to develop in that environment but I find it hard to imagine that it’s going to be faster than developing with Flex/Flash (Flesh). And even if they can both be developed in the same time for the same cost then there is still the question of support. From an Ajax standpoint there is always the consideration that code will have to be tweaked when new browsers are released. That won’t happen with Flesh.

So I can’t see many design houses that are married to the Flesh approach deciding to add Ajax to their skill set but I can see the Ajax crew developing some Flesh skills. It will start with video and then spill over more and more into just developing as much as possible in Flesh.

The team that does the MTV website certainly knows their stuff. So I was excited about the challenge when I was asked to recreate an RIA (Rich Internet Application) that they had on the MTV homepage. (open example)

But I had to go one step further. Where MTVs held 5 images I had to create the same functionality to hold an arbitrary number of images.

Oh, but wait, there’s more. I also needed to build in navigation. We needed to be able to scroll horizontally between groups. Of course the last group may not have enough images to fill the space - no problem.

And while we’re at it let’s build in tabbed navigation. Of course the data is all XML so we can change the images, groups, sizes, number of tabs, everything without opening up the Flash file. Here’s an example of the final product.

The Lenzer can currently be seen on the Zune.net homepage and also in the Marketplace homepage of the Zune software. Later on it’s going to be used in other places but I can’t say which since it isn’t public yet.

While the Lenzer doesn’t look that complex at first glance there’s really a lot going on here.

How it moves : Here’s a quick breakdown of how the images change size. There is a setInterval running at all times. I know that it isn’t a great idea to leave intervals running that when they aren’t doing anything but this is the only interval in the RMA so it doesn’t drain the system resources much. The first line of code in the interval is a check to see if the mouse is over any of the images. If so then enlarge the image that the mouse is over. Now run through all the visible images (images that are off screen have their visibility set to false and are not checked for changes.) and see how many are larger than the rest size. Get their combined width. That’s how much room is left for the other images. Take the remaining space and divide it by the number of images that are not larger than the rest size. Now resize them and finally position all the images across the screen. That’s the simplified version.

If the mouse is not over an image then check to see if any are larger than the rest size - this is where the images are set back to their rest size when the mouse is not over any images. Make the large images a little smaller, check to see how much room is left over. Make the small images a little bigger and then position them all. That’s the gist of it.

XML : Since all the data for the RIA - from the image URLs, to how fast the images slide during group changes - is in XML I needed to do some heavy duty parsing. Fortunately I wrote a class called XO (XmlObject) to do just that way before this project. I use it for every XML driven project I work on, and that’s a lot. It’s pretty tight code but it has a few issues here and there. As much as I like it I can’t wait to start using the new E4X parser for AS3.

DrawingAPI : The DrawingAPI was used to create the gradient that is then used as a gradient mask for the reflected image.

BitMapSmoothing : Since these images are being scaled from their original sizes they look a little chunky. It’s just the rendering of the images by the FlashPlayer at non-native sizes. This is fixable in the authoring environment but there’s nothing that can be done about it at runtime. That is until the 8.5 FlashPlayer came out. That’s when they added support for bitmap smoothing. You can get to it via the bitMapData class.

One of the great things about the Xbox360 is that it can be upgraded. Since it’s launch in late 2005 there have been numerous upgrades to the dashboard. (The dashboard is the interface for the console where you download games, play movies, manage your gamerTag, etc.)

Before anything is changed or added to the Xbox dashboard we build prototypes to use in user testing. That’s where I come in. I have created a Flash based version of the dashboard that has all the functionality of the Xbox - maybe even a little bit more. Most importantly the prototype is all XML driven.

Obviously this work has to be kept behind closed doors so I can’t produce an example. Instead I’ll give a brief description of the functionality:

• History: if you have used the 360 dashboard before then you probably know that it remembers where you are from screen to screen. This is like building a Flash website that remembers where you have been from page-to-page and reproduces the scene as you left it.
• No mouse: don’t forget that the 360 doesn’t work with a mouse. You use the controller to move around on the screen. All input is captured with a Key listener. This is where the 360 prototype differs the most from a typical Flash application. Typically when the user interacts with the interface that changes a state in the data. Here it’s just the reverse. The user interacts directly with the state data and then when that changes the user interface is updated.
• Dynamic navigation: each page has it’s own XML file. The XML is structured much in the same way that an XHTML site using CSS-P would be. Each element on the page is a node in the XML and that node contains information about where it is placed on the page and where the navigation can go.
• Rapter360 stands for RAPid protoTypER260. As long as no new elements are being tested I can create a new demo, or demos, in a matter of 4-6 hours. All without opening the Flash authoring tool.

This RMA for the Xbox.com homepage was originally built to rotate between five heros. (Hero: a big advertisement at the top of the page.) You know what that means: five now but maybe more later. Of course programmatically there is no difference between 5 and 21. It’s all just the length of an array to me. The one caveat I asked for is that the number of heros had to be odd. That’s because only three thumbnails are ever visible and it’s the center one that starts out as the selected one.

All in all this is a fairly straight forward RIA. The biggest lesson I learned on this project was how to create dynamic text fields populated via an XML file that contains international text. They didn’t ask for this until I was pretty much done with the project - don’t you just love it when your just about done and someone asks, “Oh yeah, and we need it to do blah, blah as well.” In this case it was the international text thing. Now it turned out that it only took a few hours of research to get everything set up and I had it displaying Chinese, Hebrew, Russian, even Sanskrit - no joke, the Xbox is a big hit in Sanskitland. :-)

Now as a rule I look at what the UX team and designers ask for and then try to anticipate what they might think of later. The first rule that I’ve learned is: declare every conceivable variable in the XML. (My XO class types variables declared in XML which is very nice.) I even use settings in the XML to position things that are loaded at runtime. It’s really nice when some designer emails and says, “hey, can you move the what’cha’ma’callit over over 3 pixels” and I respond back with, “change the whatChaMaCallit_x in the node.” I’m not sure if they love me or hate me for doing that for/to them. :-)

That is an instance of the programmers prime directive (PPD): work hard now so that you can be lazy later.

I’ve found that the PPD never really allows me to be lazy later because I’m always busy with the next thing but at least I’m not bogged down in minuscule changes 10 times a day.

I also learned that the Flash authoring tool always uses GET with the getURL method no matter if you set it to POST. That set me and the production team back a spell before we figured out what was what.

For the launch of the Zune.net website we needed a photo viewer and video player combination that I call the ZMP. I I whipped this little thing together in about a weeks time. There are instances of the ZMP all over Zune.net. They are changing all the time so I can’t link directly to one.

This, like most every RIA I produce, has one empty keyframe. On that keyframe is a bit of code that loads the XML - using my XO class - and when converted to an object then calls the appropriate class that calls other classes and loads external images or whatever and eventually builds an application. But, the FLA has a timeline with nothing but a small bit of code.

The ZMP uses the DrawingAPI to create the panels that you see in the interface. It would have been simple to create MovieClips in the library that could be attached at runtime. The problem with that is that they wanted to be able to theme the ZMP differently for each artist. By using the DrawingAPI I can keep all the colors, thicknesses, alpha settings, etc., in the XML where it can be easily edited by the production crew and artists. I don’t have to be involved with it at all.

One thing that I discovered during this process is that the DrawingAPI centers strokes over the position where they are drawn. (read more about that here.) Once I had that down it was simple to draw the interface in pixel perfect positions.