Advanced Actions

PLEASE NOTE: This information was originally posted on my website back in 2014. The method explained in the videos linked below has now been greatly simplified in more recent editions of Adobe Captivate. Instead of hiding and showing lots of grouped objects it is now possible to achieve very similar results using Object States.

Have you ever wanted to add more interactivity to your e-learning course by including a Dynamic Menu Slide with links to sections of your content? You would not normally use this type of navigation for strictly linear e-learning modules.  But if the course module has several content sections and they can be done in any order, a menu slide makes good sense.  

Well in these two video tutorials I show you how to do just that with several progressively more complex examples, starting from a bare bones simple example, up to menu slides that include visual feedback to indicate which items a user has interacted with, and finally to a very complex menu slide.

Start with simple examples first!

The first video below explains how to create very simple menu slides that require only interactive objects. Then it moves on to two more complex examples that require custom User Variables and Conditional Advanced Actions. Don’t worry if yiou are unfamiliar with these concepts as I explain how everything works from the ground up.  

Watch the first YouTube video below to see how all of this is done!

Taking things to the next level

The Infosemantics template for Adobe Captivate has a built-in Dynamic Menu slide that is far more complex than the simple examples explained in the video above. The next video below builds on the concepts explained above and showcases how to use the dynamic slide from the Infosemantics project template. 

If you enjoy creating highly interactive e-learning, you’ll eventually notice there are a number of similar variables and advanced actions you seem to be creating all the time. Wouldn’t it be great if you could save these actions, export them as some kind of file, and then import them again into another project? That’s basically what Shared Actions are supposed to deliver and this article demonstrates how to create, save, export, import, and execute shared actions in Adobe Captivate projects.

This feature was introduced in Adobe Captivate version 7. Unfortunately, there are no good workarounds for sharing advanced actions between project files in earlier versions of Captivate.  So, unless you are currently using Captivate version 7 or later, the information on this page will not be of much use to you.

About replicating actions and variables across Captivate projects

Ever since Adobe added Advanced Actions to Captivate’s long list of features, e-learning developers have been disappointed to find there was no way to transport these actions from one project to another. They were forced to recreate the same sophisticated interactions again and again from scratch in each new CPTX project file.

It was certainly possible to create interactions using advanced actions in a CPTL template file and then use this template to spawn one or more other CPTX project files, thereby allowing the child projects to inherit any actions residing in the parent template. However, once you move from the template file to the CPTX file any changes to the original CPTL have no further effect on child projects. If you created an action that you wanted to use in all other modules of a given e-learning course, tou were again stuck with the job of rebuilding the actions from scratch within each module.

So as powerful as Captivate’s advanced actions may be, they have always suffered from this one big drawback. There was no easy way to export actions from one project file and import them into another. As a result, the ability to share actions between projects has been a standing feature request for years.

Articulate Storyline raises the bar

When Captivate’s main competitor Articulate Storyline first hit the market in 2011, it took a slightly different approach to interactivity which made it possible to copy an entire project slide containing objects events (known as ‘triggers’) and actions, and then paste this slide into another project as a fully functional chunk of interactivity. This enabled developers to build their own library of re-usable interaction slides to easily plug into other projects or share with other developers.

When compared head-to-head with Captivate’s advanced actions, Storyline’s interactivity framework is not quite as powerful. But needless to say, its ability to copy and paste or share interactions across project files has been a highly-praised feature of Storyline from the day it was released.

Adobe strikes back in Captivate 7 with Shared Actions

Not satisfied to see their flagship e-learning authoring tool upstaged by a mere version 1 competitor, Adobe decided to strike back with Captivate 7 and finally plug this functionality gap by introducing Shared Actions, allowing advanced actions to be exported in a format that could be then imported into another project. Then with the update patch to Captivate 7.0.1 Adobe went one step further and made it possible to simply copy and paste entire slides between project files, with all objects, variables and advanced actions taken along for the ride. This is a huge leap forward for the Captivate product and I’ll explain the procedure for copying and pasting slides with actions a little later in this article.

However, there are some areas where I feel shared actions could still be improved:

• The approach taken feels very “programmer-centric” with some technical terms such as “parameters” that may seem a little intimidating for non-technical Captivate users.
• After using shared actions a few times you’re left wondering if it would not have been quicker just to duplicate the existing action or copy/paste the slides instead.
• And lastly, as I explain later in this article, the current implementation of Shared Actions has  far too many ‘gotchas’.

So it’s not a perfect solution, but at least it’s definitely a big step in the right direction.  My gut feeling at this point is that it might take another Captivate version or two before Shared Actions really become as useful as they should be.

Creating a new shared action

Basically, a shared action is like a template for advanced actions. You start by creating a standard action or conditional action, and then save it as a shared action.  Let’s see how this works:

1. Open the Advanced Actions dialog (Project > Advanced Actions or SHIFT + F9).
2. Open the Existing Actions list and find the specific standard or conditional action you want to save as a shared action. In the example shown below I’ve selected a fairly simple conditional action that sets a variable and hides or shows a couple of buttons on a slide.
3. Click the Save As Shared Action button at the bottom of the dialog.
   The Save As Shared Action dialog opens. (Please note that this dialog is modal, which means you cannot interact with any other part of Captivate until you close the dialog again.
4. The first thing you will notice is that the Shared Action Name is inherited from the parent action. Although shared actions are kept separate from standard and conditional actions, I still find it can get a bit confusing if they also share names. So I usually prefix my shared actions with the letters SA_ so that I can immediately tell them apart.
5. In the Description: box, type a simple yet clear description of what this action does. (You may not remember the full purpose of the action in a year or two from now.)
6. By default, the Parameter Name takes the Item Name of the current target object. For each listed Parameter, type a short description to indicate this object’s intended purpose. You can make the description as long as you want but only the first truncated line will appear. (To see the rest of the description, you just need to place your mouse cursor over the line.)
7. Once you’ve completed all descriptions, click the Save button. Captivate immediately notifies you the shared action as been successfully saved and returns you to the Advanced Actions dialog showing the original action on which the new shared action was based.

   Any shared actions you create are immediately added to a special section in the project file’s Library. From here you can export and import shared actions to other projects.

Exporting shared actions

Now that we’ve been able to create a shared action, let’s look at how to export it so that it becomes available in another project file:

1. Open the Library tab and scroll down to the Shared Actions folder.
2. There are two ways to perform the export:
   – Select one or more shared actions and click the Export  icon in the Library toolbar.
   – Right click the shared action and choose Export from the context menu.

   

3. When the Save As dialog opens, navigate to a suitable folder and click the Save button.
   
   Each shared action is exported as a .cpaa file in the target folder location.​

Importing shared actions into another project

Once you have exported shared actions you can then import them to other Captivate project files (as long as the target files are Captivate 7 format or higher).

1. Open the project file Library and scroll down to the Shared Actions folder.
2. Click the Import  icon on the Library toolbar.
3. When the Import dialog opens, navigate to the folder containing saved shared actions.
4. Select one or more .cpaa shared action files and then click the Open button.
   Captivate notifies you of the number of shared actions that were successfully imported to the Library. 

   These will then appear listed there in the Shared Actions folder and will be available from the Advanced Actions dialog.

Importing actions from a shared Library

There is an alternate method of importing shared actions that can also be used to import other objects such as images, audio, and video files that currently reside in another project. This involves sharing project Libraries. 

Here’s how this technique works:

1. Open the Library of the project where you want to import shared actions.
2. Click the Open Library  icon on the Library toolbar.
3. If you have previously opened the Library of another project file then this will already be shown listed. Otherwise, just navigate to the folder containing the project file that contains your desired shared actions and open it. (Please note that the CPTX file in question must not already be open in Captivate at the time.)
4. When the Library of the source project open as a floating tab inside your current project, scroll down to the Shared Actions folder to select one or more actions.
5. Hold down the mouse button to drag the selected actions and drop them into the Library of your current project file.  These will then appear listed there in the Shared Actions folder and will be available from the Advanced Actions dialog.

Create new advanced actions from a shared action

Once you have one or more shared actions available in your project file you can then use them to spawn new instances of the original standard or conditional action as follows:

1. Open the Advanced Actions dialog again.
2. Open the Create from: drop-down menu.
3. Select the shared action you wish to use as a template to create a new action.
4. When a new instance of the shared action is created the Action Name field is left blank. If you followed my suggestion of identifying the shared action with some kind of prefix, then in most cases you should be able to just remove this prefix again to create the new action name. Captivate will warn you if there is another action in the project with the same name.
5. If any variables required by the original action are not present in the project they are automatically created. However, watch out for this next little gotcha. If variables with the same name are already present in the project, Captivate will create duplicate variables with a number appended to the end of the variable name.
6. In the Actions grid, open the drop down list on each parameter placeholder and select an object from within the current project to replace it. There’s a potential gotcha here as well. See the section later in this article about the shared action parameter gotcha.
7. Once your new action is complete, click the Save As Action button at the bottom of the dialog. Captivate notifies you when the script saves successfully.
8. Your new action can now be executed by any run-time event.

Executing shared actions directly

You can also opt to use the Execute Shared Action command and any run-time event to launch a shared action directly. When would this be a good idea? Well, if you have a situation where you may need to use the same action several times with only slight changes to affected objects, then a shared action might save you some time.

The workflow is as follows:

1. Make sure any desired shared actions are present in the project file. If not, either create them or import them from outside the project.
2. Set a run-time event for a slide or interactive object to Execute Shared Action.
3. Selected an action from those listed in the Shared Action: drop-down list underneath.
4. Click the small {P} button to the right of the Shared Action field.
5. When the Shared Action Parameters dialog opens, use the drop-downs to select target objects in this project file to which the shared action line items will be applied. (Note that this is the only case where you will see Parameter Descriptions displayed.)
6. When all parameters are complete, click the Save button to close the dialog.
7. Repeat the above steps for any other slide or event where you want to execute the same shared action. Each separate usage requires you to set the parameters again.

Adobe’s blog post about shared actions also tends to focus on using Show, Hide, and Apply Effect actions. At first glance shared actions may look impressive. However, you won’t usually find any mention of the many shortcomings of Shared Actions. If you’d rather know about the gotchas before you encounter them, read on…I outline the downsides of using Shared Actions next.

The long list of Shared Action “gotchas”

The way shared actions are currently implemented makes them a less attractive option than they otherwise might have been. After reading the following, make up your own mind about using them.

Gotcha # 1 – To edit a shared action, delete and start again!

Once you create a shared action there’s no way to open it up again and make changes to its structure or component actions. Believe it or not, the only way to edit a shared action is to delete the existing one in the Library, create another standard or conditional action the way you want it to be, and then save this as a shared action under the same name as the one you just deleted.

If you think this workflow is somewhat ‘convoluted’, I agree with you.

Gotcha # 2 – Variables cannot be used as parameters

At the moment you can only set actions performed on slides or slide objects as parameters in a shared action. You cannot set variables as parameters. Yet, many (if not most) of the shared actions you create will involve system variables or user variables. Once you start using conditional actions you will definitely be using variables as part of condition statements in decision blocks, as well in action items where variables are assigned values.

For example, the standard action below has an action line item that assigns the value of a variable. If this were saved as a shared action only the second line item that jumps to a slide would be shown as a configurable parameter. The variable would be fixed and unchangeable.

So if you wanted to use an action multiple times in a project, and each new instance required you to change anything related to the variables (e.g. which variable is being assigned, or what value is being assigned to it), then a shared action will not allow you to do that. In my view this is a major gotcha.

Adobe has indicated they are considering adding variable parameters in later versions of Captivate, but until then variables in shared action will remain set in stone.

Gotcha # 3 – Imported variables get duplicated

When you import a shared action to a different project, Captivate checks to see if that project already contains any existing variables of the same name. If it does not find the required variables, then these are automatically created and added to the Variables dialog. So far, so good, but the rest of the story is not so good.

It turns out that if the target project already has some variables that happen to have the same names as those of the imported shared action, Captivate rewrites the names of the incoming variables by appending a number to the end of their name, and then adds these new variables to the list.

The result is the mess of duplicated variables shown above. The only way to clean up this mess is to go through your shared actions and point them back to the original non-appended variable.

But wait, have you forgotten about gotcha # 1 above? You cannot edit shared actions. Doh!

Gotcha # 4 – Parameter descriptions only show for Execute Shared Action

Parameters are what make shared actions transportable from one project to another. They are essentially placeholders standing in for the slide objects that will be targeted with actions when the shared action is used on a different slide, either in the same project or even a totally different project.

At the time you create the shared action Captivate forces you to write descriptions for each parameter, which might make you think these descriptions will be visible as a guide when you convert these shared actions back into standard or conditional actions. Indeed, the Adobe Help files recommend “appropriate descriptions for the shared action and parameters to help you easily identify them when you want to reuse”. This would be the case, if you could see the descriptions again.  But you cannot.

Unfortunately, the only time parameter descriptions will again be visible is when using Execute Shared Action as a single action. Only then does the dialog box show your carefully written text.  So it begs the question, why waste all this effort?

Conversely, when using a shared action to create another action, the parameter descriptions are nowhere to be found. They’re not even used as tooltips or help text. All you see are blank grey drop-downs that allow you to select objects, without really knowing why. After trying to create and use shared actions a few times you’ll find it feels a lot like flying blind. So, before creating your shared actions I recommend you make notes or take screenshots of the parent action line items as a guide for when it comes time to write your description.

Recommendations about using shared actions

So, are shared actions really useful; or more trouble than they’re worth? For my money…Within a project file, I don’t bother using shared actions, I just duplicate the existing actions to create the ones I need.

If you need to use the same action repeatedly within the same CPTX file, and there are no changes required each time you reuse the action, just use the same action each time. You would be mad to use a shared action and have to set up the parameter targets each time.

If you need to repeatedly re-use an action in the same project, with only minor changes each time, then I believe you are better off duplicating the action and just modifying the duplicates.

Consider the following:

• Duplicating an existing action involves a click on the Duplicate Action icon, typing a new name, making any required changes to line items, click Save and you’re done. Finished.
• Using a shared action also involves opening an existing action, clicking the Save As Shared Action button, typing a name, entering parameter descriptions for each item that needs to change, then saving those changes, then creating new actions from the shared action, and changing the blank parameters to point to new slides or objects.

Which of the above seems easier to you? I personally prefer the first option.

Only export and import complex actions, but try copy/paste slides first.

For my money the only place shared actions might conceivably win over other options is when you have a requirement to export actions from one project to another. But now that Adobe has added the capability to copy and paste slides along with all referenced variables and actions with Captivate 7.0.1, this workflow would seem to be a far better solution than using shared actions.

The next section of this article explains this workflow. Check it out and then decide whether you still prefer exporting and importing shared actions.

How to copy and paste actions across projects

As mentioned at the beginning of this chapter, the Captivate 7.0.1 update patch introduced a wonderful enhancement that we developers have been wanting for years. I’m referring to being able to copy and paste objects or slides from one project to another and have all referenced variables and advanced actions also be replicated across to the target project file. This is going to be a huge time-saver for anyone that likes to create complex interactivity and needs to be able to transport it intact from one project to another.

However, there are some points to remember in order for the results to turn out as you expect. So pay particular attention to the following example:

1. Let’s say I have a button on a slide with On Success event set to execute an advanced action called MyConditionalAction. This particular conditional action references two user variables called MyVariable and MyOtherVariable and executes a Show action to unhide the hidden caption above it. (See the screenshot below.)
   
2. Note what happens in each of the following scenarios:
   • If I just copy the button by itself, and then paste it into another project file, the button and the two variables arrive, but the advanced action or the text caption do not. The button’s On Success action is set to Continue.
   • If I copy both the button and the text caption together, then paste them into the other project file, the advanced action as well as all variables arrive safely, with the button’s On Success action set exactly as you see it above.
   • If I copy and paste this entire slide from one project to another, then all objects on the slide (including the caption and button) as well as all variables and actions referenced by the button are replicated in the target project (as shown below)

Rules for copying and pasting advanced actions with variables

So what are the rules governing this behavior? Well, the secret to success in copying and pasting advanced actions from one project to another is to make sure all objects referenced by those actions are also copied over to the new location at the same time. Otherwise the advanced actions will not arrive at the destination. Oddly enough, referenced variables will be copied over, but not the advanced actions.

This principle extends even further. If you are trying to transport an advanced action that references more than one slide (perhaps because it is executed on one slide but contains an action to jump to a different slide), then all referenced slides must be copied over to the new location at the same time, otherwise the advanced action gets removed during the operation. The more complex your interaction becomes, the more slides you may need to copy in order to replicate your advanced actions in the new project location.

Either way, this is still a huge leap forward for e-learning authors the world over and I congratulate the Adobe Captivate development team on pulling off this sizeable miracle of software engineering.

In this article about Adobe Captivate interactivity I introduce you to the wonderful world of conditional actions. If you intend building more sophisticated interactions or learning games in Captivate, then conditional actions are the simplest way to achieve your goals.  I’ll explain how to create conditional actions in the Advanced Actions dialog, how to set up decision blocks, how to configure logical IF > THEN > ELSE condition statements, and much much more.

By the way, please be aware that the concepts in this article require a good overall understanding of several other areas within the overall advanced action functionality. If you haven’t already done so, I recommend you also read the following articles in this series to prepare yourself for what we cover in this article:

• Introduction to Adobe Captivate variables
• Creating editing and deleting user variables
• Displaying user variables at run-time
• Understanding Adobe Captivate run-time events
• Using Single Advanced Actions
• Using Standard Advanced Actions

To begin, let me tell you why conditional actions are my all-time favorite kind of advanced action.

Why I always choose conditional actions over standard actions

In this article explaining Adobe Captivate’s Standard Actions, I said that don’t personally use them in my e-learning projects, preferring Conditional Actions instead. The reason is quite simple:

Conditional actions keep my options open; standard actions don’t.

The issue here is that you cannot add conditions to a standard action to convert it into a conditional action. But you can set up a conditional action to work exactly like a standard action, and enable or disable conditions as needed. So conditional actions are more flexible.

Consider the following examples:

• Example 1 – You build your e-learning interactivity using standard actions and then later find out you really needed to include some decisions. Since you cannot add conditions to standard actions, you are forced to throw away most if not all actions you’ve built so far, and start again using conditional actions.  You’ve wasted time and money.
• Example 2 – You build your e-learning from scratch using conditional actions, even though you don’t think you’ll need to add decisions into the mix. If it turns out your initial assumptions were wrong and you do need your actions to become conditional, then you can easily do so.  The risks are lower.

My belief, based on a lot of real-world e-learning design experience, is that while standard actions end up painting you into a corner, conditional actions give you the best of both worlds. Simple as that.

“Can’t you just design your project first before you build it?”

Now perhaps you’re thinking I prefer conditional actions because I don’t do any up-front design work on my project.  That’s not true. I do spend quite a lot of time designing my interactivity before I create the advanced actions. So how could it actually happen that you do all that work and still find out partway through an e-learning project that your first assumptions about what you’ll need to do were wrong? Well, it happens to me all the time. And trust me, I’m no newbie at creating e-learning.

Some clients (and know-it-all bystanders) have the misguided notion good instructional designers and conceive an e-learning project (using storyboards or whatever), and then build it from end-to-end in one go without changing tack. In over a dozen years building professional e-learning I’ve never seen that happen. In practice you ALWAYS seem to find your initial assumptions were wrong about some aspect of the design. And somehow simple things always seem to turn out to be far more complex than you imagined they would.

It’s for precisely these reasons that I now avoid standard actions in favor of conditional actions every time I build projects with Captivate. I cannot count the number of times this habit has saved my bacon. By all means choose your own path, but don’t say I didn’t warn you.

Creating conditional actions

Now let’s look at the actual process for creating a new conditional action.  It starts out more or less the same as that for standard actions, but the Advanced Actions dialog looks substantially different:

1. From the Project menu select Advanced Actions (or hit SHIFT + F9 keys) to open the Advanced Actions dialog. The default settings will be for creating standard actions, not conditional actions.
2. From the Action Type: drop-down list, select the option for Conditional actions.

At this point the Advanced Actions dialog is reconfigured somewhat to accommodate several additional elements required for working with conditional actions. Let’s look at these extra features in turn.  Firstly the IF Decision Block area, secondly the Actions area, and finally the ELSE actions area.

About decision blocks

The first change you will notice is an extra horizontal section added in the dialog header with three untitled buttons in a horizontal array. These are known as Decision Blocks. The button currently highlighted with blue text represents the block of conditions and actions you’re actually looking at in the tables directly below in the dialog. Clicking one of the other buttons jumps you to a different decision block to show its respective conditions and actions. Double-click the name of any block to overwrite and rename it to something meaningful, but since only about a dozen letters will be visible in the button, you’ll need to keep it succinct.

A conditional action must have at least one decision block, but it can potentially have dozens more. In fact I’ve had more than 30 in a single Captivate 5.5 conditional action working without issue. There does not appear to be a built-in limit. Since you can potentially have dozens of decision blocks in a single conditional action, Captivate provides a set of special controls under the buttons to manage them.

Add new decision block

To add new decision blocks, click the tiny plus  button. Be aware that any new block will be added right at the very end of the line to the far right of all other decision blocks. If you have dozens of them, this can be a bit of a pain, because then you will likely need to reposition the block by moving it as described below. But this is only possible if you have Cp 7.0.1 or later.

Scrolling left or right

Since you can only see three decision block buttons at any given time, the small triangular buttons on either end of the line of decision block buttons are there to allow you to scroll horizontally left or right to access other blocks that are not currently visible. As you can see in the screenshot above, once you reach the end of the line, the scroll button is greyed out (disabled). The fact that a scroll button is black (enabled) tells you there are other decision blocks available in that direction.

Remove a decision block

To remove a complete decision block, first click the relevant button to select it then click the  icon underneath the decision block names.

Duplicate a decision block (Cp 7.0.1 or later)

This feature is only available with Captivate 7.0.1 or later versions. Select one of the blocks and click the  icon. The new block will be added immediately to the right of the one that spawned it, with the letters _1 added to the end of the previous name. It’s a good idea to get in straight away and change the name because in the extra characters indicating this is a duplicate may not be visible on the button, and you may inadvertently find yourself editing conditions or actions in the wrong decision block.

Reorder decision blocks (Cp7 or later)

The two small grey left and right pointing arrows directly underneath the decision block buttons allow you to move the selected decision block earlier or later in the run-time execution order. Small as it might seem, this to my mind would have to be THE most important enhancement to conditional actions since they were first introduced. Believe me. These two small buttons will save you hours of wasted time cutting and pasting condition statements or action line items.

What if you’re on an earlier version of Captivate before 7.0.1?

Users of older versions of Captivate will notice their Advanced Actions dialog does not have the extra buttons that allow you to duplicate and reorder decision blocks in conditional actions. There’s really very little you can do about this other than upgrading to the latest version of Captivate. If that’s possible, I heartily encourage you to do so because these and other enhancements would make it more than worthwhile.

However, the real fun killer for creating conditional actions in earlier versions of Captivate is the inability to change the order of decision blocks after you add them to the line. In this case, if you find that your ideas about which decision blocks you needed were a little short-sighted, and you need to add one or more at the beginning of the execution order, then you’re in for some very tedious cutting and pasting to get them there. In fact, in many cases it’s probably quicker to just create a new conditional action and start again.

Workaround for changing the order of decision blocks in earlier Captivate versions

There’s no way to foresee the future and know in advance where you’ll be wrong about something. (The guy who develops an app for that will be very rich.) So, in practice it’s quite common to discover too late in your development that you needed some extra conditions at the very front of a conditional action.

Once I learned this the hard way a few times, I developed the habit of always leaving two or three spare decision blocks at the front of every conditional action I created. I found that Captivate would generally leave them alone and not complain about them being blank. However, just to be on the safe side, I would add the following condition line to each one:

IF 1 is equal to 2

Since such a condition always evaluates to FALSE, any action statements underneath will never get executed at run-time. I usually name these unused decision blocks SPARE to make their purpose more obvious.

Using this approach, if I found later in the development cycle that I needed to add extra decision blocks to a conditional action before the others, all I had to do was use one of the spare blocks. This practice has often saved me a lot of wasted effort.

Lacking the ability to clone or duplicate an existing decision block is not such a big deal as you can easily copy blocks of condition statements or action lines from one block and paste into another using the buttons provided on the header bar of the Actions table. In fact there will be plenty of times when you need to copy such lines from one conditional action to an entirely different one.

Order of run-time decision block execution

An important point you absolutely MUST understand about how conditional actions work is that at run-time ALL blocks of conditions are executed beginning with the block shown at far left in the dialog header, and moving to the right until there are no more blocks left.

So if you have three decision blocks with condition statements and actions in each one, then at run-time the first decision block will be checked to see if its condition statements evaluate to TRUE, and if so, then its actions will be executed, otherwise no action will be taken and Captivate moves to the next block in the chain, where the process is repeated until there are no more left.

About IF > THEN > ELSE conditions in Captivate

To get comfortable with conditional actions you need to understand the concept of IF > THEN > ELSE. In software programming this is referred to as a ‘construct’ and its purpose is to control the flow of what happens in the application at run-time. You can think of it as being like a fork in a river, or two doors leading out of a room. You can either go one way or the other, but you cannot do both.

Thinking about decisions in this very black or white way might feel somewhat foreign at first, but in reality we all do it every day. For example:

• You either wake up in the morning, or you stay asleep. You can’t do both, right?
• You either get up out of bed in the morning, or you stay in bed.
• You either eat something for breakfast, or you skip it.
• You either go to work, or you do something else.

Expressed as IF > THEN > ELSE statements, the actions above might look something like this:

• IF wake up is equal to TRUE, THEN get out of bed, ELSE stay asleep.
• IF hungry is equal to FALSE, THEN skip breakfast, ELSE eat breakfast.
• IF weekend is equal to TRUE, THEN stay home, ELSE go to work.

So each of your decisions to perform or not to perform day-to-day actions are usually determined by whether or not some specific condition is TRUE or FALSE.

Captivate’s conditional actions dialog is really just showing a typical IF > THEN > ELSE construct:

• IF the conditions in the top of a given decision block evaluate to TRUE…
• THEN execute the action line items in the first section of the decision block…
• ELSE execute the actions in the last section of the decision block.

By the way, it’s not mandatory to use the ELSE section of a decision block. In most cases you just leave these lines blank because you only need to specify ELSE actions if something should happen when the condition evaluates to FALSE.

About condition statements

Condition statements are what differentiate conditional actions from standard actions. In a standard action all actions listed will be executed. In a conditional action, actions will only be executed according to whether their conditions evaluate to TRUE or FALSE.

A condition statement is basically a short phrase that compares one thing with another using a couple of operands either side of a comparison operator sandwiched in-between. (Relax…I explain these terms in a moment.)

To start creating a condition statement, all you need to do is double-click anywhere on one of the blank lines in the Perform action if: section of a decision block. The first thing Captivate will ask you to do is choose your first operand from a drop-down.

Operands

In the programming world, an operand is some value that logic can be applied to in order to make a decision that will control the flow of the software application. (Remember we said your e-learning module is actually a software application too?) Looking at them another way, you can think of operands as being like the nouns in a sentence. They represent things.

As you can see in the screenshot above, Captivate’s drop-down gives only two types of operands:

• Variables – These can be either system variables or user variables. Even though this is the default value in the drop-down, you still need to open the drop-down and choose variable, and then it will allow you to scroll a list of available variables to choose the variable you want to use as the operand. (Yes, I agree that the interface is clumsy. Don’t get me started about that.)
• Literals – This can be either a number or a text string. When you choose this option, you get a text box into which you type your literal value. If your literals are the numbers 0 and 1, or the text strings TRUE and FALSE, you’re really working with what programmers call Boolean values. They’re used like ON/OFF switches to enable or disable actions.

Although having only two types of operands to choose from might not seem like much to work with, in practice it actually gives almost unlimited potential for creating powerful interactivity.

Comparison operators

Each condtion statement added to the Perform action if: section of a decision block, has a comparison operator sandwiched between two operands that are being compared to each other. Operators are like the verbs in a sentence because they do things to the operands.

Captivate offers about seven operators to choose from in the Select comparison operator… drop-down. Each one is explained below:

• Is equal to – This operator compares the two operands to determine if they match exactly. If the operands are the same, the condition will evaluate to TRUE. If the operands differ in any way, it will be FALSE. This one (or its opposite below) is usually chosen as the operator to evaluate a Boolean value in a system variable or user variable.
• Not equal to – This time the operator is looking for a difference between the operands. If they are not the same, then the condition evaluates to TRUE. If they operands match perfectly, the condition evaluates to FALSE. (See also the Is equal to operator above.)
• Is greater than – This mathematical operator compares the numeric values of operands to see if the value of the first operand is greater than the second. If so, the condition returns TRUE. If not, it returns FALSE.
• Is greater or equal to – Similar to the previous operator, but this one will also return TRUE if the operands are equal to each other, as well as if the first one has a higher value than the second. This operator is mostly used when comparing the required passing score of a quiz with the user’s current score to see if they have passed or not.
• Is less than – This returns TRUE if the first operand has a lower numeric value than the second. You could use this operator when comparing the user’s score to see if they have fallen short of a passing score for the quiz.
• Lesser or equal to – This returns TRUE if the first operand is either equal to or lower than the second operand.
• Contains – This operator is very useful as a search operator to determine whether a text string contains a word or combination of letters. For example, you could use it to find out if a user’s text entry contains a specific word or term. It will also allow you to look for a combination of consecutive number characters in a larger number. For example, in the number 1234567890 it would return TRUE if you searched for 567.

WARNING! Don’t try to use math operators on text strings

With any of the mathematical operators shown above you should always be using a number literal, or a variable that holds a numeric value, for both operands. Captivate won’t prevent you from using mathematical operators to compare text strings, but the results won’t usually make any sense, because what happens under the hood is that strings are first converted into numeric values before being evaluated. There are rules governing how a numeric value is arrived at for a text string, but the bottom line is that you’re pretty much wasting your time doing this.  

How conditions control run-time interactivity

So how do conditions, operands, and comparison operators control the flow of your e-learning at run-time?  The basic use-case is that you have one or more actions that must only be executed if certain conditions are TRUE.

For example, the screenshot at right is comparing the value of the UserFirstName variable with the text string “Rod” to see if they are not equal to each other, that is, they do not match.

If they do not match, then the condition evaluates to TRUE and any actions listed below the condition would be executed.

In this case, the action is to Show a text caption welcoming the user, Rod. If the user happened to be named Fred or some other name, he would not see the welcoming text caption.

Stacking up multiple AND / OR condition statements

So what happens if you have multiple conditions stacked up in the decision block? Well Captivate evaluates all conditions to determine whether the overall IF section evaluates to TRUE and the actions underneath will be executed. If the overall result is FALSE, only actions found in the ELSE section at the bottom would be executed.

By default Captivate shows four blank lines in the Perform action if: section of a decision block, but you can really add as many separate conditions as you want. If you add more than four, the section simply adds a scrollbar to accommodate them (as shown below).

Also shown in the above screenshot is the drop-down list just to the right of the words Perform action if: These options allow you to control how the decision block evaluation is made:

Perform action if: All conditions are true

This is the default option. It means that every single one of the condition lines must evaluate to TRUE otherwise the entire block will evaluate to FALSE and none of the actions will be executed.

If you choose this option, each line will show the word AND in the last column at the right-hand end. This is to indicate that the first condition AND the second condition AND the third condition etc must be TRUE.

Be aware that every extra condition line you add further limits the circumstances under which your actions will be executed. So you need to be very careful when building decision blocks with multiple AND conditions, as it’s very easy to get lost in your logic and inadvertently create conditions that will mean your actions NEVER get executed. The limitations are just too tight. (This is actually a common cause of issues reported on the Adobe Captivate Forums where advanced actions are not working.)

Perform action if: Any of the conditions true

This option means if any one of the condition lines evaluates to TRUE, then the entire block will evaluate to TRUE and the actions will be executed. So instead of being restrictive, this option is relatively loose. All it will take is one of the conditions to be TRUE and your actions will get executed.

As you can see in the screenshot below, selecting this option adds the word OR to the end of each condition line. So it’s really saying the entire block will be TRUE if the first condition is TRUE, OR the second condition is TRUE, OR the third condition is TRUE, etc.

Perform action if: Custom

The Custom option is something of an enigma. If you select this option, Captivate then allows you to choose whether each condition line is set as to AND or OR relevant to the next line in the stack. You make this selection via another drop-down in the final right-hand column. (Due to a somewhat short-sighted decision on Adobe’s part to limit the width of the Advanced Actions dialog, you have to scroll the entire decision block sideways in order to open the drop-down menu and make your selection.)

Let me warn you in advance about something here. Trying to mix and match AND with OR statements in a decision block is likely to give you headaches, if not ulcers. But, in order to have them work as you expect, the secret is in remembering that the AND/OR value in the last column defines how that particular condition line relates to the next condition line directly below it. Additionally, the AND/OR on the last line of the decision block plays no part in the overall decision (because there’s no line after it to contribute to the decision).

So here are a few Custom decision scenarios to do your head in:

• If you have AND at the end of a line, this condition AND the next one must evaluate to TRUE in order for both of them to evaluate to TRUE.
• If you have OR at the end of a line, this condition OR the next one can be true in order for both them to evaluate to TRUE.
• If you have three condition statements, with the first two set to AND followed by the last one set to OR, then all three statements need to be TRUE in order for the overall set to evaluate to TRUE. (Remember that the final statement’s AND/OR doesn’t affect anything.)
• If you have three conditions statements, with the first two set to OR followed by the last one set to AND, then only one of the statements needs to be TRUE in order for the block to evaluate to TRUE and the actions below to be executed.

Is your head throbbing yet? If so, I really shouldn’t need to say anything more to discourage you from trying to use the Custom setting on the Advanced Actions dialog? Don’t feel bad about this. In many years of using Adobe Captivate’s conditional actions I have never resorted to using the Custom option. If I have a complex condition where I need to mix some AND with OR statements, I much prefer to separate them out into different decision blocks. I find this gives me much better control and is a lot less likely to get me involved in any logic conundrums.

Completing a conditional action

You’ll be happy to know that once you get past the complexities of working out the logic in your decision block, the rest of what you do when building a conditional action is something of an anticlimax because it’s more or less the same as building any standard action. In the Actions section immediately underneath the condition statements, all you need to do is list all of the actions that should be executed in sequence if the decision block as a whole evaluates to TRUE.

If something should happen when the decision block evaluates to FALSE, those actions must be specified in the ELSE block at the bottom.

And that’s about all there is to it! Don’t worry if the theory of it all seems a bit overwhelming at this point. As soon as you begin creating your own simple conditional actions, the theory falls into place.

Adding multiple decision blocks

Although the ability to add decisions is what differentiates conditional actions from standard actions, what really makes them super powerful is the ability to add multiple decision blocks that get executed one after the other in a specific sequence. This just takes everything to a whole new level because this fact enables e-learning designers to create interactions that potentially execute any number of decisions and any number of actions, from a single run-time event. That’s just awesome!

As mentioned earlier in this chapter, Captivate starts you off with three decision blocks as soon as you choose Conditional action from the Action Type: drop-down. Once you’ve filled them up, all you need to do is click the small button to add another at the right-hand end of the line.

If you try to save a conditional action without specifying conditions, Captivate will curtly warn you.

If you try to save changes with some condition lines or action lines not completed, then you’ll see a different warning box telling you “The Script is incomplete”.

Preview a conditional action

Although the Advanced Actions dialog does a reasonable job of showing the decision blocks and actions involved in a conditional action, it does have some shortcomings:

• If you use more than four lines of condition statements, you must scroll to see the rest.
• You can see a maximum of 8 action lines before scrolling.
• You cannot see IF conditions, THEN actions and ELSE actions in a single view.

Wouldn’t it be nice if you could see your complete conditional action in all it’s glory in a single view?

Well now you can…as long as you have Captivate 7.0.1 or later. Adobe added a small icon  to the button bar in the top right corner of the Advanced Actions dialog. This icon is disabled for standard actions but becomes enabled when you select a conditional action. Just click the icon…

…and the Advanced Actions dialog changes to show a code-based view of your entire conditional action including all decision blocks and their respective actions. Use the small triangular arrows to collapse or expand individual decision blocks, or use the Collapse/Expand toggle button below.

What’s next?

If you’ve been following everything I’ve explained above, well done!  You’re well on the way to becoming an Adobe Captivate expert.  The ability to use conditional actions to create complex interactivity is what really “separates the men from the boys” in the Captivate e-learning world.

There is yet one more type of Advanced Action that you need to know about – Shared Actions.

However, just knowing how single actions, standard actions, conditional actions or shared actions work is not enough to make you a top-earning professional e-learning developer.  You also need to know how to use them to create the kind of sophisticated interactivity that more and more clients are asking for.  That means you need to know which techniques to use in order to solve the day-to-day instructional problems e-learning developers encounter.

I’m talking about use cases that involve the following scenarios:

• Capturing and validating user input
• Responding to different types of mouse events
• Creating toggle actions
• Dynamic navigation
• Date manipulation
• Enhanced quizzing

I’ll be covering these topics in other articles and blog posts.

If you already understand about Adobe Captivate user variables, run-time events, and how to use these events to execute Single Actions, it’s time to begin looking at more powerful tools that are capable of executing multiple actions from a single event.  Single actions in Captivate can achieve quite a lot. But when you need to execute more than one action from a single event, you must use either a Standard action or a Conditional action. 

This chapter discusses Standard actions and how they allow you to set up interactive components that can potentially be re-used in any slide of your project. 

Creating a standard action

To create standard actions (and conditional actions too):

1. From the Project menu select Advanced Actions, or hit SHIFT + F9 keys.

   
   This opens the Advanced Actions dialog and all versions of Captivate 5 onward use it with only minor changes. (The dialog below is from Captivate 7.0.1 which has an extra drop-down menu for Create from: because it’s now possible to create actions from Shared Actions as well.)

   When you first open the Advanced Actions dialog the Action Name field is always empty and the Action Type field is set to Standard actions, so that’s what we’ll be creating by default.

   

2. In the Action Name: field type an appropriately descriptive name that will help inform future developers (including yourself) that may need to maintain this course. Note that your names cannot contain spaces (Captivate will prevent this). But unless you want to crash Captivate, you should also avoid using any of the 100 or more reserved keywords. As mentioned in this article about variable names, I tend to favour CamelCase naming.

   NOTE: Action names are not sorted alphabetically
   One of the many shortcomings of Captivate’s current Advanced Actions dialog is that for some reason the Adobe developers decided not to code the Existing Actions list to sort alphabetically, as they sensibly did with the list of variables in the Variables dialog. Believe it or not, the actions appear listed in the order in which they were created. This is a huge pain in the proverbial for e-learning developers because it makes locating actions in a complex project an unnecessarily tedious task. Rest assured this oversight was pointed out to Adobe and was finally fixed in the Captivate 7.0.1 update patch.  

3. Next, on lines in the Actions table, you can specify what you want to happen when this standard action is executed by a run-time event. In the example shown above I’ve chosen to Assign the value of a variable called MyVariable with a value of 1. 
4. Once you have created your action, click the Save As Action button at the bottom of the dialog. (In Captivate 7 you also have the option to Save As Shared Action, but we’ll deal with that one in the article about Using Shared Actions.)
   When you successfully save your new standard action you’ll see the message at left below.

   
   If you make further edits to the action, click the Update Action button, and you’ll see the confirmation message shown at right above.

5. The Advanced Actions dialog is a modal dialog, which means you cannot interact with other parts of Captivate while it remains open. So after making any final changes to your action, click the Close button to return to editing your project.
6. All that remains now is to set up which event (or events) will execute your new standard action. For example, if I wanted to change the value of my variable when a button was clicked, I could set it up as shown below.

   

A useful difference between standard actions and single actions

Aside from the ability to execute multiple actions from a single event, the standard action type also has another very useful trick up its sleeve. In fact this trick can be so useful it may be worth the extra time to create a standard action, even if it would be quicker to set up to execute a single action.

What I’m referring to here is the fact that, if your timeline happens to be paused when you use the single action type to do something, Captivate then releases the timeline so that it continues playing. However, if you were to perform the same task by using the run-time event to execute a standard action, then the timeline remains paused.

Why is this useful? Well there are times when you may want the learner to do something multiple times without advancing the timeline. And in that circumstance a standard (or conditional) action is better than a single one.

Example: Toggle buttons

Let’s clarify this by looking at a scenario. Say you wanted to create a toggle effect using one button to show and image and another one to hide it. You want your user to do this as many times as they want before progressing to the next slide. So you want the timeline to remain paused while the learner plays with the buttons and then have them click the playbar or another button to continue on to the next slide.

About the interactive pause point

There’s a side issue here you need to be aware of. Many Captivate authors are aware that interactive objects have a pause point indicated by a faint vertical line on their timeline. But they do not realize these objects are only active before they pass their pause point, and are inactive at any point beyond the pause point.

Single actions un-pause the timeline

If you were to execute single actions to try and achieve this, then you’d find when your learner clicked the button, the playhead would continue and your button would stop working because the timeline would have moved beyond the button’s pause point into the inactive portion of its duration (as shown above). So even if the button is still visible on the screen, it’s now disabled and further clicks by the learner achieve nothing.

Standard actions leave the timeline paused

If you were to create the same interaction using two standard actions (one for the SHOW button and another for the HIDE button), then you would find the playhead remained firmly paused as your user clicked away on the buttons to their heart’s content. The ramifications of this seemingly insignificant difference are huge. 

If you want to see this effect in action, take a look at this YouTube video by Captivate expert Lilybiri: https://www.youtube.com/watch?v=M3nKi-DB6Fw

CONFESSION: I always use conditional actions anyway

In the interests of full disclosure, let me say at this point that my personal preference as an e-learning designer with many years of Captivate experience is to always use conditional actions instead of standard actions. There are good reasons for this decision, but to keep this topic as simple as possible, I’ll explain those reasons in the article about Using Conditional Actions.

In any case, don’t skip reading the rest of this article just because I tend to favor conditional actions over standard actions. I’m about to give you a basic introduction to the Advanced Actions dialog. You need to be very familiar with this dialog. So start with the simpler version used for standard actions so that it will be that much easier to get your head around the extra complexities added when working with conditional actions.

A closer look at the Advanced Actions dialog

Now that we’ve seen how easy it is to create a basic standard action, let’s go back and take another look at the menus, buttons and icons of the Advanced Actions dialog. We’ll expand on this information in the other article that explains how to create and use conditional actions.

If you place your mouse over each icon, you’ll see a small yellow tooltip explaining its function. The controls and icons in the header section refer to things you can do to the actual named actions you create or edit with this dialog. The items in the lower grey header bar of the grid section refer to functions performed on the line items below it. 

Managing standard actions

Let’s look first at the controls in the header section of the dialog. These are the ones that allow you to create, edit, or delete the entire standard action.

If you’ve just opened the Advanced Actions dialog, by default the Create from: field will be set to Blank, the Action Type: will be set to Standard actions, and the Action Name: field will be empty. If all you want to do is create a new standard action, then just type an appropriate Action Name, set up one or more action line items, and click the Save As Action button at the bottom of the dialog.

Create from:

If you have saved or imported Shared Actions into your project, these will be listed here as possible starting points for a new action. Otherwise this field will always show as Blank.

Action Type:

Captivate only really allows you to create two types of actions; standard actions (as we’re discussing in this article) or conditional actions.

Action Name:

Apart from allowing you to assign names to new actions, this field also allows you to change the name of any currently selected action by just typing a new name into the Action Name: field and clicking the Update Action button at the bottom of the dialog.

Create a new standard action

Once you have created a new action, or selected an existing action, to create another you just click the icon in the bank of icons at the top right corner. As mentioned above, if you have shared actions in the project, you can also use these as the blue-print for a new action.

Import and export shared actions

Captivate 7 users will see two extra buttons in this bank that were not present in earlier versions. These allow for importing and exporting Shared Actions.

Delete an action

The fact that standard actions also contain single actions (the line items on this grid) can be a little confusing at first. But it’s very important to understand the distinction, particularly when it comes to the Delete and Remove trashcan icons found on this dialog, which both look almost exactly the same.

The trashcan in the grey bar of the grid will only delete currently-selected single action line items. However, the trashcan icon at the top of the dialog will delete the entire standard or conditional action in view. So be sure to think carefully about the objective before you click either one of these icons.

Duplicate an action

If you need to create a new action, and you have already created one that is vaguely similar, just open that action and click the Duplicate icon. This creates a copy of the currently displayed action with Duplicate_Of_ appended to the previous name. Just rename and edit this new action as needed. I use this technique quite often because it can save a lot of time.

The Actions grid

Let’s now look at the grid in the lower part of the Advanced Actions dialog. Each line item in this grid is a separate single action that will be executed in sequence at run-time, starting at the top of the list and progressing downward one action at a time. Since there are no conditions in standard actions, each and every line item you define here will be executed at run-time. So if you don’t want an action executed, you need to remove it by selecting the line and clicking the Remove trashcan (not the one at the top of the dialog).

There are actually three ways to add new line items. But you need to look closely at how these work because their behavior might at first seem somewhat confusing:

Add new line items underneath others

If you click the icon on the far left of the button bank, then this will insert new line items underneath all of the other lines, no matter which one is currently selected.

Insert new line items above others

If you click the icon third from the right (just to the left of the Move up arrow) then this will insert a new line item above the currently selected line item.

Cut/Copy/Paste

This is another method of adding line items, but the difference here is that when you copy and paste a line it overwrites the currently selected line, rather than inserting a line above or below it.

Be careful of this behavior because it can easily catch you out. Although you can cut or copy multiple line items from somewhere else on this or another action, you need to keep your wits about you when you come to pasting because you need to first select a blank line, otherwise existing lines may get inadvertently overwritten and cause your action to be missing required elements at run-time.

Changing the order of line execution

Lines added to a standard action will be executed sequentially at run-time from top to bottom. You can add them in any order and use the Move up or Move down icons to change the execution order.

Tracking usage of actions

The Usage button at the very bottom of the Advanced Actions dialog deserves a special mention.

Once you start getting into creating advanced actions to build complex interactivity, it tends to go to your head a bit and before long you may find you have far more actions in your project than you actually need. So a good periodic culling is in order. But if you try to delete any action that is used on any slide in your project, Captivate will spit up a Warning message box to ask if your sure about this.

Then, if you click Yes, it will give you another warning box informing you that deleting the script is not possible because it is referenced by one or more events. (Why couldn’t it do this the first time?)

So Captivate is trying to prevent you from doing something you might regret. But, in a large and complex project, how will you ever find out which event is referencing this action? That can be like trying to find a needle in a digital haystack.

That’s where the Usage button comes in. Just select your action, click Usage, and the dialog will immediately tell you which slide or slides have events referencing this particular action. Then all you need to do is go back to those slides, unhook the action from the event, and then you can proceed to delete it.

WARNING!  A bug in Captivate 7.0 allows deletion of referenced actions

If you are on Captivate version 7.0, please be advised that it has a bug which means Advanced Actions can be deleted even if they happen to be referenced on some slides in a project. Captivate asks if you are sure about wanting to delete, but it fails to prevent you from deleting when it should.

This bug is easily resolved by installing the free 7.0.1 update patch available via the Help > Updates menu within Captivate.

Editing Variables from within the Advanced Actions dialog

Keen-eyed readers may have noticed that the Advanced Actions dialog also has a Variables button at the bottom. This allows you to call up the Variables dialog to create or modify user variables at any time, even while creating or editing standard or conditional actions.

This is quite a time-saver because these dialogs are modal, which means that only one of them can be active at any time. Without this button, if you needed new or modified variables, you’d be required to close the Advanced Actions dialog, use the Project menu to open the Variables dialog, make your changes there, and then back-track to the Advanced Actions dialog again.

Next stop conditional actions. That’s where the real fun begins!  And if you want to transport your standard or conditional actions to other projects, you may also find this article about shared actions very interesting.

Advanced Actions are a key feature that sets Adobe Captivate apart from most other authoring tools, allowing e-learning authors to create highly interactive learning experiences. In combination with Captivate’s interactive objects and run-time events, advanced actions allow you to add dynamic interactivity and logic to e-learning content so that it responds to actions taken by participants.  In short, advanced actions can make your content come alive!

The term “Advanced Actions” in Adobe Captivate covers all of the following types:

• Single actions – The simplest type, where only one action can be executed by any single run-time event. (Covered in this article.)
• Standard actions – That allow any number of single actions to be sequentially executed by a single run-time event.
• Conditional actions – The most complex type. These allow groups of actions to be executed depending on whether or not specific conditions are met.
• Shared actions – These allow standard or conditional actions to be saved in a format that allow them to be exported from one Captivate project and imported into another.

In this article I only explain the simplest action type. In the Captivate interface they are just referred to generically as “actions”.  But I’m using the term “Single Actions” here to clearly differentiate them from the other more complex actions types that will be covered in other articles in this series. 

About Single Actions

As their name implies, you can only execute these actions one at a time using run-time events to create simple interactions. However, don’t underestimate their power. Single actions can be grouped together and executed sequentially (within Standard Actions) or selectively (within Conditional Actions) to create incredibly complex interactions.

When you encounter a drop-down list of actions that can be executed by a given run-time event, you will usually see an imposing list something like the one shown at right.

Let’s take a closer look at each specific action to see how they may be useful in an e-learning context. In most cases the name gives a good idea about what the action does but there are often subtle nuances about the way they work.

Note that the actions listed below are shown in the same sort order they appear listed in the drop-down menus (which is very obviously not done alphabetically). The list at right is from Captivate 7.0.1; the current version at time of writing. Be warned that some actions will not be available in your particular Captivate version. 

Continue

As its name suggests, this action simply tells the timeline to continue playing. You may need to use this if the timeline has been paused by another action.

This is the default action for On Enter slide events and up until Captivate 5.5 it was also the default On Success action for buttons and click boxes.  (As of Captivate 6 the default has now changed to Go to the Next Slide.)

Go to the previous slide

This action jumps back to the first frame of the previous slide in Captivate’s internal slide order. This will be the current slide number minus 1.
Note that this is not necessarily the last slide you visited because you may have jumped to the current slide from a slide somewhere else in the project entirely.

Go to the next slide

This action jumps playback to the first frame of the next slide in the order. This will be the current slide number plus 1. Since Captivate 5.5 this has been the default On Success action for buttons and click boxes.

Go to the slide last visited

Captivate remembers the number of the last slide you visited prior to the current one and you can use this action to jump back to that slide. This works in much the same way as a browser Back button, but only for one jump. So if you jumped from slide 10 to slide 20, executing this action would jump you back to slide 10 again. However, since Captivate does not remember your history beyond one jump, if you were to execute this same action again, then it will jump you to slide 20 again. You would just bounce between the last two slides forever.

Return to Quiz (Cp6 or later)

This action was added in Captivate 6 as part of a quizzing enhancement called Remediation. It’s actually a bit too complex to explain here. So, I recommend you study any information you can find online about setting up remediation in normal and quiz slides.

Jump to slide

This action is dead simple. You just select a slide by number or by name to jump to. One limitation is that you will not find your current slide listed. So you cannot use this action to replay the current slide. But there is a way around this. You can create a standard action that points to this specific slide and execute it via some interactive object on the current slide.  This workaround will allow you to replay the current slide at any time.

Open URL or file

This action is very popular with e-learning developers because it allows you to create what is effectively a hyperlink to another web URL or even a file on your local hard-drive or network LAN. However, it’s also one of the actions that accounts for a lot of support calls because many Captivate authors do not understand its inherent limitations.

Specifying a new browser window

One of the other little peculiarities with this action is that when you specify the URL to be called, you also need to specify in what browser window it will open.

By default Captivate will use the Current window, which would mean opening the URL would jump your user away from the e-learning module. If you are using a SCORM-compliant LMS this would likely sever the communication link with your course and result in loss of scoring data with unhappy users and clients all round.

As the screenshot above shows, Adobe has kindly provided a way to specify that the link should open in a different window (New, Parent, or Top), but most Captivate authors don’t know about this feature because it’s hidden underneath an insignificant-looking down-ward pointing arrow beside the URL field.

Continue Playing the Project

Also take care to note the option right at the bottom of the screenshot to Continue Playing the Project. This only becomes enabled once you select anything other than the Current window as the target. Beware of this option because it’s easy to miss the fact that it gets selected by default when you choose a new target window. There is a downside to allowing this to happen.

If your course continues playing while your learner is viewing content in a different window then they will likely miss seeing something important. If you deselect this option then your course content will be paused while the learner views the content in the new browser window that opens for them. Once they finish with that, they can return to your course and click the Play button on the playbar to continue.

Linked files need to be placed inside the published folder

When using this action to open a file (as opposed to a URL) many authors expect that Captivate will magically place the linked file inside the published folder for them. They may think this because that’s exactly what it does when you insert Event Video files. However, unfortunately it doesn’t do the same with ordinary files. So the best method to ensure your links work after publishing is to manually place the file inside the same folder where the published SWF files will reside. If you do this then all you need to specify as the link to the file is its filename. Nothing more required.

Open another project

This one is a bit misleading and I personally recommend you avoid using it entirely for that reason. It supposedly allows you to create a link to another Captivate project. In fact, when you select this action the Project drop-down menu underneath list names of recent CPTX files you have opened. However, when you select one of these projects as the link target, what you are actually linking to is not the CPTX file, but the HTM file of that project’s published output. Confused already?

It actually makes sense if you think about it, because what would be the sense of creating a direct link to the CPTX project file in an e-learning lesson intended for end users that do not have the Captivate application on their system? Since you are actually linking to an HTM file anyway, I personally see little point in using this action. I prefer to use Open URL or File instead.

Send email to

Captivate authors can often be seen posting questions on the asking how to send an automated email from an e-learning lesson, usually with some kind of quiz scoring information attached. While the name of the Send email to action might seem to suggest it offers a solution the truth is (as usual) somewhat different.

All this action really does is spawn a new email item in your end user’s email client software by calling a mailto: link. So if your end user has MS Outlook and they click a button with this action set to be executed, then they will see a new blank Outlook email item open. That’s it. Nothing more. The end user would still need to complete the email and click the Send button. There’s no way with default Captivate functionality to avoid the end user seeing what the email says.

The truth is that if you want to send automated emails that deliver data from an e-learning lesson without learner intervention, then you need to use custom JavaScript programming and deliver your content from a web server.

Using parameters in the email address

On a brighter note, it is actually possible to at least save the end user some work by pre-populating the Subject line of the email with some text. To do this you just need to add a parameter to the end of the email address you type into the Address field in Captivate. So for example if the email address you need to send to is: me@mycompany.com and you want the subject line to be: About this e-learning course, then here is what you would need to type into the Address field:

me@mycompany.com?subject=About%20this%20elearning%20course

The %20 characters placed in between the words in the subject line are magically replaced by spaces when the new email opens.

But that’s not the limit of what you can do. If you also wanted to specify some body text to populate the email in addition to the subject line then all you need to do is add an ampersand at the end of the address shown above and another parameter. So it might finally look something like this:

me@mycompany.com?subject=About%20this%20elearning%20course&body=Whatever%20you%20needed%20to%20say

When the new email opens, this is what it would look like:

There’s quite a lot more you can do with email links but we don’t have time to go into all of it here.

Execute JavaScript

This action allows you to execute some JavaScript code from within your published module at runtime. If you know something about JS code then this might seem like a good idea. All you need to do is click the small Script_Window button under the drop-down menu and then enter your code into the JavaScript dialog. Simple, right? Well…not as much as you would like.​

The best way to use JavaScript in Captivate is actually to put all of your code variables and functions in Captivate’s HTML template so that it’s already there when the file gets published. An alternate method is to use a custom JS file that you add as a linked include file in the HTML template. If using the latter method then you need to make sure your custom JS file is placed in the publish folder so that it is available at run-time. Once you have this set up, then you can just use direct function calls in the JavaScript window rather than having to type in all the code.

Execute Advanced Actions

This is the action that opens up universes of possibilities for your interactivity. It allows you to use any run-time event to execute either a standard action or a conditional action.  

Execute Shared Action (Cp7 or later)

This was added in Captivate 7.0. It will be disabled in the drop-down list unless you have at least one Shared Action created in your project. (For more information, see the article on Using Shared Actions.)

Play Audio (Cp6 or later)

First added in Captivate 6, this action allows you to trigger playback of an audio file. You cannot select an audio file currently residing in the project file Library, or alternatively, import sound files that reside in some folder on your hard drive or networked LAN drive and add them to the Audio folder in the Library.

Also take special note of the drop-down arrow at the end of the Audio file field. The option here, selected by default, will mean that the slide playback is paused for the duration of the audio playback and then resume afterward. If the audio file is lengthy, it makes sense to use this option. However, if the clip is merely a brief sound, such as a pop or a click used as a sound effect or feedback, then it is probably unnecessary to pause playback.

Another little wrinkle you need to be aware of is that if you set up multiple interactive objects on a slide to trigger audio, then each one will terminate any audio initiated by other Play Audio actions.

Stop Triggered Audio (Cp6 or later)

Following on from the previous action, this one allows you to terminate playback of a currently active audio clip, as long as that audio clip was initiated by the Play Audio action. You don’t need to select which audio clip to terminate because, as mentioned above, there can only be one audio clip playing as a result of a Play Audio action. This action has no effect whatsoever on background audio, slide-level audio, or object-level audio.

Show

This action, along with its sibling Hide action below, will likely end up being one you use more than any other. If you deselect the Properties tab > Visible in output setting of a slide object, then it will be published with the project but simply not visible at run-time. You can use the Show action to make the object visible in response to some learner interaction, such as clicking a button or getting a correct answer to a question. Logically, you can only Show an object if it’s already hidden, and you can only effectively Show objects on the slide you are currently viewing.

Hide

This is the opposite number for the Show action above. It basically just sets any slide object’s visibility to OFF, thus hiding it from view. The object is still there on the slide but not visible to the user.

Don’t underestimate the power of these simple Show/Hide actions. They open up enormous creative possibilities because they give you the power to change the entire appearance of any slide at run-time.  They’re very cool!

Enable

The Enable and Disable actions work in a similar way to Show and Hide, except that these two can be used to enable or disable interactive objects such as buttons, click boxes, Smart Shapes, etc. Again, before you can enable an object, it must be currently disabled. That’s where the next action comes in.

Disable

Use this action to disable an interactive object so that it can no longer execute actions. This action can be reversed by the Enable action. The ability to enable or disable objects at runtime is very handy because it allows you to create scenarios where some things become inoperable (even though still visible) in response to user interaction. It’s basically like turning something on or off. Additionally, you can pair these actions with Show/Hide actions for even more powerful effects because then you can even change the appearance of the object being enabled or disabled.
One small caveat: The Enable/Disable actions have no effect on interactive widgets or quiz question slides. Just in case you were wondering…

Assign

This is another action that you are likely to use in almost any interaction you create. It’s the action that allows you to change the value of a variable. In most cases you will be assigning the value of a user variable, but there are a handful of system variables that are not READ-ONLY and can also be changed. 

Assigning with variables or literals

Variable assignment requires that you use either another variable, or a literal (an actual number or text string). These are the only two choices and you select them from the drop-down that appears whenever you choose assign as the action you intend to perform. It works the same whether you are assigning a variable from a single action, a standard action, or a conditional action (as shown below).

You can to assign a variable with the value one of the system variables that appear in the drop-down list. However, it’s more likely you’ll be using another user variable instead. For example in the screenshot below, the ErrorMessages variable is being assigned with the value of another user variable that contains the default error message text for invalid data.

Your other choice is to assign the variable with a literal, i.e. an entered number or a string of text characters. For example, instead of using a variable as shown above, you could just type in the error message as a literal text string. (Captivate automatically surrounds multiple words or phrases with double quotation marks to preserve the spaces between the words.)

Which is better, assign with a variable or a literal?

In most cases I recommend you should try to use a variable. Every time you find yourself typing in literal values, stop and think about whether or not you’ll be doing this more than once. If there’s a good likelihood you’ll need this same text somewhere else in your project to assign another variable or display on screen, then you are almost certainly well-advised to create a new user variable holding the literal text as its default value. Then you can just use this variable anytime and anywhere you want. The other advantage of this approach is that if you discover that you really need to change the variable text, all you need to do is open up the Variables dialog and change it once there. You do not need to remember everywhere you may have used this text in your project.  Captivate CPTX files can easily handle hundreds of user variables if you need that many.

Increment

This action performs some simple math on the value of a numeric variable, to increment or increase it by whatever number you specify.

Decrement

This is the opposite number for the Increment action. It decreases the value of a numeric variable by whatever number you specify.

For example, in the screenshot at right the On Success event will decrement or decrease the value of MyVariable by 5.

Note that Increment and Decrement actions will not have any effect if applied to a variable assigned with a text string instead of a number. If you try to Increment or Decrement a string variable, all that will happen is that your number will be applied as if it were a character. This won’t compute, so your variable will likely show a NaN error. (NaN is short for Not a Number). Since Captivate variables are not strongly typed to prevent being assigned invalid values, it’s left up to you (the designer) to ensure this kind of foolishness doesn’t occur.

Pause (Cp7 or later)

This action simply pauses the timeline, but as far as I can see from my own testing, it only seems to allow you to do it once per interactive object, even if the playhead is still in the active portion of that object on the timeline. This is a bit weird and pretty much makes this action something of a “one trick pony” that is little more than useless.

If you want a way to pause the playhead at any point on the timeline, you would be better off setting up a standard or conditional action that assigns the value of the cpCmndPause system variable to 1 and then use an event to execute this action. You can then use another event (or execute a different action) to trigger the Continue action. This setup will give you unlimited control over pausing or playing the timeline.

Exit (Cp7 or later)

This action was added in Captivate 7.0.1 to supposedly address issues with closing down playing windows at run-time. This has been an area of loud complaint in the Captivate User Forums for some years now. The action does appear to work, and will even close individual browser tabs, but in most browsers you will still get a message box like the one at right asking you to confirm the action being taken.

Exiting LMS SCORM Players

This action may still not address issues in all cases, especially where content is playing from an LMS SCORM Player. These players often make use of framesets and the Captivate content may be buried one or more layers deep down in the browser architecture. In such cases an Exit action needs to specify the exact child level at which the user’s browser is displaying the content, otherwise it may not be able to close the window.

It’s not usually a good idea in a SCORM setting to try and close the content window anyway because this may mess with the communication that needs to happen between the course module and the LMS to transmit and receive data about the user’s assessment score and other interactions.

Apply Effect

This action allows you to modify a screen object by applying one of the Effects available within Captivate. You need to select the object (by Item Name) to which the Effect will be added and then click the box at far right with the ellipsis (…) to finally choose the effect to be applied.

If you have defined and saved any custom effects then you can specify them to be applied once you are into the Effects dialog.

Toggle (Cp7.1 or later)

This action is a real timesaver for e-learning authors. Even though creating a toggle button wasn’t really all that difficult with any version of Captivate, it still required using at least a standard or conditional action. The way this action works is that you just need to select the name of a user variable, the value of which will be toggled between 0 and 1. If the starting value of the variable is a string, this will be immediately set to 0 on the first execution of the Toggle action. From then on every time the action is executed the value will alternate between 0 and 1.

If you’re wondering whether or not this can be used to toggle the value of system variables, the answer is yes. However, you’ll find that most system variables are READ-ONLY, and of the ones that can be assigned by actions, none of them appear for selection in the Variables drop-down of the Properties tab. So you’ll need to resort to using a standard or conditional action to access those variables with a toggle action.

As with all single actions, you need to remember that the default behavior after executing the action is to un-pause the playhead and if you want the playhead to continue paused then you really need to set up a standard or conditional action instead. With the Toggle action this is likely to be your best option because in most cases you’ll probably want to allow the user to use the action repeatedly while remaining on the same slide.

Show TOC (Cp7.1 or later)

This action simply expands an Overlay TOC. It works in exactly the same way as setting the system variable cpCmndTOCVisible to 1. (See also Hide TOC.)

Show Playbar (Cp7.1 or later)

This action restores a playbar that has been recently hidden by assigning the cpCmndShowPlaybar system variable to 0. Please note that it will not magically give you a playbar if you haven’t already set one up in Edit mode. (See also Hide Playbar.)

Hide TOC (Cp7.1 or later)

This action collapses an expanded Overlay TOC so that it disappears from view. It basically sets the system variable cpCmndTOCVisible to 0. (See also Show TOC.)

Hide Playbar (Cp7.1 or later)

This will make the playbar disappear by assigning the cpCmndShowPlaybar system variable to 0. (See also Show Playbar.)

Lock TOC (Cp7.1 or later)

This action sets the value of the cpLockTOC system variable to 1 which then disables user interaction with the TOC. This means that although the TOC is still visible to the user, it will not respond to clicks. Unfortunately, there’s no visible indication to the user that this is the case, which can result in some potential frustration when all of a sudden the TOC stops working. So I recommend that if you do use this or any other action to lock the TOC then you should also have some caption or image on screen to clue the user into this change of circumstances. (See also Unlock TOC.)

Unlock TOC (Cp7.1 or later)

This is the reverse of the Lock TOC action. It assigns the cpLockTOC system variable to 0 so as to re-enable user interaction and navigation. (See also Lock TOC.)

No Action

And finally for those times when you want nothing to happen when an event is registered you can set it to No Action. In Captivate 5.0 the default On Exit event for slides was Go to next slide. But this was changed in Captivate 5.5 and later versions to be No action. The slides still progress as normal.

Why are some actions disabled or missing?

Novice Captivate authors often become alarmed when they open the drop-down list beside a given run-time event and find certain actions are disabled, as shown in the screenshot at right. There are actually good reasons for this behavior:

Missing Show / Hide

These actions will only be available if there are objects on the slide that could be shown or hidden, e.g. text captions, highlight boxes, etc. If there are no such objects, then Show/Hide actions are impossible and those actions will be disabled in the event’s action menu.

In the example screenshot at tright, the Apply Effect is disabled for the same reason. There’s no object on the slide to apply it to.

Missing Enable / Disable

These actions can only be applied to interactive objects such as click boxes, buttons, and text entry boxes. So these actions will therefore only be available if you have at least one interactive object present on the slide.

Missing Increment / Decrement

These actions only appear if there are user variables in the project that can be manipulated.

One little point here…even though Boolean variables can be set to 0 or 1 via advanced actions, system variables don’t appear in the list of variables you can select for manipulation via increment/decrement actions, so they don’t get taken into consideration here. (Most system variables are READ ONLY anyway.)

Solution: Supply the correct conditions for these actions to be enabled

All you have to do is add the appropriate objects to the slide that correspond to the types of actions required. In the case of increment and decrement actions, you need to have at least one or more custom user variables already set up in the project.

About Expressions

There is one type of action you will not find listed among the single actions and that is the Expression action. These are only ever available from within the Advanced Actions dialog that you use when creating or editing standard (as shown below) or conditional actions.

You may recall that the Increment and Decrement actions allow you to increase or decrease the values of numeric variables. Basically this amounts to just performing on-demand addition and subtraction. Expressions allow you to take this a couple of steps further to perform more complex math using multiplication and division, as well as addition and subtraction.

But it gets better…  Not only can you specify a literal number as the amount to be used in the calculation, you can also opt to use the value of a variable.  This means you can modify the value of one variable by adding, subtracting, multiplying or dividing with the value of another variable.

Now, stop and think about this concept for a moment. It may take a while before the possibilities of this hit home, but once you get your head around it, you’ll find that Expressions open up lots of creative possibilities for your e-learning interactions.

Can you use Expressions to concatenate strings?

Strictly-speaking, Expressions are really only designed for doing math, but they can also be used (to a limited extent) for concatenating strings, as shown in the example below.

In the screenshot above you can see the ErrorMessages variable is being concatenated with another variable (Msg_Error_UserFirstName_IsNULL). Later condition blocks in this same conditional action can continue to concatenate extra messages to add to the information being displayed in the error.

However, as mentioned above, this kind of use is not what Expressions were really intended to do. Captivate badly needs some more actions that can be used for manipulating strings of text.

Where to next?

Now that you have a good knowledge about Single Actions, you should move on to learning about their more complicated cousins, Standard Actions and Conditional Actions. 

In this article I explain Adobe Captivate’s concept of events and how they work in e-learning, as well as list all the events available to you as a developer when  working on a typical project file. Although you don’t need always need to use events in order to create, edit or display Captivate variables, you cannot use Captivate’s advanced actions without using events to ‘trigger’ or ‘execute’ them. So a good understanding of events is essential to mastering advanced actions.

In technical terms Captivate e-learning is known as being “event-driven”. This is just a fancy way of saying that what your learner sees on their screen at run-time is the result of some change that occurs within the e-learning application.

There are only really about a dozen different events to choose from. But as you read this chapter you may be surprised at how complex some event scenarios can become.  And deciding exactly which ones to use when designing your interactions can be something of an artform.  So let’s get started!

What is an ‘event’

Events are points at run-time of an e-learning module where something happens or changes. In the software programming world, events usually have names beginning with the word On.

For example, look at these events and their meanings:

• OnClick – something got clicked;
• OnMouseOver – the user placed their mouse cursor over something on screen;
• OnMouseOut – the user moved their mouse cursor away from something on screen;
• OnKeyEnter – the user hit a key on the keyboard.

In the software world events are used to call functions, i.e. do stuff. In Captivate, events are used to execute actions in your published content at run-time, i.e. do stuff.

Captivate’s run-time events have slightly different names to those shown above, but the same general concepts apply. They usually start with the word On (though there are some exceptions), and the name of the event gives you some idea about what happened or what changed to ‘register’ the event.

We’ll first consider events exposed by different types of slides and then look at events from objects present on the slides. Some Cp objects have no events, while others can have several.

Slide events

Master slides are the only Captivate slide type that doesn’t offer events to execute actions.

Normal slides

All normal slides have the following two events:

• On Enter – This occurs when the slide enters the timeline at run-time.
• On Exit – This event fires after the slide exits the timeline at run-time. It’s important to note this fact because it means any actions triggered happen on the next slide, not this one.

These events are clearly visible when you select a slide in the filmstrip and then look at the Properties tab > Action accordion. The drop down menus beside these events show the currently selected action each event will execute.

Why you should avoid using the On Exit event

You may have noted that the example above has no action set for the On Exit event of this slide. There’s actually good reason for this. The On Exit event is only fired after the slide reaches the very last frame on its timeline. This means any action assigned to the On Exit event would only be executed at the beginning of the next slide, not the slide you intended. Additionally, the final frame of a slide is often never reached because your user interacts with some object (e.g. button, playbar, or TOC item) that navigates them immediately to another slide in the project. This would mean the On Exit action would never get executed.

So, since you cannot always predict how users will navigate your course, it’s usually best not to use On Exit for anything critical. If you set the On Exit event to No Action, the slide will still progress to the next slide when it reaches the end of its timeline.

The most useful slide event of all is always going to be the On Enter event because it always gets fired for each slide, no matter how the slide was called.

Question slides

Question slides have the following events:

• On Enter – As with normal slides, this event occurs when the question slide enters the timeline at run-time. Question slides don’t have an On Exit event. If you look on the question slide’s Properties tab > Action accordion, the On Exit event is disabled.
  This is because the On Success and On Last Attempt events actually replace the need for an On Exit event. The only way you’re supposed to end up leaving a question slide is after either succeeding or failing to answer it correctly.
• On Success – This occurs when the question is correctly answered by the user.
• On Last Attempt – This occurs when the user has answered the question incorrectly and has no more attempts available for use.

About the Multiple Choice quiz question Advanced Answer Option

While we’re discussing quiz question slides, it’s worth mentioning the Multiple Answer (radio button) quiz question type has a special trick up its sleeve that gives you yet another event you can use. It’s called the Advanced Answer Option and it allows you to execute an action based on the specific answer option a user selects from the radio button array in the quiz question.

This means you could choose to play a sound, show a different feedback text box, assign a value to a user variable, or execute any number of other actions based on which answer the user selects. What you do is entirely up to your imagination and creativity.

However, don’t get too excited about the Advanced Answer Option. It is only available with the Multiple Choice quiz question type and no other. You can of course fake a True/False quiz question by creating a Multi-choice question with only two answer options. But there is no way to use advanced answer options with Multi-answer (checkbox) quiz questions.

To get really creative with quiz questions, sometimes you just need to create them from scratch yourself.  But that’s a whole other topic…

The Quiz Result slide

Like question slides, the Quiz Result slide also has three events, but two of them are a little difficult to find because technically they are related to the quiz itself and would occur even if the Quiz Result slide were hidden or not present.

• On Enter – This occurs when the Quiz Result slide enters the timeline at run-time. Like quiz slides, Quiz Result slides also have the On Exit event disabled.
• If Passing Grade – This event occurs if the user successfully passes the quiz. It’s roughly equivalent to the On Success action of a quiz question.
• If Failing Grade – This event occurs if the user fails the quiz and has no more attempts allowed. So it works in much the same way as the On Last Attempt event of a quiz question.

Like all of the previous slide types, the On Enter event action for a Quiz Result slide is configured from the Properties tab > Action accordion. But you won’t find anywhere on the Properties or Quiz Properties tabs to configure actions to be triggered by these other two events, If Passing Grade and If Failing Grade.

So where are they? Well it turns out you need to go to the Preferences > Quiz > Pass or Fail screen to find them.

However, there is something important you need to know about these two quiz events. They are only capable of triggering actions AFTER the quiz has been evaluated as passed or failed. That means these events only fire after you click the Continue button on the Quiz Results slide. Or, if the Quiz Results slide is hidden, they only fire after exiting the final quiz question slide in the quiz.

You should also be aware that setting Allow User Attempts to Infinite will effectively mean you can never fail this quiz because the term Infinite Attempts in Adobe Captivate actually means Infinite UNSUCCESSFUL Attempts.

Interactive object events

Now let’s look at the events you can use with screen objects, starting with interactive objects. In Captivate’s world an ‘interactive object’ is defined as any object that can evaluate to a Success or Failure condition. In Captivate you always know when you are dealing with an interactive object because you will see options on the Properties tab to enable or disable Success and Failure captions.

Listed below are the main types of interactive objects you will be using to execute advanced actions.

Buttons

Captivate offers four button types to choose from:

	Text buttons – A simple button object with text label.
	Transparent buttons – So named because you can set the value of Fill Alpha down as low as 0% to make them invisible (like click boxes).
	Image buttons – These are actually composed of three images, one each for Up, Over, and Down states. The area occupied on screen by the button itself corresponds to its ‘hit area’. Captivate comes with about 30 image buttons you can choose from, but you can also create your own with any decent graphics editing software application.
	Smart Shape buttons – When used as a button, a Smart Shape becomes a clickable interactive object with its own hit area. Smart Shape buttons have up, over and a down states. The down state (when the button is clicked) reduces the dimensions of the button by a few pixels but otherwise does not change its appearance. You can also add other custom Object States if necessary.

Click boxes

A click box is effectively an invisible ‘hit area’ that you can place over the top of other objects to make it appear as if those objects are clickable, when in reality the user is registering a mouse event via the click box instead.

Text-entry boxes (TEBs for short)

A TEB is essentially an input field that accepts numbers or text strings entered by the user, and then stores this data in an associated user variable. You need to turn on Validation in order to have the user input checked against one or more correct answers so as to register Success or Failure events.

TEBs are very versatile and useful interactive objects, but they also have a few extra wrinkles you need to be aware of.

Interactive widgets

These are small pieces of software written in JavaScript (if designed to be compatible with HTML5 output). Widgets extend the capabilities of Captivate beyond what it could do out of the box. But they are hard to pin down and describe because they may potentially be any kind of interaction the widget designer/developer can imagine and is clever enough to create. They are classed as interactive objects because they can also evaluate to either a Success or Failure condition and thereby trigger actions. However, exactly what constitutes success or failure is really up to the widget developer to decide.​

All interactive objects have at least two events that can be used to execute actions. These events are clearly shown if you select an interactive object and then go to the Properties tab > Action accordion. For example, the screenshot below shows the events available for a button.

On Success

This event occurs when the object evaluates to a success condition.

• In the case of a button, click box or Smart Shape (used as a button), clicking within the object’s hit area is all that is required to register success.
• For a TEB, if Validation is not turned on, success may simply mean the user has typed something into the field provided and clicked the Submit button or hit the ENTER key on their keyboard. However, if Validation is also turned on, then success means the user’s input was checked and evaluated to be a match to one of the pre-configured correct answers.
• For an interactive widget, success is whatever the widget developer designed it to be. For example, if the widget is a drag and drop interaction, then success would be achieved by dropping objects on their correct targets. With widgets the possibilities are almost endless.

On Last Attempt

This event occurs when the object evaluates to a failure condition AND the user has no more attempts remaining. Take special note of the last part of that sentence about remaining attempts, because this is an area of confusion for many Captivate authors that I explain in this other article where I discuss what Unlimited Attempts really means. If the user still has any more attempts remaining, then as far as Captivate is concerned, they haven’t as yet failed the interaction, so no failure condition is registered, and that means there is no usable event.

Here are some examples of failure conditions for different types of objects if the user has flunked their last allowed attempt:

• For buttons or click box objects, failure means you did not click within the object’s hit area.
• For a text-entry box, failure means the number or text you typed into the field did not match any one of the specified correct answers.
• For a drag and drop widget, failure means you did not drop objects onto their correct targets.

The On Focus Lost event

Text-entry boxes are something of a special case when it comes to interactive objects. Not only do they have the usual On Success and On Last Attempt events, they also offer one more called On Focus Lost. This event gets registered if the user has entered some text into the text entry field and then clicks somewhere outside the field, thereby shifting the focus elsewhere on the slide.

On Focus Lost can be a very useful event when capturing user input from a number of TEBs if you need to know exactly which field the user has just interacted with, or you want to trigger advanced actions to perform more complex validation of entered data.

Drag and drop events

Captivate 6.1 introduced a new feature called Drag and Drop Slides which caused a lot of excitement in the community.  One of the great things about Captivate’s new drag and drop capability is that it also gives you some more events to play with.

• On Success – This event is registered when you drop all of the correct objects on their respective targets and the answer combination is submitted. You might have achieved this by clicking the Submit button provided, but you can also use the Auto Submit option as well.
• On Last Attempt – As with all the other instances where we’ve seen On Last Attempt mentioned, this one is fired when your participant fails to achieve a success condition and they have no more attempts left. In drag and drop interactions, this means they haven’t correctly dropped all the right objects onto their correct targets.
• Object  Actions – Another feature of Drag and Drop slides is that dropping a Drag Source object on a Drag Target object can also be used as an event to trigger an action.  The great thing about this feature is that each separate object dropped on the target can trigger an entirely different action.  This gives a lot of creative freedom to developers.

So that pretty much rounds up all of the events you can use when creating custom interactivity in Adobe Captivate.  Next comes the rather tricky question of how to decide when to use each one.

How to decide which objects and events to use in interactions

Now that you know about most of the available events, perhaps the big question in your mind is: “With a dozen or more to choose from, how will I know which event to use and when?”

Unfortunately this requires one of those maddening “it depends” answers. Which event you use in a given situation depends on two main factors:

1. What specific results are trying to achieve with your interaction design?
2. What kind of objects do you need to use to achieve that result? (This is because, as you saw above, different objects offer different run-time events.)

Event scenarios

Perhaps this whole event decision-making process is best explained by considering some examples of typical e-learning scenarios for which you need to create interactive solutions.

Let’s imagine you need to trigger an action when…

…the right thing gets clicked

This is easy enough to achieve using a click box, button, Smart Shape button or interactive widget. So, you can use the On Success event of those objects to execute a required action.

…the wrong thing gets clicked

You can use a button or click box set to only one allowed attempt, and use the On Last Attempt event. When the user clicks anywhere outside the hit area, they’ve immediately used up all allowed attempts and this will execute the action you specify.

But what if you need to allow multiple attempts on the correct area (perhaps because the user needs to click something repeatedly) but immediately detect any clicks outside this hit area? In that case you can set up a click box on a layer underneath the button and have the hit area of the click box cover the slide. The click box’s On Success event can then be used to trigger an action in response to this ‘failure’. (Since the correct button object is on a higher slide layer, if the user clicks the button, its hit area will register the hit instead of the click box underneath.)

See also my clarification here about what Captivate really means by the term ‘Infinite Attempts’.

…the participant enters a correct answer into a text field

Use a Text-entry Box object, turn on Validation and specify one or more correct answers. When the user clicks the TEB Submit button or hits ENTER on the keyboard, Captivate will evaluate the data found in the entry field to see if it matches any of the specified correct answers. If it does, then an On Success event is registered.

You can also use the Short Answer or Fill-in-the-blanks quiz question types to check user input for correct answers. However, there are some special wrinkles to be aware of with quiz questions.  (See the scenarios below about triggering actions when the participant answers a question correctly or fails to answer correctly.)

…the participant rolls their mouse cursor over an object

Captivate currently has no native object that can register a run-time event on mouseover which still enables publishing to HTML5.  (The Rollover Slidelet object is now being deprecated because it is only for SWF output.)

…the participant moves their mouse cursor away from an object

Captivate has no native object that is designed to register events on mouse out or rollout either.

…the participant drags an object somewhere

This one should be obvious. You need to use the On Success or On Last Attempt events of Captivate’s native drag and drop functionality.  Alternatively, use the Object Actions triggered when a drag object is dropped on a specific target.

…as soon as a slide is played

In this scenario your best option is to use the On Enter slide event. The On Exit event of the previous slide is not a good choice in this situation because it only gets fired when the final frame of the slide is reached. That event may not fire in some cases, for example, if the user clicks something that jumps them to a different slide. Therefore, using the On Enter event of the slide where you want something to happen is a better choice because it will always occur no matter how the slide was reached.

I use lots of On Slide Enter events in my projects for setting up slides that need to respond to actions the user may have taken elsewhere in the course. For example, you can use Object States in Captivate to set up a main menu slide with objects that change state to indicate which parts of the e-learning module the learner has not attempted as yet, which parts have been attempted but not completed, and which parts have been successfully completed. It also shows how to use the On Enter slide event in another example that replicates a dynamic drop-down menu in a software simulation.

…as soon as a slide is completed

This one is more difficult than it appears. It is certainly one situation where you could consider using the slide’s On Exit event. However, in order to be certain the slide is played all the way to the end and the event is fired, you would need to disable any other means of navigation away from the slide. That could require disabling the playbar and TOC (if your project has them).

Another way to achieve this goal could be to deliberately provide an interactive object that the user must click to progress further. But again, in order to be certain that the event is fired when the slide is completed you need to have the clickable object only appear after the user has viewed all content and also make it impossible for the learner to navigate away from the slide by any other means.

Sadly, there is currently no On Focus Lost event for slides like the one available for TEBs. In view of the difficulties attached to reliably ensuring a slide is completely viewed, I tend to avoid building interactions that require this.

…the participant answers a quiz question slide correctly

Use the On Success event of the quiz question. However, this may not work exactly the way you expect it to. You need to be aware of a couple of subtleties that apply to quiz questions:

• If you have feedback captions turned on for the quiz slide, then the On Success event only fires AFTER you dismiss the feedback caption by clicking again somewhere on the slide.
• If you have feedback captions turned off, then the On Success event fires as soon as you select a correct answer and click the Submit button.

…the participant fails to answer a question slide correctly

Use the On Last Attempt event of the quiz question. As with the previous example above about correct answers in quiz questions, there are some subtleties to be aware of here:

• Firstly, if you have allowed infinite attempts on the quiz question, then the On Last Attempt event will never fire, because as far as Captivate is concerned the user can never fail this question. (See my clarification of the meaning of the term ‘Infinite Attempts’.)
• Secondly, if you have allowed a specific multiple number attempts on the quiz question (e.g. 2, 3, 4, etc), then the On Last Attempt will only fire when the user has failed to select a correct answer and there are no more attempts allowed.
• Lastly, the On Last Attempt event will only fire AFTER you dismiss any feedback captions present on the slide. If there are no feedback captions to dismiss, and all other check-points mentioned above have been passed, then the On Last Attempt event will fire. So as you can see, using the On Last Attempt event in Captivate is not quite the same as saying you want something to happen when the learner gets the question wrong.

…the participant passes the quiz

Use the On Success event of the quiz. This event is closely related to the Quiz Results slide. But as we found with quiz question slide events, there are also some complexities here as well. Pay close attention to the following explanation:

• If the Quiz Results slide is hidden, then the On Success event of the quiz fires when the participant has achieved a passing score and passes beyond the final quiz slide.
• If the Quiz Results slide is showing (i.e. not hidden), then the quiz On Success event fires when the participant has achieved a passing score and clicks the Continue button on the Quiz Results slide and allows it to play all the way to the end. Please note the final part of that last sentence. It seems that the On Success event for a quiz is only registered on the last frame of the Quiz Results slide. If your user gets to the Quiz Results slide and then uses the TOC, playbar, or Smart Shape button to jump to slides beyond the Quiz Results slide, then the On Success event does not get fired and no event attached to it will be executed.

…the participant fails the quiz

And this one means you’ll be using (you guessed it) the On Last Attempt event of the quiz. The number of allowed attempts on the quiz is set in Preferences > Quiz > Pass or Fail > If Failing Grade. The normal default is one attempt, but you can set any number here all the way up to Infinite Attempts. However, just as we found to be the case with interactive objects, if you set attempts to Infinite, then the On Last Attempt event will never fire.

What if you need to trigger multiple actions from a single event?

In some cases you need to do a combination of several things as a result of a single event. This is where the full power of advanced actions really becomes evident. But you need to walk before you can run.

For now, just focus on getting your head around the concept that every action must be executed by some kind of run-time event. In other articles on this site we’ll be discussing how to use Standard Actions and Conditional Actions to execute multiple events.

Where to next?

Congratulations on getting to this point in this rather long and complex topic.  But run-time events on their own will never do anything in a Captivate e-learning module.  They’re just the ‘triggers‘ that execute Advanced Actions.  So now that you know how events work, your next task should be to learn all about the different types of actions you can use:

• Single actions
• Standard actions
• Conditional actions
• Shared actions

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 basic scripting of interactivity. As a professional e-learning developer, I have also used several other rapid e-learning authoring applications to create interactive e-learning.  But, for my money, Captivate just seems to take things that little bit further than the others.

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:

Single actions

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 drop-down list.  These same actions are also available when creating interactivity with Standard and Conditional Actions. The main limitation found with Single Actions is that they only allow you to execute one action per run-time event (hence the reason for the word ‘single’ in my preferred name for them). 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.

Standard actions

These are re-usable actions you create via the Project > Advanced Actions dialog (or SHIFT + F9). They allow you to execute one or more actions in a sequence. After creating a Standard Action you need to give it a unique name and then 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 next type much more useful.  They give you the best of both worlds.

Conditional actions

I have to confess that I love Conditional Actions! They are the unsung misunderstood work-horses of interactive e-learning. But they have a well-deserved reputation for causing Captivate developers headaches. Like their simpler brethren, the 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!

In earlier versions of Captivate you could not mix-and-match Standard and Conditional Actions together. But the Advanced Actions dialog now allows you to build both Standard and Conditional Actions at the same time and execute all of them from a single event. The only real difference is that Conditional Actions have decision blocks that specify the conditions that will determine if the actions under that section will be executed, whereas a section that is set up as a Standard Action has no condition and will therefore be executed each and every time the run-time event fires.

Shared actions

Captivate version 7 introduced a new type of action called Shared Actions. In theory they allow Standard or Conditional Actions to be saved in a stripped-down ‘parameterized’ format that can then be shared with other projects by exporting from one project file and importing into the other. In practice Shared Actions can sometimes be more trouble than they are worth because once you create them you cannot (as of Captivate 2019) edit them to make changes after that. Other than making actions portable across projects, shared actions don’t really allow you to do anything more than the other action types. They have some slight advantages in terms of run-time performance if you have a situation where you are going to need to reuse the same Standard or Conditional Action many many times in a single project or across many projects.  That’s about the only time that I believe it is necessary to use them.

Can Advanced Actions really be called ‘programming’?

Strictly speaking, Captivate’s advanced actions would not qualify as ‘programming’ if compared to languages such as JavaScript, Java or C++, etc.  Many of the established concepts that are regarded as essential to modern object-oriented programming are missing completely from Advanced Actions and professional programmers often struggle to see why they deserve the adjective ‘advanced’ at all.  So it’s probably more accurate to refer to what we’re doing here as simple ‘scripting’ of interativity.

However, when you publish your project, Captivate converts your Variables and Advanced Actions into much more complex programming code that is executed at runtime.  When the output is HTML5, the final code will be HTML, JavaScript and CSS.  It’s likely to be far more complex code than you could have written by yourself (unless you’re already a talented programmer).  Captivate’s simplified (and somewhat clunky) interface shields you from the dizzying complexity that hides just ‘under the hood’ of the project CPTX file. And, although there are lots of limitations in what you can do, some very sophisticated results are still achievable within those limits.

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.
• Execute a WHILE loop.

The list of what you can do is long and growing as clever Captivate developers come up with new ways to bend the tool 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:

Arrays

Each Captivate 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.

Functions

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 unless you happen to have the Infosemantics CpExtra HTML5 widget in your toolkit.

Complex Loops

A loop 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. Though Captivate does now allow you to create a simple WHILE loop as part of a Conditional Action, it has many limitations. So, if you need to do something more complex, you’d usually need to resort to JavaScript. 

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.

Inheritance

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 concept just doesn’t exist in Captivate’s 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 Actions. Each is a standalone object.

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.

JavaScript

Once derided by programmers as “just a basic scripting language”, JavaScript has now grown up and is regarded as a cornerstone of web-based technology. It is based on the same international ECMAScript standard as many other languages.  It’s a loosely typed object-oriented language that is now the most popular programming language in the world, thanks in part due to the recent rise in popularity of HTML5.  If by some chance you’ve decided to create widgets for Captivate that will work in HTML5, then you will need to become adept at JavaScript.  This is beyond the scope of this discussion, however, there are many books and online resources available to learn the language.

Before you begin developing in earnest using Captivate’s Variables and Advanced Actions to enhance the interactivity of your Captivate content, I recommend you take a few minutes to set up a debugging environment. Doing so can potentially save you many hours of frustration wondering why your carefully-crafted interactions are not working as you expected.

There are a number of ways you can achieve this, but in the example below I use Smart Shape Buttons because they can be timed to display for Rest of Project and are therefore available for view on any slide after the point where they are inserted.

How to set up a DEBUG slide in Captivate

First we need to insert a Smart Shape timed to display for Rest of Project. This shape displays values of any important User Variables you need to check at some point. We use a Conditional Action (triggered by other Smart Shape Buttons) to toggle the visibility of this shape when it needs to be seen.

1. Insert a new slide near the beginning of your project file or project template, but not as the very first slide. (Having too much complexity on the very first slide of a Captivate project is never a good idea because too much is happening in the background as that slide is loading.) Use graphics and captions to clearly indicate this slide is a debugging slide.
2. Create a User Variable called DEBUG_MODE_ON, set to 0 by default, and another called DEBUG_MODE_INDICATOR_TEXT which contains whatever text you want to have showing as the label of the toggle button used to Show or Hide your debug variables. I set mine with a default value of DEBUG IS OFF.
3. Insert another Smart Shape and select the option in Properties tab to Use as button so that it becomes a Smart Shape Button. Set the button timing to display for Rest of Project. You’ll need to make this button reasonably small and place it in an area at the top or bottom of the slide so that it will not end up in the way of other controls when testing the content at run-time but can still be easily clicked.
4. Double-click this Smart Shape Button to add text and from the Properties tab, click the Insert Variable button. When the Insert Variable dialog appears, select the DEBUG_MODE_INDICATOR_TEXT variable from the User Variable list and click OK. This variable’s current value will now be displayed as the button label.  We will be changing the value of this variable later when the debug display is being toggled on and off.
5. Insert a second Smart Shape and resize it to cover most of the slide but place it so that it does not cover your toggle button shape. This object displays any user variables you want to view at run-time. So add some explanatory text at the top to make it obvious.
6. Both Smart Shapes should be situated at the very top of the layers on the DEBUG slide, and both should be set to display for Rest of Project. Only one is set to Use as Button. To make these objects easier to find, give them meaningful Item Names (as shown below).
   
7. Now we need to create the conditional action that will toggle the visibility of the Smart Shape displaying your user variables. That conditional action looks like this:
   
8. Test the functionality of the debug slide by clicking the Smart Shape button that triggers the Conditional Action to Show or Hide the Smart Shape that displays variable values.  If clicking the button shows and hides the shape as intended, so far so good. The label text in the button should change from DEBUG IS OFF when the variables are hidden, to DEBUG IS ON when they are visible.

Although your debug slide is ready for use, you may want to simply Hide it in the filmstrip until you actually need it.  Hiding a slide prevents it from being published in the output.  You definitely will NOT want this slide to become visible to your end users when the project eventually goes live.  So, be sure to hide the slide again before the final publishing of your course content for delivery.

How DEBUG MODE works

Now that you have everything setup, if you encounter any issues with Captivate’s interactivity, just go to the debug slide and into the large Smart Shape there (not the button) insert all variables that are related to the problematic functionality.  This would especially include any variables that are directly referenced by Conditional Actions, or that are dynamically assigned values by other Actions, Advanced Actions or Shared Actions.

Then unhide the DEBUG slide, preview your project as HTML or else publish to HTML5, and click the debug Smart Shape button to toggle the visibility of the other Smart Shape that displays the debugging variables.

When you have finished debugging, just hide your DEBUG slide again to turn off DEBUG MODE and immediately disable your debugging environment. That’s all there is to it!

In most cases what you will find is that some variable is not changing to the value you expected and that is why things are not working properly.  In my experience faulty logic in Conditional Actions is the usual reason for unexpected interaction behaviour. The big gotcha for many newbie Captivate developers is that all decision blocks in a Conditional Action get executed, not just the one where the condition evaluates to true. The order of the decisions is particularly important because a later decision may be changing the value of a variable that was correctly assigned by an earlier decision block. So, make sure you correctly understand how these work in Captivate. You can spend many fruitless hours debugging these things unless you can expose the values of the variables.

Can’t fit all your variables in one shape? Use two, or three!

One caption is usually sufficient to display all variables you need to monitor. However, you can add more captions to the debug slide if needed. Just place the rollover areas or toggle buttons side by side at the top of the slide so that you can call up each relevant caption or shape.

Add debugging to your project templates!

Since I started using this approach I’ve found it so useful when creating complex interactivity in Captivate that I now have this debugging environment built into any project templates I set up when working with clients for whom I create courseware.