ui modal: overflow indicator

[cooper-joe]

The problem

An issue has come up a handful of times that a user doesn't realize there is more content inside a scrollable modal. This happens when the content overflows the boundary at a gap between items, so there isn't the cut-off item to give the "there's more below" hint. This is especially a problem on operating systems/browsers that encourage hiding of scrollbars.

An idea for a solution

I've been experimenting with the idea of adding an overflow indicator that is more prominent than a scrollbar (or, actually visible when scrollbars are default hidden). The indicator would be a fading-transparent overlay at the bottom of the visible area. Content near the bottom of the visible area would be slightly faded and give a clear indicator that there is more to be found beyond the visible area.

I've naively tested the idea using css mask-image, and I think it works visually:

However, this impementation has issues. The bottom of the scrollbar also gets overlaid by the fade. This would obscure interactive areas of the scrollbar. The content also requires a padding-bottom, which may look awkward on non-scrolling modals.

Questions

Before I think more about this and whether it would work UX-wise, I want to determine the technical feasibility of this idea, the questions are:

• could the faded-bottom-on-overflow idea be technically implemented in another way that avoids the problems noted above?
• are there other reasons, such as accessibility or technical challenges, why this is not a good idea?

Input and feedback appreciated, thanks.

---

For reference, the above was achieved with the following css changes to ModalContent.js:

div {
    flex-grow: 1;
    margin: ${spacers.dp24} 0;
    padding: 0 ${spacers.dp24};
    overflow-y: auto;
    -webkit-mask-image: linear-gradient(
        to bottom,
        white 80%,
        transparent 100%
    );
    mask-image: linear-gradient(
        to bottom,
        white 80%,
        transparent 100%
    );
}
div::after {
    content: '';
    display: block;
    padding: ${spacers.dp24};
}

[mediremi]

I think having a thin border above the action buttons might help as it is likely that some of the text will be partially obscured, encouraging the user to scroll down.

[KaiVandivier]

Or maybe extend the existing 'Box' to hint at extra content when it's scrollable

[cooper-joe]

@KaiVandivier, that's an intriguing idea! Do you think there's any way around the issue where the gradient-overlay obscures the bottom of the scrollbar area?

[KaiVandivier]

Not sure off the top of my head 🤔 but I'll experiment with it!

[KaiVandivier]

I haven't yet nailed down a way to get the fade to white to work perfectly, but I did want to report that one way people have solved this (using only CSS) is to use a radial shadow and some other neat tricks (article). Here's a tool to generate CSS to that effect: tool. It looks decent:

Code:

div {
    flex-grow: 1;
    margin: ${spacers.dp24} 0;
    padding: 0 ${spacers.dp24};
    overflow-y: auto;

    background: 
        linear-gradient(#ffffff 33%, rgba(255,255,255, 0)),
        linear-gradient(rgba(255,255,255, 0), #ffffff 66%) 0 100%,
        radial-gradient(farthest-side at 50% 0, rgba(17,17,17, 0.5), rgba(0,0,0,0)),
        radial-gradient(farthest-side at 50% 100%, rgba(17,17,17, 0.5), rgba(0,0,0,0)) 0 100%;
    background-color: #ffffff;
    background-repeat: no-repeat;
    background-attachment: local, local, scroll, scroll;
    background-size: 100% 24px, 100% 24px, 100% 8px, 100% 8px;
}

[mediremi]

That looks really good 👌 ✨

[HendrikThePendric]

This is mainly a MacOS and iOS issue right? Because they started hiding the scroll bar from Mountain Lion onwards? Could be that other OSs have implemented this behaviour as well by now, but as I recall, on other OSs you can see the scrollbar at all time and will know the modal is scrollable, so there is no problem to solve: the scrollbar is the "overflow indicator".

If I have understood the context correctly, we could also look into styling the scrollbar itself, so it shows also on MacOS and iOS. I've looked into it briefly but a little bit unsure whether this has sufficient browser support to pull it off.

Alternatively, the gradient solution @cooper-joe suggested could possibly also work. One precondition would be that the scrolling content has some whitespace below it and the gradient area does not have a greater height than that whitespace. If the gradient area has a greater height than that whitespace you'll see it even when the box is not scrollable, or when you scroll to the bottom.

The solution @mediremi suggested is always visible, very simple to implement, not at all error-prone and pretty clear to the user. I personally don't think that showing this border looks too bad either. There is one minor issue though: when the line-height and the wrapper height are such that the bottom-border of the scroll box falls between two lines of text, it will still not be immediately be visible to the user that there is more content below. I mention two lines of text above where this could happen, but I guess this would be even more likely if we're showing a scrollable form in a modal. Our form fields are separated by a fair amount of whitespace, so it's pretty likely the user will not see the form is scrollable.

[cooper-joe]

There is one minor issue though: when the line-height and the wrapper height are such that the bottom-border of the scroll box falls between two lines of text, it will still not be immediately be visible to the user that there is more content below.

Indeed, this is the issue that the gradient-overlay solution tries to work around. A single line border is a hint that the bottom area is fixed, but it doesn't help much in the situation you describe.

One precondition would be that the scrolling content has some whitespace below it and the gradient area does not have a greater height than that whitespace. If the gradient area has a greater height than that whitespace you'll see it even when the box is not scrollable, or when you scroll to the bottom.

Yes, this is solved in my example above by adding the padding-bottom to the container. However, the gradient area still overlays the scrollbar, potentially obscuring controls. I'm stumped as to whether there is a way to provide this gradient-overlay effect without this issue though.

This is mainly a MacOS and iOS issue right? Because they started hiding the scroll bar from Mountain Lion onwards? Could be that other OSs have implemented this behaviour as well by now...

Yes, at this time those are the main platforms where this happens. Other browsers or platforms may follow suit in the future, so having a solution in place for this would be useful.

but as I recall, on other OSs you can see the scrollbar at all time and will know the modal is scrollable, so there is no problem to solve: the scrollbar is the "overflow indicator".

The potential problem is that the presence of a scrollbar is not always a strong enough indicator of "overflow", especially if the content is cut off so cleanly as in your examples. I've seen this become a problem, even when scrollbars are visible.

[ghost]

I think we should consider this a user/OS preference. See this article: https://www.nytimes.com/2017/02/02/technology/personaltech/solving-the-case-of-the-disappearing-scroll-bars.html. Since a user can enable and disable it I don't think it's up to us to do anything about it. In my system settings I can just change my settings to this:

That shows the scrollbars all the time. If an OS makes deliberate changes to how scrollbars behave then I don't think we should do anything about that (even though I see the point).

[ghost]

(That's just with regards to the scrollbar part of this discussion btw.)

[ghost]

I think if you're showing that much content in a modal, that's maybe your core issue. We could just prioritize visibility of the content and not cut off content? That way:

1. A modal might take up more space than 100vh if it needs it
2. Content will never be hidden
3. Putting too much content in a modal will be disincentivized

I think I'd personal prefer that over a technical solution that attempts to solve what I perceive as a slight abuse of the component (putting too much content in it).

[KaiVandivier]

I think that's a pretty good idea, but I think this would take a technical solution in a different place because the current implementation of the Layer doesn't really enable scrolling if the content inside is >100vh 🤔 maybe that's easy to fix though

[ghost]

That's true. It's also my intention to sidestep the immediate technical solution a bit and take a look at the overarching assumptions.