Yahoo! Messenger just released a new beta this week with a plugin SDK so that you can customize messenger and build your own single or multi-user application. Messenger plugins are based on HTML, so you can write them just like a regular web page. Since we all know the best sites are built in Flash, I fully expect the best plugins to go the same direction.

Once you get the beta, you will find two places for plugins. The first is the tab area of your friends list. For any Flash Lite developers, I think this should be an interesting area. The space your get for a tab is not too far off from the screen real estate for a Flash Lite app. While we are waiting for the OEMs to deploy the Flash Lite player, Messenger should be a good area to showcase your content.

You can also add plugins to your IM window. If you are a game developer, this is an ideal way to get to work with multiplayer concepts, and actually get your game played by a network of millions of users. Messenger gives you a LOT of hooks to pass data, do permissioning, and otherwise deeply integrate into the Messenger experience. Even if you aren’t into games, there are a lot opportunities for creating multi user and collaborative applications.

Since I first heard about the feature I’ve been biting my tongue from wanting to tell all the Flash developers I know about this.

Now, for the really cool part: let’s talk Flash versions. Use filters, blend modes, the external Interface; they will always be available. The Y! Messenger install process is now installing the latest version of Flash for those that don’t have it. Now it is up to you to get all of your friends on Yahoo! to show them your cool plugins and help Flash Player penetration at the same time.

It does seem to be the evening for Flash Lite though. The Boston Mobile Monday group is talking about Flash Lite as well. Apparently once we get folks (the cats) shipped off to CTIA, the Flash Lite mice can play.

For those of you that want to work with Flash Lite 1.1, but don’t want to get a new phone, the Iriver U10 is a great device to get. You can upload your own content, or start hacking the main UI which is also done in Flash Lite 1.1.

Normally the U10 512MB is $200. Woot.com has it for $99! I’ve bought several things from them and all the transactions have gone well. The only trick is to buy one before they sell out. good luck! it is a fun device.

All I can say is wow. Getting into Flash Lite seems to have been a good PR move for me.

Adobe recently launched Stories, a video series letting several developers and designers tell the story of one of their projects. I was thrilled to be included in the project and was more than a bit amazed when I heard who else is in the stories.

This has my work being shown on the front pages of Adobe and Macromedia, the Engage with Flash microsite, and now Stories.

My story is about Flash Lite development and building my NYC Traffic Cam viewer. The whole experience of participating in the video was a blast. The shot of me in front of the traffic signs is at a building that houses all of San Francisco’s (just mentally pretend it is NYC!) street and traffic signs. That was just a fun warehouse to poke around in. After the many takes there where the director was pretty much begging me to demonstrate more emotion (no future in acting for me–I guess I will stick to letting flash be expressive instead), we headed on to the taxi cab.

For the rest of the evening we drove around the city continuing the interview. When I saw “we,” I mean the director, sound person, and driver/video coordinator. Oh yeah, and the three HD cameras and lights mounted in the car. We were a little crowded in there, but we spent a lot of the time just trying not to crack up as every time I got a good take the check engine light would start making noise.

After a while the crew changed the cameras and mounted one on the outside of the car. That was when the real fun began. Try driving around a city on a Friday night with people, lights and cameras packed into a taxicab plus a rig on the outside. You will get some attention. Then gaze out the window as “the world passes by,” but in reality people are making all sorts of faces at you.

All in all, I think it was about 10 hours of filming, and lots of patience on the part of the crew. I’m sure they all had better things to be doing that night.

A few weeks later, I went to visit Scott, one of my friends up in Yahoo!’s San Francisco office. We went to lunch at a nearby soup place only to discover that there was a video shoot going on there of a bike messenger driving around. I thought I recognized the cameraman, but didn’t think any more of it. Now with the Engage with Flash project, I realized that the second segment with the bike messenger, was actually that video shoot! If you click “learn how” on the bike messenger segment, there it is again… my NYC Traffic Cam viewer and a different video taken about a year ago.

In Flash 4 player world, you don’t have Key.isDown to poll a key position to do smooth interactions. Instead you rely heavily on the accessibility feature of key repetition. You hold down a key and it fires once, pauses, and then fires repeatedly and rapidly. It doesn’t make for the best experience, but with some ingenuity, you can make pretty fluid movement.

On the U1o, when you add your SWF to the device, you quickly find that the key never fires. Since we are using an accessibility feature, I wasn’t all that pissed that key repeat didn’t work for a device like this, even though I was disappointed since this narrows the types of games I can make. What did frustrate me though is that the key repeat does happen on the device UI. In menus, holding down the side of the player (the key) will continuously scroll (and even accelerate and optimize the display) until you let go. In media player and radio settings, there is functionality that relies on your holding down the button for a longer period of time.

Clearly something strange is going on. I have a few guesses of what could be going on (I have no evidence to support any of these ideas):

• FScommand2 – Perhaps there is a custom fscommand2 that can poll the key like Key.isDown. This would be essentially impossible to detect as long as it is only implemented in the protected UI.

• Different Player – The Flash games are running in a separate instance of the Flash player from the UI. You can tell this because you can set the frame rate of your game without it being slaved to a master SWF frame rate. You can also use background color and the _target for your file’s main timeline is just /. You can also tell that the UI player is not destroyed since randomized backgrounds still show their original pattern for a moment before being re-loaded. Since they are separate player instances, it has gotten me wondering if they are separate player versions. The player isn’t huge for a storage device like an MP3 Player. If I wanted to add functionality like the ability to launch the video or other broader actions and didn’t want this functionality exposed to the developer API, having a custom player for the trusted content would certainly be a route I would want to explore. None of the device identification elements seem specific enough to provide useful information on this theory.

• on() event shenanigans – I have the most negative evidence for this one. I thought that they might have mapped another key on the keyboard for for the purpose of a keyUp action so I created a button that maps every key that I could think of that was mappable in Flash 4. None returned anything unexpected. The only other things I can think of is a custom event like a keyUp (though that precise name didn’t seem to work) or there is a key that I am not thinking of to listen for.

Since I am pretty well thwarted I only have one possible test left. Some of my experiments with the UI have ended up screwing up the buttons. If I can find where they sit and unload the parent of the buttons, any buttons I add in my custom SWFs should start firing.

IMPORTANT NOTE: If you decide to give this a try, put your actions in something like a thumbnail file, NOT the background. If you screw up your UI in a thumbnail, you can restart the device and go back to the main menu. If you screw up your background, you could make it very challenging to get the device able to sync to your computer to overwrite the bad SWF. Since the device uses Flash buttons to give permission to the Power & Data selector, you need this to remain functional. Luckily, the power button seems to be a device control, not a Flash UI control, so you shouldn’t be able to break that.

In addition to adding the circle elements, I am altering the alpha level of the non-highlighted elements of the menu. To make the menu work with any background color, the text elements are set at about 30% opacity. The Flash background I’ve been working on is a bit bold color-wise and the menu items are getting lost. By bumping the _alpha of /all/currentMenu up to 300%, you can make the text opaque.

Prior to doing a little more introspection I had previously been changing the alpha of the root, but that affects other UI elements like the translucent black overlay for system notifications like volume adjustments and connectivity. By more narrowly targeting the alpha setting, I can boost just menu text and arrows.

Another interesting thing that you can see when you start doing dynamic backgrounds is that the SWF is reloaded several times. If the backlight turns off, the background will redraw when the light comes back on. The same holds for when you change from portrait to landscape or launch and exit a game. The strange thing is that right before it redraws, you still see the old state. It isn’t that the background was ever unloaded; it was just reloaded.

Making games for the U10 is fun, but I also want to be able to customize the Flash Lite UI that runs the rest of the device. I’ve gotten pretty far, so I thought I’d share what I learned in hopes that others are looking into this and can share what they have learned.

The Problem
The Iriver does a really good job of protecting its UI SWF. When you hook the device up to your computer you can see some directories, but there must be some that are simply not exposed. There are two main directories on the device, media which holds the DRM audio/video and can’t be modified except through Windows media player. The other directory is Data that can be modified as you wish.

The Vulnerable Spot
When I got my U10, one of the first features that made me raise an eyebrow was picture viewing. You use a tool to transfer JPGs from your desktop to the device where they can magically be loaded. The thing is that as I have really good cause to know from my traffic cam viewer and Flickr tool, Flash Lite 1.1 can’t load JPGs. Looking at the files on the device (/data/system/pictures/) The files are .JFU and .JTH, which I assume stand for “JPG Full” and “JPG Thumbnail.”

If you transfer any of these files to your desktop and change the file extension to .SWF, the Flash Player can run the file. The image viewer works in a very similar way to my traffic cam viewer. Instead of loading a JPG, it relies on an external solution to wrap the JPG as a SWF. This isn’t a server solution like mine though. The transfer tool does the conversion as part of the transfer process.

Knowing that, it is pretty easy to make your own Flash Lite 1.1 files and start loading Flash files into the UI. The easiest way I’ve found is to export your file and take a screen shot and save it as a JPG. Move that file over using the transfer tool to make the placeholder (and thumbnail file), then replace the JFU with your SWF remembering to alter the file extension. When you disconnect your U10 and it re-boots, go to Settings>Extra>Background>Pictures>(your image directory) and select the thumbnail for your SWF.

Introspecting the UI
With a Flash background you can do some pretty cool design things, but not a whole lot technically. To do more, it is a matter of finding out more about the Flash file that loaded the background. In Flash 5 and higher, there are a lot of tools that let you introspect into a parent SWF that another is loaded into. With for...in you can find everything you could ever need to know.

Back in the reality of Flash Lite 1.1, we have a much more limited set of tools. The best tool in our small arsenal is _target. For the background it is /bgImg/photo/photoDown. It doesn’t get us as far as I’d like since you can’t find out what else is in each of the timelines. Luckily there are other places that the images appears. Some of these other locations are a bit more revealing.

  Full SWF as the Background:
    /bgImg/photo/photoDown

  Thumb SWF in the Background Selector:
    UI in landscape:
    /all/currentMenu/setupPhotoList/listBox/list2/photo
    UI in portrait:
    /all/currentMenu/setupPhotoList/listBox/list3/photo

  Full SWF viewed in the Photo Viewer:
      /all/nextMenu/photo/photo/photoDown

  Thumb SWF in the Photo Selector menu:
    UI in landscape:
    /all/currentMenu/PhotoList/listBox/list2/photo
    UI in portrait:
    /all/currentMenu/PhotoList/listBox/list3/photo

Also using _currentframe and _totalframes can reveal a little, but I haven’t had much chance to play with sending the various movie clips to different frames. The root does have 70 frames though, so there could be some interesting things there.

I’ve been spending my time exploring the other timelines, specifically the menu timelines. Strangely, every time I try to modify /all‘s properties, it really screws things up. I have no idea how, but setting the _y of the movie clip, often makes the buttons non-functional and can even shift the UI into portrait mode. No clue why. There are however some elements off-stage if you want to take a look.

Just be careful, you can seriously screw up your ability to interact with the device. If you mess things up you can still generally connect up to your PC and replace your malfunctioning file. When it asks you whether to do power only or power and data, you may have to try a variety of buttons. If you get seriously screwed up, you can always download the firmware update tool from iRiver and reformat the device (eep!).

Thanks to everyone that attended. I was really pleasantly surprised by the turnout. There were also some really good questions after the session. If you would like to see the PPT file and the related Flash files, please download the source here.

The major points of the session focused on one of two topics. The first part of the presentation was focused on what designers can do to optimize Flash Lite 1.1 performance. I used a couple of my old files like Pellet Pop and Aces High plus a maze game I made for the iRiver U10 to demonstrate some of the design techniques:

• Smoothly animate small elements the eye is focused on and roughly animate (or not at all) large elements. This gives user the perception of smooth moving content without the hit to performance.
• Use simple animations (scripted or tweened) to cover over processor intensive task. If you need to run a harsh loop over several items, animate a transition and run the the loop as a frame loop rather than a while loop. The example of this was using an explosion animation in Pellet Pop. The trig for digging out each column of a dynamically created terrain that has been exploded is run at one column per frame during each from of the explosion animation. The cumulative effect of the script is applied visually when the animation is finished.
• Consider whether to use vectors or bitmaps in your application. Scaling and rotation really require vectors, but otherwise you should use bitmaps for the performance benefits.
• Interaction differences in the devices make all the difference. Target specific devices, or classes of devices with your SWF. Flash does a great job of staying functional anywhere, but with varying screen sizes and pixel density, not to mention interaction patterns, each device is pretty unique. By tying your layout to variables that can easily be changed, it is pretty easy to create a base file then make some documented design changes to target a new device. I showed how by changing two variables, the stage size and one button event handler I was able to make a specific port of my U10 game for my Nokia that is consistent with the Nokia interactions.

From there I moved on to Flash Lite 2.0 to show how much better life is about to get. My original maze game was coded for Flash 6, and with only changing the stage size I was able to run the original game on my phone with only a very slight loss in performance. I also showed how using Flash Lite keeps you from having to implement server solutions for XML and loading JPGs. This ability really makes Flash Lite accessible to people that are purely focused on the client side.

I wrapped up my presentation by talking about how Flash Lite 2.0 is actually moving ahead of the desktop player in certain cases. In Flash Lite 2.0 you can use right to left languages and can support any media type that your phone supports. I showed an example from Adobe on how Flash can composite 3GP video straight into the Flash movie. I desperately wish Flash for the desktop had this capability.

My presentation on mobile design and Flash Lite 2.0 is Tuesday morning at 10:30AM. I hope some of you have a chance to drop in. While I always prepare way too much content for fear of running out with time to go, I do hope this will be an interactive sessions full of questions and feedback.

I’m just putting some finishing touches on my PPT and one of the FLAs, but the session materials will be posted here before the session. The plan is to make the examples show contrasts. I will have the same application running on different devices or in different versions of the player so we can really have a discussion about the many different simultaneously moving targets that is mobile development.

The examples will be a maze game for the U10 in Flash Lite 1.1 that was ported from Flash 7, a couple of games for Flash Lite 1.1 on Nokia devices, and my Flickr application in Flash Lite 1.1 and 2.o.

If you are at the conference and want to meet up, write a comment and hopefully we will see each other there.