Button's Hover state doesn't work after mousing over a Disabled button
Jul 26, 2018
I created an interaction with 8 clickable, transparent buttons on top of a spreadsheet graphic; each button sits on top of a column in the spreadsheet (shown on the base layer). I present a series of 6 question layers (one at a time). For each question, incorrect clicks change the selected button(s) to their Incorrect state (add a Red X graphic). Clicking the correct button for Q.1 (1) disables that button for the rest of the exercise (Disabled state adds a Green check graphic), (2) resets all other buttons to Normal, and (3) presents the next Question. (I used a variable to track which question is current and therefore which button is correct for each question.)
Each transparent button also includes a Hover state (an arrow pointing to the column), which works fine EXCEPT when you mouse over a Disabled button immediately before mousing over the button. The only way to see a button's Hover state is to deliberately mouse over anything other than a disabled button first. But there are 8 adjacent columns/buttons, and learners will want to move the pointer side to side, which means they won't see the Hover states of the remaining buttons and will miss the next correct answer.
I tried changing the Hover state to simply add an outline instead of showing an arrow shape, but that didn't fix the problem.
Has anyone else run into this? Any ideas on how to fix it?
38 Replies
P.S.: The problem occurs only in HTML5 output. All hover states are fine in Flash.
I "fixed" the problem by adding transparent rectangles on top of the disabled buttons. It's a band aid, but at least now all the active buttons' hover states work because the mouse/pointer never "sees" the disabled buttons.
Hi Debbie!
Thanks for the detailed write-up of what you encountered! The fact that you're seeing problems in HTML5 but not in Flash is a red flag.
So that we can get a clear picture of your set-up, would you mind sharing your file with our team by clicking here? If there is in fact a bug lurking here, we want to identify it so we can begin tracking and prioritizing it!
Done :-)
Hi Debbie,
Thanks so much for sending your file to our team. My colleague Robert tested it, and found that this is in fact a bug.
Specifically in the HTML5 output, the hover state in an object does not work if you hover over another object with a disabled initial state.
He reported this problem so we can begin looking at next steps. I'm sorry you ran into this, and we'll keep you posted on any new information.
Following
Any updates on this bug?
Thanks for checking in, Maneli!
No news yet–I promise we'll share all updates once we have them in this discussion and update our Storyline 3 and 360 Version history pages. You're in the right place to stay up to date on any new information, and here's an inside look at how we tackle bugs when they're reported!
Hello. I am running in to this issue. would love for it to be fixed. Exact same thing, I have some buttons down below that are gated in order for you to have to click them in order, so the other buttons are just set to their disabled state. if you accidentally mouse over the disabled button first it breaks the hover state, the hand changes to the clicky finger, but the mouse over state does not run.
Also there are like at least 50 annoying bugs that I just live with, but I would love if articulate functioned as an actual program for once, so I wonder if there is a place to log, easy to work around, but fundamentally flawed issues with storyline. ( example, If you use the font size box that pops up next to your cursor, and hit enter or hand type in a number it will either, delete the text in your box, or start typing the numbers you are typing.) All is fine if you use the font size thing up above.
Hey Brian, really sorry for all the trouble you've run into. I know you must be frustrated, since these bugs are getting in the way of producing high-quality work and affecting your production time.
I appreciate you letting us know about the bug in the font size box. I experienced the same thing in my own testing, so I'll share this with my team so we can begin investigating this further.
When you run into a bug, the best way to report it to us is right here in E-Learning Heroes, like you just did -- we see every single post that comes through. You can also start a support case with us here. Once a bug is reported to us, here's how we tackle it.
Again, I apologize for all the roadblocks, but I appreciate you letting us know about your experience.
Has this bug been fixed in any recent updates?
Hi Douglas,
We're still seeing an issue in Storyline 360 and Storyline 3 where the "Hover" state won't appear if you first hover over a disabled object.
I'm sorry this is affecting your project! If we get an update on this, we'll share the news with everyone here in this discussion.
I am running into this issue as well. Are there any updates on when this bug will be fixed?
Hi Monique. No updates yet, but I've updated the impact based on customer reporting. Thank you for adding your voice!
Is there any news on when this bug will be fixed?
Hello Jarryd!
Unfortunately, we don't have a timeline. Our team is looking into the nature of the bug, so I hope we can report back with an update soon!
Thanks for your patience. We'll update everyone in this discussion when we hear of more information!
Hi Lauren
Ive read the threads and work arounds etc. I will be trying them. Don't mean to sound like a broken record, but I'm just wondering why after 3 versions that a feature so simple as a hover state would not work in this version? During the testing stage, didn't the development team see that it wasn't working on their end as well?...or did it work? I'm just saying this because so many people are identifying this problem therefore would it also not have shown up as a problem during the testing phase?
Hey!!...I created my hover using "STATES" and it works perfectly. No wait, no lag...on the mark when you hover over.
Cheers everyone
As a follow-on to what Yvan said -- my workaround is to insert a hotspot behind the buttons -- it only needs to be one as long as all the buttons are encompassed by it and you can't get to them except by rolling over this hotspot along the way. Put a trigger on the hotspot telling it to do something innocuous (i.e., change a dummy variable) when user hovers. The buttons need to have enough of a gap between them for the rollover of the intervening hotspot to have time to register.... voila. Rollovers work on the active buttons. Unless the user moves his mouse REALLY fast.
Any updates on this bug?
Good morning, Tim!
Thanks for checking in. This bug is still open for investigation, but I'll let the right team know you reached out and keep you posted on any new developments!
Following.
Following, because I'm having this issue. I tried using Debbie Chaddock's bug fix, but I must be doing something wrong; it's not working for me. However, I used Mark Lentz's workaround, and it worked as described; it still has the issue if the user moves their cursor fast.
We also have the same issue, we haven't been able to work arround it, and it's frustrating as it messes us completly the user experience of games.
We see the issues was reported 2 years ago. When will this be fixed? Could you give an update on what's the status of this?
I seem to be having the same problem. I used a theme that had a glow around the button, but when I changed the button color, the glow disappeared. When I tried to add it back using States, nothing happens.