hey guys, Is there any equivalent of `BottomSheetScaffold` for wear? Can I safely import both: `an...

# compose-wear

[Radoslaw Juszczyk]

hey guys,

Is there any equivalent of BottomSheetScaffold for wear?

Can I safely import both: androidx.wear.compose:compose-material and androidx.compose.material:material to my project and use only BottomSheetScaffold from the non wear one??

[yschimke]

No equivelant. The Wear components have a very deliberate design, supporting the shape and size of devices.

[yschimke]

Technically yes you can. We advise strongly against it, and it may not be supported if you find wear specific issues. It brings in conflicting definitions or themes, colors, Text etc.

[Yingding Wang]

Does it make sense to use a BottomSheetScaffold, which is very similar to the WearableActionDrawerView on wear os2. The notification on wear os comes up from the bottom, this might cause a conflict on UI interaction. I thought I should put action buttons on the activity overlays and not on Scaffolds. I am just curious what is the use case for this in your wear app?

[Radoslaw Juszczyk]

in the collapsed state (right image) i want to consume clicks and maybe swipe gestures

[Radoslaw Juszczyk]

and I dont want the user to accidentally open up the 'more' menu while doing it

[Radoslaw Juszczyk]

i am considering also to use three dots icon and just open another screen , but i like the idea of pulling it to open

[John Nichol]

As Yuri said we deliberately don't have bottom sheet or draw as these go against our UX guidance which is to keep the UX pretty flat - so we would recommend just scrolling up to your settings rather than having them in draw.

[Kseniia Shumelchyk]

@Radoslaw Juszczyk WearableDrawerLayout or similar patterns is not something we expect apps built for Wear 3 to use, the new Wear Material Design guidance is in favor of flatter app structure and inline actions. So if you target growing majority of users (on Wear 3) you’ll need to embrace the new design guidelines. I want to share Todoist as an example how they got rid of drawers in the nav: https://9to5google.com/2022/05/12/todoist-wear-os-redesign/

[Kseniia Shumelchyk]

We have design guidance on developer.android.com. so few useful resources:
• Design principles for overlays (aka traditional apps): https://developer.android.com/training/wearables/design/overlays
• Figma material design kit to download: https://developer.android.com/training/wearables/design/download

[Radoslaw Juszczyk]

@John Nichol yeah I tried it with scrolling but it really didnt work. It is meant to be used while playing tennis, and I want to make it as easy as possible to update the score. When I had a scroll view there, the user would accidentally scroll it up, and then before updating the score they would need to scroll it back to the top or at least check if it is not scrolled (look longer at the screen).

I am still thinking about using a scroll view but somehow prevent it from consuming touch events if it is not scrolled and user touches top 80% of the screen.

[Radoslaw Juszczyk]

@Kseniia Shumelchykthank you for your answer, I have clarity now that I should avoid drawers/bottom sheets and strive towards making it a flat hierarchy

[Kseniia Shumelchyk]

@Radoslaw Juszczyk As an initial suggestion based on your last comments, have you thought about using view pager (https://developer.android.com/training/wearables/compose/pagination) to navigate between main page with score and actions to pause/end match? And using slider or stepper (https://developer.android.com/training/wearables/compose/sliders) to change the score (it will require few taps in total, but should be faster than scrolling)

[yschimke]

Looks awesome.

[yschimke]

My 2c, if you are doing a really custom UI like this, most of the guidance is out the window, and up to you to make something users can understand and operate.

[Radoslaw Juszczyk]

thanks, yeah thats true!

The top part has to be custom, I dont want accidental scroll + it has to be all clickable (adding points while playing)

Then for the rest I will try to stick with the guidelines. For the bottom part (it is going to be match stats, score counting settings and some other controls) - it totally makes sense.

(Hopefully the user will understand that they can pull it up from the bottom)