You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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.
laurenmrice
changed the title
[Empty States] resolve outstanding design spec decisions
[Empty States] identify oustanding design aspects that still need to be resolved
Jan 10, 2025
Acceptance criteria
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.
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.
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.
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?
Alignment
Sizes
Should empty states have a default and compact size depending on where it is placed?
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?
Responsiveness
How would this work in mobile or on smaller screens?
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.
Alternatives
Figure out all the alternatives of empty state (ex: Onboarding experience, Starter content, Education content, Search best match etc.)
Playback
The text was updated successfully, but these errors were encountered: