This page is still in progress. Please email [troy ta troyworks tod com] to be notified when the library is available. We are currently working on persistance, documentation, and examples.
Cogs is a core part of the MIT licensed open source framework for developing interactives: from small components, games or large scale applications and frameworks. It's design allows fast creation of interactive mockups that can be used to fully explore and validate the design prior to creative or technical concerns. This architecture, then can be gracefully evolved to the fully fleshed out component/application...even under stress of rapid feature changes.
When used with the Sketch UI model view separation, it allows designers and coders to work in parallel, allowing faster design, and keeping design in one swf with almost no code, and code in another. There are several advantages, allowing his keep designers out of the code and coders out of the design, in the tools they are happiest with.
The importance of interactive wireframes
Traditionally interactive applications start conception using a page andstoryboard metaphor, unfortunately ending there, completely bypassing the interactive architecture phase. While this approach works well for strongly linear narratives like movies, for interactive projects it only covers the tip of the iceberg as as there are so much complexity hidden beneath the surface. Consider a seemingly simple button. It's basic visual states are up, over, down, but there are also.... Disabled, selected, focused, default, toggled. For experience design, there will be animated transitions between states, and during the states, as well as the animated creation and destruction of the component. Most of the standard components have the standard aspects built in, we've grown accustomed to using, so like power they are As users of software with prebuilt components, this richness is so ubiquitous that it has faded into the background, and we don't consider it. Sadly when innovating on the UI, there's a great deal that ends up having to be rebuilt, rediscovered, over and over again. Primarily it's not until the very end that we can start interacting with the system to realize what's missing and broken.
Consider creating a video game like Pac Man. We can create 5 screens that reflect every visual aspect, but it will bear almost no representation live gameplay. Interactives must be played in order to be understood, and numerous more to gain mastery, and during this phase you'll find all sorts of things that didn't occur in a conventional architecture phase. Some might be simple, other ommissions might be severe: You might forget a replay screen, and the transition back into playing the game. Using interactive wireframes, allows for these 'flows' to be tested an validated in conjunction with suitable use cases.
Interactive wireframes, can serve as a solid foundation that that can be gradually be flushed out with comps and working components.
Introduction to Cogs
Cogs is a statemachine library for use with AS3.0 projects. All interactive applications have a lifecycle of descrete states. A state is a behavior, for example a lightswitch has two states: off and on, only one state can be active at once. A pet might have state of meowing, quiet, purring etc. Every state has optional enter and exit actions, e.g. when you end the 'on' state for a lightbulb, you'll trigger the graphics to turn on, and when exiting the state turn the graphics off.
Cogs supports nested states. This differs from most State Design Patterns, and allows for some very cool features, and much cleaner designs. For example your are right now in the reading state, in the awake state in the alive state. So for example if I asked you to go to the asleep state you'd exit the reading state by turning your attention away from the browser, exit the awake state by closing your eyes, and enter the asleep state by breathing slowly. Cogs manages all these transition chains automatically.
Statecharts started can be used to model anything from quantum physics to component lifecycle to workflows. By using Cogs you don't have to rebuild the transitions.
In addition, there is also an ongoing library of state charts, covering common problems, such as media players, playlist, login, registration whose lifecycles can be used as templates, design validation, and examples built in Cogs, which due to the nature of Cogs being Function based for states, allows you to subclass and extended to your applications.
This is the the graphical representation of the various statemachine topologies that the COGS library supports, and the test case with all of them in on the bottom right:
This is a view of the debugger which can introspect a running statemachine and render these on the fly. These only show the inactive state. The idea is basically a Euler diagram, or variation on the pie chart with various weightings to expose different aspects of the running heirarchical statemachine.
In this case they are rendering the following state heirarchy/topology: