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.

As far as I can tell, the behaviour you describe is what Stack Exchange sites use, and I find it very intuitive; take this answer, which contains a code element, as an example.
– jubobsJun 25 '14 at 0:21

4 Answers
4

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.

What happens though if you start scrolling with the cursor at the top in the white area, then through scrolling the blue area moves upwards underneath the cursor? Do you switch the scroll focus? If not, how do you differentiate between a continuous long scroll action by the user (so you have to keep scrolling the same thing), or two consecutive scroll actions (so you would have to switch, since the first action started in the white and the second in the blue)
– HugoRuneJun 24 '14 at 18:43

2

If you are scrolling the main window and your cursor happens over the blue area, the blue area scrolls. You'd have to move your cursor back to the white area to scroll the main window. This is what eliminates the jittery scrolling. It specifically only scrolls the child-most element for that reason. You can give your users a tip for main window scrolling by telling them they can hover over the scrollbar area when scrolling the main window. That way you know you'll never happen into any scrollable child elements.
– Code MaverickJun 24 '14 at 18:48

Your answer says nothing about what happens when you reach the end(s) of a scrollbar on a child element.
– jubobsJun 25 '14 at 0:04

1

@Jubobs - Actually, it does. It says that it scrolls only that element. So naturally, when you reach the end, nothing happens if you keep scrolling down. This is what prevents the jittery effects the OP was referring to.
– Code MaverickJun 25 '14 at 0:08

@CodeMaverick Ok, I see. You might want to add that clarification in your answer, though. In such cases, my personal preference would be to use what Stack Exchange sites use: if you're scrolling some element in one direction and you reach the end of that scrollbar, then proceed by scrolling the parent in that direction. That would save you the hassle of moving the cursor in order to "escape" the child element.
– jubobsJun 25 '14 at 0:12

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.

If it's possible to change the default behavior maybe it's also possible to change inner scrollable areas too? For example, replace inner scrollable panels with expandable panels which has a "show more" link and expands fully on click. Just a suggestion.
– alexeypegovJun 24 '14 at 18:35

1

I like the pause. And I like point #1. I'll just add that you'll want to watch for the instances where the sub-scrollers are too full of clickable stuff. If I click into a sub-scroller to draw focus, I'll want plenty of empty space to click in so I don't inadvertently click something in there that links me away.
– Ken MohnkernJun 25 '14 at 13:26

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.