Refactor list component

[SeamusLeonardHPE]

The current list component requires some attention to help build a path for the v2 refactor.

• Audit the existing grommet pros to make sure we are making all suitable props available in figma
• Collaborate with devs & product team to get an understanding of common use case
• Create a first draft list component that contains a minimally configurable option and a slot options

[KennyAtHPE]

10/11 Update: Connected w/ Matt, Vicky, and Lucas to go over the component proposal.

Success Criteria

ListItem should:

1. Provide value to the user. This can be measured in 3 separate ways.
   • Inspiration: How can we help users solve problems quickly and efficiently by leveraging current and past designs?
   • Quick start: How can we provide users with a core set of variants/templates to help kickstart their designs?
   • Streamline the building process: How can we maximize efficiency by removing time-consuming tasks with building Lists?
2. Provide users with the flexibility to create any design while limiting detachments.
   • Detaching the instance severs the tie to future component updates.
3. Be easy to use
   • Why should users use the design system component instead of creating their own ListItems?
4. Be discoverable. The component and any accompanying assets should be easily searchable and contain relevant metadata.

Deliverables

• [ ] Smart Defaults - Create a few core variants of ListItems (i.e. Select & FileInput drops, TBD)
• [ ] Easily Configurable - Provide variants/component properties for ListItem's pre-composed templates
• [x] Customizable/flexible - Provide a slot component variant

---

Proposed Solution

Template Library + Slot variant approach

ListItem component and content components The ListItem component has a few others variants aside from the Slot variant.

• State: Enabled, Hover, Selected, other can be added in the future.
• Styles: Default, Card, w/ bottom border. Common styling for ListItems. We may not want to include in the first pass if this presents any additional complexity.

• Slot: Allows the user to instance swap from a catalog of premade common use cases within their ListItem component

  • These use cases would live within the template library as a component and would be set as preferred values within the main ListItem component.

  • These components would have their own variants and component properties specific to their use case. (This ListItem slot has been swapped out with the .FileInput content component. This content component has a use case specific boolean property on the close button.)

  • Alternatively, we could have the .Slot master component live within the template library so that the instance swap menu by default would search for components within that file.

List Templates Besides using the ListItem component directly from the assets panel, users could alternatively go to our Template Library to find premade full-fledged Lists to copy and paste into their designs.

• These templates are currently not being considered to be turned into components however they are using our ListItem components.
• Present List templates as a sticker sheet containing common List examples. Organization around grouping and naming is key.

(This FileInput List template is made up of ListItems using the .FileInput content component. We would be editing our templates to showcase real life examples)

User Flow

Success Criteria evaluation

1. :white_check_mark: Provide value to the user.
   • List templates and ListItem content components could be used as inspiration. Catalog/Sticker sheet view for designers to find commonly used designs and solutions
   • Premade templates and ListItem content components provide a quick start.
   • Having specific configurable options for use cases streamlines the building process. Remove that second-guessing from users by being intentional with the properties and variants we provide.
   • All layers would be named and grouped by the Design System team. Helps the designer from having to name their own elements and removes confusion during dev handoff.
2. :white_check_mark: Provide users with the flexibility to create any design while limiting detachments.
   • The slot variant does provide flexibility for any content to be swapped in.
   • If we own commonly used List use cases then folks won't have to create their own. Furthermore, if we provide appropriate configurable properties for use cases then folks won't have to detach as much either.
3. :white_check_mark: Be easy to use
   • Having specific use case configurable options helps the designer's decision-making and lessens the load within the variants panel
   • Two different ways to start, building with ListItem or editing a List template.
4. :white_check_mark: Be discoverable. The component and any accompanying assets should be easily searchable and contain relevant metadata.
   • Organizing the sticker sheet of templates and the instance swap panel is key.
   • Two different ways to quick start designs, building with ListItem content components or editing a List template.

---

Other Explored Builds

Slot only variant

1. :red_circle: Provide value to the user.
   • Does not provide inspiration, a quick start, or help streamline the designer's flow. If designers are not given anything to start with, they will have to make a unique component for all of their use cases. At that point, it would be slower to have to swap their component into the design system's ListItem component.
2. :large_orange_diamond: Provide users with the flexibility to create any design while limiting detachments.
   • The slot variant does provide flexibility for any content to be swapped in.
   • Designers would not be detaching our ListItem component but they would not be using it either. If they have to make a unique component for each of their use case, they will just use their own ListItem components.
3. :white_check_mark: Be easy to use
   • The component is easy to use because there would only be 1 variant, however, this does not provide value to the user.
4. :large_orange_diamond: Be discoverable. The component and any accompanying assets should be easily searchable and contain relevant metadata.
   • If designers make their own components and distribute them instead of using our ListItem component then that would ruin the searching experience for all users. We are already having to deal with duplicate atom components.

Configurable defaults + slot variant

1. :large_orange_diamond: Provide value to the user.
   • Provides value only if the preset configurable options are available.
   • Not scalable for us to keep enhancing the component to provide more options through variants/component properties.
2. :large_orange_diamond: Provide users with the flexibility to create any design while limiting detachments.
   • The slot variant does provide flexibility for any content to be swapped in.
   • May promote more detachments if our preset configurable options do not provide the user with the right elements.
3. :red_circle: Be easy to use
   • Variant panel gets more cluttered as more variants are introduced.
   • Not a beginner-friendly component, can easily overwhelm designers.
4. :large_orange_diamond: Be discoverable. The component and any accompanying assets should be easily searchable and contain relevant metadata.
   • If designers make their own components and distribute them instead of using our ListItem component then that would ruin the searching experience for all users. We are already having to deal with duplicate atom components.

[halocline]

cc: @KennyAtHPE, @oliverHPE, @julauxen, @SeamusLeonardHPE, @taysea, @SOjaHPE

Playing with modified success criteria. Attempting to: 1) articulate the core attributes we are solving for 1) genericize a bit to apply more broadly 1) organize into logical themes 1) first pass ordering by importance

This was a time-boxed riff. Inviting discussion, reaction, adjustments and/or alternate proposals.

---

Success Criteria

[Design system asset] should:

1. Provide value to the design system consumer by enabling:
   • Efficient building(creating?) process: How can we maximize efficiency by removing time-consuming tasks with building?
     • Quick start: How can we provide users with a core set of variants/templates to help kickstart their designs?
     • Easy to use: Why should users use the design system component instead of creating their own?
     • Provide inspiration: How can we help users solve problems quickly and efficiently by leveraging current and past designs?
   • Flexibility: Asset should be "foundational, yet flexible."
     • Smart defaults: Target "the 80% use case"
     • Configurable: Easy to configure through variants/component properties (informed by pre-composed templates?)
     • Customizable: Fully customizable should my use case require it.
2. Be discoverable.
   • Searchable: The component and any accompanying assets should be easily searchable and contain relevant metadata.
   • Browsable:
   • Follow established discovery patterns
3. Be delivered in a manner which is scalable and maintainable.
   • Updatable:
     • Built with design system atoms and molecules, so that updates to lower level assets will be inherited.
     • Minimize detachments: Provide users with the flexibility to create any design while limiting detachments. Detaching the instance severs the tie to future component updates.
   • Minimize variants: More variants --> more complexity --> more costly to build and maintain.
     • Only adds variants that have been use-case driven by shared patterns.
     • Does not include speculative variants for use-cases which have not been expressed.