Forum Discussion
Storyline Drag-Drop "Allow only one item..." won't be recognized by intersecting-check
Dear support & community.
I ran into a tricky problem with recognizing, if an draggable object was reset to its original position via the "Allow only one item..." option under the drag-drop settings.
It seems impossible -- tried intersection trigger conditions, state-checks etc...
Attached is an image showcasing the setup and what the issue is.
Goal:
To recognize if all drag-drop objects are placed on their targets, no matter if correct or incorrect. Only then the submit function must be executed.
If only one of the drag-drop objects is missing, sumbit must not work.
This must also be true when objects have been dragged out again from their targets and are "snapped" back to their origins.
What works:
When a user drags the object out of the "intersecting" area manually, everything works as intended: The trigger condition "when: Object intersection ends" recognizes the object being dragged out of the intersecting object (which in this case is the target). => Thus storyline recognizes that not all objects are currently placed on their target areas and submit won't be executed. Great.
What doesn't work:
Using the "Allow only one item..." option, which is needed in this case, a user can place an drag-drop object ontop of an object that has already been placed on a target. The old object thus will be "snapped" back onto it's origin automatically. However there seems to be no way to know if this happened! => Thus Storyline still thinks all objects are currently placed on their target areas and submit will be executed(but it shouldn't, since at least one of the object was snapped back to its original state).
Sadly I can't send a file, but I really hope the issue was described well enough for anyone who ran into the problem and found a solution. Thanks in advance!
17 Replies
Users: find bugs
Storyline team:
basically the freeform drag and drop is useless if you want to change some states?
I see this discussion is a couple of years old - is there a feature solution to this? I also want to disable the Submit button on a drag and drop until ALL draggable items have been place on a target (correct or incorrect).
AND I'm only allowing one item per target.
I saw several related discussions about this kind of issue and thought I would try a slightly different approach. Instead of checking if the draggable items intersected with the targets I thought I would check if any were left where they started (I set return to original position if dragged outside a target).
So when the Submit button is clicked I move a hotspot over the area where the draggable items started and set a variable to true if the hotspot intersects with any of the items. If true the Submit button doesn't operate, I then reset the variable to false and move the hotspot back. That works pretty well. You have to have all the items on targets to be able to submit...
It even works for me on "Try Again" with no extra code. But I'm always looking for a more elegant solution.
Hi John,
This is an elegant enough solution, and very sneaky.
I've got the hotspot test working, but how do I delay the implementation of the submit/next slide until after the test is completed? The slide moves on before the variable is updated to prevent it.
As an side line on this, John's solution of moving the hotspot off screen and then reintroducing it to test for intersections is good. However I found that when an object is off screen it can still intersect with an object that is being moved around by the user if part of that object moves off screen as well and touches the hotspot.
My solution was to move the hotspot far enough away so no intersection is possible while the user plays. I also considered deactivating the hotspot when off screen but this doesn't appear to affect it as an intersection object, so moving it far was the way I chose.
Absolutely Stefan. I've submitted this on your behalf :)
Hi Ashley,
would be great if you shared this issue with the team!
Hi Stefan,
We're always open to changing features or adding additional support, I was sharing that it wasn't an existing setup in Storyline today. Our team evaluates feature ideas and requests using the steps outlined here, in comparison to how we identify and tackle bugs.
Happy to share your thoughts with the team, or if you'd like to send along using our feature request form that's always an option too.
Do I understand you correctly that Storyline doesn't want to change anything about the behavior? It can't be that Storyline doesn't want to implement an elementary requirement and just because there is a workaround with triggers doesn't define it as a bug? The requirement is not even completely absurd, but completely normal in the area of e-learning. Or would you say that the requested requirement is not useful or necessary?
Hi Stefan,
Once you begin to add triggers, conditions, etc. to a drag and drop it will no longer adhere to the built-in Storyline drag and drop options. The triggers/conditions essentially override what Storyline is setup to do, and that's when you may start to notice some odd behavior.
It's not considered a bug at this point, as there are options (with a lot of triggers) to accommodate these custom design needs.
Let me know if you have any other questions.
Nope, I sadly still don't know any other way around. Using Michael Hinze's solution seems to sort of work theoretically, but from a economical perspective it's not really feasable.
I really hope that Ashley and Co. will read this post and give us Feedback on this bug. The bug is a little bit frustrating.
What does the Articulate-Team say to this issue? It can not be that the solution by Michael is the only possible way to tix this issue. :)
