Have you ever found that the hover state in Storyline doesn't work the way that you want it to?
Maybe you're keen on having the selected or visited states always appear in front of the hover state, only to be disappointed when the hover state overrides them?
Or perhaps you are frustrated because when you click a button you expect the selected state to appear, but for some reason, nothing happens until you move the mouse away?
In this tutorial, we are going to look at why the hover state sometimes overrides the selected and visited states and what we can do to change that behaviour.
The way the states behave can be confusing because the behaviour isn't consistent and simple things like changing the border colour of one state can have an impact on the overall behaviour of a button.
In this tutorial, we are going to look at this problem in detail and figure out what leads to these inconsistent results. Then, we'll learn how to stop the hover state from overriding other states when that isn't wanted.
Let's Look at the Default Behaviour
Before we discuss solutions, let's look at the default behaviour.
In this example, we'll be using shapes in Storyline to create a custom button. So go to Insert > Shape and create a rectangle. Then go to States > Edit States and click on the New State button a couple of times. We want to create a hover state and a selected state.
At this stage, we aren't changing the hover state, but just the background colour, border colour and font colour of the selected state.
When this is done, we'll have something that looks a bit like this:
Below is a demo of this button. When clicked, the selected state appears immediately and the hover state does not override it.
The only indication that the button is clickable, is that the cursor changes from a pointer to a little hand.
Now, let's edit the states again. This time we are going to change the background colour of the hover state. When this is done, we'll have something that looks a bit like this:
In the demo below you'll see that the text colour and (if you look carefully) the border colour of the selected state is still overriding the hover state when the button is clicked.
However, now the background colour of the hover state is overriding that of the selected state.
This isn't a good look!
(And no, I'm not talking about the colour scheme that I'm using for this demo...)
Of course, the impact of changing the hover background isn't always so pronounced. In the demo above, it makes the text completely unreadable because they are the same colour. But in many cases, it just makes things look weird. For example, if we changed the background of the hover state to purple, we'd end up with a button like this:
Okay, that's enough purple for today.
Let's now edit the hover state again, but this time we will change the colour and thickness of the border.
By now, you can probably guess what is going to happen. The border of the hover state will override the border of the selected state.
Next, let's change the font colour of the hover state.
This will mean that the text colour of the hover state will override the text colour of the selected state. As you'll see below, there is now no way to tell that the button has been selected until the mouse moves away.
Isn't this fun!
Now you may be thinking that this can be resolved by changing the colours of the selected state? Let's give that a try.
Unfortunately, as shown in the demo below, it doesn't make a difference.
Maybe if we delete the hover state and recreate it? Nope.
Maybe if we duplicate the hover state, delete the original hover state and then duplicate the duplicated state and call it hover? Nope. And that's way too much duplication for one sentence!
Maybe if we delete the selected state and then recreate it? Nope.
So, How Do We Fix This?
The fix is quite simple.
We just need to go into the selected state, cut the button and paste it again.
Then the selected state will always override the hover state as shown below.
While this trick works, I think it falls firmly into the category of 'something that shouldn't be required'. It would be great it Articulate added other built-in states such as selected hover and visited hover so that we could easily control this behaviour as needed.
Of course, it is possible to create these states ourselves. However, due to the amount of triggers that it would take to set this up for every button. It is really only a viable option if you don't have too many buttons in your project (or, like me, you're a real glutton for punishment.)
The other option is to do away with hover states altogether. The change of cursor (from pointer to hand) indicates to learners that an item is clickable. Also, as hover states don't work on mobile or tablets, this would make courses more consistent across all devices.
Anyway, I trust that this has been helpful. If you have any other state related challenges, let me know in the comments below.
Files you might need:
Here is the .story file that was used in this example.
Frequently Asked Questions:
Q. Is this a bug?
A. Yes, I think so. But, if you look at the definition of built-in states you'll see that it doesn't state (sorry, couldn't resist) that the selected or visited states should override the hover state. So perhaps this is the intended behaviour?
Q. What if I use the inbuilt buttons or different states on an image?
A. The same rules apply.
Q. Are there any downsides of using this method?
A. Yes, there is one. Screen readers will see the selected state as a separate object (but Storyline doesn't, so it isn't visible in the tab order). This means that the screen reader will read the alt text of the normal state, then when the user tabs it will read the alt text of the selected state if it is shown. This is connected to a greater accessibility problem (where the alt text of states is usually ignored), but that's a conversation for another time!
Q. How could Articulate improve on this in future updates?
A. As mentioned above, having selected hover and visited hover states would be great. Alternatively, perhaps states on the right-hand side of the States panel could override states to the left. I think this would allow for more customisation (although it may also result in confusion). If you'd like to see something like this implemented, make a feature request.
Q. Does this work the same way in Storyline 360 and Storyline 3?
Q. What about Storyline 1?
A. I think so, but I haven't tested it as I couldn't find my dustbuster.
Q. Does this work in HTML5? (i.e. will it work on my phone and tablet?)
Q. Will this work in Articulate Mobile Player?
If you found this tutorial helpful and think others in your network will also, please share using the share buttons below. Thanks!