Card - Refactoring Card component into a template

[wenannie8]

There are many different use cases for cards so the users should have full freedom to customize the design of cards. Slot component feature was explored as a way to make cards as customizable as possible. Explorations link: https://www.figma.com/file/je5AYzMavRt1cG7rmw8j1W/HPE-Card-Component?type=design&node-id=4353%3A11375&mode=design&t=p1iCvgipsGyRmAsr-1

Exploration 1: Having one empty slot

• The card component essentially becomes just an empty container.
• users can create local components with variants to replace the slot.
• • Users would have to create a lot of different variants for different layouts, themes, etc. Users cannot change the properties of the cards from the originally component easily.

Exploration 2: Having multiple empty slots

• There are multiple invisible empty slots inside the component. Users need to create local components for different sections separately (a component for heading, another component for body, another component for picture), put one component into one slot.
• Users would need to unhide slots to add a local component in the slot, which can be very tedious.

We do not want to limit the user's ability to customize a card. In Grommet currently, card is an empty container. Since the user's have the freedom to change all of card's properties, there's nothing for the Design Systems to standardize. However, we want to provide guidance to ensure that cards generally follow a consistent pattern, such as heading is always bigger than body text. We also want to give users example layouts of cards to better help users understand how to build cards. Therefore, it might be best for cards to be a templet instead of component. Templets allow us to give users guidance without limiting customizability.

[halocline]

This descriptions ☝️ is a great start. A couple other thoughts to consider:

It would be good to consider a Card as a generic layout component, consisting of loosely defined content regions (header, body, footer), direction, corner rounding, elevation, hover states. It's dimensions flexible; can be small, large, narrow, wide, , grow/shrink to fit its contents, etc. Padding should not be baked in to the Card (too many use cases where a background color/image will want to fill the entirety of a header/body/footer.

The Card layout component could then be complimented by a collection of "card templates" which are a variety of executions populating the header, body, and footer regions. Lots of variety will be good for inspiration.

---

From a Design System perspective, we want to standardize on what a card's purpose is and how it should be used:

• A container providing at-a-glance information and easy access to more details.
• Cards are containers that display content and actions on a single topic. They should be easy to scan for relevant and actionable information.
  • Contained - A card is identifiable as a single, contained unit.
  • Independent - A card can stand alone, without relying on surrounding elements for context.
  • Individual - A card cannot merge with another card, or divide into multiple cards.
  • Summarized - A card by nature has limited real estate, so it should present summarized information.
• Cards should be used when:
  • Presenting high-level, summarized pieces of information.
  • Presenting an item, or collection of items, which can best be consumed visually.
  • In all cases the presentation allows users to quickly scan the content and navigate to underlying detail if desired.

Principles

Types