HTML5 Drag and Drop not working
Sep 11, 2014
I have a freeform drag and drop interaction where the user drags dots onto a grid/graph to plot points. It works fine when I preview and when I run the Flash version (which we can't use with our LMS). The HTML5 version doesn't work.
If I check the drag and drop settings to return item to the start point if dropped outside any target (my preference) then the draggable dot never stays put. It always returns to its home even when dropped onto a valid target.
If I uncheck this setting so a dot can be placed anywhere (even off the graph which isn't my preference) then at least the dot stays put where I drop it. However even if I drop it onto a correct target it doesn't count it as correct.
I know I'm doing some out of the ordinary things here but it should work. It works with flash and I'm pretty sure it was working before I started publishing with update 6.
I'll share my file privately with anyone who can help. This is one of several issues I'm currently having with Storyline. I'm so frustrated I'm about ready to give up on it.
11 Replies
Hello Aaron,
I have opened up a Support case for you to send me your file privately so I can take a look.
Please respond the the email from support@articulate.com
In the meantime, can you let me know which internet browser you are using to test this? Here are the system requirements for authoring and viewing Storyline.
I'm using the newest Chrome update on a PC.
Thank you Aaron,
I received the file and will look at it shortly.
Has there been a resolution for this issue? I'm facing the same problem - drag and drop does not work in html5 output (checked in both Chrome and Internet Explorer).
Hi Nicholas,
I took a look at the information Aaron sent - and it seemed he had an issue with the items snapping back, but since he had implemented his own triggers on that, it was overriding the "snap back" behavior. It sounds like you may be running into a different issue entirely - can you tell us more about what isn't working correctly and where you're hosting yourpublished content to test it?
Ok, I figured out what's happening. Have no idea how to resolve it, but at least I know what causes the issue. It's Storyline 2 by the way. Basically, I converted a slide to a freeform drag and drop, identified draggable items and drop targets etc. The interaction works well in preview and in published version when running the flash output. But if I run the html5 output the draggable items cannot be dragged, basically it turns into a static slide. I found that the issue occurs when the slide is set to reset to initial state when revisiting (though drag and drop doesn't work even the first time you visit), but if I change the setting to Automatically Decide - the drag and drop works the first time, but when revisiting the slide the saved state is resumed and the interaction is unusable, which is expected, but i'd prefer to be able to use the Reset to initial state option and have it function normally in both flash and html5 and not have to compromise due to the html5 output issue.
Hi Nicholas,
Can you share an example .story file with us here? I'd like to take a look at what you've set up and do some testing myself.
Also, can you please confirm that you're working on local project files, testing within the intended publish environment and utilizing one of the support browsers mentioned here for HTML5?
Thank you for responding, Ashley. I'm attaching the file. I was removing all proprietary information as I was getting the file ready to upload and came across something interesting. There are two images all the way on the bottom of slide. Looks like in html5 output when the slide is checked to reset to initial state those images come up on top of the draggable objects and prevent those objects from being dragged. The original images I had in there had solid colors, after I replaced those images with the textures that are there now I noticed that when hovering the mouse over the draggable objects, the mouse becomes a hand in the areas where there is a break in the texture, even though the image is located below the objects. If you move the two images to the side, the interaction becomes usable in html5.
To your question, I tried this in the current Chrome version both on the computer and on Android, both from the local drive and from the server. The result is always the same - the interaction is not usable in html when the slide is set to reset to initial state.
Hi Nicholas,
Thanks for the project file - I tested this in Chrome v. 40 on my desktop (and did want to point out that you mentioned you were publishing for Android as well, and I wanted to offer a reminder about the supported Android viewing as detailed here).
I see what you're describing in regards to the mouse cursor and how it behaves with the textured elements - and I'm curious what the pictures were that you were using before? Since the dragged objects are set to a transparency, I wouldn't think that you'd be able to grab items "behind them" and especially since that picture is one large item - not individual texture pieces added. Have you looked into adding these as a part of the background as detailed here instead of just adding pictures to the slide?
I don't think it matters what kind of image is behind the objects, let say it was an image of a sunset, the bottom line is that for some reason that image jumps on top of the draggable objects even thought on the timeline it's located all the way on the bottom of the pile, and that's obviously a bug in html5 output.
Hi Nicholas,
I've tried with just that - a sunset photo and set the transparency of the photo and of the object, and everything is working in terms of being able to drag the items - so I'm not able to replicate this outside of your file with the textured image which had some transparency. Do you have a sample course with a solid photo that is causing the same behavior? Did you look at adding the photo as a background element instead of just including it on the slide itself?
This discussion is closed. You can start a new discussion or contact Articulate Support.