When you build your eLearning project with Adobe Captivate you have several options for customizing the way the elements or components of your project work. You can control almost every aspect of your project with Advanced Actions, Shared Actions, or JavaScript but how do you know which approach is right for your project?
When I first started working with Adobe Captivate I used Advanced Actions almost exclusively. Part of this was because they worked and part of it was because I was intimidated by Shared Actions and JavaScript. Two things I took away from building a few eLearning projects using only Advanced Actions are 1) it’s a perfectly acceptable approach, 2) it will likely result in the size of your project increasing. I found that the biggest advantage to using Advanced Actions, at least for me, is the ease of troubleshooting and making changes. It’s easy to tweak an Advanced Action when you want to change how something works and, if something isn’t working properly, it’s easy to pinpoint the mistake in an Advanced Action because you can “see” all of the commands in the action and what they are assigned to. The biggest drawback that I have witnessed to Advanced Actions is that the need to build many Advanced Actions can quickly lead to unnecessary bloat in your project. I often found myself writing the same action over and over because I needed to apply it to different buttons or different slides and before I knew what was happening I had 15 Advanced Actions that all did the same thing.
When I overcame my intimidation with Shared Actions I was able to turn those 15 Advanced Actions that did the same thing into 1 Shared Action and apply it in all 15 places that I had used the Advanced Actions and tis, I believe, is the greatest strength of a Shared Action. If you plan ahead, you can build a handful of Shared Action that you can use over and over; getting the same results you would with Advanced Actions without the project size and without the wasted time building additional actions. Another big advantage of Shared Actions is the ability to “share” actions between projects. If you have an action that is common across many of your projects you can export the action from the original project, save it on your computer, and then import it into another project when you need it. Shared Actions may be a step up from Advanced Actions but they aren’t without their drawbacks. You can’t directly edit a Shared Action once it’s been created, instead you will need to use the Shared Action as a template or model for building a new Shared Action. Another potential drawback is troubleshooting, because you can’t “see” what’s inside a Shared Action you are dependent on the names you, or the person who built the Shared Action, provided for the Shared Action’s parameters. This drawback can be mostly avoided with good authoring practices.
A word (or two) about JavaScript. There are very few things I have done using JavaScript that could not be accomplished with either Advanced Actions or Shared Actions. What I have found is that I can often increase my build speed (sometimes dramatically) by using JavaScript and, honestly, there are things I need to do in some of my more advanced projects that I can’t do with either Advanced or Shared Actions.
So, what do I use when I build a project? I usually use mostly Shared Actions with a few Advanced Actions and some JavaScript thrown in. It isn’t unusual for me to build a short Shared Action with some JavaScript attached to it. For example, I might have an Shared Action that allows the author to set the value of a variable and then execute some JavaScript I have attached that performs different functions based on the value of the variable. Could I have done this without the JavaScript? Yes, but if the Shared Action gets over complex and requires the author to input a bunch of parameters each time the Shared Action is used the using JavaScript for that part of the process can be a big time saver in the authoring process.
One final thing, I expect some of you may be thinking, “I don’t know JavaScript, should I learn it?” Should you learn it, it certainly wouldn’t hurt but it isn’t necessary either. Learn Captivate first. Learn what you can do with Advanced Actions and Shared Actions and then worry about whether or not you should learn JavaScript.
I agree with most of the part of your article except comment on JavaScript…. In my view, Javascript is 10 time more powerfull, flexible than that of Advanced Ation. Also writting multiple logical flows and statments are simple to write can be tested(depending on codes) externally. Not only that, writting 50 lines in Advanced action is tidios process as in every line we have to slect option from dropdown etc…Please note that this is my view, it can be wrong.
Here are some reasons why I use shared actions (in the first place) and advanced actions more than JS.:
With consultancy jobs, the client wants to be able to do small edits to the created actions. That is very well doable with well-designed Shared actions (by using parameters) and Advanced actions (which are editable in Captivate and understandable). That is totally excluded for JS.
I use JS, but the JS script window in Captivate is limitedd. THe way to go is using an external JS file where you create a bunch of functions which can be called in the Captivate JS window. I still hope that the workflow to use more complicated JS scripts will be improved in the future.
Testing a JS is still a lot more time consuming than testing an advanced or shared action. You may not believe me, there are no tests around where the three types of workflows are timed, each done with an expert in that workflow. Some label me as ’empress of shared/advanced actions’ and I find creating such an action much less tedious than writing out a JS script, even when using Brackets or Notepad+. It is perfectly possible that you disagree, because you are an expert in JS? but not in Advanced/shared actions.
There are a lot more advantages in using shared actions, one of them being not to increase the file size the same way as advanced actions. My first use of them was for a mobile project (demo at DevLearn with Sarah Gilbert). She had used several advanced actions to reduce the the number of slides and frames. When I remodeled the project with the brand new shared actions and less variables, the file size was half the size of the original project. Shared actions can be compared with functions in JS. I have blogged a lot about them, presented webinars and presented at different conferences. Have some more blog posts to come, and will offer an advanced training with focus on Advanced and Shared actions.
I only switch to JS for functionality that is unavailable in Captivate: randomizing, arrays, formatting etc.
JS works best if you have several functions ready in an external JS file, which you can call from CP. That is fine if you work in a company, but is a problem when you do freelance work for client. Not only the setup, but the accessibility is not so easy for JS files as for Advanced and especially Shared actions which can be DOCUMENTED, something that is really lacking for advanced actions.
You must be logged in to post a comment.
