Forum Discussion
Drag and Drop With Feedback Layers BUT NOT Correct or Incorrect
Although ThierryEMMANUEL has figured out a solution, I would still like to try a simpler version without using a tons of triggers.
I use the built‑in drag‑and‑drop function so that objects can return to the start area when a target is occupied. I also prefer using "state" for counting the TotalPlaced value and rely on two triggers to change the state.
What the built‑in model cannot change is that when another item is dropped on the same target, the original item still remains in the "placed" state even after returning to its initial position. Since this is the only issue in my solution, I thought—why not use the new AI assistant to solve the problem? Below is the prompt I gave the AI assistant, and it worked as expected. A single JavaScript snippet solved it.
Change the state of crit# to normal when they moves onto hotspot1 area. For example, change crit9 to normal when it moves onto hotspot1.
Here is my version3. As Nedim said, I also value discussions like this and gracful learn something from each other. Thank you!
Hello Nedim
Glad to see you here. When I saw that you had posted a solution, I thought to myself, “I'm going to learn something today.” I thought, “What a brilliant idea to use a (virtually invisible) trajectory just to trigger something. I hadn't thought of that.” But actually, I'm studying the file, and I'm still studying it, and I don't understand what it's for. (Maybe to avoid placing 8 and 9 elements). It's beyond my understanding and logic. I should understand since everything is in the triggers panel. But no. It's very strange and intriguing.🙃
Anyway, it works perfectly... except that... ELOUPEI wanted “The user can drag any of the nine in an order into the drop zones. They'll snap into place and/or return to their original spot if something else gets put on top of them.” With only one drop zone, the second one is not respected. Was it very important? Maybe not. And, it's true, it's not very clear whether a maximum of 7 or up to 9 items could be selected (even though there were only 7 zones in the original file).
So, if I were to try to simplify your proposal, I would use only 2 triggers for each movable element to adjust var TotalPlaced: “Add the value 1 to TotalPlaced when Crit1 crosses DROP(zone).” "Subtract the value 1 from TotalPlaced when Crit1 has finished crossing DROP(zone). And that works too.
Once again, I'm happy to brainstorm with you.
Hi ThierryEMMANUEL! Nice to see you again!
I initially gave up on this when I first opened the file and saw a number of unassigned lines, mostly connected to the slider. I didn’t have time to dig into that at the time, so I moved on. Since this post kept popping up at the top, I decided to give it another try—especially after noticing that the proposed solutions didn’t work as expected and that everyone seemed to ignore the slider, assuming it wasn’t relevant to the interaction.
When I took a closer look, I realized this wasn’t anything particularly complex (so, no “wow” moment this time 🙂.) In fact, I had built a very similar interaction a long time ago, so I reused a few triggers from my old .story file and continued from there. The only real challenge was figuring out how to convert an object back to its normal state after it had been dropped and moved elsewhere, while also ensuring proper tracking as it was moved back and forth.
Yes, the additional conditions in my “Add to” variable are there to ensure that the total number of dropped items does not exceed seven. Further down, if the count reaches seven and another criterion is dropped, one item is removed to maintain the limit, and so on.
You may also be right that I misunderstood the original concept of having seven separate drop zones rather than a single one, which I chose to implement instead to simplify the process. That said, I don’t really understand the need for seven drop zones if the interaction is only validated when four, five, or six items are dropped and the Finish button is pressed.
If the priority or order of the items matters (meaning the sequence in which they are presented or dropped), then multiple drop zones make sense. If so, what exactly constitutes an order or a correct sequence? However, if the interaction only checks how many items are dropped, and not which zone they are in or their order, then the number of drop zones (whether one, seven, or even nine) doesn’t really matter.
"I would use only 2 triggers for each movable element to adjust var TotalPlaced: “Add the value 1 to TotalPlaced when Crit1 crosses DROP(zone).” "Subtract the value 1 from TotalPlaced when Crit1 has finished crossing DROP(zone)."
Yes, I could have done that as well and it would have worked. I chose the state-based approach because the Placed state was already created in the downloaded file, so I went with that. I also find the state option more reliable than relying on intersecting events in more complex interactions.
I’ve now downloaded your solution as well, and I’m actually surprised that it required over 120 triggers and too many conditions spread between the base layer and an additional calculation layer (although I do like the approach of having a separate layer that runs for about a second, does its job, and then closes automatically). I haven’t studied it closely yet to understand why, but I’ll take a look. I assume it’s because you went with the multiple drop-zone approach. But as you’ve already figured out, the secret sauce here was implementing motion path animations to help objects return to their Normal state before being dragged or moved again, ensuring that the calculations remain accurate.
The solution I provided uses only about 54 triggers (six per draggable object). I also always like to have a real-time counter so I know exactly what will happen before I even test it with another button. It’s a kind of debugging aid that I can’t really live without.
Once again, I'm happy to brainstorm with you.
Likewise, and thank you. I value discussions like this. There are only a few people in the community who truly dig into the reasoning, explore alternatives, and genuinely explore different approaches and seek to understand the why, not just the how.
Hello Nedim I didn't think or write that you had misunderstood anything. I think the original file wasn't quite right, looking for solutions. I think the seven drop zones were there so that the Crits would automatically “return to their original spot if something else gets put on top of them.” As I mentioned, this may not have been the most important feature. I chose to respect it because it was an additional challenge !
Thank you for counting my triggers for me, I hadn't done that! 😁 Of course, fewer triggers make the screen easier to debug. That's one of the most valuable rules to follow. On the other hand, after setting everything up on Crit1, I was able to copy and paste it (with the triggers) and make a few adjustments. That wasn't the part that took me the longest.
I also agree with you on the need for a dynamically changing variable for debugging. Again, this wasn't the most complicated part here, and I wasn't worried about any problems on that front.
I hope that one or the other or the other or the other solution will help ELOUPEI.
Looking forward to seeing you again.
ThierryEMMANUEL LOL! Counting triggers has nothing to do with you, this post, or anything else, it’s just my professional deformation, which, to this day, I’ve never managed to revert or cure. Yeah, if only I could go home with multiple solutions like this every day :)
Thanks, Thierry. Already looking forward to our next brainstorming session!