This is a brief overview of a project I’ve been working on for an Agency client. This client does a lot of work with interactive applications involving navigation between ‘views’ and ‘frames’ of individual views. Sometimes, the views correspond to geographic maps, although the images are highly artist-stylized (otherwise we could just use Google/ESRI). In some applications, the views might correspond to a floor plan or concert hall. Each new view represents a different snapshot (revealing more detail) of some larger perspective. We loosely use the term ‘map’ to refer to each view, although programmatically, a view is nothing more than an image. Frames of a view correspond to rectangular regions having the same aspect ratio as the main ‘map’ window. Views may have interactive ‘hotspots’, clickable ‘icons’, and animated overlays associated with them in addition to arbitrary framings. If map projection information is available for a view, icons may be geo-coded.
Instead of developing each such application from scratch, the client wanted a class library, Flash ‘template’ and XML data structure to help organize each application into a common structure. This provides numerous benefits in addition to code re-use. Decoupling visual assets from the primary application facilitates easy distribution of design/development workflow among multiple people. Structuring view/frame layout in XML allows non-coders to make simple changes to the application without touching code. The system employs a template .FLA (this agency works only with Flash) and base Document class that encourages commonality among all applications using this ‘map system.’ This makes it very easy for one person to learn the application structure and quickly help on another application without having to deconstruct another person’s code and decipher library assets. The map system employs an internal transition engine that is programmed to an interface, not any specific implementation. This allows transitions to be coded once and then re-used by simply including the transition in the XML and linking it to a view transition by id. Artists may experiment with different view transitions and parameters simply by editing XML. Framing and frame transitions are an interesting exercise in analytic geometry. These are handled internal to the system by a general-purpose zooming engine.
The template .FLA allows a designer to position the ‘map’ application by placing a blank MovieClip on Stage. Since all such applications begin with a common, base template, the clip already resides on Stage for the artist. The widow size is set in XML. The system itself handles internal preloading of the application and all map assets. The lead developer extends the base Document class to override event handlers and add any application-specific logic outside the map. Some of the wiring with regard to hotspots and other interactive elements is handled in XML. Printing is automatically integrated into the system. Either the map or the entire Stage may be printed and print parameters are assigned in XML. Modality is also automatically handled internal to the system and exposed to the application developer via the system API.
Unfortunately, I can’t show the XML or even discuss the code in detail as it’s proprietary, but here are some screen shots shown views/framing, hotspots, and animated overlays.
This application involved a very complex transition between views. Once coded, however, the parameters can be modified in XML and re-used in other map applications simply by including the transition class in the XML and assigning it to a view transition via id. Hotspot interactivity is wired into the main application in XML as each hotspot graphic is associated with a class extending MovieClip inside the system.
This application used only one view with many framings/overlays. Frame transitions are handled internally by the zoom engine. After specifying the framing (rectangle coordinates), the designer sets the transition time in seconds in XML. The application developer initiates the transition from the Document class. A default handler is always overridden to implement app-specific functionality after each transition completes.
Although the term ‘map’ is used to describe the system, the manipulation of views/frames is generic and does not necessarily pertain to geo-coded data. In addition to the numerous coding challenges (including being forced to debug/develop using the Flash IDE), I enjoyed the practical application of analytic geometry in this project. I can only hope that the client is open to extending this system to work with AS only projects in FlashBuilder in the future 🙂
The Algorithmist 