The company I am at hopes to one day deliver content via mobile devices and in anticipation, does not want to use hover states in any courses so that the same courses can some day be used on mobile devices.
While I don't necessarily agree with that strategy, I am open to finding ways to not use hover states. Unfortunately, they can be used in so many great ways. Has anyone shared a similar experience and did you find any tricks or things that worked well to design courses not using hover states yet still maintaining quality, effectiveness, visual appeal, etc.?
Interesting question... Maybe you can still consider using hover states as long as they aren't necessary to viewing content. What i mean is, you can still use a hover state on a button and then it will appear to people using a computer, but it won't appear to the users on the tablet. That's fine because it doesn't impact the course one way or another. It just becomes a problem when you're using the hover state to show important information or something necessary for the learner. I think you can definitely do a hoverless course and still maintain quality and visual appeal. Fun challenge!
Thanks for your input! I think you're right in still using hover actions, just make sure it doesn't display important information. It will be a compromise, but at least I won't have to eliminate hover states altogether. In the mean time, I'll also try to come up with creative alternatives to the important hover interactions.
I have been building courses for which the primary audience is tablet users and had the same issue. Have had to work with making things into buttons instead of using hover and also incorporating more drag and drop interactions.
Careful design with current limitations and you can maintain hover states for desktop viewing while still having a similar experience on tablets.
First, the hover state behavior on desktop behaves as expected. That same state on a tablet becomes the 'down' state. When a finger taps on a button the hover state appears. A quick test with a few buttons proves that it's not that much of a concern.
Secondly, the concern lies in the user experience design. Provided your buttons/objects are intuitive that invites a mouse-over, that same visual design will arguably invite a finger tap. If you're showing a layer as when a user mouses over an object, that same layer will show when a finger taps and holds a button/object.
Remember, hover states are a visual reaction to an event (mouse over). The motivation begins before the actual event. Using the same approach that motivates a user to mouse over an object would essentially be the same to tap a button/object.
While I don't necessarily agree with that strategy
This is kind of interesting to me. I don't find that hover states (besides the ones where they aren't necessary viewing the content and are just for visual cues) give me more value than just clicking to reveal something.
As Kevin suggested, you could easily make it so that the selected or down state and the hover state are the same thing. That way if you're on desktop, you can just hover, but it doesn't prevent people from being able to click on it on their phone.
It would be interesting to know if users would actually use the down stage...
Personally I tap on objects, the only time I think I use the down state is when I am saving memes from google as the down state brings up a menu. Actually now I think about it that's more a long press.
It would be interesting to know if users would actually use the down stage...
Yeah, I'm partial to "selected" state myself. I don't know if I've ever used down state on a course but I could see it being useful for a meter or something along those lines.
In Storyline you don't have to do anything additional with object states for mobile use. Create a normal button with a hover state. When you publish and view on desktop, the visual feedback of the mouse over will show the hover state.
That same button viewed on a tablet will display that same hover state but now behave *as* as down state when tapped (because you can't hover your finger over).
I've never used hover in Storyline because my very first client with it, was planning to have ipads. I never miss the hover state because I've never used it. I have always designed info to show when clicked on. I think it will be a challenge for you at first, but you will get past it. Its kind of a mindset change.
I agree Jacinta, although I have used hover states, with more and more courses requiring mobile accessibility I find myself tuning my design into something that works for both and the hover state is something I'm using less and less.
The down state is something I've never used in my life. I can imagine it could be useful for mobile designs when used intentionally. A Hold-and-reveal interaction!
The built-in Hover state behaves like the Down state on mobile. I still find it useful for some designs that I need both desktop and mobile. Project dictates.
Nope, that's why I'm asking for creative suggestions.
You can do some pretty effective things with hover states and I was looking for something other than turning everything into a click interaction. I think Kevin has especially added some helpful information.
17 Replies
Hi Walter!
Interesting question... Maybe you can still consider using hover states as long as they aren't necessary to viewing content. What i mean is, you can still use a hover state on a button and then it will appear to people using a computer, but it won't appear to the users on the tablet. That's fine because it doesn't impact the course one way or another. It just becomes a problem when you're using the hover state to show important information or something necessary for the learner. I think you can definitely do a hoverless course and still maintain quality and visual appeal. Fun challenge!
Hi Nicole,
Thanks for your input! I think you're right in still using hover actions, just make sure it doesn't display important information. It will be a compromise, but at least I won't have to eliminate hover states altogether. In the mean time, I'll also try to come up with creative alternatives to the important hover interactions.
You could use mouse clicks (equivalent on mobile to taps) to show layers. Set the layers to hide when timeline ends.
I have been building courses for which the primary audience is tablet users and had the same issue. Have had to work with making things into buttons instead of using hover and also incorporating more drag and drop interactions.
Careful design with current limitations and you can maintain hover states for desktop viewing while still having a similar experience on tablets.
First, the hover state behavior on desktop behaves as expected. That same state on a tablet becomes the 'down' state. When a finger taps on a button the hover state appears. A quick test with a few buttons proves that it's not that much of a concern.
Secondly, the concern lies in the user experience design. Provided your buttons/objects are intuitive that invites a mouse-over, that same visual design will arguably invite a finger tap. If you're showing a layer as when a user mouses over an object, that same layer will show when a finger taps and holds a button/object.
Remember, hover states are a visual reaction to an event (mouse over). The motivation begins before the actual event. Using the same approach that motivates a user to mouse over an object would essentially be the same to tap a button/object.
This is kind of interesting to me. I don't find that hover states (besides the ones where they aren't necessary viewing the content and are just for visual cues) give me more value than just clicking to reveal something.
As Kevin suggested, you could easily make it so that the selected or down state and the hover state are the same thing. That way if you're on desktop, you can just hover, but it doesn't prevent people from being able to click on it on their phone.
It would be interesting to know if users would actually use the down stage...
Personally I tap on objects, the only time I think I use the down state is when I am saving memes from google as the down state brings up a menu. Actually now I think about it that's more a long press.
Yeah, I'm partial to "selected" state myself. I don't know if I've ever used down state on a course but I could see it being useful for a meter or something along those lines.
In Storyline you don't have to do anything additional with object states for mobile use. Create a normal button with a hover state. When you publish and view on desktop, the visual feedback of the mouse over will show the hover state.
That same button viewed on a tablet will display that same hover state but now behave *as* as down state when tapped (because you can't hover your finger over).
There's nothing extra you have to do.
I see - that makes sense Kevin. I misunderstood your first response.
Though I'm still partial to selected state :) (what if someone has an extra
large thumb that covers up the content?)
I've never used hover in Storyline because my very first client with it, was planning to have ipads. I never miss the hover state because I've never used it. I have always designed info to show when clicked on. I think it will be a challenge for you at first, but you will get past it. Its kind of a mindset change.
That's an easy one. Just use extra extra large buttons :)
I agree Jacinta, although I have used hover states, with more and more courses requiring mobile accessibility I find myself tuning my design into something that works for both and the hover state is something I'm using less and less.
The down state is something I've never used in my life. I can imagine it could be useful for mobile designs when used intentionally. A Hold-and-reveal interaction!
The built-in Hover state behaves like the Down state on mobile. I still find it useful for some designs that I need both desktop and mobile. Project dictates.
Is that really the hill you want to die on? If the company wants you to design without hover states, design without hover states.
Nope, that's why I'm asking for creative suggestions.
You can do some pretty effective things with hover states and I was looking for something other than turning everything into a click interaction. I think Kevin has especially added some helpful information.
This discussion is closed. You can start a new discussion or contact Articulate Support.