Drag and Drop states don't function properly

Dec 17, 2019

Storyline doesn't seem to understand how drag-and-drop actually functions in the real world. It seems pretty simple, yet the states are maddeningly complicated, and I can't get it to operate the way an actual drag-and-drop interaction would.

Here's the scenario: there are files and they need to be dragged into their correct folder. If you drag a file onto a folder, that folder should change states to show it is a drop zone. Once you drop that file, the file icon should disappear, and the folder icon should return to its normal state. If I start dragging the file and then decide I don't want to drop it into a folder, it should return to where I started dragging it from.

However, when I build that in Storyline, it would appear that I have to add multiple triggers to get it to behave only semi-correctly. There are 2 problems: 

#1, If I pick up a file, but change my mind and don't drop it in one of the folders, it disappears, and I can't pick it up again to put it in a folder.

#2, If I drop a file into a folder, the "drag over" state of that folder stays active until I drag something else over it and off of it to reset it to normal. I added specific triggers to 2 of the 12 files, but it seems like an awful lot of extra work when it should be out-of-the-box functionality.

Am I missing something, or did Storyline?

5 Replies
Jerry Beaucaire

To get the effect you want requires that you take control of all the triggers, the opposite of what you were hoping.  ;(

  1. Under DRAG AND DROP properties, turn on the "Delay Item Drop States Until Interaction is Submitted".   This will allow you to see the items that have "snapped back" to their original positions when not dropped on anything.
  2. Next, pick a drop item (Address) and add two more triggers.  (I know, I know...)

    This way YOU are setting the "invisible" state of these items as they are dropped, and Storyline is snapping back visible items when not dropped on one of these folders.
  3. Copy those two triggers onto your other items with the same CONFIDENTIAL target, these triggers won't need editing as they pasted.
  4. Copy the triggers onto one of the PROPRIETARY folder items, edit them to fit this new target, then copy those edited triggers to the other items in that folder group.
  5. Then repeat with the last group PUBLIC.
Russell Brown

This is probably a correct solution to handle problem #1. Do you agree with me that this seems like it should be out-of-the-box functionality, without having to create 24 extra triggers? To handle problem #2, I employed a similar workaround, but this time with 36 extra triggers. So whenever I pick up an object and drop it on a target item, there is a trigger to change (A) the target back to normal, and (B) the drag item to hidden. That's a total of 5 EXTRA triggers for EACH drag item. So much extra work.

Jeff Forrer

Looks like you are getting a handle on it. 

The reason #1 was happening is because when you dragged an item and did not hit a target, it was setting the state to Drop Incorrect which you had an empty state, so was working as expected.  With the delay set per Jerry's suggestion, then it stays but then you have to change that on drop OR you can change your draggers to hidden when they drop on one of the 3 targets, that way you can handle that change with one trigger since you are not using the drop correct, incorrect states as long as they only have one shot at it, then you should be good

Most drag and drops are simpler than yours ;0), meaning that there is one target for each dragger, in your case they can drag to any of them, so it is more of an arbitrary sort.  

I agree that drag and drops can become cumbersome with trigger counts, I had one once with over 100 triggers, but without being able to do some basic coding to assist, this is what we have for now.

The good thing is with the new triggers panel, this can be done MUCH faster now ;0)

Jerry Beaucaire

My suggestions above seemed to solve both problems you had presented with only the 2 additional triggers.   I'm not doing the math, so maybe we're saying the same thing.

It's a lot of work, agreed, but the triggers being copyable reduces the pain of the duplication process, IMO.

Out of the box?  I get what you're saying.  But the way the system is setup currently the 'LEGO BLOCKS" they have provided give us fantastic control and we are constrained only by our imagination.  The more they fine-tune specific behaviors, an argument can also be made that that reduces flexibility, and results in more "requests" for code updates.  You know?

So, the way it is, and with the help of the community, we seem to be able to handle most scenarios we come up with, yes?

Jeff Forrer

I agree with Jerry, what we have to date is pretty awesome.  I enjoy the challenge of trying to solve the problems we are faced with and there always seems to be a solution, although sometimes it takes more than what we expect.  What is interesting is that there are many ways to do the same thing, and everyone thinks differently, so interesting to see what everyone comes up with and this is great place to learn. ;0)


This discussion is closed. You can start a new discussion or contact Articulate Support.