Developing software simulations in Adobe Captivate

By a demo simulation we mean an e-learning course which comprises a sequence of (any) software or application screens (or an emulation program) and teaches how to work with it step by step with directions and hints for the user.

By a test simulation we mean the same demo simulation but in this case the user completes all the operations in the emulation program by themselves, without any hints. Upon the completion result, the user gets a score.

General concepts and trends in the development


A year or two ago, a standard software simulation had a quite simple look: a sequence of screens, basic design, hints where to click in the demo, and scoring in the test. Today, every simulation has its unique design, animation options, and also sophisticated mechanics and algorithms. For instance, when the user completes a task in the simulation, the screen can switch to a document where they should find the necessary information and copy it to the emulation program (like inputting details from a receipt, for example). Other examples are: additional screens between operations, creating ‘find-the-mistake’ tests in the middle of the simulation, inserting a video. For the past year, more than half of our e-courses have already been made for iPad and on HTML5.

This very change has also applied to the simulations: they are ported to new platforms and customized to new needs of our clients.

The target audience of this article

Is why if you are a representative of a company which has decided to order a software simulation course, you will learn the following from this article:

  1. The process of developing a simulation;
  2. How to organize an effective screen recording with the provider, so that no time will be wasted for collecting lost screens;
  3. The risks to consider during the development.

Note that this article will talk about using Adobe Captivate for recording and preparing simulations. For the past several years, our company has tried different development tools, and currently Adobe Captivate remains the key tool for preparing software simulations, considering all its restrictions.

However, the aim of this article is to tell not so much about possibilities and trends as pitfalls a customer can face while ordering a software simulation. Though the process doesn’t seem difficult (to record screens, send them to the provider and wait for the new e-course), there is plenty of risks in this process.

Simulation development process

Let’s begin with the development process of a software simulation. It involves the following steps:

  1. Screen recording
    1. Preparation of a computer for the recording
      1. Installation of Adobe Captivate
      2. Preparation of the program for the recording, creating test user accounts, protection of confidential information, possibly – creating a test environment in the program.
    2. Preparation of an expert and a contractor to the recording
      1. The expert should take time to prepare an algorithm of working with the program (i.e. which operations to record).
      2. The contractor is informed of the time and address where to come to record.
      3. The recording. At this stage, photos of devices can be taken, for example, when the simulation is about a self-service machine or teaches a cash-in-transit courier to operate an ATM. In this case, a photographer should also come.
  2. Screen processing and making a demo version.
    1. The contractor prepares the design of simulation elements and assembles a demo version containing several screens for testing by the customer.
    2. The contractor assembles all demo simulations according to the demo version.
    3. The contractor assembles all test simulations.
    4. The contractor can prepare and record voiceover for the simulations. In this case, the user completes the simulation along with the speaker giving hints and explanations on how to work with the program.
  3. Publishing the simulations in SCORM and testing them in the system
    1. If the simulation is a part of an e-course, it should be put into the e-course. Then a SCORM package is created followed by testing the course workability and correct transfer of the statistics to the LMS (Learning Management System).
    2. If a separate simulation is assembled, it is published in SCORM, tested, and the transfer of statistics to the LMS is adjusted.

Tips on the content of the simulation

1. It’s not recommended to record big simulations (containing more than 50-80 shots). Firstly, users simply won’t memorize all the stages of such a long process at once. Secondly, the simulation itself will be very big in size after the processing and will load slowly. If it involves also complicated mechanics, hints, and algorithms – then the risks of technical bugs raise.

2. It’s important to confirm the design of the simulation at the stage of the demo version approval. Many elements in the simulation are created by copying these elements or their styles. Often, making even small amends in the design takes much time as the majority of them are made manually. Redesign in the middle of the development process means the changes should also be made in the finished simulations, which significantly increases the time for the development and also can lead to artefacts and malfunctioning. We strongly recommend avoiding this.

3. Often, the completion path or the program interface changes, which has been the basis of the simulation. As a rule, no additional recording is organized; the contractor only receives updated screenshots. The specialist responsible for creating the simulation should compare the old information with the update by multiple manipulations in Adobe Photoshop (making new screens using the elements and fragments of different shots). Using Adobe Photoshop always takes a lot of developer’s time – this should be taken into account while updating the calendar plan.

4. Additional issues arise when names of clients or the information of an organization are changed in the simulation. That’s why it’s a perfect way to record the software using the names and other information which can be demonstrated. If it’s impossible and the information should be changed in each screenshot of the recorded simulation – be ready for additional time input and ask the contractor for the deadline for this work.

5. If you have decided to add sound to the simulation, the testing of a demo version with the sound in your LMS will be a must as some technical issues while working with the system may arise and should be identified as early as possible. If the amount of simulations in the e-course is quite large (more than 20), the development period will become longer. Not only preparation, recording and cleaning sound takes time but also adding it manually to each slide of the simulation and adjusting the elements of animation to the voiceover. Moreover, sound re-recording traditionally takes a lot of time and requires additional expenses. The text of hints in the simulation is much easier to change. And the last thing: sound in a simulation makes its size times bigger, which negatively affects the speed of loading the course or a single simulation.

Tips on the devices for viewing simulations

Often, simulations are viewed by users on PCs (personal computers). In this case, the majority of risks can be mitigated by an early preparation of the simulation and testing it on users’ devices. If the course containing simulations is planned to be viewed on both a PC and a tablet, a set of mutual restrictions appears:

  • For a tablet, it’s better to record software screens in a larger scale
  • The elements and interactive spots should be made large and thus more comfortable to be tapped. The right mouse click and double click should never be used for menus (on a tablet, both these actions change for a long tap which doesn’t always work well)
  • However, if the e-course is planned to be viewed on a PC, the developers have to make hints about actions separately for a PC and a tablet

The best solution for e-courses viewed on different devices is to make all actions performed by the left mouse click (a single tap for tablets) and inform the user of the keyboard shortcuts used in the real program interface. Yes, these shortcuts won’t work in simulations while viewing them on a PC but it will help to avoid bugs while viewing them on a tablet.

The risk of iOS update is particularly worth mentioning. To a lesser degree it’s associated with PCs and to a greater degree – with tablets. Thus, an iOS can update and cause bugs in a simulation. For example, while viewing a simulation on a tablet, the virtual keyboard will randomly appear and disappear after tapping the screen. It’s possible to address the issue the only one way: to learn about the devices the simulation is going to be viewed on, and be ready for such situations.