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.
Michael, I think they bought RoboDemo from a company called eHelp (or maybe they bought the whole company). This doesn’t absolve Macromedia of knowing they had a not-so-great product on their hands, but might explain why they “rushed to release”–it was already a product out in the market before they even owned it.
Thanks for your review, though. I’ve thought about investigating it more closely as a possible tool for online tutorials for faculty and students. Sounds like it might be worth waiting for Captivate–I’ll certainly wait for your review of that!
-Jim
You’re right about eHelp being the original vendor, Jim, but I believe that Version 5 of RoboDemo happened (shortly) after the purchase.
By the way, I want to be clear that RoboDemo isn’t so bad that it’s unusable. Furthermore, I’m not aware of any product in its price category that’s a whole lot better (though I’ve heard good things about Camtasia). If you just need a tool to pump out a dozen short lessons on how to use, say, your course management system, it would probably be OK–especially if you’re viewing those lessons more as online “show me” help rather than “guide me” and “test me” certification. But it’s enough of a pain to author in that I wouldn’t use it for larger training projects.
Michael, a while back you linked to my comparison of ViewletBuilder vs Wink, and I believe ViewletBuilder, at least for the price, is a darn good competitor to RoboDemo. Having said that, I haven’t used RoboDemo myself, but in looking at your issues, I do know that the audio timing works on ViewletBuilder, as does the click/pause feature.
I’d also like to point out some pretty advanced tutorials our Learning Commons put together using ViewletBuilder – http://elearn.ucalgary.ca/tutorials/blackboard/
Can you show us what you ended up with with RoboDemo, or did you just abandon the project?
I’m afraid I can’t show you the results from the project, not because we abandoned it but because they were for a corporate client and live behind a firewall.
Glad to hear you’re happy with Viewletbuilder and thanks for the examples.
Michael, first off, let me say that I have no relationship with Macromedia other than that of a long-term user of their products. I came to your article interested in your conclusions, because I am currently in the middle of a long and complex product where, for a number of reasons, my company opted to use an internally-developed simulation tool rather than RoboDemo or Qarbon ViewletBuilder, both of which I advocated for as far-superior products.
That said, I think your review of RoboDemo is wrong in some of its basic assumptions, overly harsh and uncharacteristically naive about the workings of the software industry.
Regarding your first suspected reason for your problems with RoboDemo: RoboDemo 5 was a product developed and released in October 2003 by eHelp Corp. Macromedia completed its acquisition of eHelp in December 2003. Until summer 2004, if you tried to purchase RoboDemo 5 from Macromedia’s site, you were forwarded to an online store at ehelp.com. Even today, if you open up the Help|About window, you will see the copyright, support address and website all point to eHelp sites. (These now forward to Macromedia.com, although the old forums are still available as read-only at http://robodemo-forums.helpcommunity.ehelp.com/phpbb2/) Blaming Macromedia for a rushed release is therefore, inappropriate. Version 6, now known as Captivate, is the first fully Macromedia-ized version, and I believe it has been rewritten from the ground up to address many of the issues reported in earlier incarnations.
As for your experience with the “Pause movie until user clicks” setting: I can’t duplicate that. If I capture a short demo, insert a “click box” into the movie with the default settings, upon playback the movie automatically pauses and waits until I click the click area before continuing. Perhaps I am not understanding your description of the problem correctly.
As to your second suspicion, this may be closer to the mark. RoboDemo was, indeed originally intended purely as demo software. With version 4 of the program, eHelp released 2 levels of the program: Standard, and the more expensive eLearning Edition. The eLearning features were added on to the base program; in the version 5 release, the two levels were merged. Many of the problems encountered by you and other users with regard to timing issues are due to the poorly-designed “auto-capture” feature. Many of the comments on the old eHelp forums advised users to capture demos manually rather than using the automatic mode. It seems that Captivate will include some of these automation features.
For your third scenario, you are a little mistaken: RoboDemo was not built on the Flash platform. It uses its own proprietary file format and development paradigm. It merely exports to Macromedia’s .SWF format in the same way that it exports to Word format. If you want to export the .RD file to a file usable by Flash, you need to buy an add-on called the “FLA export module” which performs the complex format conversions. Captivate includes .FLA export in its standard features, leading me to believe that there is more Flash functionality in the new product — a good thing, in my opinion. It is true that originally Flash was designed “…to move objects around on a screen following a timeline.” However, since the addition of the full-fledged programming language, ActionScript, in version 5, language enchancements in version 6 (MX), and a completely new, fully object-oriented version 2 in MX 2004, the timeline has become less and less central to Flash’s development paradigm. Flash MX 2004 Professional offers a development environment which completely eschews the timeline for a form-based IDE akin to Microsoft’s VisualBasic.
Accordingly, your criticisms of Flash’s sound capabilities left me somewhat perplexed. I think you should tell the Flash developer you consulted to review the documentation on Flash’s “Sound” class. It was introduced in Flash 5, then revised and made much more useful in Flash 6. Specifically, have him or her take a look at the “Sound.onSoundComplete()” event handler. (The name should give him or her a hint about what it does.) Even without the sound object, it is very easy to design an animation which stops the main timeline and relies on a sound-containing independent movieclip to un-pause the main movie when it finishes playing. We’ve been doing this since version 4. I strongly suspect that any problems RoboDemo has with syncing sounds have nothing to do with Flash.
I realize I’ve gone on at length here, and I apologize if I’ve rambled, but I read your site regularly in my newsreader and I have come to respect and enjoy your writing and opinions on so many aspects of our industry. I hope my rambling may have helped you in some small way with your “learning about online learning.”
First off, Sheep, thanks for your honest criticism as well as your compliments regarding my blog. Both are equally appreciated. (And yeah, I definitely learned from your post. Thanks for that too.)
Case in point: I appreciate your correction on 5.0 being a pre-Macromedia release. (It’s possible that Jim, above, was trying to tell me the same thing and that I misunderstood his comment.) Regarding the pause error I mentioned, though, I feel pretty confident about it. We reproduced it on several authoring machines and the Macromedia help desk acknowledged it as a known issue. (Well…they acknowledged it as a known behavior, anyway.) I can’t guess why it happened for us and not for you.
Your information regarding the history of the eLearning edition are interesting. It’s been clear to me that auto-capture RoboDemo is intended to compete with epiplex and OnDemand, both of which have far more advanced and polished capture functionality (epiplex moreso than OnDemand) that cut down authoring times by an order of magnitude. Of course, these products are both also an order of magnitude more expensive. Auto-capture is hard; it doesn’t surprise me that eHelp broke some things when they tried to implement it. Maybe Captivate will get it right.
On the third point, I think your added information only serves to reinforce my position. The authoring file format is less important than the fact that the end product is an SWF file. However eHelp was manipulating data within their own file format, they could only output in the ways that Flash let them. As far as I am aware, this is the only output format RoboDemo has supported, which leads me to surmose that their developers would logically be thinking quite a bit about how Flash works when they built their own product. (They would have been stupid not to do so.) I don’t know when RoboDemo 5 came out in relation to Flash 5 and 6 (and I’m not about to speculate), but the fact that there now exists a way in Flash to deal easily with sound syncronization today doesn’t mean that (a) it existed when Robodemo 5 was created or that (b) even if it did exist it would have been easy for the eHelp developers to extend their own (proprietary) authoring system to take advantage of it. We just don’t know how hard it is to refactor their code to take advantage of newer developments in Flash (which, by the way, is one reason why we can hope that Macromedia owning the product will mean that it can keep better pace with new Flash functionality in the future).
My point wasn’t to cast aspersions on the current state of Flash and ActionScript. It was merely to point out that, when you build your product with heavy dependencies on a third-party platform, you end up being tied to the way of thinking encouraged by what the platform snapshot affords at the time of your initial development. Untying that knot is often a lot easier said than done.
Just an FYI: RoboDemo was NOT orignally an eHelp product. RoboDemo was first made available to consumers as “FlashCam”. It was eventually sold to eHelp. They made lots of improvements.
Captivate is the first real “overhaul” of the initial product. Once items such as the click box issue are eradicated, RoboDemo/Captivate will definitely provide the best value on the market for what it does.
For those seeking extremely high-level performance, you still can’t beat Authorware. Many companies, unfortunately, aren’t interested in investing the $3K per license for that application.
At any rate, just thought someone would be interested in some additional history on the product.
hello I have very need to RoboDemo and crack please send to my mail
I will be very happy tanks.