IA, IxD Deliverables defined….Prototypes, Mockups, Flows oh my!
I develop RIA and games, where I find that webpage methodologies break down, and use several terms/tools in the early phases to capture various facets of the system. Lately on the IxD mailing list there has been some confusion as what is what so here's my list:
- Wireframe - a single screen as output by IA's, typically representing one state at a time, a skeleton to serve as a container for available copy and for graphic design to flush out as 'Comps'
- Sitemap - a rought organization of wireframes into sections and navigation between pages.
- Storyboard - sequence of wireframes + graphical interaction (mouse clicks, drags), typically a one way trip through a system, trying to get buyin from the entire team. Can be expansive in covering a wall, often required in team discussion to jump around and interrelate, or played back in a video like format. Frequently the beginning of a usecase/workflow.
- Comps - aka composition, a single screen as output by graphical designers based on Wireframes, and provided copy.
- Interactive Wireframe - aka clickthroughs, wireframes stacked in time,selectively hiding an showing things, to help flush out the interactive architecture. As somethings have to be played to be understood.
- Mockup - a high graphic fidelity, but limited in interactivity similar to a theme park ride. Great fun on the ride, but get a few feet off the track and the whole thing breaks down. A version that faithful covers all the use cases states to be conveyed, can also be called a simulation.
- Statemap/Lifecycle - a heirarchical statechart of all system states and events between them, frequently having links/thumbnails to various fidelity comps. Like a subway map it should encompass at varying levels of detail the entire system of states relevant. I find this missing in most designs. Screw this up then everything is already broken. Been compiling a library of common LifeCycles (user registration, media players), as I find that they are constantly rediscovered, and getting them right..can be tricky. I'll publish them as I have time.
- Flow - a particular usecases/workflow across the statechart + sitemap etc.
- Prototype - a typically technically driven 'spike' to answer a narrow question if something is feasible or not, or better than another scenario. typically disposable. Often using whatever is available ducktape, wood, paper + glue. Tehcnically anything that isn't building the final release meets the definition of a prototype. Thus I find it's more practical to have more specific terms (like mockup) to describe what I expect of a deliverable, what it does and what it won't do. However in the case for questions like 'can we sort 10000 items clientside, based on the dominate color' generally there isn't any other term available, so I use spike/prototype.
Soo many acronyms and deliverables: IA, IxD, UX, PX, XD, UCD….
In an ongoing series of articles on the early phases of RIA or Game project development one is likely to come across this menagerie of terms and titles:
- IA - information architecture, the organization of all the data in an application into logical bundles, and a clear navigation between. The careful choosing of the right ui components to match the underlying dimensionality of the data (e.g. a grid for multicolumnar) and single/multiple selection.
- IxD -interaction design, the consideration of the bi-directional communication of a user, armed with a mouse joystick and keyboard 'talking' with your application to collaboratively achieve a desired goal.
- UCD - User Centric Design, focusing on a particular end user capabilities and needs first, rather than technical merit, or business concerns first. It should focus on current or designed target audience, and often leads to workflows optimized to those User profiles, e.g a 7 year old editing a photo, has different requirements than an adult.
- UX - user eXperience, the summation of good copy, good graphic design, good motion design and smooth workflow, minimizing boredom, confusion.
- PX - player eXperience, the special considerations of user experience in games., or what makes games fun, typically involving [1] and progressive dynamic difficulty adjustment [2]
- XD - eXperience designer, can mean various things, typically someone skilled in blending a workflow (the minimal path to achieving a particular goal) with a narrative/plot to make it emotionally compelling and engaging. Often this is some blend of AfterFX, and Flash, and can involve actors and writers to script the experience.
Here's a paraphrase of how the IxD list views the blurry overlaps:
Information and Content are the nouns,
IA is the grammar,
IxD are the verbs,
Graphic Design are the adjectives,
Your app is the poem
Experience Architects are the poets....
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.