Research on scrolling within modal (web)? pros/cons?

Question

From a web UI perspective, is there any research or defined best practices in regards to scrolling within a modal window? Please provide specific links, studies, etc.

I am of the school that a modal should always be constrained (within) the user's viewport and if the content is longer, then the content should scroll within the modal.

However, a colleague leans more towards never scrolling within a modal - that the modal can extend (height) beyond the viewport and the user utilizes the browser scroll for accessing the contents of the modal below the fold.

Here's a wireframe comparison for illustration (in a mobile/handset web context):

I should preface my question with that I think modal's should only be used as intended, for small pieces of information or interaction, however we have instances where this is not adhered to.

Edit:

possible approach. Distinctly maintains only one scroll bar and may address pros and cons of each approach: https://trello.com/card/complete-trello-api-v1/4d5ea62fd76aa1136000000c/1397

Answer 1

I agree with your colleague, mostly for reasons that are outside your control. I'm also particularly against the solution Trello uses in its mobile app, so it's interesting you bring that up.

My reasoning is as follows:

1. If you use the browser's own scrollbar for all cases, the item with focus is not nearly as important when the user scrolls down. In most (all?) browsers, opening a modal with a scrollbar on a page with no scrollbar and pressing the down arrow or page down functions does not scroll the content in the modal unless the user clicks inside (or tabs to) the modal itself before trying to scroll. That's especially annoying when the modal occupies a large percentage of the window (so there's a reasonable expectation on the part of the user that pressing page down will page down the content in the modal).

2. It avoids the issue of double-scrolling. As mentioned by other comments and answers here, the expected behaviour of scrolling a content pane on a page that itself can scroll is somewhat undefined. This was a notable problem with Windows 8 (until Windows 8.1) in that scrolling the mouse scrollwheel in a Metro app would natively scroll the entire app display horizontally, until the mouse cursor happened to enter the zone of one of the vertically-scrollable subpanes of the app (when the behaviour immediately changed to scrolling the subpane vertically). That meant the user couldn't reverse the action they performed to get themselves into that situation to get back out of it. It's also a problem when the user actively scrolls the subpane all the way to the end and then continues scrolling (e.g. on a device with inertial scrolling); should the page immediately begin scrolling once the subpane is scrolled to the end? If so, that removes the usual "snapback" effect in the subpane.

3. On mobile, I'm in the habit of scrolling using the very, very edge of the touchscreen only. Since my finger is running up and down a relatively hard edge (the edge of the device), it's much easier to restrict the scrolling to the vertical axis without accidentally scrolling horizontally (which can be a pain, especially when I've double-tapped to zoom into a column of text on the page, where scrolling horizontally would pull the column away from the centre). If you introduce an arbitrary gap between the side of the touch panel and the scrollable section (as Trello does), my expectation of being able to scroll along the edge of the window is broken, and I need to move my finger to a relatively unusual place to scroll the pane. In general, you've made the hit target much, much smaller for me (even though the edge of the screen on a mobile device is a relatively small physical target, it's exceptionally easy to target with an actual finger because I can use my muscle memory alone—I don't need to process where the scroll pane actually is).

Aside from all that, I'm averse to the idea of opening up modal interfaces in a little frame, especially on small-screen mobile devices (i.e. phones). The screen space is already limited, and there's already a clear expectation of each successive detail view taking over the whole screen. When you open a detail view in a tiny little popover display, you're effectively moving the "Back" button away from where it's expected (at least on iOS), and introducing a useless frame of chrome around the content.

Answer 2

While I agree that a modal should usually be very focussed and have only a small amount of content, this doesn't always work. There are many situation where it makes a lot of sense to have a large modal window with a bunch of interactions. Your example is one, you have the photo popup in Facebook that also shows a conversation. I've utilized this pattern in a number of designs and tends to work just fine. So, although modals are not perfect the other options like a non-modal overlay or navigating to a new screen are not always available or better.

Having said that DA01 already pointed out that you should strive to always have only one scrollbar.

A scrollbar does two things: it indicates there is content off-screen, and it's the control to pull that content into view. As such, I believe the scrollbar should have a clear connection to that content, also visually. The Trello example is weird in that the scrollbar seems like it should scroll the entire window because it is all the way on the right, but it only scrolls the popup.

I don't have research specifically for this situation, but it's one of the basic rules in interface design that the control that affects a thing should be close and clearly related to that thing. There are many more examples of modals with the scrollbar in or near the modal, than ones with the scrollbar at the edge of the viewport: Facebook photo popup, Safari reader mode, OSX mail app compose modal, Gmail compose overlay, et.c

Answer 3

Modal view should always contain a brief information, having a scrollview is discouraged. Mainly because of the reason that Modals are mostly annoying and people would want to get rid of them as quickly as possible, that is why modals have very pronounced Cancel button. Apple's HIG (Human interface guidelines) Modal section also discusses this .

Avoid creating an alert message that is too long. If possible, keep the message short enough to display on one or two lines. If the message is too long it will scroll, which is not a good user experience. -From Apple Human Interface guidelines

Answer 4

I think that the only scroll bar inside a modal should be in a portion of that modal, like facebook conversations in photos theatre as Koen said. If you are considering use a "global" scroll in your modal, maybe you must think in create a new screen for that content.