[Discussion] Expandable component and variations

[natalia-fitzgerald]

Discussion: Expandable component, variations, usage guidelines, and use cases.

Background

I have started a review of the expandable component as a part of the CFPB Design System in React component verification process. In reviewing the expandable component, I audited the implementations of the "padded expandable" variation. I also reviewed the expandable component more broadly. The purpose of this issue is to both capture details of and discuss the current usage of the expandable component on the website with a focus on the "padded expandable" variation.

Padded expandable

The "padded expandable" variation increases:

• The size of the expandable label from 18px to 26px
• The top and bottom padding from 10px to 25px

Expandable	Padded expandable

Expandable options in Wagtail

The following options are offered in Wagtail for both single expandable or expandable group:

• Is bordered: Adds a border (o-expandable--border)
• Is midtone: Adds a gray 5 background color (o-expandable--background)
• Is expanded: Sets the expandable to be open on load (o-expandable--onload-open)

• Is expanded padding: Changes the expandable label from 18px (equivalent to H4 in size) to 26 px (equivalent to H2 in size) (o-expandable--padded)
• Add icon to the left of the expandable label

Expandable (group):

The following options are only available for expandable groups:

• Heading for the group
• Body text
• Is accordion (o-expandable-group--accordion)
• Has a top rule line
• Uses FAQ schema

Expandable (single)	Expandable (group)

For the padded expandable, if a Wagtail user populates the fields as presented, will they end up with an Heading 3 for the group and Expandable labels that are 26px. On the "Learn more" page a workaround is being used where the heading for the expandable group was placed in the body field and styled as an H2.

Expandable group visual results

The following reflects the visual result at desktop if the fields in Wagtail are populated as presented.

• For the standard expandable group the group heading is an H3 (22px) and the expandable label is 18px.
• For the expanded padding expandable group the heading is an H3 (22px) and the expandable labels are 26px. So, the heading for the group is smaller than the expandable labels.

"Is expanded padding" not selected	"Is expanded padding" is selected

Expandable labels and our type hierarchy

In reviewing the styling for expandable labels, I noticed that the expandable labels do not pull in headings from our type hierarchy. At this point in time, the padded expandable label does not align in weight with the CFPB Design System type styles.

Type styles

Expandable

• Desktop: 18px, Medium (500)
• Mobile: 16px, Medium (500)

Padded expandable:

• Desktop: 26px, Medium (500)
• Mobile: 22px, Medium (500)

CFPB Design System:

• Heading 2: 26px, Semibold (600)
• Heading 3: 22px, Regular (400)
• Heading 4: 18px, Medium (500)
• Heading 4 (mobile): 16px, Medium (500)

For discussion and exploration

Padded expandable

• Should we continue to offer the padded expandable? If yes, then continue.
• For consideration: Change the styling of the expandable to 22px at desktop and 18px mobile
• Should Wagtail users have the option to use the padded expandable for a single expandable or should this option only be offered for expandable groups that sit under a group heading?
• Should a Wagtail user of the expandable group module be able to select H2 or H3 for the group heading?
• Write usage guidelines for the padded expandable
• Update the name of this variation to be more descriptive. The size/prominence seems to be the defining feature rather than the increase in padding.
• Should selecting "is padding expanded" apply to individual expandable group items or should it apply to the entire group? Currently a user can apply this on an individual expandable group item which would mean that some expandable labels in the same group could be 26px and others could be 18px.

Expandables (overall)

• Should the expandable labels correspond to our type hierarchy in both size AND weight?
• Should it be required to populate the heading field when using an expandable group?
• What should the defaults styling options be set to in Wagtail?

@jenn-franklin @ajbush @keelerr @itsmedavep @anselmbradford @gogogabby007

[ielerol]

From our earlier discussion, it sounds like the padded expandable is a distinct use case from standard expandables, and I'd like to see it work something like info unit groups--where you choose between the standard or the larger expandable when you add the component, and that affects which fields and settings are available. That way the regular and padded expandables can potentially each have their own set of default styling options, like heading size or background, if we think they need them.

It also doesn't make a lot of sense to me to have a single padded expandable on its own. If a single chunk of content is that high priority, why hide it behind an expandable? And if there's too much content for a single page to be readable/approachable, that smells like a more fundamental issue with the content or page design. I'm not sure we can constrain users within Wagtail to add at least two expandable sections, but it does also point towards making the option something that happens at the component selection level like the info unit groups, and also something to include in the usage guidelines.

[natalia-fitzgerald]

From a Wagtail perspective, there is also the question of how we present the options for a single expandable versus an expandable group. This may come later, once we have sorted out what the actual variations or types are for expandables, versus what the properties are.

Currently in Wagtail the following options are offered for a single expandable:

Single

• Label
• o-expandable--padded
• o-expandable--onload-open
• o-expandable--background
• o-expandable--border
• Includes icon

In Wagtail, when you decide to add an expandable group, the following group level options are offered:

Group

• Is accordion
• Has top rule line
• Is FAQ schema

The expandable group (o-expandable-group) is made up of single expandables (o-expandable) and Wagtail offers all of the same options for each single expandable whether they appear alone or within a group. In practice, this means that you could have a lack of consistent styling between expandable items within the same group. One lower-lift way to address this would be to indicate in the DS that (and perhaps in Wagtail itself) that, within a group, all expandable items must receive the same styling.

[jenn-franklin]

Hi! A handful of thoughts:

Padded expandable

First, I think this may be an unpopular opinion—and I don’t have strong convictions about this opinion but still wanted to mention it. 🙂 I’m still waffling on if the padded expandable is needed. If I’m following correctly, we use it correctly in two designs, Find advice for your student loans and "Learn more: Navigating financial rules and regulations." In the other handful of designs in which it’s used, I think we are asserting that the use is incorrect and should be changed.

For the two correct uses, I think the padded expandable and page designs in and of themselves are lovely. But I do wonder if the regular expandable group or info unit groups would also work in these designs. Another semi-related design solution is jump links, which would enable skimming though may be a solution better suited for longer chunks of content.

Because there doesn’t seem to be an overwhelming need for the padded expandable variation, I’m feeling hesitant to include and maintain it in the DS and Wagtail. These thoughts occurred to me when I was noodling on the Wagtail implementation of the padded expandable (see below), so I wanted to share. But I don’t have strong convictions about this, so if we want to proceed forward with the the variation, 👍.

Expandables in Wagtail

I like @ielerol's concept of—if we continue to offer the padded expandable—it being presented similar to how info units are presented. Also, I totally hear you @natalia-fitzgerald regarding this comment. Once I started playing with how padded expandables are presented in Wagtail, I quickly started questioning how expandables are presented more broadly. Do we need to offer separate “Expandable” and “Expandable group” options in the main Wagtail menu? Do we need to offer styling options per expandable vs. per expandable group? Here’s a preview of some of the noodling I'm doing in the Figma file @natalia-fitzgerald started. Perhaps we can revive this conversation at a design meeting soon.

[natalia-fitzgerald]

@jenn-franklin
Thanks for sharing your thinking. I'll dig into this more next week but I wanted to clarify one piece.

• In the two "correct" padded expandable implementations, a workaround is being used in Wagtail which is the only way to end up with a 26px for the heading and 22px px for the expandable labels). If you look at the "Learn more" page in Wagtail, for example, the heading for the expandable group was placed in the body field and styled as an H2 (26px). This is currently the only way to get the Wagtail implementation to produce the desired result.
• If a Wagtail user were to populate the fields as presented ("Heading" and "Body") they would end up with 22px for the expandable group "Heading" and 26px for the expandable "Labels." So, in the Wagtail interface, the "Heading" for the expandable group (the parent) is smaller in size than the expandable "Labels" (children).
• If the padded expandable component variation is preserved we should work to create a Wagtail experience that doesn't require a workaround.

Let's plan to discuss this at the next Design CoP!