Feedback on the Core cds-card component

[astorije-vmware]

Context

At CloudHealth, we've been converting our products to Clarity Core with React using the @cds/core and @cds/react for a little over a year now.

As part of that, we had converted our (non-Clarity) Card component to a Clarity-like card based on the Clarity Angular card component. Ours is a React component, so we created an API that we thought most resembles other Clarity Core components in order to:

1. minimize conversion work once a Clarity Core component comes around (based on our expectations from working with Clarity Core so far)
2. provide a seamless experience to our developers: if you know how to use a component such as CdsModal or a CdsAlert, using our Card component will look awfully familiar.

This is what we have at the moment:

Screen.Recording.2021-10-07.at.3.58.21.PM.mov

And here is the code corresponding to those 2 cards:

<Card aria-labelledby="regularCard">
  <CardHeader cds-layout="horizontal gap:sm align:vertical-center" id="regularCard">
    Card title
    <CdsTag readonly status="success">Label</CdsTag>
  </CardHeader>

  <CardBlock>Lorem ipsum … aliqua.</CardBlock>
  <CardBlock>Lorem ipsum … aliqua.</CardBlock>

  <CardFooter>
    <CdsButton action="outline" size="sm">Action 1</CdsButton>
    <CdsButton action="outline" size="sm">Action 2</CdsButton>
    <ButtonMenu />
  </CardFooter>
</Card>

and

<Card aria-labelledby="clickableCard" clickable>
  <CardHeader cds-layout="horizontal gap:sm align:vertical-center" id="clickableCard">
    Card title
    <CdsTag readonly status="danger">Label</CdsTag>
  </CardHeader>

  <CardBlock>Lorem ipsum … aliqua.</CardBlock>
  <CardBlock>Lorem ipsum … aliqua.</CardBlock>
</Card>

Feedback

1. An interface closer to other Core components

This is how a card like the above would be implemented using the current API in preview:

<CdsCard>
  <div cds-layout="vertical gap:md" aria-labelledby="regularCard">
    <h2 id="regularCard" cds-text="section" cds-layout="p-y:sm">Card title</h2>

    <CdsDivider cds-card-remove-margin></CdsDivider>

    <div cds-text="body light" cds-layout="p-y:md">Lorem ipsum … aliqua.</div>

    <CdsDivider cds-card-remove-margin></CdsDivider>

    <div cds-text="body light" cds-layout="p-y:md">Lorem ipsum … aliqua.</div>

    <CdsDivider cds-card-remove-margin></CdsDivider>

    <div cds-layout="horizontal gap:sm p-y:sm align:vertical-center">
      <CdsButton action="flat-inline">Action 1</CdsButton>
      <CdsButton action="flat-inline">Action 2</CdsButton>
    </div>
  </div>
</CdsCard>

A few things seem a little out of place compared to other Clarity Core components:

• The need for extra divs with manual gaps, margins, etc. means there is very little chance all cards out there will share consistent styling. The need for flexibility is totally understandable, but no 2 cards should have different margins IMO.
• The dedicated cds-card-remove-margin prop for CdsDivider seems a little too specific/one-off.

Overall, we think an interface closer to modals or alerts would make a lot more sense. Selfishly, it would more closely match what we already have, but it would ensure consistent styling by abstracting things behind cds-card-header, cds-card-content or cds-card-block, cds-card-actions or cds-card-footer with built-in, consistent margins. It would also more closely match the other Clarity Core components.

2. Automatic id/aria-labelledby attribute generation

At the moment, it is necessary to pass those manually, but it would be super nice if those things could be automatically generated, similar to how cds-input treats label/input id generation 😍

3. Auto-inlining flat buttons

I think it would be a neat idea if, when using flat buttons, they could be automatically turned into inline-flat buttons. There are definitely pros and cons to this, such as: what if one wants to use a mix of both outline + flat buttons, definitely don't want to auto-inline those, and then what if other cards next to that one only have flat buttons, probably worth leaving those.
Not sure I'm fully sold on that one, but just throwing the idea out there for discussion, to help with consistency.

4. Border styling

This is obviously subjective and controversial, but the heavy shadow around cards feels a little... off.

As you can tell above, we have modeled our own Card component against the Angular cards (thin solid border + thick bottom border) and it overall looks "cleaner" and more "modern", however subjective those terms are.
At CloudHealth, our design team tends to put most things inside a card and that would make for heavy designs.
Additionally, when co-locating a card aligned on top of a datagrid, an alert, or any other Core container that has a thin border, it will look uneven.

I know that this can be customized, but we overall do not customize our Clarity components unless we absolutely have to, in order to increase consistency within our own products (it's almost impossible to ensure every developer will implement customizations consistently across our codebases unless we provide a shared custom component), but also within other VMware products.

5. Clickable cards

Are they gone from Clarity? I'm assuming the accessibility of clickable cards is very hard to ensure and therefore the priority goes towards non-clickable cards with a call-to-action in the footer, could you confirm?

We are currently not using any clickable cards, so it's not going to be a problem not to have them in Core, but I want to make sure we communicate this internally if that's the case.

---

Thanks again for the wonderful work, we're excited to have yet another Core component taking over one of ours that we can slay! 😁

[bbogdanov]

Hi @astorije-vmware,

Thank you for your feedback!

I will take the chance to give some clarity on each point.

1. The initial API proposal for the card was with header, footer and body, actions, etc. The reason we didn't go in that direction is that the card is really not that complicated. It just a box with a visible border and a shadow (panel with a shadow). What's inside it, is up to the users. We wanted to provide a fully customizable card as it is with the Angular Card.

The cds-card-remove-margin is needed because of Shadow DOM and it's specifications about what's possible to reach with CSS. But at the same time we wanted to make sure we are giving you the freedom do remove the dividers.

2. We will discuss it and get back to you

3. Like you said it would be complicated to know when the user will like to have a flat or inline one and it can get messy at some point and I believe - less is more

4. With Core we tend to adjust some components styles. @colinreedmiller can give you more details about why we made that change.

5. You are right. The a11y is hard to ensure the reason why we don't have them but we are working on what I call fancy checkbox/radio button that looks a lot like clickable card and it would help in most cases

[astorije-vmware]

Hi @bbogdanov, thanks for the quick answer!

1. API

It just a box with a visible border and a shadow (panel with a shadow). What's inside it, is up to the users. We wanted to provide a fully customizable card as it is with the Angular Card.

I think that's the part we're struggling with a little. As consumers, we would much, much prefer a card component to be a little opinionated, therefore consistent, over providing absolute flexibility.
If a card is just a box with a border, it is our opinion that someone who needs complete customization should simply use a div with the amazing design tokens you are currently providing. I think this complete flexibility is already provided with the design tokens.

And the content can totally be flexible, we're thinking what goes around it should be rather consistent across cards.

Just our 2c of course, but as it is it means we have to ask our developers to not use the CdsCard component otherwise our products will become a wild west of inconsistent margins, paddings, separators, headings, etc. 😅
We can totally provide our own component built on top of Clarity's card, but in general we try to use Clarity as-is (and it looks amazing already this way!).

3. That's totally fair, I think I was just thinking out loud since flat-inline buttons for card has been strongly requested by our UX team. We'll just have to be careful with reviews!

4. Noted. I think I'll remove our clickable cards at the moment.

Thanks again, love the progress on everything! 😍

[astorije-vmware]

@bbogdanov, with the recent release of checkbox panels and radio panels, is there an intension to match the designs eventually (borders, shadows, paddings)?

vs.

[bbogdanov]

@colinreedmiller

[colinreedmiller]

The designs are different because they are fundamentally different components from an interaction perspective, meaning they have different a11y requirements. While cards are containers that may be used as needed, the radio / check panels are form elements that allow greater detail to be added to each available option. The need for different states and the consequent a11y contrast requirements in the latter leads to the visual differences you see.

[hippee-lee]

@astorije-vmware -

tl;dr - {checkbox|radio}-panels are form elements with an input and a label. Applications should take care to ensure the content projected into the label is accessible.

In addition to what @colinreedmiller posted, the selection panels as I ended up calling them are essentially checkbox and radio inputs with some css that styles the label so that content can be put inside of them. They come with all of the constraints for form labels wrt a11y - no interaction only span elements for text. There is still some gray area when it comes to icons and images - my interpretation of the specs is that these are ok as neutral/inert elements but that wasn't shared with all a11y folks so I removed them from the examples.

[hippee-lee]

As far as styles, they are more of an evolution or an extension (not sure what the best word is here) of the form control styles. So, despite the original proposed name that was clickable cards, they are not at all related to cards.