Anatomy of design system drawers

[alexander-bobin]

The intention of this discussion is to share findings after we recently dug into proposed designs for drawers in Cloud. Although it is likely too early to converge on drawers across the Reapit group, it is still valuable for us to all see the same thing.

How was this information uncovered?

• By reviewing designs from Karmen and Andrei
• Important: The design team are quickly producing many designs and some are still up in the air. What we find here though are emerging, high-level patterns that we believe are solid.
• By asking further clarifying questions.

Are there still unknowns?

Yes. See the bottom of this document.

Anatomy

Headers

Footers

Body/content

Where the guts of the drawer goes. This could be displayed information or form fields. See below for more.

Drawer types

We found there are at least 3 drawer types.

Detail drawers

• Karmen has called these read-only drawers. We have previously called these detail drawers. The name is up in the air. The purpose is clear... display information only (there are few exceptions)
• We occasionally some kind of action bar at the top of the drawer body
• Exception: In some cases, there may be an "inline" mutation with no submit button where the action is immediate. For example, toggling something off and on.

Tabbed detail drawers

• We only have one example
• Notice the tabs are considered part of the header and affect the what is displayed in the body

Form drawers

• Karmen has previously used a different name. The name is up in the air
• Typically a simple header with the footer having save and cancel buttons with and maybe delete link/button
• At this stage Karmen believe these should not be combined with tabs
• Over the last 5 years at Console, these are about 70% of the drawers we have delivered

What do we need clarity on

Stepped form drawers

• Some have called them wizard drawers. The name is up in the air
• We have no design examples but there is a strong suspicion these will be required
• Quite likely the footer buttons will change as the user proceeds through the steps
• Some information will be displayed to show their progression through the steps
• At this stage that's all we know

File preview beside a drawer

• Previously in Cloud, in special cases, we have allowed a PDF to be uploaded in the void to the left of a drawer and then file is then previewed in that space
• The design team are not yet sure how this functionality will be tackled or reproduced
• We should get clarity soon-ish as this is actively being looked at by the design team

[alexander-bobin]

/cc @willmcvay @adrian-reapit in case you did not see this

[willmcvay]

@alexander-bobin Thanks for this and apologies for the slow reply. @HollyJoyPhillips is working on the individual specs for components right now for v5. There will be a single component by component spec going on the board in the coming weeks, and obviously drawers will be included in this.

Her priority for these specs is around value add, both in terms of where we have greatest current divergence from the DS and where teams need the components.

In terms of the former, can you give us a short bullet list of features and or / behaviours you would like to see in a Drawer not currently available? Possibly a proposed component interface would be helpful.

In terms of the latter, how high a priority is the Drawer component in to see updated versus any other work for v5?

[alexander-bobin]

Full disclosure
We have just been through the process of clarifying, designing and building primitive drawer components in react-ui-core. These are Drawer, Drawer.Header, Drawer.Body and Drawer.FormFooter. These can be viewed here. I'm happy to run anyone through decision making and what we learned on the way. Just shout.

Not yet built: allowance for tabs in the header, some kind of "action bar" at the top of the body.

We are toying with the idea that there may be higher level components to guide correct usage of drawers (e.g. a details drawer can have a close button but not a footer) but nothing exists yet within the DS so we are reluctant to go further for now.

Answers to questions
Any features or behaviours required can come from looking at the Design System (which I have condensed in this discussion to make things easier). What I see:

• no allowance for category in header
• no allowance for tabs in header
• subtitle rename to supplementaryInfo
• unsure about canDismiss. In Cloud we see a need to have a callback like onClose
• some formalisation of an "action bar" which is sometimes placed at the top of the drawer body
• footerItems would may leave the door open for inconsistent design/implementation for form footers where we need a right aligned button group and an optional link on the left. The footer generated a good amount of in-team discussion for us recently.

A more important note, I'd say that the current Drawer component in Elements hides away what are genuine components in the DS. The header and footer. As far as possible, we should aim to have 1:1 components from DS to implementation. This became especially clear to me after seeing Figma's recently showcased Code Connect..

For proposed component interfaces, the recently delivered components show that.

As for priorities, the pressure is off from our side since we have components to use. @kurtdoherty do you have any input here?