[Empty States] identify design aspects that still need to be resolved

[laurenmrice]

Acceptance criteria

• Familiarize yourself with the workgroup mural and figma file.
• Go through the Slack threads related to this topic.
• Refer to Tracey's page header workstream.
• Identify any outstanding design decisions below that still need to resolved for Empty states. It would be good to have these in order before finalizing website documentation guidance and this may help inform us if this is defined as a component or pattern in the future.

---

1. Variants (components)

How many components in our system would need an empty state situation? So far it seems like Tile, Data table, Side panels, On page/Inline with content.

• This still needs more exploration. Need concrete use case examples for each to determine if this is correct.

2. Formatting

Anatomy

We need to identify the anatomy of how it appears in each variant/component to see if there are any differences or exceptions.

• This still needs more exploration.

Text and illustrations

When can you have both text and illustration and when should you only have text? Are there any considerations of when to use one or the other? Should it always be consistent if you have multiple empty states in one page? This needs to be identified.

• This still needs more exploration.

Buttons and links

Need to decide how many buttons should be included in an empty state? Does this depend on the component the empty state is on? Is it bad to have multiple call to action buttons in one empty state scenario that are different styles of buttons? Should we allow links?

• This still needs more exploration.

Alignment

• Need to create a final stance of when text and illustrations of empty states are left or centered aligned. Note: I believe the workgroup was saying to just always center align in every scenario instead of being choosy to make the guidelines easier and more straightforward. Need to confirm this direction.
  • Decision: We should stick with vertical, center alignment across all empty states.

Sizes

Should empty states have a default and compact size depending on where it is placed?

• This still needs more exploration.

3. Behaviors

Text max-width

Finalize a text max width across different components for empty states. We have decided it for data table,but what about smaller spaces, like in cards or side panels?

It would be best to finalize this while defining the specifications for the empty state.

• This still needs more exploration.
• Ask Tracey about what shes doing with text max-width for page header, we could use a similar approach possibly.

Responsiveness

How would this work in mobile or on smaller screens?

• This still needs more exploration.

4. Types and Alternatives of empty states

Types

Determine if empty states should be categorized and, if so, define the types (e.g., First Use, No Data, Error States). Decide if First Use and Error States should be considered as empty states or treated separately.

• This still needs more exploration.

Alternatives

Figure out all the alternatives of empty state (ex: Onboarding experience, Starter content, Education content, Search best match etc.)

• This still needs more exploration. At first glance, these seem like different patterns and not part of empty state.

---

Playback

• Playback findings to design team and get feedback.

[github-actions]

Thank you for submitting a feature request. Your proposal is open and will soon be triaged by the Carbon team.

If your proposal is accepted and the Carbon team has bandwidth they will take on the issue, or else request you or other volunteers from the community to work on this issue.