Can anyone tell me what's the point of Storyline's default functionality where a state is selected but it reverts to the hover state when you're hovering over it. In my opinion, the hover state should ONLY be functional in the normal state. That makes sense, right? It's also so inconsistent.
Sometimes, I have no problem with clicking the object, activating the selected state, and not being bothered by the hover state whenever I move the arrow in the area.
How can I make it so that the hover state isn't annoying me when the user clicks on the object and activates the selected state without creating a hundred different triggers?
I totally agree with you. I always use this workaround, Cut and paste the object back while you are in the selected state. You won't need any triggers. See the attached video.
Edited after Walt's post: I assumed the hover state was needed. If not, Edward, disregard my post and do as Walt suggested below.
The answer seems intuitive to me. If you don't want the object to show that the mouse is over it, don't use the hover state.. it really serves very little practical purpose, if any. I use shapes rather than the built-in buttons, precisely because of the huge load of built-in states (baggage, in my opinion) that they carry. I only add states that are absolutely necessary. Selected frequently is, while Hover without adding new information, seldom is.
See, I disagree. Hover states are critical for me because I'm using several shapes that must be selected in order to compare each shape's information. The hover state is instrumental in its visual clarity for the learner of what is to be selected.
Hover states although not explicitly an accessibility requirement it does help to identify content that can be interacted with.
@Edward in contrast how is the additional content of your hover state passed onto the user if they use a keyboard? The content will take focus but will not show the hover state - did you add the additional instructions to the alt text?
4 Replies
I totally agree with you. I always use this workaround, Cut and paste the object back while you are in the selected state. You won't need any triggers. See the attached video.
Edited after Walt's post:
I assumed the hover state was needed. If not, Edward, disregard my post and do as Walt suggested below.
The answer seems intuitive to me. If you don't want the object to show that the mouse is over it, don't use the hover state.. it really serves very little practical purpose, if any. I use shapes rather than the built-in buttons, precisely because of the huge load of built-in states (baggage, in my opinion) that they carry. I only add states that are absolutely necessary. Selected frequently is, while Hover without adding new information, seldom is.
See, I disagree. Hover states are critical for me because I'm using several shapes that must be selected in order to compare each shape's information. The hover state is instrumental in its visual clarity for the learner of what is to be selected.
Hover states although not explicitly an accessibility requirement it does help to identify content that can be interacted with.
@Edward in contrast how is the additional content of your hover state passed onto the user if they use a keyboard? The content will take focus but will not show the hover state - did you add the additional instructions to the alt text?