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.

If you are interested in learning more about Flash Lite or just want to meet some of the folks from Adobe mobile, come ot tonight’s session of Mobile Monday. It is tonight at 7PM in Mountain View on AOL’s campus (specifically: AOL Building 12, 401 Ellis St., Mountain View, CA). Write a comment if you plan to be there, I’d love to meet up.

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.

EDIT: The woot for the U10 has ended

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.

I am on a bit of a U10 kick recently after doing a U10 game for my presentation at Flash Forward. Craig Babcock wrote a comment on my previous entry and as I started to rant I thought it would be better to respond as a post rather than a comment. The U10 breaks every notion of key events that I have had and manages to be internally inconsistent with itself.

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 my previous post I talked about how to make the background of your U10 a Flash movie, so I thought I would post the source for my first background, a random generating background. It looks fairly plain on the desktop, but when you add in all of the menu items from the device, it looks a little more interesting.

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.