Flash: Fast Prototyping and Sketching UI with FlowControl
While I enjoy the new power of Flash9/AS3.0, one of the things I really dislike about the AS3, is how much extra work to do basic things like setup buttons to do simple timeline control, this is especially hard on designers and animators who don't code. I agree with 5etdemi post 4 years ago, the basics have ironically gotten harder to do.
What wrong with ECMAScript/Actionscript? Well, it is not especially well suited for certain tasks, the worst of which is time-based/timeline-oriented animation and declarative drawing. I mean, it seems pretty ironic that ActionScript is derived from ECMAScript which was primarily oriented at scripting in a text-based environment, HTML and the DOM. Simply put, ActionScript has leaned more and more towards heavy lifting text operations (like RegEx and the new XML implementation) and less towards building programmatically what Flash was originally meant for, animation.
While there are useful utilities like Lee Brimelow's nice event generator utility, I wanted less, as even if being good with actionscript, when you have a few minutes to put together something for (or during!) a client/skype meeting, scripting isn't really an option. Thankfully AS3 has some tricks to help!
( press RIGHT arrow key to advance)
One tennant of Sketch is using the type and instance names to do most the event binding work, largely this is to allow Designers to stay on the timeline, but the same could apply to objects created in actionscript as well. So in the above example there are 2 scenes, and a bunch of empty frames, and a nav control. What's special is the buttons you see are actually just semi-transparent buttons (I call InvisiButtons) that have instance names like 'next', 'prev', (shown in the button names) there is no other script on the timeline for them. That via the FlowControl listening to ADDED event are autowired up to call 'nextFrame()' , 'prevFrame()' etc. These InvisiButtonscould be used as a hotspot over a comped image or basic text and wireframe graphics, allowing low to high fidelity comps to be created.
In this example a ENTER_FRAME event updates the TextField off to the right to show the current scene, frame et, to show where you are.
FlowControl has some other nifty features.
- optional features is the fadein, fadeout effect, with configureable color, so while there is a normal timeline, the fade effect is free and ads a bit of polish IMHO.
- tooltips telling you where the buttons go/do.
- keypress for left/right arrow to go to the next previous frame, escape to goto first frame-useful for slide shows
- XXX_autoBtn. If it sees this pattern that button will generate an XXX event (e.g. sayHi_autoBtn generates a new Event("sayHi"), which anybody is free to listen to.
All these are in the example (as well as all the code for FlowControl) on code.google.
Flow Control can be used 'embedded' as the document level class (or extending from it) or loaded as an external swf, and I'll be demoing that in the future. That latter feature is more targetted to creating highly skinnable games which I'll be covering in future blog posts.
FlashCS3: Tip to speed compilation
Flash CS3 has improved compiling speed over Flash8, however seemingly innocent use fonts can still bring compile times to a halt. with a font like Futura, an missed 'embed All' can turn your compile times to 30-45 seconds, as every compiler requires Flash to copy every character in the entire world...every time. Needless to say 15-30 seconds doesn't seem like much, but if your compiling often, this can reduce
Going through and removing font embedding from every textfield is somewhat tedious. But you can use the MovieExplorer to help drill down, you may even find text fields you've missed. I'm sure somebody has a JSFL to help.
The other tips are when using Flash CS3 and blessed with a timeline, put a temporary script (gotoAndPlay) to skip the intros and tutorials to delve into the heart of the what your working on at any given time. When using Cogs you can do similar things by passing a non-default initial state in the constructor.
Agile vrs Model Driven Design
Here's another vote for where Cogs and the related framwork comes in handy
http://joeberkovitz.com/blog/2007/05/17/software-modelling-soft-focus-or-hard-edges/#more-55
I don’t think of MDA ("Model Driven Architecture") and “agile†methods as necessarily opposed to each other. Modelling, whether it’s UML or some other system, can serve several good (and potentially agile) purposes:
snip..
2. Some models are far simpler than the corresponding structures in the target programming language, in which case code generation from a model may save a lot of needless work. Complex state machines are an example.
This I totally agree with, and Cogs (or any decently written FSM/HSM engine) will allow this from the boardroom to the code room, to testing and most importantly back, even with new teammembers, without huge impedences. It allows the two strategies, plan ahead, or discover along the way to be used in tandem and at different times.
The basics are that modelling if known ahead of time can save huge amounts of work provided the models actually correspond to the problem domain..provided they are known, frequently they aren't precisely and that's where the devils in the details come in. When properly used, they bypass the expensive rediscovery process, rebuilding from first principals, and facilitate communication. Design patterns is all about this, a library of frequent solutions. Cogs and the use of state machine libraries just extends this to the time domain.
Some things are truly novel, but common application behavior like registering and logging in to quitting the service, or all the possible states of a media player have been done a million times or more, some have tricky aspects that one doesn't discover until one is chin deep in the mire, and like the wheel don't really have any benefit from rediscovering..with a chisel how long will it take you to make a wheel that is perfectly round?. State charts are design patterns for behavior over time and they transcend any particular language, and useage be it parsers, game AI, components or web applications. These patterns are a good place to start in the Information Architecture phase, by considering how the application you're developing is different, it can expose the unknown rollercoaster you are about to code for...and reveal states that may be important you didn't even know you needed to know.
While these patterns could be implemented in a number of ways, at a code level, Cogs (and any HSM) and related libraries are just the most compact representation of the problem in code, much as compression of data finds common patterns in a file and compacts them. Less code leads to less issues, faster development, and less bugs to track, and a better idea of where to fit them in.
Back to the architecture phase, excess modelling can be *superevil*, it's an evil of preoptimization in projects, and arrogance on the behalf. Designing optimizations before actual use is known, which frequently requires dramatic rethinking when this is discovered (this is especially true for projects not grounded by user testing in how end users...not the design and tech geeks building the app will actually interact with it). Such ungrounded, it's easy to ask silly questions that seem important and design around imaginary concerns (let's design sunglasses to protect against the evil green sun!), as many projects aren't chess matches with a known winnning position, once released into the wild the game changes to checkers: same board, different strategies and pieces.
This swings back to the advantages of using agile development approaches: test first, design to fit the test, be ameniable to change, iterate lots. Which using Cogs, ActiveFrame, Sketch do as they are based on years in the trenches looking at how and why applications fail to scale, providing a bridge between rapid prototypes to build team consensus (both inhouse and clients) to compelling usable end-user oriented end products. But here, testing first can lead to taking as long as evolution did to get things useable, let alone right. So the solution is somewhere inbetween.
Flow charts and statecharts are good place to start or pause along the way, because being visual language, anybody can participate, from domain experts to designers to tech. in addition, because modelling an application without considering state and behavior over time is pretty fool hardy, kinda like saying your planning a trip that requires a car, anda single tank of gas, but no idea of where your going. Since COGS uses very few words to descibe a state, and it's actions, there is almost a 1 to 1 representation between the diagram (minus layout aspects) and the underlying code and documentation. More detail of course in the code since it reflect the actual path, rather than just the map. But compared to classes based approach with tons of files scattered, it's generally easier to read, and thus pass the torch as needed when projects are handed off.
Introduction to ActiveFrame, Cogs, Chain, Score, Sketch, fXperience
Intro to StateMachines
The good news is if your in team development, you've been diagramming them for years, as flowcharts and bubble diagrams. Bubbles are states, arrows are transitions. This is one of the keys to their usefulness in teams. The diagrams can be understood and modified by anybody, and can represent anything from a users interaction with the whole application, a game's AI, or the graphical transitions in a button rollover. Any Animator who has done keyframes and tweens knows has been unwittingly using states and transitions, but what about developers?
Most any application developer is familiar with OOP, and many design patterns like the State Pattern. Some may have heard of the term finite state machine (FSM) with a possible vague understanding of what one is/does, most are probably not familiar with Hierarchical state machines (HSM), which are especially powerful, especially in experience driven, Flash
and AIR content working with asynchorous network requests, and large media upload/downloads, long timeline, all of which have complicated life cycles with asynchronous call/callback.
I started using them in projects after first learning about them in software from Jonathan Kaye. After using a few different versions in a few different projects, and developing my own, I have been on a quest to spread the word ever since. OOP and SM's foundational aspects. They are orthogonal and complimentary, OOP describes the nouns of the system StateMachines's the behavior over time. An example the cat is meowing, cat is the noun, meowing is the current state, and it will change over time.
Intro to Cogs
Cogs is the AS3 library of statemachines, and common patterns that people can extend/plugin similar to how people reuse design patterns, to avoid reinventing the wheel. Just as in Design patterns, there are fundamental patterns, from simple toggleable button, to synchronized media players.
It's named Cogs first after the tiny teeth that compose gears, that when meshing properly make up engines which power most the mechanical world, and secondly Cognition as the meshing of neurons make up the engines of intelligence. Cogs primary use is increasing the intelligence of components, games, game AI, and applications, by several approaches:
Cogs allows you to ask where you are, where you can go, and automate chains of execution between two states. Often event driven components are black box event generators, identical events broadcast at different times mean completely different things (like NetConnection) this is far from simple.
The FSM and HSM are based on Miro Samek's approach of using functions instead of classes to represent states, this very low level implementation has several advantages, one of the first is being less code to understand and write. It also enables behavioral inheritance, similar to. Cogs is different in several ways from Miro's inspiring work in his book. First all possible transitions are supported instead of just the common ones, and are validated by the unit tests..and the testing framework itself being an FSM and supporting Asynchronous testing easily.
Ongoing I'm working on API's for deep history, serialization/deserialization a graphical visualizer, among other things.
ActiveFrame
Cogs is part/foundation of a larger framework named ActiveFrame. Which strives reduce commmon architectural decays, largely by decoupling.
- A message bus enabling event decoupling,
- Java Spring 'Dependency Injection' for Implementor Interface decoupling,
- plus a decoupling of the UI and controller..which can live in completely different swfs, similar to AS2.0's Object registerClass.
It's reasonably small for all these features, allowing it to be used for components, games, game AI or full blown applications.Sketch
is the visual extension of the Cogs, to deal with the View/UI world (e.g. movieclips/timelines, sprites), common layout, and UI/controller decoupling communication. While Sketch can be used whereever Flash can go, it's strong points are design and script heavy projects, in teams that have strong separations between design and scripting... they don't even have to be working on the same file.
Since it's based on Cogs, it's very easy to prototype and if flow diagrams (state diagrams) are used in the IA and Creative phases, it can act as a common language between design, IA, and engineering, as diagrams can easily be translated to code and back, and reworked easily. It supports what I call "introspectable UI's", in that the statemachine can act as the model, and summarize all the active states supported options to generate an appropriate "where can I go from here" UI.
Chain
is the workflow component, it's coordinates dependent parallel and sequential and nested tasks, with asynchrous call/callbacks, providing status along the way. Some uses for this are preloading assets, playlists, unit testing, easing and tweens, build out and tear down of UI's.
Score
is the the parallel timeline orchestration component, similar to a Orchestral score for coordinating multiple instances with a single virtual playhead. Useful for overlapping events. It's similar to an actionscript version of the Flash IDE timeline.
fXperience
is the visual components library. This is based off Cogs/Sketch, components have a wider lifecycle than those built into Flash and Flex., e.g. a button transitioning in, transitioning to up, transitioning to over etc. They support easy and iteratible skinning, so projects can start out simply as a graphic than graduate to more complicated ones as need requires.
Misc
All are a part of the TroyWorks AS3 code library that is MIT licensed on google (but isn't finished/uploaded yet, API isn't stable) There are many other useful utilities, datastructures and components of interest I'll be covering in more detail as they get more fully flushed out and converted to AS3 from AS2, I'm trying to make sure I don't add something already in AS3, and take full advantage of AS3's architecture.