e-Literate

Present is Prologue

Tag: simulations

  • Second Life: A Simulation Wiki?

    As usual, Jon Udell is onto something interesting. A company called Linden Labs has produced a MMORG called Second Life. Three things make this particular venture somewhat unusual, though. First, they bundle a free development environment, so that people (theoretically even non-programmers) can create their own clothes, bodies, objects, buildings, and so on. Second, it’s not so much a game as it is a virtual market. People own the digital objects they create and can buy and sell them. And finally, they are actively recruiting educators to use their virtual world.

    All in all, it’s vaguely reminiscent of JotSpot, in the sense that it’s a consumer-oriented social canvas for creating certain kinds of applications. In the case of Second Life (SL), you can think of it as a simulation wiki.

    (more…)

  • Harnessing Autobiographical Memory Through Simulations

    The Eide Neurolearning Blog has an interesting post on autobiographical memory. It seems to me that the best way to tap its power from the perspective of online learning is through discovery learning adventure games. Check out, for example, this great little action maze that teaches emergency first aid best practices. It was created using a great (and inexpensive) authoring tool called Quandary. By embedding the learning content into a first-person narrative experience, you should be able to acivate autobiographical memory.

  • Why RoboDemo 5 Sucks

    This post isn’t a litany of the things that I don’t like about RoboDemo, although there will necessarily will be some of that. Rather, it’s my own speculation as to why a smart company with a reputation for good software produced a lemon of a release. Make no mistake about it, though; Robodemo 5 sucks. It mostly sucks in fixable ways and it’s possible that some of the problems have already been fixed in Captivate, it’s newly released successor. (I won’t know for certain until I find time to kick the tires.) But the question remains; why did Macromedia release a product that is badly broken?

    Before continuing, let me put in a caveat. I am far from a RoboDemo expert. My observations are from working with it on one project with teammates who, like me, had lots of simulation design and production experience using other products but had no RoboDemo-specific experience. I wouldn’t be surprised if there were some things that we missed. Nevertheless, most of the problems that I intend to write about here should have been much harder to hit and easier to solve than they were. Even if we missed some functionality in the product, that does not absolve Macromedia from not making that functionality the default behavior or, at least, more obvious.

    The first and least interesting possible reason why Macromedia released an inferior product is that they rushed a release out with known bugs in response to external pressures. Given that this is the first release of the product since they bought the product line, I wouldn’t be surprised if they felt they needed to push a first release out the door quickly. And there is evidence of this. For example, when you put an interactive element on a screen (e.g., a click box) and set the option to “wait for user response” (or something like that; I don’t have a copy of the software with me at the moment), RoboDemo ignores this setting and moves onto the next frame regardless of whether the user has clicked. In order to make the proper behavior happen, you have to change the setting for the frame from the default “continue” and hard-wire it to go to the next numbered frame. That adds two clicks of authoring for every single interaction screen, not to mention the fact that you have to do extra editing clicks if you happen to add, delete, or change the order of the screens. Plus, it creates many more points (one per interaction screen, to be exact) where you need to QA for possible authoring errors. In a project of any substantial size, this ends up being a significant time drag. (Also, RoboDemo apparently doesn’t handle right-clicks for interactivity options. How could that be?)

    At first, we thought that we had to be missing some setting; how could Macromedia release a product with such an obvious glitch? Incredibly, their customer support operator told us that, yes, the only way to get Robodemo to actually wait for the user’s interaction is to hard-wire each frame as we were doing. They refused to acknowledge that this was a bug despite the fact that they also said the behavior would change in the next release. I saw a handful glaring and careless bugs like this one, and we weren’t even pushing the product that hard.

    The second possible cause of RoboDemo’s suckiness is that e-learning functionality appears to be tacked on as an afterthought. It is, after all, called RoboDemo. While there are features that allow you to build in interactivity, add scoring, etc., these all have to be added manually. It should be possible to set the product in either demo or e-learning simulation mode. When set for the latter, the product should add click boxes and the like by default. There is some indication in the marketing copy for Captivate (a.k.a. RoboDemo 6) that the new version has something like this. If it exists in version 5.0, though, we certainly couldn’t find it.

    The third possible cause is in some ways the most interesting. It’s possible that some of the problems with RoboDemo are because it is built on top of Flash and relies heavily on the Flash authoring paradigm. Remember, as an animation product, Flash was fundamentally designed to make it easy to move objects around on a screen following a timeline. Some of the features that make it suitable for e-learning development were added as afterthoughts and were not necessarily added in a way that makes sense from an e-learning-centric perspective.

    Take sound, for example. In Flash, sound is built on a timeline. According to one of the Flash developers on my team, there’s no real easy way to tell animations in a flash movie to pause and wait for sound file to finish playing. You basically have to fiddle with the timeline until they line up.

    Maybe this is why there is no way in RoboDemo to automatically synch up audio narration so that the learner isn’t moved along to the next screen before the narration is finished. You basically have to go to the settings for one of the visual elements on the page (like a call-out bubble) and set it to display for the same number of seconds as the length of your sound file.

    For each and every page.

    In order to fix this behavior, two things would have had to happen. First, the RoboDemo developers would have had to break their habitual mindset as Flash developers and see that the Flash audio model is not the right one for simulation development. My impression of RoboDemo is that it was designed by Flash developers to create a bunch of short-cuts for some of the things they would do when developing a simulation by hand in the Flash authoring environment. This isn’t a bad start, but they need to stop thinking like Flash developers and start thinking like e-Learning designers to gain more significant authoring time savings for their customers. Second, once they realize that the Flash model isn’t right, they would have to develop a work-around, essentially fighting against the way that Flash naturally wants to do things. This just isn’t easy even for the best development teams.

    So those are the three reasons why I think RoboDemo 5 ended up being a deeply flawed release. Again, I’m not a RoboDemo expert; these are my impressions after a little more than a week of getting up-close and personal with it. Still, I’m pretty confident that the margin of error on my suckiness assessment is relatively modest.

    We’ll see if Macromedia does any better with the new version.

  • Educational Conversation Pattern: Role-Playing Simulation

    Here is another tool that affords a particular educational conversation pattern. This time the pattern is role-playing simulation

    I may have to start a new site theme for this stuff.

    (Found via thee-Learning Centre.)

  • The Distant Librarian: Wink vs Viewlets

    Another of Stephen Downes’ Breaking the Power Law blogs provides a useful comparison of Wink to Qarbon’s Viewletbuilder. The short version: Wink is free but ViewletBuilder is nicer.

  • Research Pages of Stuart G. Towns: Wink

    In one of the blogs from Stephen Downes’ “Breaking the Power Laws” list, Stuart Towns recommends a nifty little tool called Wink. While it definitely falls in the low-end category of the range of software simulation products I outlined in eLearn, it has the great benefit of being free.

  • Teaching Hands-On Classes Online

    From the Sloan Consortium, whose web site is turning out to be a gold mine of solid higher ed distance learning research, come articles on teaching electronics and Chemistry through distance learning. They used multimedia simulations of electronics in the former case while resorting to kitchen chemistry assignments in the latter case. For both courses, distance learning students tested as well or better than their classroom counterparts.

    Here’s a particularly delicious nugget:

    Of particular interest is the fact that, as evidenced by the results of the procedural evaluation, distance learning students were at least as competent as their traditional counterparts in utilizing laboratory equipment such as beakers, graduated cylinders and electronic balances, despite the fact that this type of equipment was not available to them in their kitchens. It appears that in the case of the first semester introductory chemistry course, the laboratory goals can be achieved equally well by the distance learners doing the Kitchen Chemistry Laboratories at home as they can by students in traditional laboratories.

    In some ways, this shouldn’t be surprising; K-12 science teachers do this kind of thing all the time because the schools can’t afford real equipment. I myself (in a prior life) had great success teaching middle school science using what was essentially a kitchen chemistry curriculum out of the University of Hawaii called FAST [PDF]. Likewise, high school teachers having been using virtual frogs in bio labs for years and years. Applying the same principles on a post-secondary level is not a huge leap, especially for 101-level courses. What’s interesting is that the methods, i.e., substituting real-world items in the student’s immediate environment when that’s possible and creating online simulations when it’s not, marry so well together in an e-learning environment as strategies for dealing with what is fundamentally an environment of low situational control for instructional designers.