Mouse scroll wheel should target focus or hover?

Question

I've noticed an inconsistency with controls responding to scroll input. Different OSs (and even different programs within the same OS) behave differently.

Here's the scenario:-

Imagine you have two controls A and B. Both are scrollable. A has focus for keyboard input. The mouse pointer is hovering over B.

I scroll using the scroll wheel.

Which panel should accept the scroll wheel input and why?

Does it depend on what kind of controls A and B are? If so, in what circumstances?

If panel B should scroll, should it also gain focus?

Answer 1

Control A should never scroll. Either Control B or nothing.

1. The scroll should be on the Control B (that the mouse is hovering over), unless Control B is in an inactive Window.
2. If Control B is in a Window that is inactive (but Control A is active by the fact it has focus) then scrolling over Control B should do nothing.
3. If the Control B Window is changed to being active by the mouse hovering (as is often with Linux) then Control B would scroll.

As from chris' comment here's the Windows guidelines, it may well be that they occasionally break their own guidelines though:

• Make the mouse wheel affect the control, pane, or window that the pointer is currently over. Doing so avoids unintended results.
• Make the mouse wheel take effect without clicking or having input focus. Hovering is sufficient.
• Make the mouse wheel affect the object with the most specific scope. For example, if the pointer is over a scrollable list box control in a scrollable pane within a scrollable window, the mouse wheel affects the list box control.
• Don't change the input focus when using the mouse wheel.

• Give the mouse wheel the following effects:

  • For scrollable windows, panes, and controls:
    • Rotating the mouse wheel scrolls the object vertically, where rotating up scrolls up. For the wheel to have natural mapping, rotating the mouse wheel should never scroll horizontally because doing so is disorienting and unexpected.
    • If the Ctrl key is pressed, rotating the mouse wheel zooms the object, where rotating up zooms in and rotating down zooms out.
    • Tilting the mouse wheel scrolls the object horizontally.
  • For zoomable windows and panes (without scrollbars):
    • Rotating the mouse wheel zooms the object, where rotating up zooms in and rotating down zooms out.
    • Tilting the mouse wheel has no effect.
  • For tabs:
    • Rotating the mouse wheel can change the current tab, regardless of the orientation of the tabs.
    • Tilting the mouse wheel has no effect.
  • If the Shift and Alt keys are depressed, the mouse wheel has no effect.

• Use the Windows system settings for the vertical scroll size (for rotating) and horizontal scroll size (for tilting). These settings are configurable through the Mouse control panel item.

• Make rotating the mouse wheel more rapidly result in scrolling more rapidly. Doing so allows users to scroll large documents more efficiently.
• For scrollable windows, consider having clicking the mouse wheel button put the window in "reader mode." Reader mode plants a special scroll origin icon and scrolls the window in a direction and speed relative to the scroll origin.

Answer 2

IMO, Window B should always scroll (but not get the focus if not already in focus) and Window A never.

The two main reasons are:

• Many users do not have the complete understanding of what an active window means.
• Users expect a reaction from the window behind the cursor.

And this is getting more and more true with the significant use of smartphone/tablet operating systems in which the concept of plural windows disappears completely.

By the way, it is the case on OSX since Snow Leopard. (maybe even before)

Here is an example of what I do a lot on my computer:

• I work on (1)
• I have my cursor on (2) and whenever I need an info in that page, I don't have to change the focus, just scroll and continue to type (typing will happen in (1) whereas scrolling will happen in (2))

Answer 3

You should do whatever is standard on the platform you are supporting. This standard will either be described in a UX guideline or will be a natural consequence of handling scrolling via official SDKs and controls.

Failure to precisely match the platform has several downsides:
1. It is inconsistent and therefore confusing to users.
2. Depending on your choice, you may end up producing scenarios where the scroll wheel causes two or more views to scroll simultaneously.
3. Users who override the default platform behavior will fail to override your application's behavior.

Even for a cross-platform application, I recommend using platform-specific behavior on all platforms, rather than being consistent across all versions of your application.