Forum Discussion
How do button states stack?
I am making a collection of button templates in the style of my company's branding. In doing so, I want to make full use of the functionality that states in Storyline 360 provide, but am having trouble making sense of them.
My issues come from the interactions between states that are active simultaneously on an object. In this case, the Hover, Selected and Visited states.
Firstly, here's what I want to do:
The button has a Normal state with a medium blue fill and black text.
The Hover state should set the fill to a light blue.
The Selected state should add 6 px. black outline.
The Visited state should set the fill to a dark blue and the text colour to white.
My resulting states are shown below as they appear in Storyline. For clarity, I added a text box to each state, to see when each one was active.
The expected behaviour is that when, for example, the button is Selected and Visited, it should have the black outline, dark blue fill and white text.
The resulting behaviour, however, is that the button has the medium blue fill and black text of the Normal state, plus the black outline of the Selected state, as shown here:
At first, I assumed that the Selected state was just overwriting the Visited state completely. However, when I added the text boxes I saw that was not the case, as both words were visible at once.
In case only the "edited" parts of each state were overwriting each other, I reset each state and edited only the aspects that differed from the Normal state (in case I had accidentally set the Selected state's fill and text colour to the same colour as the Normal state, and that was overriding the Visited state). Unfortunately this had no effect on the results.
Is this expected behaviour? And if so, how exactly do different changes from different states overlap? Is there a way to achieve what I want to do without adding several custom states corresponding to each possible combination?
Thank you in advance
This is a long overdue issue with states in buttons in Storyline. A lot discussions about this to be found in the community. One of the weirdest things is, that when you make custom buttons yourself. So an image with states...they behave differently then out-of-the box buttons ( with states ) you edit.
Some of the results you describe are mutually exclusive. For example, you describe wanting the Selected state’s outline to override the Visited state’s, but the Visited state’s text to overwrite the Selected’s text.
Still, Math is right. Some consistency, leading to predictability in button states would be helpful.
I've done a LOT of work with button states and I've found that when something doesn't display correctly, there's usually a good reason. If I ran into a button display issue, and the resolution wasn't obvious, what I would end up doing is deleting the button altogether, and then recreating it from scratch. Simple enough. I'd be happy to look at this scene, and hunt down the issue alternatively. Could be there is left-over content that's not visible for some reason until the button is clicked. I've never head of states "overlapping," but there's likely unresolved formatting in the button state.
I've thought of a new way of phrasing my question that may help clear up some confusion:
Do states store all of the information about what they display, or only the parts that are different from the Normal state?
The first option would mean that when an object is in its Visited state, Storyline only displays the Visited state.
The second option would mean that when the object is in its Visited state, Storyline displays the Normal state and then applies the changes for the Visited state (in my example, it would change the font and fill colours).I really appreciate your offer to help though. I've attached a story file with just the button in question. Following your advice, I recreated it from scratch (without the text boxes for each state), taking extra care to only edit the properties of each state that I wanted to apply when combined. However, the same thing happened as before, and only one state applies at a time.
Hello EmiledeKadt,
Happy to chime in!
You can think of the built-in states as states that are added as a layer on top of the normal state which would explain why elements from the normal state sometimes show in the other built-in states. One way around this is to add a background for the built-in state or use custom states for the interaction.
We understand the feedback from the community regarding how this behavior can be improved, and we're all tracking this through a report that gets shared with our product team. We'll let you know if there are any updates for this behavior!
Storyline 360: Definition of Built-In States
- Normal: This is the neutral state for an object. By default, it's also the initial state for an object (i.e., how it looks when it first appears in the published output), but you can change the initial state if needed.
- Hover: This is how an object appears when learners move their mouse over it. If this state exists for an object, it'll automatically display when learners hover over it. You don't need to create a trigger to invoke the hover state, but if you want to use this state on a trigger, note that trigger conditions won’t restrict its built-in function.
- Down: This is how an object appears while learners are clicking it. If this state exists for an object, it'll automatically display when learners click it.
- Selected: This is how an object appears when it's been selected. It's generally used to indicate that a learner has chosen the object. For example, a check box uses the selected state to provide a visual cue (check mark), indicating it has been clicked.
Selected states are often used in conjunction with button sets, so only one object gets selected at a time. If the selected state exists for an object, it'll automatically display when learners click it. You don't need to create a trigger to invoke it, but if you want to use this state in a trigger, note that trigger conditions won’t restrict its built-in function.
- Visited: This is how an object appears after learners click it. It's useful when you want to provide learners with a visual indicator of the objects they've already clicked (for example, a series of buttons).
Storyline 360 remembers this state when learners revisit the same slide later unless you've configured the slide properties or layer properties to "reset to initial state."
If the visited state exists for an object, it'll automatically display after learners click it. You don't need to create a trigger to invoke it, but if you want to use this state in a trigger, note that trigger conditions won’t restrict its built-in function.
- Disabled: Use this state when you want to disable an object. A disabled object is visible to learners, but it won't respond when hovered over, clicked, or dragged. Unless it's the initial state of an object, you'll need to use a trigger to invoke it.
- Hidden: This state makes an object invisible. Unless it's the initial state of an object, you'll need to use a trigger to hide an object.
