About a month ago Nascar.com contacted me to create a flash video/image slideshow for their homepage that was loosely based on a previous module I wrote for CNN’s video page. The module presented some interesting technical challenges, which I will try to discuss to give you a little better understanding.

TECHNICAL FEATURES

file size is 11kb

different browser based session behavior (leaving a page, coming back, closing a browser, coming back)

sound is controllable from javascript

sound muting fires an even that can be handled by javascript

swf itself is degradeable for various Flash versions (different
behavior for 6&7 players)

architecture allows for new asset types other than image & video

asset display order is configurable via xml

amount of times an asset is displayed is configurable via xml

initial sound volume is configurable via xml

initial sound on/off is configurable via xml

fade duration is configurable via xml

ability to pause on any an asset configurable via xml

Launch Project

Browser session based behavior
The content team at Nascar wanted the module to have variant behavior based on whether you had seen it or not during the current browser session. They wanted the module to play from the start of the sequence if the page was being viewed for the first time, and pause on the last instance of the sequence, if the page had been viewed in the current browser session. This required the swf to know about it’s state in context of the browser’s session state. The browser’s session state can be defined as the lifetime of a browser instance, or loosely as how long you have a browser open. When you close a browser and have no instances running the browser’s state has ended. Since a swf has no internal way of knowing whether it was created previously by a page back or page refresh in the same browser, or whether it is an initial creation by a fresh browser instance, it has to be given this information by the browser. In order to do this, I created a browser based session cookie after writing the embed code of the module. A boolean representing the existence of this cookie was passed into the module on embed, denoting whether the module had already created during the current session. Thus, for the initial embed the boolean would be false and every subsequent embed it would be true until the browser was closed. This allowed me to provide the behavior that the content team wanted.

External toggable sound feature
Nascar is an html driven site which can include multiple independent rich media pieces in a single page or session. These multiple pieces may conflict and create unwanted user experiences, if there isn’t some “glue” provided to allow them to function as a greater whole. The slideshow module contained audio, which could potentially be playing while another rich media’s audio was on. Therefore, it was important to provide the module with “glue”, to make it’s audio controllable externally and to notify other elements when it’s audio was unmuted. These rich media experiences could be other swfs, video players, etc. In addition, these audio experiences could be triggered by the internal actions of the other module (ex. clicking play in another swf), or external actions of the page itself (by clicking an html link that launches a pop up with a windows media player). With this type of interaction requirement, a javascript interface for controlling and receiving audio events was the logical choice to provide the “glue” to communicate between variant technologies. This communication layer took the form of a setSoundEnabled method in javascript to toggle the sound on and on off in the swf, and a internal call to an external javascript function everytime the sound was unmuted. The external call to javascript when unmuted served as an event, whose handle could be defined by the html page. Whenever another multimedia element on the page wanted to play sound, it could mute the module’s sound via the javascript “glue”, and vice versa be muted by the module’s unmuted event.

Degradable versions of SWF module
Since Nascar.com is such a highly trafficed site, they want to be as accessible as possible to their user base. Having a Flash 7 specific module on the homepage would limit their demographic, and limit the experience of users without that plugin. Thus, there needed to be some sort of degradeable experience for users who had not received the Flash 7 plugin. In the case of the module, the only thing that really required it to be version 7 was the progressive flash video. As a degraded experience, each video that was in the sequence also had an associated image with it, which could be used in it’s place in the slideshow. This made degrading the experience from 7 to 6 a matter of showing an image instead of a video. I was able to accomplish this by using an internal check in the swf’s code against the user’s plugin version and displaying the asset accordingly. This internal check was two lines of code and allowed me to reuse the same swf for both 7 and 6 versions.

Synchronous Development
From a development standpoint, the module is merely a content shell, which is setup completely by a dynamic xml feed describing configuration settings and assets. During requirements, I defined an xml schema based on the configuration requirements given to me by the Nascar content team. Once the schema was defined and agreed upon, their technical team was able to work in a synchronous development cycle with me. As I created the shell’s implementation logic, they were able to automate the generation of the actual xml and its associated assets from their CMS. Since I was using a sample xml file and assets, the module was plug and play when it went to production.

Hopefully this shed some light on some issues that I faced, how I handled them, and how you could address them if ever faced with the same situations.