Expand card component

assigned to @cam.x

changed milestone to %14.5

@cam.x Great work on this and getting the different variants outs. Here is an issue that has some discussion on documenting cards #1149 - I'll close that issue in favour of this issue. If we need to create a new issue to track Figma component changes then we can create a new one in the future as the steps for updating a component has changed since %13.1

@cam.x Question - one thing that comes up from time to time is should cards be clickable? I would appreciate guidance around that.

Here is a past discussion about it between @beckalippert @jeldergl #639 (comment 374445502)

@mle Thank you for this, I will add some adjustments to separate "clickable cards" and "non-clickable cards"

Also, paste the original discussion here.

import from comment

@cam.x Just for posterity in case it helps- here's an example we have of non-clickable card components that have links.

Thanks for linking to that comment @mle. Because of the nuances with having links or actions within a card that also might appear linked I tend to think we should stay away from that pattern. Also just another plug for the considerations in this article https://inclusive-components.design/cards/.

@jeldergl The example here, is our doc page should align with Pajama guidelines? I found the shadow of the cards is very different.

@cam.x the Docs site uses a separate repo for code and styles. At the moment it doesn't use GitLab UI. I did design those shadows used there, but even those shadows have some desired updates that I noted in the audit linked in gitlab-org/gitlab-docs#987 (closed).

Hi, @jeldergl @mle I have given it some thoughts, what do you think about following?

Two main types of cards

The two major types of cards are:

Readonly cards (without action)
- Those cards can have either rich content or simple content, but none of them contains any actions that the user needs. So there is no affordance needed for the card style, such as hover or active.
Cards with Actions
- Buttons: Buttons are always located at the button of the cards. The button is obvious enough to tell the user that it is clickable, there is no need to add hover status to the whole card.
- Tertiary Action: when there is a tertiary action, to make sure the user knows this is clickable, we can add hover status to the whole card as an affordance to indicate the clickable action.
- Links mixed within the content: when there are links mixed in the content, to make sure the user knows this is clickable, we can add hover status to the whole card as an affordance to indicate the clickable action. There are also exceptions, such as a full-width card with a big table, adding hover states to the card will be overwhelming, so for this type of card, we don't add whole card hover status.

No matter which cards, TECHNICALLY, we don't make the whole cards clickable(don't attach a link to the whole card, links only attached to the action itself).

I noticed this part:

No matter which cards, TECHNICALLY, we don't make the whole cards clickable

Wanted to flag that cards are currently clickable in the product - not sure if/how we want to include that in the documentation?

The example that comes to mind is boards - the issue titles are clickable but the cards themselves are also clickable. In that case, clicking the card will open up a drawer with more information about the issue in question, whereas clicking the link within the card will open up the issue itself. The different actions correspond to different behaviors.

I guess I wanted to confirm: are we suggesting that we'd remove that behavior entirely, along the lines of what's suggested in Jeremy's comment?

@cam.x I replied with separate comments to thread discussions better.

@ameliabauerly

I guess I wanted to confirm: are we suggesting that we'd remove that behaviour entirely, along the lines of what's suggested in Jeremy's comment?

Yes, basically reflecting on the original comment you pointed out.

The example that comes to mind is boards - the issue titles are clickable but the cards themselves are also clickable. In that case, clicking the card will open up a drawer with more information about the issue in question, whereas clicking the link within the card will open up the issue itself. The different actions correspond to different behaviours.

@ameliabauerly In the scenario you describe, for the behaviour of clicking on the card and opening more information, can it be replaced by a button or link? Does it have to be the card itself to be clickable?

One reason I think the card itself shouldn't have the unique clickable link is the technical problem @jeldergl addressed in the blog. The other is the affordance for the card itself to be clickable is not clear. Not all cards are clickable, not all cards give a similar hint of what will happen if you click on the card. If we can't keep clicking on the card itself clear and consistent across the platform, it is better not to use it. Instead, we can use buttons, links with copies, to make sure users know what to expect after they click on something.

Thanks for clarifying, @cam.x!

I definitely agree the affordance isn't as clear without the buttons. But space might also be an important consideration, especially on something like Boards. If we added, for instance, the two button variant described here, the issue cards on boards would be quite a lot larger than they are now. There are probably ways of solving for that but, I guess I just wanted to flag the potential impact of this change so we're sure we can update existing card uses to align with the new guidelines?

@uhlexsis - Do you still work on boards? Maybe y'all are updating the board design anyway, so the proposed guideline update in this issue aligns with the larger vision for that page. But, thought it might be worth getting your eyes on this change, just in case you have thoughts on whether the new guidelines would work for that use case? (Also, I guess I'm presuming those are cards on boards but, maybe they are something else in that context?)

@ameliabauerly Thank you for explaining. I agree that cards will be longer, and there might be repeated button copies. We can keep working on it to improve, maybe use icons or something or type of patterns

Do you have a concrete example in Figma or something? Which will have us brainstorm easier.

@cam.x, I actually have recreated a boards card in Figma that you're welcome to grab. But, I'm not the DRI for boards, and that was created awhile ago. Alexis probably can let you know if there's a better/more up-to-date working version of a boards card :)

mentioned in issue #639 (closed)

mentioned in issue gitlab-org/gitlab#340588 (closed)

changed the description

closed

reopened

closed

@cam.x I had this issue open to improve the layout design of keys & tokens. It's been sitting idle for awhile though, and I can definitely refresh it with whatever the outcome is here. I wouldn't say my design is finalized, but rather hope to share a use case for this component in the future.

Thx @aregnery definitely a good use case for this, I will add those life examples to helps define the usage of cards

reopened

changed the description

suggestion Have you considered approaching the cards as variants versus grouping them in two groups as read-only and with actions?

For example this could have the default card with heading and body text. Then with image, and then with actions. You could then have multiple combinations and could be easier to write guidelines for.

@mle Yes, I think that's also a way to organize the doc. I am fine with that. I do "action" and "without action" is now is mainly to address this point, to make sure we can talk enough on this point! I can do some editing at a later stage when we are ready to go for docs :) Good suggestions!

suggestion For the actions, if we are able to speak to where buttons should be aligned left or right then we could leverage the existing guidelines on primary, secondary, and tertiary/delete buttons https://design.gitlab.com/components/button#alignment

@mle Definitely! I will add this to the doc to make sure the button order follows our guideline!

question Would we ever have both links in content and actions?

Links mixed within the content: when there are links mixed in the content, to make sure the user knows this is clickable, we can add hover status to the whole card as an affordance to indicate the clickable action.

@mle I think that's possible, but not common cases. Imagine in the card, there is doc like content, some of the terminologies will link to another page? But the main action is to read more on this doc? I think hyper link actions inside the content of the cards should be allowed.

@cam.x I suspected that it was not a common case so thanks for confirming.

I think this is a gray area because I could see the case for the link in the content area or as a secondary/tertiary button "Learn more". I think we could tackle this as a future iteration and shouldn't block the initial content about cards. You already have a lot to wrangle at the moment.

@mle thanks for separating things into threads!

@gitlab-org/ecosystem-stage/foundations I'm at capacity to give this my full attention, would any of you be able to help work through cards here from a UX and frontend perspective? For quick reference, here's an article that I think has some fantastic considerations.

@jeldergl I don't have capacity either. Perhaps a Pajamas maintainer can help here: @ameliabauerly @pedroms @rayana are you able to assist?

What exactly is needed here, @jeldergl? I also don't have a ton of capacity, but I can try to help guide a MR through if one is created. Is that what you were needing, or were you wanting someone to review and guide the discussion in this issue a bit more? Wasn't sure so, wanted to check in!

@great question @ameliabauerly. I think working through an MR would be helpful.

@cam.x since there's a lot of conversation here do you think you're ready to open an MR for this? I think it'd provide a better opportunity to review the proposed direction. Otherwise could the description here be updated with decisions? Thanks!

@jeldergl I feel like there are several things I want to discuss more before we move to an MR.

Add some examples about complex content to make sure the guideline fits, especially the clickable behaviour where the most comments came in
Restructure how we categorize the cards:

basic cards
cards image
cards with graphs (dynamic graphs)
cards with actions
cards with images and buttons
cards with more complex content, such as tables, multiple actions

I am planning to work on it this Friday, still have things to wrap up today and tomorrow within my group stage.

Does this plan fit?

This really is a lot to discuss @cam.x. Do you think a good MVC would be a more general "visuals in cards" where you can address placement and scale?

Some items on the list take this out of card territory for me, like including tables. We do address multiple actions in the footer today too.

@jeldergl An MVC sounds good! There is a lot to talk about, I will focus now on basic cards, cards with images and cards with action as examples, and include basic behaviours, placement and scaling.

I will create a separate issue for others. I think someone showed me really complex card which is in the product already. @jmandell it was you? For the separate issue, we might want to prioritize relevant guidelines about what we already use in the product, such as the tables, and also what is mentioned in this comment, also has 3+ more actions per card.

I'm also at capacity this week but am happy to provide support in an MR

@gitlab-org/ecosystem-stage/foundations I have addressed most of the comments if they are not talking about edge cases such as complex layout etc. I have updated the proposal in the description area. If this is all good, next week I am going to start an MR and we can move the discussion there!

@gitlab-org/ecosystem-stage/foundations

Since no additional suggestion was added to the issue for a while. I created an MR: !2654 (closed) directly.

Anyone has time to review the MR !2654 (closed) ?

changed the description

marked this issue as related to gitlab-org/gitlab#340029 (closed)

mentioned in issue gitlab-org/gitlab#340029 (closed)

changed milestone to %14.8

mentioned in merge request !2654 (closed)

removed milestone %14.8

Hi @cam.x,

Please make sure that both a workflow label and weight are added to your issue. This helps to categorize and locate issues in the future.

Thanks for your help!

unassigned @cam.x

De-assign myself for now, I will be on parental leave for a while soon (Feb - June 2022), so I won't be able to work on it for a while. I can pick it up later if no one did during my leave ;)

mentioned in merge request gitlab-org/gitlab!98765 (merged)

gitlab-org/gitlab!98765 (comment 1117274813) is an example use case of "complex content" as card-body, in this case, it's a hoverable list. These need to take full width of the card container, so their on-hover background covers the full width, but currently the card body always has some padding.