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.