Codifying drawer-toggling behavior

[pwolfert]

RFC: Codifying drawer-toggling behavior

Problem

The design system provides a <Drawer> component that can open and close, sliding over other content on the screen. It does not, however, give guidance on how toggling these drawers should work or how multiple drawers should interact in a page. There are two common questions that application teams have related to the behavior of drawers:

1. What happens when a drawer is already open and the user opens a new one?
2. What happens when a drawer is open and the user clicks on the toggle button again?

In order to create UX consistency within these sites, the design system should provide documentation and possibly code as well that prescribes these drawer behaviors.

Proposal

Based on previous discussions, I'm proposing we answer those two questions in the following ways:

1. What happens when a drawer is already open and the user opens a new one?
   • Answer: We close all other drawers. Depending on how applications use drawers, this may not be desireable, which is why it is opt-in behavior. For HelpDrawers on healthcare.gov, closing them seems like the most appropriate answer.
   • Alternate answer: We allow users to choose between a set of behaviors, like close or stack
2. What happens when a drawer is open and the user clicks on the toggle button again?
   • Answer: The drawer remains open but we shift focus back to the drawer.

These answers are open to debate. They are just what I gleaned from reviewing several conversations we've had with product teams.

We could answer these questions with documentation only. However, I like the idea of codifying it in our tools, so I'm proposing that as well. To accomplish this in code, I propose adding two new things:

1. A new useDrawerMananger hook that provides everything you need to manage the toggle state of a drawer and its trigger
2. a new DrawerManagerProvider component that controls what happens when there are multiple drawers in play on the same page

The hook can be used by itself to manage the state of a drawer and its toggle. If the hook is used in combination with the DrawerManagerProvider, every hook-managed drawer within the provider's subtree will respond to other drawers opening. More specifically, when a new drawer opens, other drawers will close. Alternatively, we could support multiple behaviors by adding a prop to the provider to specify the desired behavior (behavior="close" or behavior="stack").

function MyComponent() {
  const { toggleClick, closeClick, isOpen } = useDrawerMananger();

  return (
    <article>
      <p>
        Some text with a <Button onClick={toggleClick}>help drawer</Button>
      </p>
      {isOpen && (
        <Drawer
          heading="Drawer Heading"
          onCloseClick={closeClick}
        >
          {/* ...content */}
        </Drawer>
      )}
    </article>
  )
}

function MyApp() {
  return (
    <DrawerManagerProvider>
      <MyComponent />
      <MyComponent />
      <MyComponent />
    </DrawerManagerProvider>
  );
}

Benefits

1. The hook is flexible enough to be used on any kind of button-ish component with some sort of action handler and on any kind of component that has some kind of component that needs to be shown or hidden.
2. Codifying the interaction between drawers will improve UX consistency between applications on a website.

Risks

Because this is opt-in behavior, my hope is that the risk is low. It requires no API changse to the existing Drawer or HelpDrawer components.

1. It's more surface area for bugs
2. Apps could potentially have multiple kinds of drawers that they wouldn't want to be managed in the same way. For instance, they could have help drawers which should only have one open at a time as well as interactive modal-type drawers that can stack. If they used the same hooks and provider for both, it wouldn't work. They would either need to only use it for one type of drawer, or we'd have to have a way of specifying which manager certain drawers belong to (which would be easy enough to do but add complexity for our users).

Questions and Feedback

1. We could potentially generalize it to use it for toggling other sorts of things, like accordion items or even radio buttons. In that case, the API might look something more like

   const { toggleClick, toggleOffClick, isToggledOn } = useToggleMananger("my-unique-id");
   // ...
   <ToggleManagerProvider groupId="my-unique-id">

   however, it wouldn't make sense to reuse this if we wanted to support multiple drawer behaviors like stacking. Thoughts?

[zarahzachz]

What happens when a drawer is open and the user clicks on the toggle button again?
Answer: The drawer remains open but we shift focus back to the drawer.

Did you mean drawer button?

[pwolfert]

I mean whatever button opens the drawer initially. I guess toggle implies that it can be used to toggle it off, doesn't it? Right now we have a DrawerToggle component that we don't really use anymore, but calling it a toggle doesn't really match the behavior we're proposing of it only being used to turn something on.

[zarahzachz]

I've one question, and maybe this is for design, but we have the idea of focus trapping in a Drawer. I wonder if we set the pattern that toggling the Button opens/closes a Drawer will create confusion when some Drawers have the trap enabled? We don't currently have an overlay to indicate the non-Drawer elements aren't interactive, so I'm curious if this pattern would introduce user frustration

[pwolfert]

This is the case I was thinking about when I mentioned an alternate "stacking" behavior. In the case of these modal drawers, it wouldn't make sense to close all the others when a new one is introduced. The risk would be that people would use the hook indiscriminately and start to get weird behaviors. It might only make sense to have the close (only-one-at-a-time) behavior for help drawers.

[pwolfert]

It's a good point. It's also a fair argument against having any sort of code around it at all.

[pwolfert]

To this point and Forrest's comment below, what if we had only one DrawerManagerProvider behavior but two hooks? You use the useDrawerManager hook if you want it to sync with other drawers and only have one open for cases like help drawers. And you use a useDrawerToggle hook when they need to stay independent of each other?

Or maybe more generically,

1. useToggleManager and ToggleManagerProvider
2. useToggle

Or if we want to get rid of the idea of "toggling" because clicking it again should only open it and never close it, maybe something like:

1. useOpenManager and OpenManagerProvider
2. useOpen

The above behavior is what we're proposing for drawers and is the behavior of radio buttons but doesn't actually match the behavior of accordions. A third option that adapts to slightly different use cases but risks not actually fixing the problem of inconsistency would be to have a toggle hook that returned { toggleClick, openClick, closeClick, isOpen } and allow the user to decide if they want to use toggleClick or openClick for the triggering button.

[pwolfert]

We discussed this as a team (@zarahzachz, @forrestbaer, @scheul93, and I) and came to a conclusion:

While this pattern could be useful in other places later, we want to keep the behavior that we're codifying simple and constrained to the most common use case on HealthCare.gov. That common case is non-modal (non-focus-trapping) informational "help drawers" that should only have one open at a time. For alternative behaviors, teams are still free to implement their own management code as they have always done.

[forrestbaer]

I like the idea. Stacking seems like it could cause some UX strangeness. I haven't seen that pattern before, so I don't think we should offer something like that. The idea of reusing it for other interactive elements that open and close seems like a good one.

[pwolfert]

For the sake of referencing in the future, the need for this RFC arose from the following tickets:

• https://jira.cms.gov/browse/WNMGDS-1183
• https://jira.cms.gov/browse/WNMGDS-1250
• https://jira.cms.gov/browse/WNMGDS-1594

[forrestbaer]

Work completed in #2482