search

nhsuk / nhsapp-frontend

NHS App specific styles on top of nhsuk-frontend
https://design-system.nhsapp.service.nhs.uk/
MIT License
6 stars 0 forks source link

Bottom sheets (aka Bottom drawer) #31

Open davidhunter08 opened 1 year ago

davidhunter08 commented 1 year ago

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 commented 1 year ago

Team Rocket are exploring using bottom sheets for test results.

Screenshot 2023-11-17 at 11 26 43
davidhunter08 commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

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 commented 11 months ago

@davidhunter08 nice

davidhunter08 commented 9 months ago
MicrosoftTeams-image (1)

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

davidhunter08 commented 9 months ago
Screenshot 2024-02-20 at 13 54 46

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

michaelgallagher commented 9 months ago

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

davidhunter08 commented 9 months ago

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 commented 5 months ago

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

Image

zachrigby-nhs commented 3 months ago

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

Screenshot

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

zachrigby-nhs commented 3 months ago

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

Screenshot Screenshot

Question

michaelgallagher commented 3 months ago

@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 commented 3 months ago

@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 commented 3 months ago

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 commented 2 months ago

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?