Bug: Down state not clearing Hover state on buttons

Hi Ray

in the hover state trigger  can you select the 'restore' checkbox to remove the image from display

Hi Wendy,

Thanks for your super-speedy reply!

I should've pointed out in my earlier post that I'm not using the "Convert to Freeform" feature because certain cylinders in my activity can legitimately go in either rack, and the built-in, forms-based drag-and-drop interaction builder in Storyline doesn't allow me to have drag objects that correctly match multiple drop targets.

I didn't create a hover state trigger for this interaction; I'm just using the built-in hover functionality that Storyline gives me by default. I don't see a Restore checkbox anywhere (but maybe I'm not looking in the right place?). I'm guessing the Restore checkbox might be in the drag-and-drop forms interface. Is there a way I can set this either via triggers or some other way by hand? The interaction is hand-coded.

Cheers!

    -Ray

Hey Ray

hard to say without seeing your file so maybe I'm barking up the wrong tree. See the attached very rough sample where I created a 'show' state that is  an enlarged version of the normal state. I used a trigger to change state on hover and it allows me to restore it back to normal 'off hover' - it may not work with your drag and drop items though.

If you can share a slide maybe someone can take a look and see if we can help.

Hi Wendy,

Thank you for that test file! It's much smaller than my actual Storyline file, so I will work with yours. My modifications of your *.story file are attached. You used Storyline 2, but I only have Storyline 360, so hopefully you have access to that too, otherwise you probably won't be able to load my file. My findings are documented below, just in case.

The more I investigate, the stranger the behavior seems. I took your file and expanded it a little so we could more easily see what is going on. Your circle shape seems to mostly work as it should. Here are its states after I expanded them a bit:

I labeled each with the name of the state to make it easier to see what is happening, and I added a drop state.

What's different about this circle shape that makes it work when my gas cylinder graphics,which have the same triggers associated with them, do not work? Does the circle work because it is a shape and not a PNG image? Is it because it is a contiguous single object and not composed of 2-3 separate elements? I added some of these cases to see if I could figure out what is happening:

First, the red hydrogen cylinder. For this drag object, I used the built-in Hover state instead of creating custom Show state (as you did on your circle object):

I added a text label below the object in each state so we can follow state changes during testing. When--surprise!--that didn't work reliably, I added a green glow to the (built-in) Down state and a blue glow to the (custom) Dropped state.

When I hover over this red cylinder, it switches to the Hover state and shows me the close-up. But it doesn't change the text label to Hover! How can it not? How can it show the close-up but not the text label associated with the same state?

When I click the red cylinder in preparation for dragging it, is seems to go into the Down state because I see the green glow. Yet, it still does not change the text label below the cylinder to Down--the text below the cylinder still says Normal even though I see the green glow. It also still shows the close-up from the Hover state! So to recap: when I enter the Down state, I see the glow from the Down state, the close-up from the Hover state, and the text label from the Normal state!

It is as if all the states are stacked on top of each other and once selected, each state remains visible. The object starts in the Normal state, then enters the Hover state, and then the Down state. If those states were stacked in that order, with the Normal state on top, I think it would explain what I see in each state. (In reality, each state should hide all other states so only one state is visible at a time. Maybe there's a bug preventing that from happening?)

When I drag the red cylinder, the glow from the Down state remains, as does the close-up from the Hover state, and the text label from the Normal state.

When I drop the red cylinder into the drop target, I see everything as I expect to see it: the blue glow and the text label that says Dropped.

--

Next, on the green compressed air cylinder, I tried to use your method: instead of relying on the built-in Hover state, I created a custom Show state and added a trigger to manually change the state of the green cylinder to Show when the mouse pointer hovers over it. Here are the states:

You can see that they are essentially the same as the red cylinder states: the only difference is the second state in green set is a Show state instead of the built-in Hover state. Following your lead, I checked the Restore on Mouse Leave checkbox for the hover trigger that changes the cylinder to the Show state.

When I hover over the green cylinder, I see the close-up and the label below the cylinder switches to Show (recall that the label did not switch to Hover in this state when I tested the red cylinder). I have no idea why this behaves differently than the red cylinder, but this behavior so far is correct for the green cylinder.

However, when I click the green cylinder preparatory to dragging it, things go awry again: I see the green glow, indicating it's entered the Down state, but the text label below the cylinder still says Show and the close-up is still visible.

When I drag the green cylinder, all three elements (the Show text label, the cylinder with the green glow, and the close-up from the Show state) get dragged.

When dropped, I see everything I expect from the Drop state: blue glow/label says Dropped.

--

For the gold nitrogen cylinder, I went back to using the built-in Hover state, but this time I grouped all objects in a state together.

Grouping did not help, and in fact made the behavior even more erratic and hard to predict.

So the bottom line is: I think there are one or more Storyline bugs at play here (unless you or someone else can see mistakes I've made in the Story file that could explain these strange behaviors).

I still don't know what's different about the circle shape that allows it to transition between these states when the png graphics-based buttons do not. But in a way, it doesn't matter because I can't use basic shapes for my course--I need to use these images of cylinders.

If I had to guess, I'd say that in the case of the red cylinder at least, there is a bug preventing each state from hiding previously-displayed states. Hopefully that can be tracked down and fixed fairly easily/quickly.

Cheers!

    -Ray

Hi Ray

I do have 360 but a lot of folks don't and I didn't want to do the sample in that if you couldn't open it. So I'll download your file and take a look at it. 

So the down state is just for testing it won't be required?

Hi Wendy, 

That's right: I just added the Down state to help me see what is going on. I don't need any special look for it, though, in the actual course.

Thanks so much for taking another look. 

Cheers!

    -Ray

Hi Ray

see this video

I worked on the green cylinder only. I took the show state and grouped the objects > save as picture, deleted the group > then inserted the picture. I duplicated it and renamed it hover (default state). I removed the down state. It appears to me to be working as expected. I also removed the 'show' state trigger and let the default hover state take over.

Let me know and if so I'll upload the .story file for you. If it's not let me know and I take another look

Hi Wendy,

First, I want to thank you for helping me investigate this issue. It is a genuine act of kindness that I truly appreciate. Thank you!!

When I watched your video, I didn't hear any audio--not sure if there is meant to be any.

It looks like, by making each state contain only a single object, you were able to get each state to show by itself (hiding the others), whereas, when we leave each state composed of two or more separate objects (or even two or more objects grouped together), each new states fails to hide the previous states. That behavior with states containing more than one object seems like a bug to me and I have opened a case with Articulate tech support. But your proof that more of the implementation works when there is just one object in each state may  be an additional helpful clue that assists Articulate's engineers in tracking down the exact cause of the bug.

Even with your work-around, the video shows that when you drag the green cylinder, the close-up from the Hover state drags along with it. That's the original thing I was trying to avoid. The idea is that I want to be able to hover over the cylinder to read its markings, but when I start to drag it, the close-up should clear off the screen and just the cylinder should be dragged. 

My assertion is that this failure to clear the close-up from the Hover state during the drag operation is another (?) or related (?) bug in Storyline. The first thing you have to do when you start to drag an object is push the mouse pointer down. That should take the button out of the Hover state and into the Down state (whether we specify a Down state in the states panel or not). That does not seem to be happening with any of the cylinder implementations we've tried. Yet it works with your original circle shape: as soon as you start to drag the circle, the close-up (from the Show state) clears and you see only the original circle during the drag. I cannot explain the inconsistency. Again, I think it is a bug.

Much as I didn't want to, I ended up re-implementing by putting the close-ups each on a separate layer, and then attaching a Show Layer when mouse hovers over trigger to each cylinder to show the close-up layer. That worked (mostly). But I believe the (conceptually simpler) implementation with the close-up as part of the Hover state should work. The fact that it doesn't is, I think, a Storyline bug.

Hopefully Articulate can fix it soon.

Cheers!

    -Ray

Hi there, Ray.  I'm going to dig into this behavior a little; I don't like the inconsistency that we're seeing with different objects and the hover state when being dragged.

Thanks a bunch to you and Wendy for your notes -- I definitely have some direction here!

I'll post a comment on what I find on my end.

Hello again!  I did a little testing in my own file, and I wanted to confirm the expected behavior with our product developers.

Here is my test file where you can see that the drag items (blue circle and picture of a book) have a Normal, built-in Hover (circle), Custom Hover (book), and Down states.  Both the shape and the image behave the same way when I go from simply hovering my mouse to actually clicking and dragging the item.  

• With the blue circle, my first test included only a color and label change between Hover and Down.  Everything looked to have behaved as expected -- the color shifted and the states looked distinct.
• I then added another object (the lightening bolt) to the Hover state to see if that was carried into the Down state.  Sure enough, the color shifted, but the bolt from the Hover state was still present in the Down state.

An object can be in two states at once, effectively adopting the appearance of both states.  This article is specifically geared toward the Disabled state, but it gives a nice visual explanation of how the Disabled state also draws from other states' appearances.

Since your mouse is never really leaving the canister, it remains in both the Hover state and the Down state.  This behavior is by design.

I think your workaround of using layers to show the close up is a good idea!  How do you hide the layer once you start dragging the canister?  

Hi Crystal,

Thanks for investigating.

I am going to have to go on record here as saying that Storyline's "by design" behavior here is not rational in any design sense that I understand, and here's why:

Storyline allows me to design each state. If I wanted the close-up to be in the Down state, I could certainly have put it there. But that should be my decision. I explicitly did not put it there to ensure that the close-up wouldn't be dragged along with the main object.  

Storyline should not override my state designs (either by mixing and matching states or in any other way). If Storyline's developers feel that some users will want combinations of certain states, they should give these combinations names and make those named states available for me to edit. For example, if Storyline's developers think people will want a combination of the Visited and Disabled states, then they should provide a named, editable Disabled Visited state where I can design what that state should look like. (Another example: there should really be a Drag state so I can specify not just what happens when the learner depresses the mouse button, but also what happens when he or she starts to drag the object). 

Bottom line: Storyline should never override my state designs. I don't think anyone using Storyline expects to have states combined surreptitiously; that can only come as a strange surprise (i.e., a "bug").

The logic of managing states should be extremely simple: when the condition is met, show that state and hide all others. Don't overcomplicate it by adding in hidden surprise combination rules that we have no control over.

Please share this with the developers.

I will answer your question about how the layers approach worked in a separate comment.

Cheers!

    -Ray

Hi Crystal,

Because of Storyline's surprise, hidden button-state combination rules that override the look of some states with state combinations instead, I was unable to get the drag-and-drop behavior I wanted just using button states. I will reiterate here that I feel this behavior by Storyline is wrong and should be changed in future versions. To get around this problem, I put the close-up images on separate layers.

Here's what my basic interaction looks like:

Since the draggable cylinders are too small to allow learners to read their labels, I initially created a Hover state with a large close-up so learners could hover over any cylinder to read its label. Here's how I set up those states:

The problem, as we now know, is that even though my Down state does not contain a close-up image, Storyline combines the Hover and Down states (without my knowledge or permission! Grrr), so when someone drags this cylinder, the close-up drags along with it, which is not what I want.

To work around this problem, I removed the close-up image from the Hover state (but left the orange glow):

I then put the closeup image on a new layer:

Then I added a trigger to the cylinder object to show this layer when the mouse pointer hovers over it:

I got the close-up image to hide when the learner begins the drag operation by checking Restore on mouse leave in the Trigger Wizard panel:

This mostly works (I'll explain why it only "mostly" works in a moment). Here's how it looks when I hover over a cylinder:

And here's how it looks when I drag:

You can see that I am able to drag the cylinder without the close-up, as desired.

So why do I say it only "mostly" worked? Well there are two things I still take issue with. One is minor, the other fairly major (and, I'm going to argue, is actually another Storyline bug or design misstep). First, the minor issue: Storyline recognizes that when I depress the mouse button while hovered over a cylinder that the cylinder must enter the Down state. However, even in this implementation, Storyline still combines the Hover and Down states. It's great that Storyline is consistent, but unfortunate that, in my opinion, it is in this case "consistently wrong." :-)

When I enter the Down state, all other states should be hidden, but they aren't: I end up with a combo of Hover and Down (which you can see because the orange glow from the Hover state is correctly replaced with the green glow from the Down state, but the close-up from the Hover state is still present, even though we're no longer in the Hover state):

The other problem is more of a thorn in my side. :-) Recall that I checked the checkbox marked Restore on mouse leave on the Trigger Wizard panel:

In the context of layers, I expect this selection to restore whatever layer I was on before executing this trigger. So, initially, I'm on the base layer. I hover over any cylinder and the trigger shows the close-up layer. When I roll my mouse pointer off the cylinder, I am "restored" to the layer I was on originally: in this case, the base layer. 

But, what happens if someone rolls over a cylinder after clicking Submit? When the learner clicks Submit, a trigger executes that decides if the cylinders are all in acceptable racks. If so, the Correct feedback layer is shown; otherwise, the Incorrect feedback layer is shown.

Suppose the Correct feedback layer is shown:

Now if I roll over a cylinder in the Oxidizing Gasses rack, it will show the close-up, but it doesn't restore to the Correct feedback layer! Instead, it always restores back to the base layer. I think that is a bug (or, if a feature, an incorrect design decision from Storyline's developers):

This seems to violate the common meaning of "restore." It may be due to the fact that I have each layer set to hide all other layers. But if I turn that off, I would have to manually hide all other layers most of the time, and with 10 close-up layers, that's 90 triggers (to have each layer hide the other 9) or some complicated code to keep track of which layer is showing at all times. Not worth it. 

So, in a work-around to my work-around, I had to put a large, invisible (100% transparent) rectangle behind the feedback box in both feedback layers. This invisible rectangle covers the rest of the slide in order to block the cylinder objects from being hovered over.

Whew! It would have been much simpler if the button states just worked as they should.

Cheers!

    -Ray

Hi Ray

sorry it's not working as you would like - but glad you've found a workaround. All the best with your project.

Thanks Wendy!

Cheers!

    -Ray

I am having the same issue in 360.  I am using transparent pngs for the different states because we have different backgrounds and I can see the hover and down states at the same time.  The only fix for this that I can see is not to use transparent pngs.  this is annoying.  Is a fix on the way?

I rebuilt the buttons and now appear to be working properly.  They must have gotten corrupted.

Welcome, Steven! I'm sorry you hit a snag earlier and happy to hear rebuilding the slide helped! Fine detective work there.

While it's tough to identify why slides become corrupt, I did want to share these best practices that can help reduce the risk of corruption. Thanks again for the update, and let us know if you run into any other issues!

I am having the same problem in 360 with creating a button from pngs.  I have a png for normal, another for hover.  I have both use a shadow effect.  I then have a down state where I get the image used for hover state and remove the shadow, yet the hover state remains.  I originally had it as the built in Hover state but it didnt function properly.  After perusing this thread I put in a manual trigger for hover state with restore selected, yet the problem persists.  This is frustrating.  I didn't have this problem in Storyline 2.

Hi, Dean. 

I'm sorry the frustration continues - but we're here to help. 

With your permission, I'd like our Support Team to take a look at your project file to investigate what's happening. You can share it publicly here, or send it to us privately by uploading here. We’ll delete it when done troubleshooting.