To follow up on my previous post about defining core libraries with FDT, I have found it better to add individual linked libraries on a project basis that changing the existing core lib to include multiple libs. Part of the reasoning here is that if you have a ton of projects with Flash Nature assigned to them, when you reassign the core lib, all of the projects have to rebind/rebuild based on the new lib. Eclipse is not a happy camper with this and will eventually choke up on you. By assigning linked libs on a per project basis, the bind only happens for that project at that time. AKA, your machine does it freeze and wave its digital fist at you.

To add a linked library for a project
1. Right click the project in the Explorer pane of Eclipse
2. Click the FDT Source Folder
3. Click Add Linked Libraries
4. Add away and get a sandwich from Healthy CA

One of the developers over at Vimeo emailed me asking how to use the Express Install option with the Flash player if they were using AS3. For those unaware of the Express Install option, it is the capability of the Flash player to update to a new Flash player version inline on a webpage vs downloading and installing it. After looking at the question, I realized there may be some confusion around this topic, since most people implement it but regard it’s implementation as voodoo magic. So I felt like I would answer the question and debunk the voodoo a little.

What are the Guts of Express Install?
First, how does Express Install work? It’s pretty basic and not something a NASA engineer needs to look at. Essentially you are loading in a SWF from Adobe that then does all the work and tells you it’s status. Your host swf needs to be at least 215 x 138 pixels and the option only works in players 6r65 and above. The SWF you are loading is located at

http://fpdownload.macromedia.com/pub/flashplayer/update/current/swf/autoUpdater.swf

This SWF is considered loaded when it’s startUpdate function is defined. At that point, you can define MMplayerType, MMdoctitle, and redirectURL on it and call it’s startUpdate function, and it will begin it’s process. During this process it will report back to a function installStatus that you define on your root (with the following codes “Download.Complete”, “Download.Cancelled”, and “Download.Failed”).

What are the options with Express Install?
Now you can handle this one of two ways, implementing the logic to do the update in your own application or use an updater swf that is a proxy or prerequisite for your application swf (when needed). If you were to go with the first option, you are baking the code to do the update in your application. AKA, bad choice because isn’t that the whole point? Your application is using a version of the player that you need to update to. In previous AS1/AS2 cases the code is fine and could still run, but it’s somewhat defeating the purpose. However, in the case of AS3, no chance to collect cash and get out of jail, you are stuck.

The proper Express Install
The proper way to do this is option 2, using a SWF whose sole purpose is to do the update. Luckily, about 99% of the web is using SWFObject (whether 1.* or 2) and this is built in for your comfort and joy. With both implementations (which use Javascript to embed a SWF), you just define your Express Install SWF and you are good to go. In addition, you are given the source of the SWF to manipulate if you are feeling fancy. What SWFObject then does is run through a series of steps based on the version of player you have installed.

1. Runs a JS detect to see if you have the version needed.
Yes, it writes out the content SWF.
No, is there an Express SWF and the player is above 6r65
No, write out Alternative content

2. Yes, embed Express SWF, which then runs through it’s process
Express SWF is successful, it calls back to the JS

3. JS writes out the content SWF

Summary
Ok, so all that said, let’s summarize. Key point, SWFObject does everything you need to do. If you want to implement it yourself, just implement the same logic that SWFObject uses. SWFObject uses a separate SWF which is published as AS2 and can be used in previous players. You don’t embed any Express Install logic in your app and just let the installer SWF handle the magic for you. It has the logic which can step into your content once it is done. Hope this help with anyone that may be confused by this process.

A few days of work, delivered 5 months ago, a lot of waiting , and the delegate tracker I did for CNN has finally seen the light of day

Democrate Delegates
Republican Delegates

The module allows you to view a graphical representation of the delegate “race” between candidates for either party. I’m pretty big on usability and information display, and I think it was a little tricky from an informational standpoint, since the way delegates are gained, lost, and solidified over time. In order to make it clear to the user, only the delegates that were considered solid were used as plot points. The “unsure” delegates are listed in the mouse overs. So overall I think the information is decently portrayed.

In retrospect, one criticism I have is the iconography used. All of the candidates are represented by their parties mascot (donkey or elephant). This doesn’t make sense unless you are comparing 2 entities of different parties. A better icon for the graph would have been an image of the candidate, since they are the entity that is physically in the race. Another criticism is the actual style guide of interface elements (up, over, disabled states). Needless to say, the designer working on the project had an issue with it too. A lot of the elements look disabled when they are selected, enabled when disabled, etc. All that said, I think the module turned out great, but I think the taste is sometimes when all the details match up.

One thing we did do to jazz up the module with a bit of flair was to add the ability to scale the graph and animating the icons from point to point. Like with design, it’s sometimes the little things that make and application more pleasurable and fun to use.

Check it out, let me know what you think, and remember to pay attention to the details on your projects, it all adds up.

Watch the Demo

At NAB (national association of broadcasters) this week, Akamai and NBA.com are showing off a live video app that Dreamsocket developed for the Final Four. The application they are showing is basic, a video mosaic that allows you switch camera feeds during the live event by clicking sections of the mosaic or buttons. I developed that app in a blink, but what I’d really like to show is the prototype. The prototype actually used a single mosaic feed, which it spliced and then blitted to the screen.

So what do I mean by blitting video? For those not familiar with the concept, instead of letting the video just “show” on the screen, you actually capture the video and cut sections of it and then render them where and how you want them. In the case of the NBA mosaic, the mosaic video was a single video that had 4 different views in it. The broadcaster combined all 4 into the same picture and broadcast that video (you see this in the news sometimes). When I received the video, before I “showed” it, I cut it up and then placed it into pieces I wanted. What this allowed me to do is have the mosaic be 4 interactive elements that the user could zoom in and out of them in real time. Since I could have as many duplicates of the video parts that I wanted, I was able to use each video section in the actual buttons as well. This gave real time views of each section.

So technically and visually, the concept is pretty cool. However, it is interesting that it has some actual benefits as well. You can’t achieve the interactivity another way without opening all 4 feeds at once, which is expensive on the server, the bandwidth, and client machine (aka not feasible). By opening a single feed, you are consuming only the bandwidth for one stream, you are never hit with the delay of switching a stream, your feeds are never out of sync, and you have full control over manipulating the entire mosaic.

Are there downfalls? Yes, there are. For one, this is only possible with video whose rights you have to script. In the case of using FMS, you need FMS3 and the server must allow you to capture the video’s pixels in it’s application script (p_client.videoSampleAccess = “/”;) or via it’s configuration. The other downfall is that because you have 4 videos in one, each individual video’s quality is a lower because your are zooming a smaller space.

All that said, this is an interesting concept that has a lot of different ways you could take it. Love to hear people’s thoughts and ideas.

Finally making use of Twitter. Catch my random thoughts there.