Assima Simulation Software: Initial Impressions April 19, 2007
Posted by B.J. Schone in eLearning.Tags: Development, eLearning, SCORM, Simulations
trackback
I saw a demo of Assima today, which is a tool that can be used to create (nearly) fully functional software simulations for eLearning. Assima is considered to be a next-generation simulation tool because it captures application information at the object level rather than just grabbing screenshots*, and it gives the developer the ability to record the application’s functionality once and then output it as several different movie or simulation types.
In terms of eLearning, a simulation tool should allow you to create the following:
- Demo movies (Watch it.)
- Training simulations (Let me try.)
- Assessment simulations (Test me.)
With many of the products I’ve seen, such as Adobe Captivate, you have to record three separate movies to get all of this functionality. With Assima, it appears that you can capture information once for an application and then output it in any of these three formats. If an application changes, you can “doctor” it in Assima. For example, let’s say IT adds two new buttons to a PeopleSoft screen after you built all of your PeopleSoft training. You can simply go in to Assima and add form objects (ex. buttons), and then apply actions to them instead of re-recording everything. Your changes are then automatically made for your demo movies, training simulations, and assessment simulations. That could be a huge time-saver.
So, if you want to create a simulation of an application, such as Microsoft Word, you first need to allow Assima to scan the application and read-in the menus, shortcut keys, etc. This is a fairly quick process, but it does need to be done for each screen and/or dialog box within the application. Of course, the true functionality of the application isn’t automatically captured; you have to “teach” the application’s functionality to Assima. If you want to teach the learner how to create a bulleted list, you need to record yourself creating a bulleted list. After that, you can tell Assima how to display the demo movies, training simulation, and assessment simulation for this task.
I’m excited to learn more about Assima. They definitely have the right idea, but I’m concerned that the file sizes for simulations will be very large. We’ll see. I’m also curious to see how easily the simulations integrate with learning management systems (LMSs). The movies are supposedly SCORM-compliant and AICC certified, but I’ve yet to see them published to an LMS with my own eyes. Assima is also quite expensive compared to other mainstream simulation tools.
* For the record, I know Knowledge Planet’s FireFly product can grab application information at the object level, but I’ve never been a big fan of its output format: big Java applets**. Plus, from what I’ve seen, Assima’s additional functionality beats it, hands-down.
**See this post’s comments for more details.
B.J. Schone
Eric Matas
kevinthorn
eLearning Weekly 
Just to be up front, I work for KnowledgePlanet.
I wanted to add some information around Firefly using “big Java applets”. Firefly uses one applet that is less than 1 MB in size to render simulation files. We share with our customers code that allows that one applet instance to be re-used among one or more simulations, therefore only requiring it to be downloaded once. A typical Firefly simulation file is roughly half the size of a comparable Captivate movie and from what we have heard from our clients that have evaluated Assima, their deployment requires a collection of large files that complicate deployment.
When I used FireFly, it was to record a few short software simulations. Maybe that’s why the 1+ MB file size seemed large to me at the time; I thought that short simulations would’ve been much smaller in size. So, based on that information, I figured the size of the simulation files would then scale up depending on the length of the scenario being recorded. It’s good to know that this may not necessarily be the case. I’ll be sure to consider that in the future. Thanks for the information.
Bonjour à vous tous
Nous travaillons avec Wizard Training Suite depuis 2005 et EPSS Performance Suite depuis le début de l’année 2007.
Nous apprécions la rapidité avec laquelle nous pouvons produire nos modules e-Learning, et surtout la facilité avec laquelle nous pouvons les maintenir et gérer leur lifecycle.
Les applications capturées sont en Visual Basic, DotNet, émulation 3270, IE et bientôt SAP. La grande ouverture d’Assima pour traiter toutes ces plateformes est très appréciable.
Pour revenir au poids des modules, il faut compter 2 Mo pour le runtime que l’on précharge une fois pour toutes sur les postes de travail, et entre 100 et 200 Ko pour une simulation d’une vingtaine d’écrans.
Hi, I m the CTO at Assima.
Just a clarification on this thread, as the object capture and publish options may appear confusing sometimes.
1/ On the object capture:
Most of the sim tools out there now claim they capture object (the case of Firefly for example, as noted in this thread). Although that is true, there is still a big difference between all of them, and our technology (hence capabilities). Most tools capture information of objects to allow them to replay partly or entirely these objects in the screen context. However, all tools (bar us) do not capture enough information to be able to replay all objects. So they all end up with enhanced screen copies. Still with the example of firefly, they output a file called lesson.sim. Well surprise… just rename the it as lesson.zip and you will see that it contains all screenshots of your application. Deceptively, Firefly, like all other sim tools without exception (bar Assima) still uses screen copy that they enhance (nothing different than Captivate). Then the question is how much the screen copy is enhanced. Hotspot, edit fields, listbox, menus, etc…
And of course, there is a big limit when it comes to scrolling, complex objects behaviour (grids, treeviews, etc..) than most application incorporate nowadays. There is also a limit as to what you can redesign, as you still deal with pixels, not information.
Assima is the only solution out there to capture only information (no screen copy), so you end up with real objects throughout your simulation (no screen shots), and that is what makes the difference in end user experience (interactivity, like the real thing), and development & maintainability (change information, not pixels).
2/ on publish options
Assima has 2 architectures for publish:
a/ runtime
b/ full HTML
Depending on your needs you will choose one or the other.
For the runtime option, you can choose:
– CD ROM publish (executable)
– ActiveX publish (although it is more and more banned by large corporation admitedly)
– Java publish (using java v1.3 minimum)
Each of those publish use a runtime of around 2Mb. This is a one off runtime for all your simulations
Then each lesson is in the region of 100-200Kb for a 20 screens lesson, fully interactive.
Each publish is fully compliant with SCORM and AICC
I hope this help clarify the positionning of most simulation tools, and the huge difference between technologies and capabilities, despite the fact everyone out there says “we re capturing at object level”. Again, most of the time, it s true, the problem is “how much do you capture?” and “is it enough to get rid of the screen shot?” if you just capture position, size and caption for each object, you will still badly need the screenshot, and then be badly limited by it. If you capture all information without exception (what assima is the only one to do), then you can get rid of the screenshot.
I’d like to see some demos of assima and firefly presentations. Can anyone direct me to some actual samples? Thanks.
There is a big downside to “try” and capture every object – does it include object that are not win32 objects – does it include jave swing capturing and other technologies? what about non-standard controls? can you recognize them?
there a lots of nice tools out there – eedo’s simplify is another example which gives you lot’s of the features like Assima
Hi there!
For demonstration of Assima, you have to ask our Marketing or Sales department, we have offices covering all of Northern America and Western Europe. They will be pleased to answer any questions.
For the more technical stuff (ie the non windows 32bits native components), the answer is:
– Java (Swing / Awt / Oracle…): we have plugin in our product to recognize various architectures. We have a plugin for Java (written in Java) which recognizes all Java standard components, and also helps us as a base to customize the extension and recognize the ones which are not so standard. So yes, most Java controls are fully captured and simulated back.
– Emulators (green screens) are also an example of non Win32 objects. We have emulator plugins to capture these objects/information too.
– Same goes with .NET, we have a native .NET extension…
– and the list goes on, as surprizingly or not, the applications which are using Win32 objects are very rare…
That is the two sides of the same coin:
Head/ The clone is the ultimate software simulation ;
Tail/ you get a full clone when you match 99-100% object recognition, (less than 90% you’re an enhanced screen shot solution, and still badly limited by the screenshot boundaries, like Firefly for example) and you need to spend massive R&D effort to get to this level, as 3 applications out of 4 do not use win32 standard objects.
Hope this helps