Hello all - I have a question about the Selected and Hover states.
I have an 4 images - as you move over each image - I have the hover state set so it gives it a slight highlight, and I have the selected state so it makes it a bit brighter.
I have noticed however, the hover state seems to take precedence.
What I mean is that if I hover over my image - it highlights - I click it - but it appears that nothing happens. But once I move off the image - the selected state then displays.
What I want to happen is when I click it - it changes to the selected state - and not the hover state at that point.
Do I have to explicitly make that happen on the click trigger?
If you're having difficulty getting the states to work as detailed there, are you able to share a sample .story file with us here so that we could take a look at what you've got set up?
Ashley, has this been solved? A "Selected-hover' state would in fact be a really great feature-add for Storyline. We use custom buttons/options for all of our courseware and this is an ongoing issue on my team as well.
I'm not sure based on Rob's description (as I didn't see his file) if he was using triggers or allowing the states to control themselves based on the definitions? There isn't a state that combines selected and hover if that is what you're looking for - but you're always welcome to share your thoughts in the form of a feature.
Thanks for the response Ashley, I've sent the feature request sent, but this really needs a workaround in the meantime...
For example: We're using states to show selections of graphical elememnts that are in a custom marked quiz, and we're experiencing (and always have) the same issue that Rob described: When the user clicks the element, it doesn't appear to be selected until the mouse leaves the area. If the 'down' state is also used, the selection identifier (in this particular case is a checkmark) shows ONLY while the mouse button is down and this is confusing to learners. The flip side (that we've tried) would be to include the checkmark in the hover state, but then if the element is already selected and the user is de-selecting the element the checkmark stays there until the mouse leaves the region. Herein lies the NEED for a selected-hover state.
Thanks for describing that fully here - it's really helpful and hopefully you included that in your request as well. I'll defer to our community of experts for other design solutions and workarounds.
Lacking some genius input (and there are geniuses here), I think you are faced with a priority decision. Which is more important, hover or down and selected? My personal preference is to drop the hover, for what it's worth.
Hi, if you folks are still subscribed, I was hoping to get some clarification on what you're looking for. I feel like, if I understand this correctly it would be useful, just want to make sure I am on the same page.
I am attaching a story with a button with 4 states. Right now, I am not sure if you are:
A.) Looking to create something like what is shown (due to the way hover works, which you can see bleeds into the down and selected states) ?
B.) Looking for a 5th state to be built in and available for that purpose, without the hover state bleeding in?
Thanks Bill for sharing an example - even if they're not subscribed it may help others who come across this thread, so we always appreciate the examples.
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!
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?
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.
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.
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.
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. :(
18 Replies
Hi Rob,
You don't need to create triggers for these as detailed here in the definitions of all the states, and how they'll behave.
If you're having difficulty getting the states to work as detailed there, are you able to share a sample .story file with us here so that we could take a look at what you've got set up?
Ashley, has this been solved? A "Selected-hover' state would in fact be a really great feature-add for Storyline. We use custom buttons/options for all of our courseware and this is an ongoing issue on my team as well.
Hi Jay,
I'm not sure based on Rob's description (as I didn't see his file) if he was using triggers or allowing the states to control themselves based on the definitions? There isn't a state that combines selected and hover if that is what you're looking for - but you're always welcome to share your thoughts in the form of a feature.
Thanks for the response Ashley, I've sent the feature request sent, but this really needs a workaround in the meantime...
For example: We're using states to show selections of graphical elememnts that are in a custom marked quiz, and we're experiencing (and always have) the same issue that Rob described: When the user clicks the element, it doesn't appear to be selected until the mouse leaves the area. If the 'down' state is also used, the selection identifier (in this particular case is a checkmark) shows ONLY while the mouse button is down and this is confusing to learners. The flip side (that we've tried) would be to include the checkmark in the hover state, but then if the element is already selected and the user is de-selecting the element the checkmark stays there until the mouse leaves the region. Herein lies the NEED for a selected-hover state.
So, thoughts on a workaround?
Hi Jay,
Thanks for describing that fully here - it's really helpful and hopefully you included that in your request as well. I'll defer to our community of experts for other design solutions and workarounds.
Lacking some genius input (and there are geniuses here), I think you are faced with a priority decision. Which is more important, hover or down and selected? My personal preference is to drop the hover, for what it's worth.
Hi, if you folks are still subscribed, I was hoping to get some clarification on what you're looking for. I feel like, if I understand this correctly it would be useful, just want to make sure I am on the same page.
I am attaching a story with a button with 4 states. Right now, I am not sure if you are:
A.) Looking to create something like what is shown (due to the way hover works, which you can see bleeds into the down and selected states) ?
B.) Looking for a 5th state to be built in and available for that purpose, without the hover state bleeding in?
or C.) I still don't follow.
Thanks for the clarification.
Thanks Bill for sharing an example - even if they're not subscribed it may help others who come across this thread, so we always appreciate the examples.
Hi Bill,
In our case, we're looking for "B" the 5th state that does not bleed through.
Regards,
Jay
That is correct Jay - B is what is missing.
And 5 years later, we still don't have a "Selected-hover" state. Why is this taking so long?
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.
"Thanks for sharing your issue. We will look for solutions, but not really." Great stuff!
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. :(