Interactive Simulation Newsletter
| WELCOME! People ask us why we chose the title "Interactive Simulation." After all, the engineering world has "Modeling and Simulation," and the instructional design world has "Performance-Based Training", or "Simulation-Based Training," and other fields have specific terms for how simulation fits into their practices. What does "Interactive Simulation" add? While David and I certainly didn't want to simply add a new buzzword, we felt that we needed an umbrella term to represent a foundation of core concepts and skills applicable to the evolving role of simulation to various disciplines, from training and assessment/certification to rapid prototyping, predictive modeling, and marketing. The "simulation" part was easy, because we certainly wanted to capture the idea of modeling reality, or a plausible reality, in some way. As you will likely hear by talking with us for more than a few minutes, however, "simulation" alone is never a solution; it must always be seen and planned for in the context of careful consideration for the types of interaction necessitated by the project goals. Because we felt it was important to emphasize the study of interaction in the development of useful simulations, we therefore arrived at the term "Interactive Simulation." This is the first issue of the monthly Interactive Simulation Newsletter, by Jonathan Kaye and David Castillo. In these issues, we will discuss topics related to Interactive Simulation and to Flash in particular. Our goal is to foster discussion about topics within "Interactive Simulation" so that the community as a whole can adopt and share best practices, leading to the most effective use of current technology to solve real problems. |
This
Edition's Contents:
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. |
|
|
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:
We also will monitor the discussions for particular topics that might make good newsletter information, so go out 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.
Many of you have been writing to us asking about our simulator developer classes we are advertising on FlashSim. We are at a stage in which we need your help, and we want to give you something for your participation. If you have 15 minutes or so, and want some free software that helps you build and debug state engines, please fill out the survey located at
Simulation today is a buzzword that is used by a growing number of companies and individuals to mean different things. Many e-learning companies, never to miss an opportunity to repackage and sell their wares, have jumped on the bandwagon to declare that they suddenly now don't just do e-learning, they produce 'simulations,' too.
Our mantra regarding performance-based training is that it is ultimately about performance improvement, not about building simulations. In that vein, we present a brief list of tips, in no particular order, we have learned in our experience building simulations and simulation-based training.
- Write Performance
Objectives.
Clearly state the types of interactions you want to allow the operator
to perform, and the intended reactions. If you rush in to build the
whole simulation at once with less consideration for the specific types
of behaviors required, you likely will develop more than you need and
you will spend more time and money than you want.
- Don't Just Watch,
Do! Unless
the skill is particularly complex and intricate, have the user perform
tasks right from the beginning, not simply watch demonstrations passively.
- Not Just Interaction,
Meaningful Interactions. Some people say that good
eLearning must have a lot of interactions. Not true! Good eLearning
has interactions that are meaningful to the performance objectives,
not merely interaction for the sake of having interaction.
- Not Fun and Engaging
to be Game-like, Fun and Engaging to Support Content.
Some say that good eLearning should be fun and engaging, like a game.
This is not wholly true. If the fun elements are not related to the
content, then they may distract from and interfere with the retention
of content and skill building, which is the purpose of the training.
- Focus on Performance
Improvement, not on Simulation Building. Often when people
think about simulation-based training, they think they need a whiz-bang
simulator. If you focus on creating a simulator before seriously planning
how the exercise will impact performance, you will end up spending too
much time and money on the wrong thing. Remember, if you cannot show
that the simulator improves performance, it doesn't matter how realistic
the simulator happens to be. Huge sums of money have been wasted by
trying to throw technology such as 3-D onto problems that were not well
defined with respect to performance objectives.
- Don't Forget the
Tracking. Designing your simulations with tracking is an important
way not only to help document user proficiency, but also to help you
analyze the effectiveness of your training. By tracking user performance,
you can get a better picture of where the user may be delayed in performing
procedures or possibly making errors as a result of the instruction.
- How Will You Measure
Results? When
you write each performance objective, write how you will know/measure
if that objective has been achieved. When we write objectives without
a clear indication of what successful achievement means, then the objective
is either too complex or too vague, and should be broken down into more
precise terms.
- Teach Content based
on Expert Performer/Instructor.
There is a temptation, especially in small teams, for the instructional
designer or the programmer to determine how to teach the device operation.
However, unless that person is proficient with the device in its intended
operational setting, you should recruit an expert performer or instructor
to assist in this process. Novice operators may focus on teaching in
a manner like "this button does that," in some sequential
fashion, whereas a master performer may need to convey thinking in terms
of systems, not individual buttons.
- Don't Let Programmers
do Graphic Design, and vice versa.
Unless you have a very small project, we have found that you should
let programmers do the programming and graphic designers do the design.
The tendency to save money by having one person assume both roles usually
ends up with an amateurish outcome that could easily be fixed by hiring
the right person for the right job.
- Start Small.
For your first few simulation projects, choose the projects that are
well-defined, "low-hanging fruit." If you try to tackle a
complex task right off the bat, then you can much more easily be sidetracked,
confused, and frustrated since it takes time and experience to shape
the development process and apply new skills into your practice.
- Make it Pay Along the Way. Design your projects as much as possible such that you have deliverables you can use at short intervals, rather than creating project which requires everything to come together in the end before you can test out its usefulness. For example, you may want to start a simulation project by developing it as an instructor's aid during a lecture, rather than jumping to the self-paced version. This can help you get results from your investment as soon as possible, and to leverage the investment in various aspects of your business.
|
In our book, we give approximately twenty different types of components you will find on many devices, such as buttons, knobs, gauges, and digital displays. The basic graphics provided with the components can be modified within your movie, but those changes would affect all the instances of the component. In this short article, we describe how to add a new parameter to the knob components (jog and potentiometer) so that you can specify a different bitmap or movie clip to use as the indicator. This allows you to use the same component within a movie but give it completely different appearances.
The basic idea is that we create a new component property that gives the designer the ability to specify a "Linkage ID" to replace the indicator graphic. In the code, we use attachMovie when the instance is created to bind the graphic with the instance. The linkage ID is for a movie clip in your Library which you want to use in place of the default indicator graphic, for example, defJogIndicator, for the jog knob indicator). If no linkage ID is specified, the component uses its default indicator graphic (or whatever it has been changed to in your movie).
Since the potentiometer is a subclass of the jog, we only need to make the change in the constructor of the jog (FISJogAttach). However, we do have to add the property (we call indLinkID) to the component properties of both FISJogAttach and FISPotAttach, since Flash does not propagate the component properties from the definition panel to subclasses.
The binding occurs in the constructor:
if (this.indLinkID != "") {
this.ind._visible = false;
this.ind = this.attachMovie(this.indLinkID, "ind1", 1);
}
Internally, the routines use this.ind to refer to the indicator movie. Therefore, these statements reassign this.ind to the specified movie, if the user gives the instance a linkage ID.
That's it! No big change, but something that can let you reuse your components on a much broader scale. As far as making the indicator movie clip rotate correctly, you need to align the center of the knob bitmap with the center of the container movie clip (the container is the movie clip you make with the linkage ID). For example, if your knob bitmap is "knob.jpg", create a new movie clip and place the graphic so that the center of the knob is at the center of the new movie clip. Then set a Linkage ID for the new movie clip (go to the Library, select the movie clip, and right-click (or CTRL-click, for Macs) to choose "Linkage...").
Two Important Final Points:
- To specify a linkage ID, you must check the "Export for ActionScript" checkbox. To have Flash properly access your graphic, you need to check the "Export in first frame" checkbox in the Linkage panel. Alternatively, put the movie clip on the stage somewhere not visible (perhaps add a clip event on movie load that sets the clip to _visible = false). If you don't do one of these, Flash won't automatically pull the graphic out of the Library properly.
- Make sure to turn off the background (dial) graphic. In this simple extension, we merely place the whole graphic in the indicator clip. If you wanted to extend the knobs to distinguish a background bitmap graphic with a different indicator graphic, you can use this technique for each of the background and the indicator.
Hint: There are some other extensions beyond the code in the book which we have built into these components, and we will talk about in future newsletters. Can you find them?
As always, please post message on the discussion board if you have any questions!
| Date | Event | Location |
| May 9 | One day workshop on Building Process Simulations | Arecibo, Puerto Rico |
| May 20 | How to Build Product Simulations, Philadelphia MMUG | Philadelphia, PA |
| June 23 | How to produce simulation-based e-Learning without breaking the bank, at the eLearning Instructional Design Symposium | Boston, MA |
| June 24 | One day workshop on Building Device Simulations, Slice of Life | Philadelphia, PA |
| About the Book | Sample Chapters | Gallery | Discussion | Downloads | Resources | Contact | BUY THE BOOK! | Home |