Selected / Hover state - what about selected hover??

Hi Peter,

Since this discussion is older, let's revisit the default behavior in Storyline 360! Currently, a Selected state will show a "Selected/Hover" until you hover off the object.

Let me know if you're experiencing something different!

Hi there, I have a similar issue.

When a user needs to select an object as an answer to a question, I would like the objects to have a hover state to show the user the objects are clickable. When a user then make their selection and clicks on an object I want the object to change to a selected state (the colour changes to indicate to the user it is selected) Thats all easy to do however the problem is when you click the object your mouse is still on the object and it goes to a hover state which makes the user think they havn't clicked the object properly and they keep clicking, then they think it's broken. Can you have a hover state on an object however when it is clicked and changes to selected it stayed selected (the hover state would be completely disabled) until if/when the user changes their mind and selects another answer/object?

Hi Sarah,

Thanks for reaching out! The hover state in Storyline 360 cannot be edited as of the moment. You can reach out to our product team by raising a feature request if you'd like to modify the current behavior of the built-in states. 

One design workaround that you can implement is to add a glow to the selected state of your object, so your learners will be able to quickly identify the moment that the object's state changes to 'Selected'. I've attached a sample file which demonstrates how this can be done. 

This  sample has another option.

Good effort Walt, that's a load of triggers to go with the custom state. Your example shows what most users want the buttons to do. But for lots of menu pages with multiple buttons linking to other pages, its a lengthy workaround and tricky to get a team across without someone mucking it up when editing (e.g. making button adjustments and additions on the fly). For a long course, its a lot of tinkering with buttons. I have tinkered with custom triggers and states to workaround this matter also, and find that method to be quite cumbersome and involved.

This matter should really be fixed in the Storyline 360 authoring program, and set different to how it is at present. This issue was flagged to Articulate here 7 years ago.

It was also flagged here 5 years ago - https://community.articulate.com/discussions/building-better-courses/tutorial-getting-the-hover-state-to-behave-itself

The above discussion contains an alternate workaround which like the workarounds discussed here should not be necessary. Its also somewhat inelegant and messy (e.g. after I cut and paste a button within a state (just to shift what layer it appears on in relation to other states), the button often changes size which then requires adjusting to match other states. My usage of that method over some time now confirms that the order in which users cut and paste states (or add new states) influences what state appears above others. This finding is not a product feature but a quirk not documented by the vendor, presumably not intended, but used by customers to get buggy buttons to become publishable for elearning projects.

This issue could be resolved by Articulate via:

1. a change to default configuration in Storyline so that Hover states do not appear above Selected or Visited States after being clicked - until after user moves cursor away from the object then moves back over button. This solution would not require users to make custom workarounds to a commercial authoring tool. Or;

2. add options to the 'Hover' state. Such as a tickbox for 'appear above Selected state after being clicked' and 'appear above Visited state after being clicked'. Storyline sets that option as unticked by default for buttons users create. Which means the problem is solved for most users. This way, if users have a desire to have the Hover state show above the Selected or Visited state right after clicking it (for a scenario I have not required yet) the option is there.

Fellow customers, the link to log bug fix issues is below. 

https://articulate.com/support/contact/feature-request

I've logged a request including example files and documents.

This is absolutely ridiculous that this hasn't been resolved. It is the most basic of UX expectations, that the Selected state takes precedence over the hover state. Or that we get a hover-selected state as previous suggested. We have to constantly either design around this huge flaw or use bubble gum and chicken wire triggers to work around what is such a glaring issue. After 4 years of being a heavy user of SL, I am beginning to wonder if monitoring this community is all for show. :(