We are working on an app that is meant to be on one side of the screen, it is a desktop app for video calls. Right now if you hover the app's window it steals the focus so the user can start typing to search contacts to call or directly use the buttons to do so.

I have read many articles and UX posts saying that you should avoid stealing the focus of an app. Others say there are some exceptions, for instance, alarms apps.

So, is ours a legitimate use case for stealing the focus?

  • Like you said... valid use cases for both. So make it easy on yourself and just have a configuration option to turn it on/off. Then everyone gets to have it the way they want it.
    – musefan
    Aug 10, 2020 at 14:15
  • It's on the side of the screen, can users choose which side it should dock on? Can they keep engaging with their previous task, or does your UI cover what they were doing and risk causing them to lose their train of thought?
    – Izquierdo
    Aug 10, 2020 at 15:27
  • Why would a simple click not be a more suitable trigger?
    – gidds
    Aug 10, 2020 at 23:04

1 Answer 1


Hovering should be a "safe" action

Hovering, or simply moving the mouse is normally a purely passive action, and doesn't typically get treated as decisively as other user input (except, perhaps, for detecting inactivity). Hovering is an exploratory action, and should be guarded as a safe way for the user to gain additional contextual information, and peruse their environment before taking actions.

You may think that changing focus is not really affecting much and is easily fixable, but it now means that the user's hover action is no longer "safe". Their typically harmless explorations now have consequences.

Hovering is not expected to affect the state of the system

Both on the web and in desktop applications, hover actions do not permanently change the state of the system. For example, a menu that expands on hover is expected to collapse when the mouse leaves. This norm reinforces the idea that a hover action is only a "shadow" that only temporarily modifies its surroundings.

Provide the feature only after explaining it, and allow the user to easily disable it

This feature will break the user's expectations for hover actions, so it should be an opt-in feature, or at least one that is explained at the start. I see the value in providing the feature so long as it fits the user's workflow, so empower them to utilize it if they wish.

As an additional note, your example of the alarm application breaking the users expectation by capturing focus is justified (in my opinion) because it's time-sensitive. Its core purpose is to capture the users attention at a certain time, so the intrusion is actually beneficial.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.