Try: Remove (or make transparent) the scrim/backdrop from bottom sheets

[iamthomasbishop]

Bottom sheets have served us well, and as we have been working on the latest refinements I'd like to try something that we've talked about a few times going way back to the early days of the project -- either removing the scrim (the backdrop that sits between the bottom sheet surface and the contents of the canvas) or making it transparent.

Current

The inspiration for the original bottom sheet and its behavior/style was the Modal variation of the Bottom Sheet component in Material Design.

Inserter	Custom Color Picker	Cover Color Settings

Proposal

Mockups

Here are some quick rough mockups to visualize what no-scrim would look like:

Inserter	Color Picker

Details

Opacity

The issue with the scrim is that while it provides a subtle visual distinction between the sheet surface and the canvas, it obstructs the canvas just enough that it can make some tasks challenging -- such as color selection, where the color that selected appears artificially darker. I think regardless of which behavior (below) we decide on, this is one thing we will do for sure.

Scrolling

The biggest question that is open for discussion is whether or not we should allow the user to scroll the contents behind the sheet while it's open. For example:

• If we do allow the user to scroll the contents behind the sheet, the user will be able to navigate the canvas while the sheet is open
• If we don't allow the user to scroll the contents, the behavior would essentially remain as it is -- any tap outside of the sheet surface would dismiss the sheet

Dismissing the sheet

Depending on the scrolling behavior we decide on, we'll need to adjust the dismissal options:

• If we do allow scrolling, dismissing the sheet will require more precise/explicit action. We should probably add an explicit "close" button of sorts on sheets -- or perhaps it's okay if only swiping on the sheet dismisses a sheet
• If we don't allow scrolling, a tap anywhere outside of the sheet surface closes the sheet (a la Tooltip, Menu, etc. components) -- this is the current behavior albeit with a scrim

Preferred approach

My proposal would be to:

• As a start, try simply setting the scrim's opacity to 0. We can then test in various contexts to get a feel for how much tension the change results in
• If we find that users will expect to be able to scroll the contents behind the scrim, we can explore a scrollable solution -- whether that means any touch gesture dismisses the sheet or only a single-tap dismisses the sheet.

Note: removing the scrim will essentially mean it is no longer considered a "Modal Bottom Sheet" in the eyes of the Material Design guidelines. If we're using Material as a framing, it'd be more similar to a Standard or Expanding Bottom Sheet.

Feedback, suggestions?

I'm open to any feedback or suggestions. Let me know!

cc @hypest @pinarol @maxme @dratwas @lukewalczak @SylvesterWilmott

[hypest]

The biggest question that is open for discussion is whether or not we should allow the user to scroll the contents behind the sheet while it's open

Do we have some use cases in mind for when such content-scrolling-while-sheet-is-shown would be useful of required?

In case there is some cases, I guess I'd start to think of the sheet as an expanded toolbar, not an over-the-content UI per se. Perhaps such an interaction would actually make sense for when we do alter parameters of a block (say, the background color) similar to what we do for bold/italic/etc, where we expect immediate application of the change? Perhaps we've been there before in terms of discussing this but, maybe now that we consider removing the scrim one way or the other, maybe it's OK to consider the "expanded toolbar" idea?

[iamthomasbishop]

Do we have some use cases in mind for when such content-scrolling-while-sheet-is-shown would be useful of required?

Good question. I think there are probably more examples than I can think of off the top of my head, but I think we'll quickly understand how much friction exists if we start with a non-scrolling approach.

Currently, there are some situations where sheets obstructs the contents a bit more than we'd like. And we should probably consider (in the medium/long-term) implementing a "smarter" scroll-position mechanism, but I think allowing the user to manually adjust the scroll-position would feel pretty intuitive. Here are a couple of examples off the top of my head:

The biggest one that jumps out to me is the "add new block" indicator. Sometimes it becomes hidden when the inserter sheet is open, although that can be probably be mostly resolved by implementing a "smarter"scroll-position mechanism. I think we might eventually want to also allow users to drag that indicator to re-position the insertion point, but that's another story. 😄

Another example would be if you have a tall block (let's say ~1000px), especially one that has some children. Let's say I open its block settings sheet by tapping the cog icon (at the bottom of the block) and I adjust a setting that affects children, which are off-screen. If I want to bring those children into view, I currently have to take 2-3 actions -- I have to tap to dismiss, scroll the canvas, then re-open the settings sheet if I'd like to further customize settings. Whereas if we allow scrolling while the sheet is open, it would only require a single swipe. Those little interaction "savings" will add up if I'm customizing settings often.

I guess I'd start to think of the sheet as an expanded toolbar, not an over-the-content UI per se

I mean, sort of. Bottom sheets can vary in terms of complexity and behavior, but for block settings sheets specifically, there's definitely a discussion to be had about how/when changes are applied on-canvas. To date, we've tried to make most changes done on settings sheets immediate and dynamic -- e.g. the push for changes on Slider cells to show dynamically in real-time -- but there's probably room for alignment and behavioral consistency.