Bottom sheets (aka Bottom drawer)

[davidhunter08]

What

A bottom sheet is a user-interface pattern used commonly in mobile apps for providing contextual details or controls in the lower area of the screen.

Other information

Bottom Sheets: Definition and UX Guidelines (Nielsen Norman Group)
Material design system - Sheets: bottom component
Sheets | Apple Developer Documentation
How to Create Awesome Bottom Sheets | by Thomas Cree

[davidhunter08]

Team Rocket are exploring using bottom sheets for test results.

[davidhunter08]

Bottom sheets are a mobile-app UI pattern intended to present temporary contextual information while maintaining access to the main content. When used for a few options or some additional information, a bottom sheet can enable quick access to controls; however, they should not be used on top of other bottom sheets or for displaying lengthy content.

[michaelgallagher]

Bottom sheets are a mobile-app UI pattern intended to present temporary contextual information while maintaining access to the main content. When used for a few options or some additional information, a bottom sheet can enable quick access to controls; however, they should not be used on top of other bottom sheets or for displaying lengthy content.

@davidhunter08 fwiw apple's own apps break that last rule all the time

[michaelgallagher]

the team rocket example above is one where i wonder if and how we might implement it as a native sheet. it would be nice to understand how much freedom + control we have to design those (e.g. can you use Frutiger in a sheet? can we use our own entire FE library? etc)

[davidhunter08]

Thanks @michaelgallagher I'm meeting with team omelette tomorrow to hopefully discuss exactly that!

I've been playing about with a bottom sheet in HTML

[michaelgallagher]

@davidhunter08 nice

[davidhunter08]

Team Mavericks are looking to use native bottom sheets for users to 'Give feedback'.

[davidhunter08]

Team Valiant are looking to use native bottom sheets for users to 'Filter results'.

[michaelgallagher]

q: is this the native component version? if so, should we be using the stock component header?

[davidhunter08]

q: is this the native component version? if so, should we be using the stock component header?

Hey Mike, there are still lots of questions around this component. I think some design / dev collaboration in native code to explore the possible is needed. We spoke to Team Omelette (Beyond the Shell 🐣) in December in regards to prototyping / testing native components but the team were not at that stage yet.

We met with Team Mavericks yesterday, a decision was made to build the web version of the 'Give feedback' across all platforms (which simply goes to a new page when selecting the 'Give feedback' link and doesn't use a bottom sheet / overlay) until we understand more about implementing a native bottom sheet.

[Tosin-Balogun]

Bottom sheets used by secondary care team

The secondary care team currently have the 'filter' and 'sort by' function of their hospital document and questionnaires user flow

[zachrigby-nhs]

Something we are looking at in N&M is utilising the bottom sheet to allow users to remove/restore messages from the App. We have tested this patten in both moderated and unmoderated testing sessions and the pass rate is very high. We'd be looking to use the bottom sheet component once it has been built, and if its possible, to act as dialogue and confirmation interactions for removing/restoring messages

A few questions/queries that were raised in a recent playback of this journey in the IxD huddle:

• "In its current form, it can only render static content but for it to be used as a template, they need to figure out how that would work"
• Can we route to other pages from a native bottom sheet component? e.g. Navigating the user back to their message inbox once they have deleted a message

[zachrigby-nhs]

Team Native are shortly going to be developing the Native Bottom Sheet component and spoke to me recently on the 'dismiss' interaction comparisons between the iOS and Android versions of the component, so I produced this documentation for them which I think is correct, but have a question about the iOS version (see below the screenshots)

The main difference from an interaction perspective is that the Android bottom sheet does not have a 'Close' button, whereas the iOS version has a 'Close' text button. On both, the user can click outside the bottom sheet (fun fact Material refer to this as the Scrim), drag down on the handle, or click 'Apply' to dismiss the bottom sheet.

There is also an interesting interaction on the Material bottom sheet where users can dismiss it by swiping left or right from the edge of the screen, referred to as Predictive Back

Question

• Does anyone know if I've correctly understood the iOS full detent modal in that the visual appearance of this is a 'modal stack' (where you can see the content behind has sunk backwards slightly)? Looking at some of the examples in this thread, the modal stack hasn't been applied so I'm not 100% sure I've got this right.

[michaelgallagher]

@zachrigby-nhs i'm pretty sure you're correct about the full screen sheet on iOS pushing the "root sheet" back in the view.

some questions:

1. how does dismissing the sheet via the drag handle interact with running the filter? e.g. if a user has changed the selection, and then they drag down to dismiss the sheet, what happens? does it run the new selection, or cancel the changes?
2. have we considered disabling the drag bar? this might help people accidentally dismissing the control, and it would preempt the previous question. not sure what that means for android, where there is no close button.
3. how many options could be in the list? is the upper limit infinite, given that it includes senders?
4. should the iOS close button be on the left side of the header? so far as i can tell, this is standard; it also matches the pattern of "the control to get out of here is in the top left, e.g. the back button". that said, perhaps it is odd with the sheet header being right under it?
5. have we considered placing the sheet title ("filter") and the close button on the same row?
6. does the content area of the sheet scroll if the list is tallerer than the view? is that why the divider separating the buttons from the rest of the card goes full width while the divider under the title doesn't?

[zachrigby-nhs]

@michaelgallagher some thoughts to your questions

1. Fairly certain the only way to run the filter selection would be to click the apply button. Dragging the sheet down would before applying the selected filters would cancel their selection, and they would just be shown whatever they were looking at before. I'm assuming that if they did this after previously applying a set of filters, then dragging the sheet down when editing those selected features would result in them seeing their originally filtered list of messages
2. Reading up on the documentation it actually seems like the drag bar is an affordance for resizeable bottom sheets, so we might be able to do away with it at least in the iOS version. Slightly concerned that the Android version doesn't have any sort of close button, but maybe Android users are so familiar with this that we can lean into it?
3. Technically, yes?
4. I put the close button top right as most of the apple documentation has an 'X' button top right, so I did a straight swap
5. We could use the 'stock' title for iOS bottom sheet which is centre aligned at the top, which would put it in line with the close button, but the Android version is just one big container it seems. At the moment the configuration is so that the content area of both bottom sheets is the same, but I'm open to changes for sure. I've also just noticed the title is labelled 'Filter by' which feels odd. I would have thought 'Filter' or 'Filters' would suffice but I will check with content design
6. Yeah the content area scrolls, but the buttons are sticky at the bottom

[zachrigby-nhs]

Another question on this that just came up in a call with some of the Native developers is what type of error message/component/pattern do we show if the filter wasn't able to open for whatever reason.

Their suggestion was to use a native error pattern, since the error is to do with a native component (the bottom sheet). For example, showing an error message in a dissmissable snackbar component on Android. For example 'Cannot show filters'

Thoughts?

[Tosin-Balogun]

Another question on this that just came up in a call with some of the Native developers is what type of error message/component/pattern do we show if the filter wasn't able to open for whatever reason.

Their suggestion was to use a native error pattern, since the error is to do with a native component (the bottom sheet). For example, showing an error message in a dissmissable snackbar component on Android. For example 'Cannot show filters'

Thoughts?

@zachrigby-nhs – I think the suggestion of using a native error pattern does make sense.
It is essentially us trying to stick to platform conventions as much as we can. I suppose if we could style it, then it would be good to use our NHS brand language for errors there too (if possible).

Do you know what the equivalent of a snack bar for iOS would be?

Would that be an alert modal or something similar to a floating component with a dismiss?