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!
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.
I'm hoping someone will offer an easy, build-in solution for the issue you described. In the meantime, have a look at this rather trigger-heavy workaround here. Is this what you wanted?
Hi Michael! Thanks a lot. Would you mind sharing the story file for me to take a peek and see if this would work for us?
See attached the file.
Totally crazy? I couldn't agree more :-) I'm still hoping that someone will jump in with a clean, simple alternative.
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. :)
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.
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.
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.
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,
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.
Hi Ashley,
would be great if you shared this issue with the team!
