Why?

Shared actions were a new feature in Captivate 7 and were improved in Captivate 8. Nevertheless I rarely see examples of shared actions, and there is also lot of misunderstanding.  Some users think they can only be reused in other projects. I did see experts claiming that they are totally useless, that it is much easier to duplicate advanced actions. I don't agree with that opinion, about 90% of all the project I have developed do include shared actions. They are especially useful for responsive projects as well. In a recent article you can find links to tutorials about shared actions.

 A problem that still remains is that you cannot edit an existing shared action, had hoped that would have been solved in 9 in a recent version but it didn't happen. The reason is probably that since they are not much used, this improvement doesn't get on the priority list. If you want to learn more about how to create shared actions and see some examples, have a look at this recent article in which I summarized several older posts. This post is a showcase, where I'll try to explain when to use a shared action, and when you cannot use them. The origin of this showcase is due to this question in the forums. The answer I gave there is working, but has a serious drawback, I will explain both this first simple answer, followed by a second version that will work in all situations. I hope you learn from that workflow: test out all possible situations, even though they seem to be improbable. As a trainer/coach never underestimate how trainees will explore courses.

Problem

User did look for a solution to apply to this use case:

• Drag&Drop slide with two drag sources and two drop targets
• Each drag target should accept only one drag source
• Depending on the sequence of the dragged items, one out of two texts should appear.
• Learner can switch the drag sources
• Auto submit for the answer.
• Slide needs a reset button

Example movie

Watch this embedded movie (rescalable HTML), where you'll see the two solutions after publishing. As an alternative you can also watch it directly using this link. You can test the problem with the first solution as well. Everything works fine if you switch only once, like first dragging the First text to the Top target, than drag the Second text to the Top target. However if you switch a third time, First text to the Top target, you'll see that the functionality is lost. This will not happen with the second solution.

Setup Drag&Drop slide

The setup is the same for both solutions. Drag sources are shapes and labeled SS_DragOne and SS_DragTwo. The shapes acting as drop targets are labeled SS_DropTop and SS_DropBottom. The feedback will appear in another shape SS_Feedback, which has 3 states: Normal, OneTop (first scenario with SS_DragOne in SS_DropTop) and TwoTop (second scenario (SS_DragTwo in SS_DropTop). 

Since Auto Submit is turned on in the Actions tab of the Drag&Drop panel, I dragged the Submit button out of the way to the scratch area. 

That means that both possible answers have to be defined as Correct answers. This can be done with the button 'Correct Answers' on the Options tab of the Drag&Drop panel.

Each drop target should accept only one drag source, but the learner can switch them if wanted, as long as no correct answer has been defined. For that reason editing the dialog box 'Accepted Resources' is necessary, because the default setup is that each Drop target accepts all drag sources. This dialog box can be opened from the Format tab of the Drag&Drop panel, when a drop target is selected. It has to be repeated for both targets. Rest of the setup like snapping behavior is not important for the rest of the workflow, do what you like.

First solution

This solution is using two variables: v_first and v_second. They are related to the first scenario (SS_DragOne in SS_DropTop and SS_DragTwo in SS_DropBottom) and the second reverse scenario. Default value of the variables is 0. 

I used the same shared action for all object actions, for both targets. It is pretty simple, conditional with one decision. It has three parameters:

1. First parameter is the variable associated with the scenario, v_first or v_second. 
2. The multistate feedback object is the second parameter
3. The state to be shown, which fits the scenario is the third parameter.

This was the original idea:

• When the first drag action occurs, it fits into either scenario 1 or scenario 2; the appropriate variable is set to 1.
• If the drag source is replaced on that same target nothing happens.
• When the second drop target is filled with the other drag source, it has to be in the same scenario. Checking if that associated variable has a value=1, means that both targets are filled, and the feedback is shown, depending on the scenario variable.

What is the problem with this action? It works fine until the user changes the object twice on the first target: in that case the feedback will be shown to early. That was the reason for the second solution which does avoid this problem.

Second solution

Besides the two scenario variables, a third variable to track the number of drag actions was created: v_counter. It started also with a default value of 0. The shared action now has 3 decisions as you can see in this Preview:

The first decision 'Always' is a mimicked standard action. The increment command for both v_counter and the associated scenario variable (v_first or v_second, depending on the object action) will always be done.

The second decision 'Complete' checks if both targets are filled, which is the case when both v_counter and the associated scenario variable have the value = 2. In that case the correct feedback is shown (similar to first solution).

The third decision 'Incomplete' is the one that solves the problem with solution 2. If there has been 2 drag actions (v_counter is equal to 2) but the associated variable for the active object action is still set to 1, that means that the user has switched the drag sources on one target two times. In that case the variable for the other scenario (which probably has already a variable different from 0) is reset to 0. 

It is not necessary to define v_counter as parameter, since it will be used as counter whatever the scenario. This action needs 4 parameters, because both v_first and v_second are used in the action; whereas in solution 1 only one of them was used..

Reset 

This is not the default Reset from Drag&Drop, because it will not reset the variables nor the state of the feedback container. I used the usual workaround (micronavigation as explained in 'Replay Slide' is not possible yet due to a HTML5 bug in CPwhere the On Enter action is not executed) to reset the variables and that feedback container. Two dummy slides with a duration of 0,1sec are inserted: one before each D&D slide. The reset button triggers the command 'Go to Previous Slide', thus forcing the playhead to re-enter the D&D slide.

The On Enter action 'EnterDD' is also a shared action and looks like this:

I used that action for both D&D slides, even though v_counter is not used in the the first solution. 

I hear you! Why a shared action, you only need it twice, and the only edit to make to a duplicate advanced action is the label of the feedback container. If you were one of my college students, you would know that 'Weymeis never acts without a reason....'. I will try to explain why I preferred a shared action with two parameters, instead of two advanced actions.

When you import this shared action in a new project by dragging it to the Library from this project opened as External Library (see Libraries) the variables v_counter, v_first and v_second are created automatically in that new project, with their definition and default value. That is a time saver, something to take into consideration when creating shared actions. This happens only for variables that are not defined as parameters.

Offer

Do you want to try out those actions? Send me a mail (info@lilybiri.com) and tell me if you use shared actions, or will use them in the future?  As a 2018 offerI will send you a project that you can use as external library with the two shared actions (EnterDD and DragSequence) described in this blog post, and instructions how to use them.

Moving

Intro

Since a while I get a lot of worried messages by all channels: on Adobe forums, by Linkedin, comment on this blog, mail... And they all ask the same question: what will happen to your blog when Posterous is closing down? I do find it a bit strange, that such a crisis situation leads to more contact with readers then normally. This blog seems to be useful to a quite a bunch of users. When I started, about 2,5 years ago, never imagined those articles would find their way to users all over the world. And they are useful to me as well: I spare a lot of time, just pointing to a post instead of having to repeat the same answers again and again on the user forums.

Must confess that I hesitate to search for another host. I really want to keep all rights on the content (which is not the case for a lot of blogging hosts), even though some rare readers feel they are entitled to 'take over' my ideas and propagate them as their own, without any reference. 'Since it is distributed for free, it is public, no need to point to the original author in that case' must be their way of thinking. Not very ethical, but that is only my personal opinion. 

For the moment, I do not have a final solution. I already concluded that I need to look for a non-free host in the future. Keep an eye on this blog, if I take a decision about another host, will post the link here.

If you are just plunging into advanced actions, keep on reading. I describe a rather simple use case, suited for novices in advanced actions. The only problem could be the expression 'Mimicked standard action' in the conditonal action Bt_Click. For more info about that, read this article.

ClickClick

I used this name for a small cptx-file, built as an example for yet another use case.:

'I am trying to use a button to toggle between 3 images. I created a variable, initially set to 0. The button triggers a conditional advanced action, where I check that variable, change it and show the next image. But it always shows the first image'

Screening the conditional action I detected that the user was trapped by the fact that in a conditional action, all decisions are always evaluated in sequence. Captivate will never stop evaluating when a correct condition has been reached, but goes on with the rest of the decisions and statements. 

Learning from mistakes is very efficient, here is a description of the original conditional action; the first image Image1 is originally visible:

Decision1 

• IF var is equal to 0
• Assign var with 1
• Show Image2
• Hide Image1

Decision2 

• IF var is equal to 1
• Assign var with 2
• Show Image3
• Hide Image2

Decision3

• IF var is equal to 2
• Assign var with 0
• Show Image1
• Hide Image3

If you evaluate all decisions, you will indeed end up with always having Image1 to show up: first decision results in true, but variable is changed to 1. That means that the second decision is also true, and the variable is changed again. Ultimately the last decision will also be true because of that change, so Image 1 is shown again. 

Example movie

In this one slide movie I have a version of my answer to this use case. Here you will be toggling four images, and to make it a bit playful, when you have viewed all the photos, you can play a little game pressing the Guess-button.

If you want to see the entire movie, you'll have to download it from this link: ClickClickClick. Posterous is not supporting an interactive PDF. In the SWF embedded here, you'll not see the Hangman widget, not be able to play. The Guess button will appear, but is not able to show the interaction, sorry about that. Download the interactive pdf if you are curious about the Hangman interaction.

Slide objects - variable

On this unique slide you'll see from bottom to top on the Timeline:

1. A group with 4 photos, labeled GrFoto; will be set to invisible on entering the slide
2. The button BtClick that will let you toggle the images, visible and will trigger the conditional advanced action Bt_Click (it is possible to have the same name, if you define the button name before the name of the action)
3. The button BtGuess, will be hidden on entering the slide. This button will trigger the standard advanced action Bt_Guess
4. An instance of the Hangman interaction, initially invisible.

Advanced actions - events

EnterSlide

This is a standard advanced action - triggered by the On Enter event. It will hide the group GrFoto, the button BtGuess and the interaction.

Bt_Click

This conditional advanced action - triggered On Success by the button BtClick - has 5 decisions:

1. Always: a mimicked standard action to increment the variable v_click and to hide the group with photos. I preferred to hide the group with this first decision to save time. It is only necessary to hide the previous shown image, but if you want to do that with an advanced action you need more statements. Because all statements are always executed, I can hide the group (same statement for each click) and afterwards show the appropriate image, depending on the click number. 
   

   
    
2. Click1: checks if the variable is set to 1 (which will happen due to decision Always after the first click), and shows the first photo.
   

   
3. Click2: similar to Click1, checks if v_click is set to 2 (after second click) and shows second photo in that case.
4. Click3: similar to Click1, checks if v_click is set to 3 (after third click) and shows third photo in that case.
5. Click4: has more statements than the other 3 conditions. It checks if v_click is set to 4, shows the fourth image. But because all photos now have been viewed, the button Bt_Guess is shown and v_click is reset to its initial value 0. The last statement allows the user to toggle the photos again if wanted. But the button Bt_Guess will remain visible all the time from now on.
   

   
    

Bt_Guess

Rather simple standard advanced action - triggered On Success by the button BtGuess. It will hide the photos GrFoto, and show the interaction that was hidden. Because the interaction is on top of the buttons, it is not necessary to hide those buttons, although if you are a perfectionist, you could hide them of course.

Learned something?

If you take time to compare the original conditional action with my proposal, you'll see how important the sequence of the decisions is, and the fact that CP never stops with evaluation when a correct condition is met. I did increment the variable with a mimicked standard action, not within the real conditional decisions. This means that the variable will not change when CP is executing all the statements. 

Some timesaver tips are concealed in the actions as well: grouping of the fotos will allow to show/hide them with one statement (see EnterSlide, Always in Bt_Click and Bt_Guess). 

Using the Expression statement to increment v_click (Always in Bt_Click) is more efficient, compared with conditions + Assign combinations.

As usual, please feel free to comment. This means a lot to me, will help me to decide about accepting the transfer work to another host.