Hello. Can we not hardcode `BottomSheetMaxWidth = ...

# compose

[why]

Hello. Can we not hardcode BottomSheetMaxWidth = 640.dp in future releases of material3 BottomSheetScaffold and just pass it as a default value/preference?

[Ian Lake]

That's a set value in the Material3 specs, not something that allows customization: https://m3.material.io/components/bottom-sheets/specs

[why]

I already read the docs. So are you suggesting me to reimplement the whole thing if I want the bottom sheet to be full width?

[Ian Lake]

The Material Components are only going to follow the Material Specs, so if you don't want the Material Spec, you would need to not use the Material Components, that is correct

[why]

I thought Compose was about building our own components on top of existing ones (at least some basic ones) to get the desired results (like basic buttons, input texts etc).

[Ian Lake]

Bottom sheet is indeed built on AnchoredDraggable, the lower level API you can build your own components on top of

[why]

Ok I'll look into it thanks!, It's all internal stuff...

[Stylianos Gakis]

Yes, copy the internal stuff into your project if you need to deviate from the material design specs.

[why]

Now that's very composable! @Stylianos Gakis

[Stylianos Gakis]

Yes, the foundation package is the one which gives you the core components to build whatever you want in.
The material package is not meant to be that. It's an opinionated implementation of those core components using a very specific design system called material design.

[Ian Lake]

anchoredDraggable is all public Compose Foundation APIs: https://developer.android.com/reference/kotlin/androidx/compose/foundation/gestures/package-summary#(androidx.compose.ui.M[…]tableInteractionSource)

[Tapan Desai]

@Ian Lake I agree that it’s the material design guideline but it would be nice to have an option to override maxWidth for some specific usecases.

That way, developers wouldn’t have to unnecessarily spend time on rewriting a component or re-inventing the wheel.

We came across this scenario, when we wanted to show our payment screen in a bottom sheet layout on tablet. Attaching screenshot for reference.

In the end, we had to make a custom component which took a day or so. The time we could have spent on the payment screen itself, if we just had a way to override the maxWidth

I am sure, there are many others who would benefit from having an option to override this.

Please consider this for a future release.

[Ian Lake]

I think that is exactly the kind of UI Material doesn't want you to write for large screens. Glad you got it working 👍

[Tapan Desai]

I think that is exactly the kind of UI Material doesn’t want you to write for large screens.

I am not sure I understand. Can you please elaborate here? Also, we make what we get from UX Designers. And they want very specific things

[Stylianos Gakis]

What we get from UX Designers. And they want very specific things

Yes, and if those things aren't the very exact things that the material design specs mention, then it makes total sense that you need a custom component.

[Tapan Desai]

Wouldn’t it be convenient to have an option to override the default maxWidth? Instead of making an entire component just so that you can change the width. We are not the first one to have needed this and I am sure we won’t be the last.

On a side note, if you will refer to Shopify POS app on a tab, you will see that they use bottom sheet extensively and it is taking the maximum width available.

So in short, the default behaviour (maxWidth in this context) of the bottomsheet will follow material guidelines and if needed, developer can override it for some specific usecases. After all it has a Modifier property

[Ian Lake]

Let's go back 2 years, back when there wasn't any max width at all. All of a sudden, the guidelines set a max width and that max width was encoded in every Material component. Why did this happen?

Was it quantitative results from A/B tests from the Google Play Store across different max widths (noting the sheer volume of bottom sheets shown for every in app purchase for every app across all of Google Play)?

Maybe it was qualitative results from UX studies done by the System UI team as they prepared for the Pixel Tablet and Pixel Fold and were concerned with how important surfaces like the share sheet appear on larger devices?

Or perhaps it was a holistic look at the design space for larger screen devices in their entirety in cooperation with apps like Google Maps (which you'll note doesn't use the same bottom sheets it does on phones on larger devices) that brought about whole new components like side sheets, the recommendation for the largest window sizes: https://m3.material.io/components/bottom-sheets/guidelines#8be001d3-cfe2-47bd-ac2c-62d1c5c814ff

No, it has to just be an arbitrary maximum that designers shouldn't take into consideration at all when designing for Android

[Ian Lake]

If you want to write something that specifically doesn't follow the design guidelines, you absolutely can. But if there's a maximum width without an override, that is there for a reason and I'd think that the best working environment would mean that this kind of disconnect which is causing you to do more work would start a conversation with your design team to understand if the deviation was intentional, why the deviation exists, and maybe whether you should be doing your own A/B test or UX research with your users to validate that the change is actually a net positive in your specific case

[Tapan Desai]

Thanks for the detailed explanation @Ian Lake.

I will definitely discuss this with our UX team.

By the way, we did consider the side sheet but it was ruled out for 2 reasons.

First, it was not available for Compose at that particular point of time (it is still showing as Planned on material.io)

The other reason is, the UX team said that we have an entire payment (checkout) journey, which means multiple screens. So side sheet was not suitable for that

If I may ask, is it possible for you to share a possible timeframe for SideSheet to be available in Compose. Even if it’s in alpha release?

[Ian Lake]

It looks like this might be the closest feature request that exists for side sheets: https://issuetracker.google.com/issues/185097403

[Tapan Desai]

Thank you for your time @Ian Lake. Won’t drag this discussion any further.

I just want to point out some error in the documentation that made us think that we can use full width bottom sheet when needed.

https://m3.material.io/components/bottom-sheets/guidelines#6b04cb93-0448-48ed-91a7-8de6896f8b9e

[Fabio Grumiro]

Hello just noticed that it is now possible to override the maximum width:
https://android-review.googlesource.com/c/platform/frameworks/support/+/2752210/7/compose/ma[…]ndroidx/compose/material3/ModalBottomSheet.android.kt

[why]

Ah, finally. Thanks for letting us know @Fabio Grumiro. You have no idea how much TROUBLE this one param saved me. After all, Software has "*Soft*" in it for a reason. Programmers tend to forget that. Thanks to the Material team and the participants for acknowledging this issue. [SOLVED] in material3 1.2.0-alpha09.

[Atul Gupta]

Now we have to start this entire discussion for StandardBottomSheet 😔