Integrating Flash

Every once in a while you might say to yourself, "Why haven't I thought of this before?" I said this to myself last night, driving home late after struggling with the very same type of flash integration issue that I have seen time and time again here in our own development team. A little well-designed flash can make a very nice visual impact on a web site. [Notice I said "a little" flash. I've yet to encounter a full bore flash-based web site that could compete in usability with a well-done HTML or "hybrid" site... one that did not make me feel hostage to the medium.] But these production-time issues have surfaced repeatedly, making it so easy for me to curse the medium when, in fact, the problems we encounter are far more a result of our approach than the medium itself. Oh, if only there were a way to recover the wasted hours, those spent trying to guess what's going on inside the "black box" of a .swf file. That said, I came up with a new practice for the team which I believe will, at least, avoid costly late-night troubleshooting sessions in the future. Through spending slightly more time up front on our flash pods, we'll provide ourselves with a much-needed window into the guts of the .swf file, giving the integrator a clue as to what's going on inside. A common scenario is the deployment of a .swf file that uses a web service to retrieve a "gallery" of images; more accurately, a list of files that the pod will use to create an attractive dissolve-in/dissolve-out type of image viewer. Rather than hard code a path to the web service, the flash developer typically relies on the integrator to pass a flash var with the appropriate information. Other flash vars may include the display time (seconds) for each photo, the speed of dissolution, etc. But how many times have we attempted to deploy a new pod, passing what we believe to be the correct parameters to the flash, only to face unexpected results... perhaps a blank, lifeless pod on our page!! Did we incorrectly name the flash var? Is the path somehow be interpreted in an unexpected fashion? Solution? From now on, we'll incorporate a debug window in our flash pods. This window -- an integral part of each pod -- lists the names of each flash var expected by the pod, and also shows the values currently being set. The window could be made visible by default (being made invisible by yet another flash var) or perhaps through some discreet mouse action. This information would be invaluable for identifying the source of a given problem -- whether the trouble lies with an oversight on the part of the integrator, or with the pod's developer. One more thing we'll do better from now on: Error handling within the flash pod. If the pod encounters an unexpected response -- or fails to encounter something expected -- it will report this in the debug window rather than just "freeze". This feedback will be well worth the extra time it might take (probably minimal, generally speaking) to build in such error handling. If your team has solutions to similar problems, please share. In the meantime, happy coding.