Interactive Simulation Newsletter

This Edition's Contents: Welcome to the Newsletter Your Opinion Counts! Do's and Don'ts of focusing attention Tips on Starting to Build a Simulator Direct Event Handling with the State Engine (revised FStEng component!) Upcoming Events Let Us Help You with Your Projects

This newsletter is brought to you by Jonathan Kaye and David Castillo, the authors of "Flash MX for Interactive Simulation," the first practical guide to building interactive product simulations and performance-based training in Flash.

Enter your email address here to receive the accompanying source code and automatic notification on future newsletter releases.

WELCOME!

Welcome to the third issue of our interactive simulation newsletter.

Our first article, "Do's and Don'ts of Focusing the Learner's Attention," presents and discusses ways to focus the learner's attention through highlighting. Following that, we are featurig a perspective by John Bicknell on how the concepts taught in the book can be applied to simulator-building projects. Lastly, in the Component Corner, we describe an easier way to program event handling for the state engine we developed in the book, which is accompanied by our (new) FStEng version 1.5.

If you have a story to tell about a simulation project you are developing or have developed, please let us know. By sharing and discussing our experiences, we all become better simulation developers!

We constantly run into all different people around the country and world who have interesting simulation projects they have in mind or have prepared. We want to encourage you simulator programmers, instructional designers, gamers, managers, and other developers to share your stories and best practices with the rest of us. We invite you to lead or join the discussion on our FlashSim discussion board:

http://FlashSim.infopop.cc/

We also will monitor the discussions for particular topics that might make good newsletter information, so go forth and post!

If you have suggestion for topics you'd like to see in the newsletter, or links to events or interesting Flash pieces you've made, please email us at newsletter@FlashSim.com.

You've met with your subject matter experts and developed your content outlines and ready to begin designing your instruction. You plan on first creating a graphics storyboard and then writing your script. One of the challenges you will surely face, especially when teaching complex technical information, is focusing the learner's attention. Many strategies have been used to accomplish this feat, some more successful than others. This article is intended to put forth some basic strategies for your consideration. When reading this article, try to visualize each of the key points in the context of a project you are working on or have worked on. We will begin by reviewing the common strategies that seem to work. Then, we will examine some strategies that either did not contribute to the instruction or worse yet distracted from it.

The Do's

Use graphics highlights. Probably the most common strategy for focusing the learner’s attention is to highlight an object or objects. If you use a simple box or other object outline, use colors that standout from the background (without clashing with your color themes) with a thick enough stroke to be quickly spotted. Since highlights are designed to focus the learners attention, keep it on one thing. If you want to focus the learner’s attention on a group of things, use one box to enclose them all at once, or, at the minimum, some visual representation that connects the highlighted elements, rather than highlighting multiple objects individually. If you use, a primitive shape like a box or a circle, then completely enclose the target object with little if any extra space around it. We have found that excessively large highlights can be distracting.

Timing display of highlights. Highlight an element or object for only as long as it is the target of discussion. When your audio script moves on to another topic, then highlight the next target object, first removing the most recent highlight. 

Dim the non-essential information. You may prefer to dim out the non-essential information rather than highlight the salient element(s). This is especially useful for complex frames containing many objects competing for the learner’s attention. By dimming out the non-essential information, rather than removing it altogether, you keep the target object in its context. For example, it is one thing to locate a particular switch on a frame with no other competing information, and another to locate that same switch amongst a panel with several other switches, dials, and displays.  

Use animation. If you are presenting elements of an interface that are close in proximity and follow a basic pattern such as left-to-right, right-to-left, up-to-down, etc., the learner usually can follow your guide without a problem. However, if you need to highlight an element that is at some distance from the most recent element, you may want to use animation to guide the learner's attention from the current element to the next. This type of animation should be fairly simple, such as a pointer or cursor. Animation in this way should be prominent enough to attract and carry the learner's attention from element to element, but not so flashy that it distracts from the tone and pace of the presentation.

Use animation to demonstrate consequences. If the effect of performing an action is subtle, you can use animation to call attention to how the learner can tell that the operation was done successfully or unsuccessfully. For example, on a project to teach how to use a hospital bed, we built the instructional frame so that when the learner pressed a button, the relevant bed section animated in a manner similar to the real device. This animation helped the learner to map their actions with the intended outcomes of operating the device.

Schematics of hydraulic, electrical, and pneumatic systems are excellent examples of using animation to add instructional value. Since it is often difficult to show the learner what really happens "under the hood," you can animate objects on a schematic to show what happens at the system level when they perform certain actions. 

Use textual information. Although it is widely practiced to use a text box in addition to recorded audio, you must recognize that text boxes will compete for the learner's attention with the other instructional channels. For example, if you have a text box and a highlighted graphic or illustration, the learner cannot follow along with the text box at the same time as paying attention to your instructional highlights. For this reason, we suggest making text boxes optional, or not using them at all. If you choose to use them, we suggest that you synchronize text changes with th presentation pace so that they do not compete for the learner’s attention. Unless making your content accessible to a hearing-impaired audience is a prime concern, rather than using text boxes to display word for word the recorded script, we prefer using bulleted list that identify key points.

Fade out prompts. When using any of the strategies listed here to focus the learner’s attention, you should consider incorporating a strategy for "fading out" the prompts, in other words, systematically reduce the frequency and strength of prompts as the learner becomes more proficient. A learner may be completely successful locating a highlighted switch or recognizing an animated valve on a schematic and may be entirely unsuccessful at performing without the instructional helpers.

One way of accomplishing this is to remove the prompts unless asked for ("Hint", "Help Me", etc.) at a certain point in the learning process. This is analogous to removing the training wheels on a child’s bike, while still supporting them on an as needed basis. You can also program the prompts so that they are time or error triggered. For example, if a learner’s takes too much time or makes an erroneous response, the program can prompt them. We implement this fading process during the practice phase of the instruction.

Use interactivity. Arguably, the most powerful way to focus the learner’s attention is to use meaningful interaction. We define meaningful interaction as getting the learner to perform things that are similar enough to the real world tasks as to support learning. If we provide occasion to make responses such as when we display a panel with a certain set of controls, we can focus their attention on the elements of the system in which they can control at that moment.    

Don’ts

Avoid non-instructional animation. All too often, an instructional program is “jazzed up” with “bells and whistles”. This can take the form of non-instructional animations and graphics. It is our strong belief that learners have a hard enough time processing the essential instruction that we should as compassionate instructional designers minimize non-essential information from the program. The adage “if you are not part of the solution, you are part of the problem” applies to any visual or auditory signal that can compete for the learners attention. 

Avoid absence of context. Another well-intentioned, yet instructionally hurtful strategy is to remove too much competing information resulting in a loss of context. Learner’s engage in instruction to learn to perform in a real-world context. It is a delicate operation to balance the removal of potentially distracting, but contextually-important, elements. Try to keep the frames organized and uncluttered, but as realistic to the actual workplace as possible so as to facilitate transfer of learning. 

Avoid over prompting. When introducing a learner to a new subject, it is a common mistake to help the learner too much. Adult learners come to the learning environment with a great deal of experience much of which can support learning new material. The instructional designer should employ the prompting strategies listed above carefully so as not to offer the learner help before they have had time to do it themselves. It is our view that if a learner can perform unassisted, they should perform. We make this claim with the clear understanding that the learner should not have to guess. They should have access to assistance whenever they are uncertain about their response. 

Avoid "locking out" learner control due to prompts. Sometimes, when using animation to highlight a concept, the developers forget to allow a learner to bypass a demonstration when the learner wants to move more quickly. This can frustrate learners because it does not let them move at their own pace. Be careful that your animation sequences do not lock a learner into sitting through a full sequence, especially if the sequence is more than a couple of seconds in duration.

Summary

It is not our intent to address every possible strategy for focusing learner attention, but to instead draw your attention to some common strategies that work and some that don’t. In practical terms, you as the instructional designer need to determine what will work best in any given situation. This survey has hopefully given you something to think about as you face that increasingly challenging task of focusing the learner’s attention on what matters most.

We invite community members to share their experiences in designing and building simulations.  John Bicknell wrote these suggestions about his experience in adapting our book's message and content to fit his needs.

Preparing for a New Way to Think about Problems

As you work your way through the book it’s very easy to get too bogged down in detail, and you forget (or may not even know in the first place) what you are pursuing.

The big picture is we need to find a way to handle and organise states. A digital watch is probably one of the easiest things to picture when you are thinking about states. As you put your watch into its various modes: stopwatch, display date, display time etc. you are flicking it through it’s states. From state to state the display changes, and the buttons on watch perform different actions.

At first glance you’d maybe think it a little tricky but not too hard to simulate your average digital watch in Flash. It's not until you get into it that you really begin to see the complexity involved, especially when you start to think about setting the time and date. You will end up writing 10s if not 100s of little functions to handle the button presses and control the screen, it very quickly becomes such a tangled mess, that once you have it working, you daren’t touch it again and you live in fear of amends. Try it--it’s not fun.

Statecharts coupled with the state engine gives us a way to divide and conquer the simulation. Every function, every bit of data has its place. Every function fires without fail at a given point in a given order. The statechart is equally as important as the code. Don’t been tempted to bang in the code without a detailed chart and event-action tables. With chart and table on your desk you will be in complete control of your code. Writing, changing, amends and bug tracking will take much less time and be far less taxing for your brain. You will be able to concentrate on writing the code for one state at a time. When you’re done you will have a complex, reliable and amendable simulator for much less effort.

Start small and work your way into it, you will soon begin to appreciate the possibilities and the power of this way of programming, you will begin to be confident about bigger more complex projects and start seeing other uses for this style of programming other than simulators.

About Myself

I'm just an English freelancer living in Valencia, Spain. I have been developing various things associated with the web, server-side and client-side for a while now (I bought a copy of Flash 2 when it came out). I really enjoy working with Flash and ActionScript especially on projects associated with learning. My most successful project to date would be this one for the RNLI (uk lifeboats). Had hundreds of emails of nice feedback. http://www.rnli.org.uk/training/launch.asp. Now working on version 2, and some more gas detection simulators! I can be reached at: john@geckotec.co.uk.

Since our book's release, we have had the opportunity to learn about your experiences and those of our clients in using the state engine to underly significant projects. As a result, we have heard about some difficulties in understanding how to program the event handling, and therefore recently undertook to help remedy this situation. This month, we discuss how we have implemented a more intuitive approach (but computationally more expensive) to writing event handlers that are easier to understand as mapping from your designs to implementation.

History of our Flash MX State Engine Implementation

For the book, we developed a state engine implementation that was contained in an external file, FStEng.as. Shortly after the book was released, we packaged the state engine in a component form, to remove the problem of waiting one frame between reading in the class definition file and defining a state engine. In the process of writing code hints for the component, we discovered that Flash didn't allow code hints for methods and properties that had underscores. Therefore, we removed the underscores and released a version 1.2 of the state engine, with code hints. We also made a minor modification to parameter ordering for the state manager, to ensure consistency.

Therefore, we had two basic versions. First (v1.0), the FStEng.as version from the book, and second (v1.2), the component form that we give out for free once you fill out our simulator developer survey.

In this edition of the newsletter, we present the next (minor) version of the state engine, v1.5. This version introduces an easier way to understand and program event handling. The changes are cosmetic, as far as functionality is concerned--any projects you have done with v1.2 will work with v1.5, and anything done with v1.0 will work with small modifications (removing underscores from state engine methods and properties).

What Was Unintuitive with the Original Event Handling?

In our book, we argue for the importance of centralizing event handling with respect to the currently active state(s). This is opposite from what may be considered the "conventional" OOP approach to programming, namely defining an event handler for each particular class, and within the event handler deciding which state the application is in, and acting appropriately. The problem with the latter approach is that when you need to understand the behavior of the system as a whole, you have to go through each class to see which handlers are relevant, and what the relevant handlers do to the system state in each case. As your program grows, it becomes more difficult to understand how the system as a whole behaves, since the things that implement its behavior (how you handle events, in particular) are spread out among all the classes.

The former approach, namely using the state engine, organizes event handling by the current system state. Therefore, if you need to understand how the system behaves in a particular context, you can simply look at the event handling and other activities that are defined for that particular context (state).

In the original event handling for our state engine, we defined a single point of entry for all events, called "ieh" (internal event handler). The ieh routine was essentially a big "switch'' statement, which first determined which state should handle the incoming event, and second processed the event (for example, firing a transition or executing some internal action(s)). This approach gives the developer very fine control over how events are handled, but it gives a lot of freedom as to exactly where and how to handle the event. This can cause a breakdown between the description of event handling as written in the event-action table, and the implementation. Such a breakdown could result in the implementation being difficult to understand in spite of having a clear event-action table description.

If we look at the big picture of what the event handler is supposed to do, we see it has three basic tasks:

1. Determine the current state(s) which should handle the event;
2. If there are any internal actions for the current state(s) triggered by the event, execute them;
3. If there are any transitions for the current state(s) triggered as a result of this event, fire the transition.

Our main point in using statecharts is that the design is the central element of the process, not the implementation. Therefore, if we allow too many liberties in the implementation, it makes it hard to connect the design and implementation so straightforwardly, and we lose some of the value of the design.

The Good Things about the Conventional Approach

The "conventional" programming approach has some positives in its simplicity and apparent "naturalness." For example, when we want to write an event handler for a button, we say something like

myButton.onPress = function () {
...
}

Honestly, this is pretty convenient and straightforward to understand. The problem, as outlined above, is that when the system gets complex, we make system changes within these event handlers, and so understanding or changing how the system behaves in a particular context means having to go through and potentially modifying all the event handlers in the system. This can easily lead to errors if the program does not have a solid and unambiguous representation of state.

A less error-prone system would permit us to define event handling with respect to the current state, but with the convenience of saying "take these actions when the button is pressed". In other words, we'd have a different button event handler for each system state that required a different handling of the button. In that way, if we needed to change the behavior of the program in a particular state, we simply modify the event handlers that apply to that state.

The Best of Both Worlds

If we look at the conventional approach example above in terms of the statechart perspective, we're really saying that we'd like to define internal actions (i.e., actions that do not cause state changes) to be easy enough to define as something like

state1.onPress = function () { ... }

This lets us define actions with respect to the current state. In other words, this statement means "use this onPress handler whenever state1 is active." Remember, because of hierarchical states, it is possible for state1 to be active and some sub-states as well.

There are two things going on here: first, it is specify a trigger for the action (the button press), and second, it is specifying an action (the function). If we were to code this in the internal event handler of the original state engine, we'd first determine if state1 was active, then check the trigger (was the event sent in a button press?), and finally execute the internal action (the function). Therefore, we'd have to do some legwork in programming this functionality, and it really appears more difficult than our "natural" tendencies.

If we also could define transitions in this way, simply saying "take a transition on button press", it would be much easier to translate the event-action table into code.

In version 1.5, we essentially added this functionality to the state engine. Instead of the old way of defining an internal action:

state1.addIntAct(0, function () ...);

and then writing the trigger processing code in the ieh routine, you now can define internal actions implicitly by making statements such as:

state1.onPress = function () { ... }

This also works for transitions, which we now define as

state1.addTrans(0, new trans(...), "onButton1Press");

(as opposed with the original engine, adding the transition with addTrans, and writing the trigger processing code in the ieh routine). These conveniences make it much easier to translate the event-action table directly to code. Space here does not permit a full explanation of how to use this--check out the accompanying code for the Stolex watch (Stolex4.fla) to see the new methodology in action. Use our discussion boards to tell us what additional information you need to understand these additions better.

How Does this Work?

Since we cannot use magic, the natural question is "how are we tying onPress to the event and value?" Boy you ask good questions. The answer is that we build a table that maps properties like "onPress" to the real trigger (event and value it expresses), for example,

{ onPress : function (ev, val) { return (ev == "button1" && val == "press" },
  onRelease : function (ev, val) { return (ev == "button1" && val == "release" } ... }

The new state engine creates a default "ieh" routine, so you no longer write that routine by hand. The default ieh routine finds the most specific, currently active state and sends the event to that state's new "onEvent" method. This default onEvent method cycles through the state's internal action triggers and transition triggers. If any trigger is met, then the action or transition is fired.

When we determine the current state(s), we start with the most specific sub-context and percolate the event to its parent and ancestors, as necessary. This is necessary to handle the "interrupt-driven" event handling we discuss in the book. For example, if we had two states such as

We want to make sure that the internal actions of states 5 and 1 were executed, if the triggers were met. Therefore, we first send the event to state 5 to handle, and it finds the appropriate internal actions to fire. Once it is complete, state 1 is allowed to test its internal action triggers against the event, to see if there are any relevant actions to execute. Unlike internal actions, for transitions, if a sub-state has a transition that is triggered, then the parent states do not check their transition triggers. This allows sub-states to "override" transition behaviors of their parents.

This new scheme introduces inefficiencies with respect to event handling, since all transition and internal action triggers are tested for the current state, and all internal action triggers are tested for all active states up to the root. However, for the beginner, those inefficiencies are worth the price of the convenience, we believe. The more experienced developer can choose to use this mechanism, for simplicity, or code specific actions in a state's onEvent handler, or, simply use the old approach of defining a complete ieh routine.

The best way to understand this is to look in the example code for the Stolex watch. As always, please post message on the discussion board if you have any questions, or email Jonathan directly!

If you'd prefer not to receive this newsletter, send us your name, your registered e-mail address, and the message: "Unsubscribe" to removeListener@FlashSim.com.

If you are receiving this newsletter from a friend and want to subscribe yourself, please email us a message with the subject "Subscribe" to addListener@FlashSim.com.