Forum Discussion
Overlapping States
I've been noticing a randomly occurring, but frequent, issue since the newest update. On some objects, the Normal/Original state will overlap with any other state (Hover, Visited, custom states, etc.)
So when you hover over a button, the text might change color, or an image might change, but the original text or original image can still be seen underneath.
Here is a quick example, a side by side screenshot from a published example:
On the Hover state, the icon is changed so that the bars on the chart sit a little higher when hovered over, though you can still see the original icon being used underneath when this happens. Additionally, you can see the stroke thickness looks more intensified as the images are overlapping. If I did this with a lighter text color on the hover state, and made it bold, you could still see bits of the original text peeking out from behind. I've tried testing this with .PNG, .SVG, .GIF, and other transparent files, but it happens with Storyline assets as well.
Here's another example using an icon built into Storyline. On Hover, the icon should just rotate 90 degrees, however, when in Preview or Published mode - the icon overlaps, and instead of having horizontal lines, we're left with a waffle/grid. Each example was made using a new Storyline file.
What's strange (or stranger) is that I can make a new state, set it to hover, delete all the objects on that new state, copy and paste in place the original assets used, and then swap the icon - and it will still happen.
The only workaround I have is to paste in place the base of the button (in this case the white rounded rectangle) two or three times, depending on any shape effects (e.g. drop shadows), which adding a bunch of objects to one state doesn't always yield the smoothest results once published. Additionally, in some circumstances, doing this causes a flicker effect on the hover state where the new button base flashes in before the rest of the other objects do, or the drop shadow will flicker when hovered over.
Fixes? Workarounds? Is this a known issue that needs to be patched?
Unfortunately still an issue. My workaround was to have the normal state blank and triggering another state at timeline start, so the overlaying state has no interfering graphics. Not perfect, but works for now.
Hi Alexander!
Sorry to hear this has been slowing you down!
Thank you for sharing the workaround with the community. I'm sure other users discovering this thread will find it very useful. We'll be sure to update this discussion as soon as we have news to share!
I reverted to the previous version of Storyline and I am still having the issue. I was hoping the previous version wouldn't have this bug. Tried re-doing the states in this older version with no luck
Hello J C,
Sorry to hear that you ran into this issue as well. Our support team has identified the following workarounds which seem to have worked for some users:
- Remove the shape from the Normal state that persists in the Hover state. Here is a Peek 360 recording showing this workaround.
- Imagine that when editing the other states, the other objects from the Normal state are there. You'll just need to edit and overlap the state's objects with themselves to effectively "hide" the objects from the Normal state.
Feel free to open a case with our support team here so we can look at your project file and check which workaround works best for you while we permanently address the behavior.
Thanks Jose- I found a workaround by creating a small object as the normal state and then basically doing what you said- using the other states to cover that object.
Did anything ever get fixed with this? I am having the same issue. Visited and Hover AND Selected states overlap.
Hover is meant to be black text on green circle. Selected is the exact same. And Visited is meant to be white text on black, with the green checkmark above the text. After clicking, it shows this:
Hello Kristen,
I'm sorry you've hit this snag. The description you shared seems different from the bug reported in this post. Would you be willing to share a copy of your Storyline file privately through a support case so we can look at how the states and triggers are set up?
Our Customer Support Engineers can help determine whether the behavior is within the scope of the existing bug and find possible solutions. We'll delete your file when we're done testing.
Hi Kristen,
I can confirm that the issue has not been fixed after all of these months, years, and versions. I just had this issue pop up in Storyline 360 x64, and I was the person who originally made this post, so it is still very much an ongoing issue that is still affecting most, if not all, users.
It looks like your issue may be similar, if not the same, though its hard to tell without knowing what the Normal state looks like - though it does appear identical to the issue in this thread. Adding a screenshot of your States menu would be helpful!
Again, the best option, until it eventually gets fixed within the upcoming months or years, is to simply workaround Storyline's issues. A "fast" way is to simply break the relation between the states by deleting everything. Here's how to do that:
- Select the object
- Select Edit States
- Select New State
- Select All (Ctrl + A)
- Delete everything from the New State
- Go back to the Normal state
- Select All (Ctrl + A)
- Copy (Ctrl + V)
- Return to your New State
- Paste-in-Place (Ctrl + Shift + D)
- Make any necessary edits
That should do the trick, though it sometimes doesn't work. If that's the case, you just have to workaround the workaround. In this case, it could be copying and pasting the green circle and recoloring it. The key thing to note, is that it will overlap anything it doesn't find new and different from the original/Normal state. For example, the circle can change colors - but its still the same circle to Storyline. However, copying and pasting that same circle and recoloring it makes it a new circle, and thus it shouldn't overlap. Does it create extra work? Yes. Is it inconvenient? Yes. Is it the best option? Basically.
There are several workarounds, and plenty of great advice in this thread, if both of those options do not work! I look forward to when this issue will eventually be resolved in a future version of Storyline, as it really takes away from Storyline and its use.
Hi, having the same issue here. I have been using Storyline since it was released and this is the first time I am experiencing this.
The funny thing is that it happens with some elements, and some other is not. This erratic behaviour makes it so difficult to identify and correct, because it is not happening on preview mode, only when publised :(
Adding my vote here to have a solid look into this.
Thanks @spencer for the follow up.
Hello Victor,
Sorry to hear you're having issues with your project file related to overlapping states. It sounds like some random elements in your slides may be causing the issue for some objects but not for others.
Could I have you connect with us in a case so we can determine what's happening? Our support engineers may request a copy of the affected Storyline project to aid in the investigation. You can share it with them privately within the support case. We'll reach out soon after we hear from you!
(Edit: I see that other people have already suggested this, but I wanted to throw this out there anyway for anyone new to the thread.)
There may be a workaround using custom states. I was having the same issue when using Storyline's built-in states (hover, down, visited, etc.) and created a custom state with a trigger to simulate the built-in state I wanted.
Ex: The Normal state was overlapping the Hover state
My steps:
1. Create a new state by typing in a name different from the built-in options (Ex: Object Custom State)
2. Edit the custom state as desired
3. Create a trigger with the "Change state of" Action (In my case: "Change state of Object to Object Custom State when the user hovers over Object")
4. Select the "Restore previous state when the user hovers out" option
This showed no overlapping in Edit or Preview Mode
(From intern Anna Miller, working under Brandon Horn)
Hello, does anyone solved this issue? Yesterday and today I worked on two different files from two different courses, and still facing this unexpected behavior :(
I attached an image where you can see a yellow border, wich should be the hover status, a green icon which belongs to Visited status, and a white mark behind the green icon which belongs to the Normal status :D
I'm using Storyline 64bit v.3.90.32893.0
I'm going to submit a new case attaching my file.
Thank you!
Hi Giulia,
I'm sorry to hear you've hit this snag!
It looks like you're working with Philam in a support case. We can continue the conversation there if you have any questions.
I have a case in support right now. Not much happening so far.
Hi Mike,
Thanks for reaching out. I see you've connected with my teammate, Gerald. You're in great hands!
Hi folks,
I am having this same issue. It looks like the Staff here are more dedicated to finding temporary work arounds than an actual solution after 2 years of this ticket being active.
When will we stop being told to add Story files and submit tickets and finally have Articulate correct this behavior issue? Two years of Band-Aids is extremely unreasonable for your costs.
I am experiencing this issue as well. I have worked in Storyline for a very long time, and never encountered this before. I need a workaround, as I am on a very short deadline.
My normal state has a star shape added to it, and it is showing through in the other states. This is extremely frustrating. I have already wasted hours on this, and this is not billable time. I cannot expect my clients to pay me for issues due to the software.
Hello Carrie,
Thanks for reaching out!
Just to clarify the behavior you're experiencing, the built-in states by design are treated as a layer on top of the normal state, which means if an object from the normal state is not completely covered when a built-in state is shown, the object will be visible in the built-in layer. We have an open feature request to improve this behavior based on the feedback shared here in the community, and we'll let you know if there are any updates.
One way around this is to use custom states instead. I've attached a sample project file that compares the behavior of built-in states with custom states. You'll notice using custom states prevents objects in the normal state from appearing when a change state occurs.
If you don't mind me mentioning, as the original poster, this was not 'normal' behavior several years ago when I reported the bug originally. It actively caused issues mid-project, which was what prompted me to open a support case, where Articulate staff acknowledged the issue and logged it as a "software bug".
Could you provide some context or history on the issue? I've been trying to find out information about my support case that's been open for over three years, but I'm finding out more information in Articulate's replies to other people's comments on my post than I am directly from Articulate.
I don't mean to come off as complaining! I believe some transparency would really help in instances like this! I don't mind if it takes several years for Articulate to address a bug, so long as its being addressed and I can see/know its being addressed. I get that Articulate has a lot of pots on a lot of stoves, and some things can sit on the back burner a bit longer. However, reading that the bug is now considered 'normal' behavior and the fix is now a 'requested feature' is a bit disheartening and confusing.
This was never normal behavior and it's unfortunate that is how it's being presented now. There are a few other bugs with states that cause you to have to delete and restart the entire state. I truly hope those will not be considered "normal behaviors."
