The Flash prototypes have been made in CS3 using ActionScript 2.0. Most parts are vectorial, but the maps are jpgs. The animations are made mainly by tweening. Event listeners are the most important part of the system: they allow one to catch an event to control the interface behaviour in different situations.
Fot the code we used a graphical approach to ActionScript 2.0, taking maximum advantage of the wysiwyg interface.
All the events in the timeline are managed using control variables located in the root (main scene) timeline. To read and write variables in the main timeline, from any location inside the animation the “_root.” address string must be used before the variable name.
Once all the control variables are set, each event starts in a particular condition and in the process updates the variable values.
With this method is easy to track the state of every interface component (visible/invisible, selected/unselected ad so on) using simple listeners that check every frame if a value has changed.
Event listeners are commonly used in programming and are parts of the code that listen – or wait – for an event – or condition – to occur before starting an action.
Since an event listener it’s basically a repeated check in time for something to happen, can be made in Flash simply by placing the check code inside a movieclip and let it loop.
A timeline based event listener is just a 2 frames animation with a small simbol in the frist frame (for an easyer selection and also for distinction) and the check code in the second frame. Inside a 30 fps animation the check occours 15 times per second, altough, if necessary, the check can be copied also in the frist frame to be made every frame (30 times per second). The main advantage of this approach is that we can create as many listeners as we need, identified by a shape and a color, and put them into the library to be used, just as any other object, dragging them into the scene frames where we want them to exist. Also, as these listeners are just like movieclips, they are stored in the library as objects, therefore once I modify the reference object in the library, all the related istances will be changed at the same time (just as happens when we change a function that is called a lot of times in the code: once we change the function, all it’s calls will be affected by the changes).
In the prototypes we used a lot of event listeners. For example we put one on the lateral sliders and one on the “magellan” badge on the top so they can slide in and out according to the state of the “work” menu (open/closed). The “work” menu, when opened, sets the state variable “sliders” to zero. When this happens, the listeners read the change and move the timeline of the sliders to the “slide out” animation frame. In the same way, once the “work” menu is closed, “sliders” is set back to 1, and, according to this, the listeners move the sliders timeline to the “slide in” animation frame.
This technique may be complicated to explain but very easy to implement, and is quite effective, as allows the designer to treat pieces of code as objects visible in the scene, that can be copied, cutted and pasted graphically. With this kind of listeners any kind of event can be synchronized to any other in the animation and there’s no limitation on the level of complexity this system can handle, as the designer is aided by a graphical approach to the code implementation.
Magellan | Concept | Design | Process | Flash | Processing | Teamwork | Reflections | Downloads