Mouse wheel interaction with nested scrollbars

Question

Nested scrollbars (a scrollable area within another scrollable area) present some unfortunate difficulties, mainly when scrolling trough them with the mouse wheel.

Whether such scrollbars are a good idea at all, or should be avoided, has been discussed before:

• In-page scrollbars - Yes or no? Or maybe

• Are inner scrollbars a bad ux?

For this question, I would like to ask what can be done if one is stuck with such a constellation:

^{download bmml source – Wireframes created with Balsamiq Mockups}

Let's say that the above window layout is already mostly set in stone. The app has an outer area that is too tall for a single screen, and several tall inner areas. What can be done to make user interaction with a mouse scroll-wheel easier?

The default windows paradigm seems to be:

• scroll the area over which the mouse cursor currently resides
• unless it is not possible to scroll further in that direction, in that case scroll the next higher level.

Is this a reasonable default? In my experience this can lead to some jarring interactions when an user tries to scroll the large area, and during that process a smaller area is moved below the cursor, so the scroll target switches.

What can be done to improve the user experience here?

Answer 1

I've been in this situation many times. What I've always done is program the app to scroll the child-most element that the cursor is over and only that element:

To clarify, when I say only that element, I mean that if you're scrolling an element in one direction and you reach the end of that scrollbar, I program it such that it does not proceed by scrolling its parent element in that direction.

Some would argue that if it did proceed by scrolling its parent element in that direction that it would save you the hassle of moving the cursor in order to "escape" the child element. While this is true, it is precisely the situation I try to avoid, as it would also cause unwanted jittery up and down interaction between the various elements that would be scrolled.

So in summary, I program the app so that when you're scrolling an element in one direction and you reach the end of that scrollbar, nothing happens until you do 1 of 2 things: 1) you scroll in the other direction or 2) move your cursor to another element you wish to scroll.

Here's a visual representation:

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 2

A bad situation to be in, but it somtimes happens when maintaining old applications.

There are a few things you could do to make things a little less confusing:

• Scroll the main window scrollbar by default, and only scroll inner controls if the user explicitly clicks on them. This would also require some visual feedback on which control is currently selected, so it may not be an option for you.
• Keep the default behaviour, but introduce a gap between scrolling handover. By this I mean that the user has to turn their mouse wheel an extra little bit after the inner scroll bar comes to an end before the outter scroll bar starts moving. I think that the pause will be enough to let the user realise the inner scrolling has stopped, and give them a chance to stop turning the mouse wheel before the outer scroll action is activated.

Answer 3

Absolutely do not change the default behaviour in this regard. Why? Because this is one of those rare things where OS behaviour is too strictly and consistently defined to break it. As of yet I have not seen a single application breaking this behaviour (not counting crazy old half emulated applications which were never meant to be run on windows or are officially cross platform but realistically not) and you would need to have a extremely good reason to do so. The next question becomes: do you have extremely good reason to? Well, haven't heard it yet reading the other answers. True, especially when you leave little space between the sub areas and the side scroll bar it's far from nice to scroll down quickly, so it would be good to create some horizontal space if sensibly possible (easy on the web, hard in a desktop app), but that's hardly good enough a reason to break consistent standard behaviour. Franchesca's answer in that regard is quite sensible as it tries to expand on standard behaviour rather than changing it entirely, however I am not sure how practical the solutions are.

That is not to say that you are not correct in pointing out that there is a problem here. The real problem here however is not how to make the mouse wheel interact - that being the part that should be set in stone for the most part - , but why a bad UI is set in stone. User50881's suggestion to use tabs instead of aligning them below each other is for example valid and in most cases sounds excellent. Or depending on the content there are countless other interfaces that could be considered and might be better. Point is, if you get the time to code up custom scrolling behaviours (something that's far from easy), then I have trouble believing that the UI itself couldn't be changed with the right proposal.

Answer 4

Is this a reasonable default? Yes, if you want the small areas scrollable.

What can be done to improve the user experience here? Get rid of te nesting, use 3 tabs for example, content area 1, content area 2, rest of page. Or replace areas with buttons to open a popupwindow.

With more details what is inside the boxes people can give you better specialized tips.