UX review of Tearsheet and Create tearsheet

[oliviaflory]

• Get an understanding of the UX of Tearsheet and Create flow (tearsheet)
  • ie what makes Create version unique
  • Why do teams gravitate to Create version instead of the base component

To do:

• [ ] Audit the two component variants
• [ ] Form an opinion
• [ ] Playback to Product team

[RichKummer]

Notes

• Github issue #6164: Focus issue where tearsheet focus leaves during a Continue flow betweeen tearsheets.

[RichKummer]

Kenny chat 10/15/24

1. Kenny's opinion is that tearsheet should go into the Core library as variant of modal, rather than its own separate component. If you take out all the Product-specific pieces of Tearsheet, it's essentially a type of modal, with some style changes such as being pinned to the bottom and transitioning up from the bottom of the screen.

   • We could add a transition variation to the existing modal for the animation.
   • Tearsheet would be a variant that acts as a container. Consider everything below the header as an open space to populate content (including the grid influencer). Product would then fill the canvas with the functionality needed.
     • Modal has its own header, similar to what Tearsheet has.
     • Tearsheet should inherit base functionality of modal.

2. Tearsheet is too complex to move into core’s component library as-is. It should be simplified when brought to Core.

   • The only other component as complex in Core is data table.

3. If the team sees internal components used in products library, then you should consider bringing to Core.

   1. Ex.) Status indicators

---

Elysia chat 10/15/24

1. Should tearsheet also bring in its stepping functionality to the Core library? Teams would likely have to add this themselves for Tearsheet.
2. The interstitial screen for Novice to Pro uses a modal, but has similar features to tearsheet: progress indicator, action footer. Should we consider porting the actions into modal as well?

[RichKummer]

Wide / Narrow comparison

Element	Wide	Narrow
Header	–	–
Label	✅	✅
Title	✅	✅
Description	✅	✅
AI label	✅	✅
Close	✅	✅
Header actions	✅	🚫
Tabs	✅	✅ (We show this in docs, but not Storybook)
Main structure	–	–
Main area (scrollable)	✅	✅
Footer actions / Navigation buttons	✅	✅ (Recommend up to two buttons)
Influencers	✅	🚫
Stacking	✅	✅

Doc review

Types of dialogues: tearsheet, modal, side panel

• Tearsheets should be used over modals when you need to scroll or display complex content like a data table.
• Tearsheet takes over the screen with an overlay, so do not use when the user needs to also interact with that content (use inline editing or side panel instead).
  • Side panel is also useful when the user needs to see both the dialogue content and page content side-by-side.
• Tearsheet should be used instead of modal when using an iframe to display content.
• Tearsheet has a unique animation for coming into and out of view. It also has a unique animation for stacking.

Influencer

• Should we be more clear that certain types of actions belong in one influencer over the other?
• Should only one be viewable at a time? We advise not to use 2 influencers at the same time due to the lack of available screen space appears in the docs.

Header

• For the header, the action buttons (that could also be a dropdown or menu button) floats from the right without being visually anchored to anything. I think we can add some updates and spacing logic to ensure the buttons look more visually balanced.
  • It seems that the buttons were positioned to avoid overlapping with other elements at small breakpoints.
  • We might consider being flexible with horizontal space to avoid overlap and maximize content visibility.
• It seems that there was some spacing thought put in for the header actions that was not implemented. See below.
  • This structure needs to account for the “X” button and now the AI label as well.

Divider (create flow only)

• The divider styling is available in code for create flow but not tearsheet. We don’t mention this in our docs, but show it in the gifs.
• Is this styling necessary when separating sections? Or is this more optional? Is it required at all?
  • Should we enable this styling in the base tearsheet?

Other thoughts

• Should we create guidance for different flows:
  1. Linear flow: similar to the Create flow, where the tearsheet enables the user to move along a track (back and next).
  2. “Vertical” flow: uses stacking to take user out of the flow to perform some action (such as importing settings).
  3. (We have this guidance currently for stacking).
• Tearsheet’s buttons are used very often in its implementation. It’s rare to see a tearsheet without them since modal is the better option for showing strictly read only info. I think the action footer should be absorbed by the simplified version of tearsheet so teams do not have to remake this.
• One request was to change the size of the buttons in the action footer. One consideration is that we might need to separate actions on the tearsheet layer vs actions inside the main content area.
  • Smaller buttons might appear to be inside the main area content.

[RichKummer]

Matt G Dev discussion 10/17/24

1. Create flow comes with a divider → are team’s using this?
   1. The divider is outdated. The CreateTearsheet used to have a switch in the influencer to show all the steps at once. The divider would be used to separate out each step only when they were shown this way.
      1. The team removed it the switch, but haven’t removed the divider yet. The thinking was that you couldn’t show steps together if certain steps have validation.
      2. We can probably remove the divider styling/functionality from the code.
2. Mentioned teams are looking for more composibility on button footer.
   1. Some team products use a large amount of steps: 40 steps for example. Some teams want a custom “Skip” button to move between steps.
   2. In CreateTearsheet, the buttons are out of their control. From a dev perspective, we should have the button footer as a slot which could have any button needed.
      1. Currently, we’re very prescriptive with the buttons that can go into CreateTearsheet.
3. For the influencer, could adopters pass in a child influencer component?
   1. Tearsheet does this a little better than CreateTearsheet, with Tearsheet being closer what teams want. In that, the influencer has a prop that adopters can pass in what they want.
4. Should we consider allowing for both stacking and stepping in base tearsheet?
   1. It would be nice to bring stepping into base tearsheet. Adopters can technically do it but they would have customize it. It would be nice to have a way to have tearsheet handle it from the base level.
   2. At the same time, it would be nice if the component didn’t handle the stepping logic internally. It would be easier for systems team if adopters could handle that
   3. Another idea: maybe some of what we have in CreateTearsheet could be added to Tearsheet.
5. Are there other issues you’ve seen with Tearsheet?
   1. Focus handling with Tearsheet always has issues. I think it stems from the stacking functionality.
      1. If we port over the stacking functionality to Tearsheet, we need to clean up that code.
   2. Lee’s looked into using the browser dialogue for tearsheet. The stacking with that works more seamlessly because they’re dialogue elements.
      1. Lee’s PR is looking to change modal and tearsheet to using dialogue.
      2. We might benefit from treating it as a web dialogue but would need to look into it.
   3. A good portion of our tearsheet code is just for stacking.
6. Are actions in the header for Tearsheet used frequently?
   1. We don’t hear a lot of questions with actions in the header. Maybe it doesn’t get used as much?
7. In the header, we always force the description to be truncated at two lines.
   1. For the Wide variant this is fine, but in Narrow it doesn’t really make sense. Maybe the truncation rules are not on us, but rather the adopter teams themselves.
8. The biggest portions of Tearsheet that need refactoring/rethinking:
   1. Stacking
   2. Slots for influencers and actions
   3. Focus handling

[RichKummer]

Telemetry data (Dec 2023 → Oct 2024)

Component/Pattern	Repos	Metrics
Tearsheet	1,570	552,556
CreateTearsheet	1,871	10,609
CreateTearsheetStep	1,871	27,394