Storyline 360: Quiz Question Responses Shift Slightly on Hover
May 15, 2019
Has anyone run into a strange issue that upon publishing and loading a course to your LMS (we use Saba), some responses to quiz questions shift ever so slightly on hover or when selected? The course was originally built in Storyline 2, and this was not an issue. It is also not an issue when previewing within Storyline. However, when taking the course as a learner, the random shifting of words is quite annoying. It's not consistent; some question slides are fine. And within one slide, not all answers necessarily shift.
The way it functions, I would have guessed that the states had been edited and that the hover or selected states had the text moved a pixel or two. But this is not the case. Any ideas or at least confirmation that I'm not crazy would be helpful. :)
Thanks,
Tessa
52 Replies
Good morning, Meredith!
Thanks for those additional clues.
Your theory sounds right, as each browser zooms in a different way. What browser(s) are you using to view the content on your LMS?
Let us know if Cornerstone gives any insight there. Also, if you could share a sample file with our Support team, we're happy to take a look:
Hello,
I've also experienced this with a couple of our SL quizzes and have checked out all of the states of each answer to be sure nothing is different. Changes have been made to the overall sizing of the answer selections, but I feel like this has occurred on answers that were not adjusted, though I can't be sure. Has there been any updates to this issue?
Thank you!
I had the same issue described here. After trying everything I cut the question that was causing the issue and pasted it into notepad, then added it back and the shift no longer occurred. I was copying the question from a Word doc, and I imagine that the question had formatting that carried over. In my instance it was only the last question that caused this, and I copied other questions from Word and there weren't the same issues.
Thanks for that suggestion Daniel! That's definitely been a help with other formatting issues I've had when writing code (Word is the worst when it comes to this), so I've been in the habit of not using Word. I wish this was the case though. That would have made things easier, lol.
I hear you Mario! So I just ran into this again and tried my fix that I mentioned above, and it did not work. But extending the answer text box just a couple of pixels at the bottom (so the text box with the last answer is not aligned with the bottom of the answer box) seemed to fix it for me. Hopefully that might help others!
This post was removed by the author
We, too, are experiencing this with our selected states. It doesn't happen on every answer choice every time, and I've even had a course up on one monitor, saw the shift happen, moved it to another monitor, and then the shift didn't happen. Very weird!
We always check to be sure we have the settings correct - we just use normal and selected states - but even with the height and width remaining the same and the preview working fine, they get funky when published to Review 360.
We haven't devised a fix for it yet.
Hi Jillian,
Thanks for reaching out and sharing that you're experiencing a similar issue.
You mention that the behavior was different on another monitor. I'm curious about the display settings and what they are set to? Do the monitors have the same DPI setting?
I'd like you to share your project file with our support engineers to investigate what's happening with your permission. You can share it privately by uploading it here. It will be deleted when troubleshooting is complete.
Hello,
Would just like to add that our Team is also experiencing this issue. Thanks
Luke
Hi Luke!
We're happy to help! I'd like our team to work with you directly. Please use this link to connect with a Support Engineer.
Just want to add that I have this issue as well, and upon close inspection it appears to happen lots of places - a half-pixel shift upon rollover, or even where thin lines or frames should align exactly. If you drag your player window you can watch the items shift slightly. It's the hardest to deal with in quiz feedback buttons for me.
Hello,
Is there a solution for this case? It's really frustrating.
We are experiencing the same issue when we run the output on our lms. Workarounds are very time consuming, I hope this can be solved. Only the hover states causes this for us
This is still an issue at the moment, my questions shift all over the place when they are hovered over. Even in a completely new (blank) file. Please address this issue as it is seriously distracting. I don't need to add a file because this issue can be reproduced with any .storyline file. Just create a graded question and voilà the issue appears.
Hi Leslie! I missed your reply. I'm sorry!
The monitors are the same setting, and this happens in every project we have, no matter the user/developer.
Thank you!
Hi Jillian!
No apologies needed 😊, and thanks for those extra details!
From here, I'd like our team to work with you directly to help troubleshoot. Feel free to use this link to connect with a Support Engineer, and someone from my team will reach out with a next step!
Hi I am experiencing the same with buttons, particularly when viewed in REview360. A hover causes a slight growth of the button and text although there is absolutely nothing in SL360 I can see to cause this. Is there a back end setting which causes hover states to demand more attention for the user?
Hello Sandy,
Thanks for reaching out! It sounds like you see a button with text increasing in size when hovered over after publishing in Review.
Without taking a peek at the button properties, It's hard to pinpoint what would cause this. Could you share your file with us here, or if you're more comfortable, connect with a support engineer here to share it privately. We're happy to take a look and help troubleshoot!
Adding my two cents here as well - since I want to receive updates about this. The shifting text for hover and selected states is a definite issue. Overall, it makes quizzes feel "sloppy" - like a developer didn't take the time to perfect text box sizing, letting, or whatever. I often delete states and recreate them manually when this occurs, but that only solves the issue sometimes. I'm spending too much time on these fixes and still, most of the time, I'm settling for "good enough." As someone mentioned above, there's no need to upload a file since this is a well-documented issue that has persisted for a long time.
Thank you for any insights you can provide on the status of this update.
The issue seems to be that the shifting happens on selected because the radio button's size changes ever-so-slightly, and that's not something we can control, as far as I can tell. What we've resorted to, which is time consuming, is create text boxes that lay over top of the automatically created ones. We then white-out the original text that's under our new text. It removes the selected state problem, but it's not great.
I do have a ticket in with this, and the engineer is always helpful, but they seem to think it's an issue with the modern player, and we've had this issue well before we started using the modern player.
We were using the Classic player at 100% and did not have this issue. We recently moved to the Modern player and this issue is persistent through everything we are building. It appears to be related to what size the browser window is and how Storyline displays states in response. Sometimes we don’t get the jiggle and sometimes we do.
I see that you keep referring people to support engineers. If there is a solution/s to this issue, I wish you would post it/them and direct us to it.
This is extremely annoying.
Hello Steven,
Thanks for following up, and I'm sorry you're experiencing this as well.
Our team has a bug logged where hovering over and selecting choices in a graded question slide will cause the text to be jittery when using the Modern player.
For now, the workaround we recommend is to use the Classic player and lock it at optimal size:
I'm sorry I don't have a fix to report now, but you're in the right place to receive new updates now that you're subscribed to this thread!
Also experiencing this issue. Please fix ASAP! Can't use the classic player, so not an option. The Modern player comes default with Storyline 360 and we paid for that, so please fix it.
Hi everyone!
We just released another update for Storyline 360, and included are some new fixes and features you'll see in the release notes here. Just launch the Articulate 360 desktop app on your computer and click the Update button for each application. Details here.
While several bugs are referenced in this discussion, I wanted to point out a related one that some of you may be experiencing. We fixed the issue where:
A Hover state is causing text inside objects to shift whenever an object is hovered on when the player is set to "Scale player to fit browser."
I don't have any updates to share on the others mentioned, but we'll be sure to share any news here as well!
Overview
Our team has been struggling with this issue for a while now. We have been doing a text overlay on top of where the text of the radio buttons are, then getting rid of the text in the radio buttons themselves by either blending them into the background or simply keeping the shape of the hot zone of the button, and deleting the text. This solution, although it does work well, is rather kludgy and adds to the work load. And it also might make maintenance a hassle down the road.
Dreaded Technical Details
The radio button images change shape in the different states. The Down state and the Selected state are slightly larger than the Normal state. Since HTML flows from left-to-right, top-to-bottom, whatever changes on the left will affect what gets drawn to the right of it. So when a radio button changes state from (for example) Normal to Down, the graphic in the state changes from 20 pixels wide to 22 pixels, and shoves the text over to the right and down one pixel.
For those of you that have worked in Flash, you may know about a thing called a registration point. That is the point of reference for a button or a graphic where things proceed from, or to put it another way) grow from. The "registration point" in Storyline buttons is always the top-left corner of a button, so when the graphic associated with the state of the button changes, it changes everything downstream.
Articulate attempts to solve this issue by making the default vertical alignment of a radio button to Middle. This attempts to allow the states of the button to stay relatively steady, with no movement upon clicking it. But they precede from a false premise: that it's "registration point" is the center of the radio button's graphic, rather than the top-left.
A Solution
I found that if you change the default vertical alignment of the radio button to Top instead of Middle, this shifting between states goes away.
I also make sure my radio button text follows this general guideline with a 16px font size (which we are using as a default size):
If these buttons are vertically aligned on the slide, they need to be well-separated - not on top of one another, in other words. Just keeping them apart a little bit helps with the screen redraw issue.
Directions
Start by right-clicking on the radio button and go to:
Format Shape >> Text Box >> Text >> Vertical Alignment
and select “Top”.
You may also need to adjust the top or bottom margins in order to get the text vertically centered to the radio button - especially you have two- or three-line answers. Add margins by going here:
Format Shape >> Text Box >> Margins
There is a Top and Bottom margin setting that you can play with to center the text to the radio button. But as long as the height of the buttons follow the size recommendations stated above, you shouldn't have to tweak these much.
Also, be advised that Storyline sometimes changes the height and width of the states of the radio buttons for unknown reasons. To check this, right-click on the radio button and go to:
Size and Position >>
And check each state of the button to be sure width and height for all states are the same.
HTH!