Forum Discussion
Build an Accessible Drag and Drop Interaction in Storyline
Hi there. Can I ask, for Drag Items, Point 2 it says:
2. “Deselect” all other drag items when this drag item is selected (Change other drag items’ states to Normal, if they are currently selected)
Change state of Drag Item 2 to Normal when user clicks Drag Item 1
If Drag Item 2 state is equal to Selected
Change state of Drag Item 3 to Normal when user clicks Drag Item 1
If Drag Item 3 state is equal to Selected
… (add this trigger for all other drag items on screen)
If I select all my Drag items and had them as a "Button Set" wouldn't that cut out the need for this step? Or would that impact on the functionality?
I ask because I am trying to simulate a DragonDrop but with 6 items, and it seems to be exponentially more complicated with every additional line of triggers. To be honest, there was probably less coding involved in getting Apollo 11 to the moon.
Why is there a state on each DROP called DROP CORRECT, when the Submit button just monitors the states of the DRAG items? What is the practical purpose of that state?
Do items only become draggable in non-Freeform (regular ordinary) slides when they have a DROP CORRECT and DROP INCORRECT state applied to them?
The reason I'm asking is that when the user opens the slide and uses the mouse to drag the items, the slide activity gets 'registered' when the SUBMIT button is clicked.
However, when the user uses keyboard tabbing and RETURN/ENTER to complete the activity, the SUBMIT doesn't see anything as being completed.
I have had to manually create an INVALID ANSWER layer to show if the user hits SUBMIT without doing anything but the keyboard commands just don't convert the correct or incorrect motion path movements to the DROPZONE states.
I now have 17 lines of triggers, PER OPTION, and it's a nightmare to try and troubleshoot.
I have always found relying on STATES within Storyline to control stuff to be very flaky and it seems that this is a prime example to remind me why I never bother with them as key triggers for interactions. Give me hardcore TRUE/FALSE or something tangible, that can be monitored by a reference variable - not some Drop Correct state that gets immediately covered by whatever gets dropped upon it nonsense.
It's been a while since I created this, but I think you are correct that using button sets would remove the need for the deselect triggers and simplify things significantly.
The drop correct state is on the drag item, which is what the submit button registers.