Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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?

share|improve this question
2  
Microsoft recommends scrolling whatever window you're hovering over. Possible good read. –  chris Jan 8 '13 at 13:05
    
@chris I suggest that you add that as an answer. I'm going to add the text of the Microsoft page to mine as its better than just a link - however if you add in an answer I'll happily refer to yours –  icc97 Jan 8 '13 at 13:32
2  
@icc97, It would be a bit redundant. It fits well in yours with the hypocrisy comment :) They do that with a lot of things, and while they can't really hope not to, it's kind of funny to see. –  chris Jan 8 '13 at 13:35
    
@chris Thanks :) –  icc97 Jan 8 '13 at 13:40
add comment

3 Answers 3

up vote 5 down vote accepted

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.
share|improve this answer
    
I think I agree with you, but is there any study to back this up? I'd rather not go with opinion. –  Iain Galloway Jan 8 '13 at 11:13
    
Whereabouts in the Windows 7 Explorer did you find an example of the control A scrolling? I tried but couldn't find any examples. –  icc97 Jan 8 '13 at 13:31
    
It would be good if Windows designer were to follow their own advice and to allow propagation of scroll events on the window under the mouse cursor, instead of just the one with focus –  pqnet Jan 13 at 22:06
add comment

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))

enter image description here

share|improve this answer
    
If I may play devil's advocate for a moment, I'd suggest that e.g. users expect a reaction from a textbox containing the caret regardless of whether the mouse is over it. –  Iain Galloway Jan 8 '13 at 11:17
1  
It goes further than that though. On OSX, the scroll action will scroll whatever element the cursor happens to be over (if indeed it has scrolling enabled) and in Windows, it scrolls only the active element when the cursor is over it. In my opinion OSX got it right here, scroll what the cursor is over. Scrolling is a mouse action and as such should be attached to the cursor position on screen. –  Kyle Sevenoaks Jan 8 '13 at 11:45
    
@lain Galloway thx for your comment! Well by observing people working on computers (e.g. my parents), even if the UI always hints which window is in focus (e.g. it is the only one that has alpha=1), they don't necessarily get it and they tend to not understand why they sometimes have to click to have a particular window in focus. I think that users are not expecting a reaction from a textbox containing the caret but rather that users are expecting every window they see to be directly in focus. –  leMoisela Jan 8 '13 at 11:47
add comment

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.

share|improve this answer
    
It's not consistent even within a platform, though. For example, Windows 7 Explorer does A but Office 2010 does B. Plenty of other examples as well. –  Iain Galloway Jan 7 '13 at 21:58
    
Could give a screenshot in the question of the example of Windows 7 explorer scrolling A? –  icc97 Jan 8 '13 at 9:22
    
Not sure I can screenshot a scroll interaction, but I'll see what I can do! –  Iain Galloway Jan 8 '13 at 15:49
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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