Why Captivate has Advanced Actions
Wanting to open up more creative possibilities for e-learning developers, the software architects behind Captivate kindly provided a mechanism allowing non-programmers to customize interactivity of their e-learning content. This all comes under an umbrella term of “Advanced Actions”. It’s really just a simplified method of scripting to customize how Cp e-learning output works at run-time.
For me personally, advanced actions are THE killer feature of Captivate that make it my go-to tool for creating custom interactivity in e-learning courses. Of course Captivate is by no means the first or only rapid e-learning authoring tool to have this capability. In fact most (if not all) other tools now offer some form of support for scripting. As a professional e-learning developer, I also have other rapid e-learning authoring applications in my tool-kit that enable scripting of interactivity. But, for my money, Captivate just seems to take things that little bit further.
Captivate offers four different ways to execute actions and uses the broad term Advanced Actions to encompass them as a whole. Here’s a quick summary of what they are and how they differ from one another:
Adobe just calls these ‘actions’ in the help files, but I prefer to use the term ‘single actions’ because it better describes how they differ from the other types we discuss below. These are the actions you can assign directly to any run-time event via the Properties tab > Actions accordion. Their limitation is that they only allow you to execute one action per event (hence the reason for the name). If you need to execute multiple actions from a single event, then you need one of the next action types. Another limitation of single actions is that you have to set them up each and every time. You cannot save and reuse them as you can with the ones we discuss next.
These are re-usable actions you create via the Project > Advanced Actions dialog (or SHIFT + F9). They allow you to execute one or more single actions in a sequence. After creating a standard action you need to trigger (execute) it using any one of Captivate’s dozen or more run-time events. I don’t personally use many Standard Actions because I find the fact the next type of action much more useful.
I love conditional actions! They are the unsung misunderstood work-horses of advanced actions. Like standard actions they also allow you to execute any number of single actions from a single run-time event, but with the bonus of being able to specify multiple IF>THEN>ELSE conditions that determine whether or not groups of actions get executed at all. This then allows your content to respond to user interaction and make decisions on-the-fly. And this is where Captivate gets really exciting!
The reason I prefer Conditional Actions over Standard Actions is that once you create a Standard Action you cannot add conditions to it later if you should find out your project requires them. You have to throw away your current actions and start again with Conditional Actions. However, you can set up Conditional Actions to work the same way as Standard Actions and then use the condition clauses if you wish at a later date. I cannot count the number of times this approach has saved my bacon in e-learning courses. So remember this: Standard Actions paint you into a corner, but Conditional Actions always leave you with a way out.
Cp7 introduced a new type of action called Shared Actions. In theory they allow standard and conditional actions to be saved in a stripped-down ‘parameterized’ format that can then be exported from one project file and imported into another. In practice they tend to be more trouble than they are worth (in my opinion). Unless the actions are very complex, in the vast majority of cases it’s going to be quicker to set them up again from scratch in the target project. Other than making actions portable across projects, shared actions don’t really allow you to do anything more than the other action types. They’re something to watch for the future but I wouldn’t get too excited about them in their present form.
Can advanced actions really be called ‘programming’?
What you CAN do with advanced actions
So what level of sophistication are we talking about here? Well consider the following examples:
- Create your own custom User Variables and display them in your content at runtime;
- Use dozens of System Variables that Captivate exposes for you;
- Use run-time events to execute Simple Actions chosen from a menu;
- Define a series of actions to be performed in sequence, and save this as a Standard Action that can be reused and executed by events on any number of slides;
- Create IF – THEN – ELSE conditional actions that determine whether or not certain actions (or sets of actions) are executed;
- Create dynamic content that responds to user input;
- Manipulate numeric variable values to calculate results or scores;
- Hide or show objects at run-time;
- Change the appearance of objects to indicate state;
- Concatenate strings to assemble sentences or create your own custom date formats from component system variables;
- Create dynamic navigation menus that indicate which sections a user has completed;
- Simulate navigation components such as tabs, drop-down or fly-out menus;
- Store user details in custom variables and then use these later in the content;
- Create custom quiz interactions;
- Share actions between projects (only in Cp7 and later versions).
The list of what you can do is long and growing as clever Cp authors come up with new ways to bend Captivate to their will.
What you CANNOT do with advanced actions
So what are some of the limitations mentioned above? Here are just a few examples:
Each Cp variable can only store one value. This means you cannot create a variable as an indexed array containing multiple values. Additionally, you cannot assign an object as the value of a variable.
As mentioned above, you can define a series of actions to be performed in sequence, and save this as a Standard Action or Conditional Action to be triggered by screen events or user interaction. But this is not really the same as being able to program with reusable functions. For example, you cannot call one advanced action from another advanced action.
If you need to do something repetitively in software, you will usually end up using a loop. This is a logic structure where the program asks a question, and if the answer requires an action, then it is performed and the original question is asked again and again until the assigned action is no longer required. Captivate has Conditional Actions that allow you to ask questions (IF conditions) and THEN execute actions, ELSE do something else. You can fake a simple loop by create multiple conditional clauses that do essentially the same thing over and over again to roughly approximate effect of a loop. But there are no looping action types per se.
Nesting of advanced actions
You cannot build an advanced action inside another advanced action. If you need to have the same code in more than one action, you have to manually recreate the code in other clauses of the action, or copy and paste lines one at a time. Trust me. It gets tedious fast.
This is an important programming concept that allows you to save code when creating new types of objects by appending or extending existing objects. This just doesn’t exist in advanced actions. So for example, you cannot use advanced actions to define a new type of text caption or highlight box. You cannot extend an existing advanced action. Each must be standalone.
Actions are not reusable across projects
Until Cp7 there was no way to copy actions from one project to another. If you copied and pasted slides from one project to another, all actions and variables were stripped out. (It was actually a useful way to fix a project that had become unusable due to corrupted advanced actions.) The only way to reuse any variables or advanced actions was to build them into your project template and use this template to spawn all new projects.
Now at last with Cp7 there is a new feature called Shared Actions which we will explore in a later newsletter. It’s by no means a perfect solution because in many cases it’s actually quicker to rebuild the action in the new project than to use a shared action. But at least it does offer some hope for the future of advanced action re-usability.
What if I want to go beyond the limitations?
With such a long list of limitations it’s easy to see why hard-core programmers are unimpressed with advanced actions. They’re more accustomed to unlimited creative vistas. But on balance, most Captivate users are NOT programmers. They’ve usually been thrust into the world of e-learning authoring because they just needed to create or deliver training materials. The truth is, advanced actions are really designed for non-programmers.
But that doesn’t mean serious programmers are left out in the cold.