Bottom Sheet

Done

A bottom sheet is used to overlay content on top of the user interface for the purpose of focusing the user’s attention on specific information or to accomplish a specific task. As a general rule, bottom sheets should provide contextually-relevant content to the parent view underneath. This component is designed only for the mobile experience. The wide-screen equivalent is the side sheet component. Anything that is considered “Mobile” will display a bottom sheet while “Tablet” and “Desktop” display the side sheet.

Bottom Sheet

Anatomy

The bottom sheet component is made up of a raised surface that contains content and affordances to close the bottom sheet. All other elements are optional. Bottom sheets come in two variants: full screen and partial. 

Full screen bottom sheet

Full screen bottom sheets are raised above the surface and completely cover the context underneath. 

  1. Surface
  2. Backstack - Small Medium Emphasis Quick Action Button (Guidance)
  3. Heading - Subtitle 2 
  4. Up to 2 Actions - Small Medium Emphasis Quick Action Button (Guidance)
  5. Divider (When Scrolled)
  6. Content (For reference)

Partial bottom sheet

Partial bottom sheets only come up as much as needed to display the content within the sheet (more on this in the behavior section).

  1. Raised surface
  2. Content heading (optional) (See content headings)
  3. Scrim (optional)
  4. Close affordance
  5. Header container (if needed)
  6. Content (just for reference)

Footer

Bottom sheets can contain optional footers to provide space for calls to action where the CTA can remain sticky and not scroll with the content.

  1. Footer container
  2. Content scrolled below footer (just for reference)
  3. Divider (when scrolled)
  4. Content within the footer (just for reference)

Heading alignment & truncation

Headings for full height bottom sheets should be center aligned and fixed in the center of the screen.. Content headings for partial bottom sheets can either be left-aligned or centered, depending on what makes the most sense for the solution. Note: Heading text should truncate when space is not available, and should never wrap to two lines.

  1. Full screen bottom sheet (centered heading only)
  2. Scrolled full screen bottom sheet (centered heading only)
  3. Partial bottom sheet (left-aligned heading)
  4. Scrolled partial bottom sheet (centered heading)

Specs

‍
Color

Element Property Value
Raised surface Background color ∆surfacePlatformRaisedBackgroundColor
Heading Type color ∆colorPlatformGray900
Close affordance (partial variant) Handlebar color ∆colorPlatformGray200
Raised surface Shadow color ∆surfacePlatformRaisedShadowColor
Quick action button (Full screen variant) Container color ∆colorBrandedGuidance50
Quick action button (Full screen variant) Icon color ∆colorBrandedGuidanceAccessible

Elevation

Elevation will only be on the surface of the partial bottom sheet. When scrolling, it will take on the divider.

Element Property Value
Raised surface Shadow Y-offset ∆surfacePlatformRaisedShadowY
Raised surface Shadow opacity ∆surfacePlatformRaisedShadowOpacity
Raised surface Shadow blur ∆surfacePlatformRaisedShadowBlurResting
Raised surface Shadow spread ∆surfacePlatformRaisedShadowSpread

Spacing

Bottom sheets have padding of ∆spacingPlatformBase (24px). All other content spacing is defined at the atom or component level. On partial bottom sheets, the handlebar should be placed 8px below the top edge of the surface.

Full screen (default)

Full screen (scrolled)

Partial (default)

Partial (scrolled)

Footer


States

Header

Content, at its default state does not impact the header divider or treatment until scrolled. Once scrolled, the header then takes on the divider with the content scrolling underneath while the header remains fixed at the top of the screen.

  1. Full screen — default
  2. Full screen — scrolled
  3. Partial — default
  4. Partial — scrolled

Footer

Content, at its default state may or may not impact the footer divider. If there’s enough room for the content to appear within the bottom sheet without scrolling, the footer does not take on a divider; however, if there’s too much content to display, then the content can overflow off the screen. In this case, the footer in the default state would take on the divider.

  1. Footer — content in a default state (dotted line represents unscrolled content)
  2. Footer — content scrolled (notice dotted line representing scrolled content underneath the footer and beyond the visible bounds of the device), or content that is not visible due to limited screen size.

Buttons

Call to action buttons can be either inline with the content on the page or they can be inside of a footer. Sticky footers with buttons are great for when you need the user to still see the button when doing something within the page but if the user is filling out a form, then use an  inline button with the content. 

  1. Inline button
  2. Sticky footer button

Theming

Color

Element Property Value
Close affordance (full screen variant) Quick action button background ∆colorBrandedGuidance50
Close affordance (full screen variant) Quick action button icon ∆colorBrandedGuidanceAccessible

Shape

Element Property Value Note
Container Large ∆shapeBranded Partial bottom sheet only; full-screen bottom sheets have no visible corners, and should ignore the theme entirely
Quick action button Small ∆shapeBranded Full-screen bottom sheet only

Type

Element Property Value
High emphasis section heading (small heading from the type scale) Font family ∆typeBrandedFontFamily
High emphasis section heading (small heading from the type scale) Font weight ∆typeBrandedFontWeight
High emphasis section heading (small heading from the type scale) Line height ∆typeBrandedLineHeight
High emphasis section heading (small heading from the type scale) Character spacing ∆typeBrandedCharacterSpacing

‍

Placement

Bottom sheets should always be anchored to the bottom of the screen, and can be placed into one of two states: contextual or persistent.

Contextual placement

Bottom sheets are contextual by nature, and should only appear when the user needs some contextual UI, and be dismissed fully when no longer needed.

‍

Persistent placement

Sometimes the content in a bottom sheet will be continually referenced throughout a user’s journey, and should be persistently pinned at the bottom of the screen until a flow is completed or the user navigates away from the context.

‍

Usage do’s

Bottom sheets are useful for a wide variety of use-cases and can contain one or more atoms on their surface, and can appear as a result of user interaction or by system request. Some examples of bottom sheet usage: 

  • Providing quick access to contextual features.
  • Surfacing contextual interaction options.
  • Surfacing interstitial content with medium emphasis

Usage don'ts

Avoid using a bottom sheet when:

  • The content makes more sense existing within the parent context
  • The interaction is initiated by a card component (in which case the card should grow to fill the view instead of triggering a bottom sheet)
  • There is no contextually useful information or possibilities for interaction on the bottom sheet

Native versus responsive web

Use bottom sheets on viewports smaller than 560px. On 561px and over, the physicality of gestures is lost, and interaction is typically performed with a mouse. Because of this, bottom sheets should be replaced with Side Sheets or otherwise persistent content.

Anything that is considered “Mobile” will display a bottom sheet while “Tablet” and “Desktop” display the side sheet.



Behavior

Bottom sheets have a minimal number of interaction patterns, all of which support their contextual and interstitial nature. These interaction patterns are: entry, swipe to fill/shrink, and dismiss/resolve.

Entry

Bottom sheets enter from the bottom of the screen in 300ms using the Deceleration curve. If there is a scrim it should fade in over this time.

Swipe to fill view or shrink

Generally speaking, partial bottom sheets should come up just enough to display the content within; however there may be some instances where you want the bottom sheet to come up halfway — requiring the user to scroll to reveal more content. Partial bottom sheets may be swiped up to fill the view if there’s more content available to show; otherwise swiping up will not change the height of the bottom sheet. This interaction can be reversed by swiping down. This animation should be timed by — and track with — the user’s finger. Appropriate affordances fade in and out over 100ms halfway through the transition. If any snapping is required it should occur over 150ms using the Standard ease.

Dismiss or Resolve

Bottom screens are dismissed and resolved using the same animation, exiting the screen over 250ms using the Acceleration curve. If there is a scrim it should fade out over this time.

Header and footer behavior

When headers or footers are used, they should always remain within view and receive a divider only when content scrolls underneath.

Interaction Steps Duration Easing Notes Haptics
Header/Footer receiving elevation as content scrolls 1. Surface becomes visible ∆motionTimeFast ∆motionTimingFunctionStandard The header/footer surface becomes visible with an elevated surface treatment prior to content scrolling underneath. None
1.5 Header title becomes visible ∆motionTimeFast ∆motionTimingFunctionStandard The header title becomes visible at the same time as the header surface. None
1.5 Footer title becomes visible ∆motionTimeFast ∆motionTimingFunctionStandard The footer content becomes visible at the same time as the footer surface. None


Developer Docs

Vue Developer Docs

Component documentation coming soon!

Introduction
Anatomy
Specs
States
Theming
Placement
Behavior
Dev Docs
Dev Docs