A typical interface screen has many elements on it. Hover effects inform users what they can interact with by providing visual feedback on buttons. But there’s a problem — hover effects are for desktop apps, not mobile apps.
There are no mouse devices on mobile, so users don’t have the luxury of using hover effects. Using a hover effect on mobile apps causes buttons to stay stuck in the hovered state when tapped. This stickiness not only confuses users, but it frustrates them when they’re forced to double-tap buttons to initiate an action.
Removing the sticky hover effect isn’t enough. Mobile users need visual feedback because mistapping buttons is a common problem. The target sizes of mobile buttons are smaller than desktop ones and more challenging to hit. Not only that but sometimes their finger will hit a target with different surface area pressure that won’t always trigger the action.
The hover effect for mobile buttons is a ripple effect. A ripple effect provides the visual feedback users need when they tap a button. Users see a ripple animation on the button that assures them their finger hit the target accurately. If they don’t see a ripple effect, they know they mistapped the button. The visual feedback gives them immediate confirmation of an accurate tap so they don’t end up waiting and wondering why there’s no response if they mistap.
A ripple animation is intuitive because it mimics the touching of water. When you throw a stone into a pond, there’s a ripple on the surface that allows you to see where it landed. The property of water provides visual feedback, just like a ripple effect.
It’s important to convert your desktop hover effects to mobile ripple effects. Doing so gives users certainty and assurance that they’re hitting their target after a tap attempt. It’s not quite like a hover effect, but it provides the same visual feedback users need when they interact with buttons.
Book
Affiliate
What about using ripples everywhere, including desktop?
That wouldn’t cause a problem, but this technique is especially needed for mobile buttons.
Does any mobile browser add this ripple effect on buttons natively?
Hi Anthony,
To be fair I don’t see the upside to a ripple effect at all. That effect, just like a regular change of colour or scaling, still does only one simple thing: showing whether a button has been clicked or not.
“Mobile users need visual feedback because mistapping buttons is a common problem.”
How would a ripple effect solve this in any different way than a normal state change of a button?
The ripple effect is a state change of a button. But it’s better because it’s a more intuitive one that mimics the metaphor of touching water which follows the principle of familiarity. It triggers and dissipates immediately, letting users know progress is taking place much like the pulsation in a progress bar.
Yes the ripple effect you’re describing is pretty neat but I don’t think you can say with any confidence that this approach is “better” due to it being more intuitive. If you want a button interaction that follows principles of familiarity surely have a button displaying as “pressed” with sympathetic inset shadows, etc… (i.e. mimicking a real world button) would be the most intuitive solution.
Without any demonstration of statistics from users I think it’s difficult to argue any solution is “better” that another.
It’s intuitive because of the reasons mentioned in the article. The difference between a ripple and a pressed effect is that the ripple is more noticeable because it has motion animation. It’s stronger confirmation and feedback to users when they’re not sure if they fully tapped a button.
I have to stand by jon.
Imo the »ripple« effect is not really improving the feedback of touching a button.
My main point is, that this effect mimics something you never have in such a context in a real world situation. Besides, im not really liking the appearance and »look and feel« of such a solution.
There’s nothing inherently sudden with a button press animation, it’s up
to the designer how instant or gradual a change is visually.
And this is my gripe with this article. You even mention this, that hover effects are for desktop, not mobile. Yet you still make the comparison as hover vs ripple. What your article is really about is instant fx vs ripple. In that case I agree, ripple is more intuitive. But make a gradual animation and the case isn’t shut as easily.
I’m sorry but now you’re just being condescending and your arguments fall flat. I don’t want to be negative but you’re profiling yourself as an expert and are spreading these articles as facts without actual statistics are actual good arguments for that matter. Could you please respond to my first question?
“Mobile users need visual feedback because mistapping buttons is a common problem.”
How would a ripple effect solve this in any different way than a normal state change of a button?
” you’re profiling yourself as an expert and are spreading these articles as facts without actual statistics are actual good arguments for that matter”
That statement is condescending yet you’re calling me condescending. You should be careful, hypocrites have no credibility.
In any case, lets get to the root of the problem. That’s fine that you disagree. But what are you disagreeing with and why do you disagree? You have not made a case against anything I’ve said. Asking a question repeatedly is not making a case. Making a case requires statements with specific reasoning behind it.
Since you’re not clear, I have to do extra work to infer what you’re saying. So, if you were really making a counter case, you would say: “The ripple effect does not prevent users from mistapping buttons because…”
Then I would respond back by saying that I never claimed it prevents mistapping. This quote “Mobile users need visual feedback because mistapping buttons is a common problem.” is not claiming that it prevents mistapping. The visual feedback is to confirm whether the user mistapped or not. If you go on to read the rest of the article, you would see that it says that.
I agree with anthony, I think google team design won’t waste time and research fund on the whole material design without a basis. Although I wish ripple effect can be implement purely on CSS.
As a user, I hate such effects. It may look good at first, but you soon get annoyed by it.
I’m kind of confused here because I feel like there’s a mix between the :hover vs :active in CSS On mobile Chrome, if you declare :hover then :active (the proper way) and touch the button, it gets the :hover color then the :active then it keeps the :hover color. Is this an issue? Because usually when users hit a button (or link) they expect something to happen, like a new page loading, something appearing, etc. So I’m not sure this is a real issue. Is it? Like did someone in user testing actually see some issues with this?
In native apps, I’m not sure there’s a hover state anyway, so this is a “non problem” for native apps where you only get the equivalent of “active” state which is when users hit the button.
The issue is the button staying stuck on hover after tap. If you google “sticky hover mobile” you’ll see many people having issues with it.
I like the concept and I’m looking to put that into my project right now. I was wondering if you had any examples of this ripple effect being applied in an app or website? Looking for references – thanks!
I’d love to see some code examples of this.
I am a bit shocked with the comments against ripple effect. The satisfaction of having this kind of feedback feels super natural to me. As Anthony explained, it’s like throwing a rock in the water and seeing the water respond back. When you use your finger to tap on the screen, you’re applying pressure on the screen, so it feels fluid to see an effect of expansion that looks like it started where you tapped. It will not make you tap there more or faster, but gives you a subtil satisfaction and a sense of continuity.
I’m a little late to the party here, but wanted to add my 10 pence worth. I’d understand the desire to use the the ripple animation because of the cool targeting signifier (shows where you tapped), it’s another confirmation a user has tapped the target correctly, but to claim it’s “intuitive because it mimics the touching of water” does not map to an inherent understanding of what a button is.
The common understanding of a button is something that can be “pressed” it moves downward or changes visual state, like the buttons on remote, car dashboard, or a keyboard (yes they’re buttons too). On a screen a we conceptualize a button as a coloured rectangle with a state change on interaction. Using the analogy of “water” is a cool visual aesthetic, but nothing more… a button should show a visual state change, removing the “sticky hover effect” can be enough if the :active state is styled appropriately.
I’d also say the water concept is purely subjective and in no way a principle of familiarity or a sense of continuity.
While the ripple effect is kind of cool, using it to indicate hover state is minorly problematic because it runs afoul of accessibility guidelines that suggest that animations should be able to be disabled by the user (typically via motion preference settings). In addition it has a bad a11y “smell” because it depends on the user being able to perceive a short duration animation quickly, and as a general principle you’d want a persistent state to be represented in a persistent manner.
Since this is fundamentally a workaround for an undesirable browser quirk (that is, displaying hover styles when no hover has actually occurred), when focus or focus-visible styles would be more appropriate, it seems like using the suggestion at the end of this thread would be more appropriate: https://github.com/common-voice/common-voice/issues/424
Namely, using @media (hover:hover) {} around hover styles will prevent mobile Safari from doing this entirely. As long as you are applying appropriate focus or focus-visible states, this seems like the way to avoid this issue without resorting to questionable (if visually cool) workarounds.