Tag- Re-visit guidance

[vavalos5]

Follow on ticket on #3232

Who is requesting this? (add contact details here) Internal

What is the problem this ask is trying to solve? Current Tag documentation not clear + we're introducing a new variant + should use new format to simplify guidance/examples. We should re-visit and simplify guidance to specify exactly which type of tag one should use. We should make it easy enough for a product designer to quickly understand which type I should use, any limitations and behaviors so it enables them to quickly utilize and build designs.

Branch with latest design: TBD

Anatomy to form basis of documentation: https://design-system.hpe.design/components/tag?q=tag Already on DS site but could possibly be enhanced

Imported design system site page to figma to mock up edits outside of code: TBD

---

Reviewers:

• [x] Taylor
• [x] Julia

List possible consequences, involved assets and components: 1

Define MVP for this ticket (format, amount of detail, where it should live, etc):

Follow up tickets: (if necessary) 1 : #4032 2 3

Checklist (add your progress in the comments)

• [x] Review current Tag guidance and document areas of opportunities
• [x] re-build using new page template
• [x] Guidance
• [x] Gather feedback
• [x] Create a PR or new file
• [x] Ask for review
• [ ] Publish
• [ ] Communicate

[SeamusLeonardHPE]

@vavalos5 I asked Matt for some input on the exploratory file I shared with you

Question: Should we introduce variants that are more related to use case rather than purely grommet props? Response: "This is the right question. We should be defining this from the lens of "how does this thing (these things) help a user and when?" "Why and when I might need or want to use these things?" We need to answer these questions before we start talking about "types".

Would it be helpful for us to identify use cases that we later can group into types?

As a user i would like to - Be informed of metatdata related to my current view As a user i would like to - Navigate to see other data sets with matching tags As a user i would like to - Remove a metadata tag from my current selection As a user i would like to - be made aware of new features ...

[vavalos5]

Figma file Took a first stab at this @SeamusLeonardHPE We can chat tomorrow. Would love your feedback, thanks!

[vavalos5]

I've identified more use cases and have categorized them by current HPE use cases and non HPE use cases. To add, I've applied a tag type to each use case.

I've also created a matrix diagram that allows product designers to follow to help them identify on the type of tag they should use for their use case. I think i'll have to expand this a bit more to meet some other use cases though. I've sent this to a few stakeholders to follow and have received feedback but awaiting on others.

Currently there is a need for the following 3 types of tags:

• Read-only Tag
• Removable Tag
• Filter Tag

I'm proposing we change the naming of our tags due to the fact that each type we currently have on the site are all NameValues or Values and should be named more closely to what they do/use case related.

Informational (this is a new tag we're adding) previous ticket we called it assistive ----> Read only Rational: Simpler naming that explains what the tag does - it's a read only and nothing else. No interactive functionality.

Read-only tags provide users with the capability to:

• quickly identify categorized services from which data comes from
• identify metadata that is non-critical
• aware of new features and trials
• identify server settings

Name Value/ Value + "removable" ----> Removable Tag or Dismissible Tag Rational: NameValue and removable have the same styling with different use cases. Almost like a “CRUD” tag but to create, assign and remove tags.

Removable Tags provide user with the capability to:

• create NameValues or Values as categories
• assign and apply metadata to a service or product
• remove tags assigned
• select filters for a search within a global search and view my filtered item in search input field. (text into tags)

Filter Tag can stay as "filter" or we can change to "selectable" Rational: Filter tags are used for just that, filtering. Filters prompt actions, actions are prompted by buttons. Explaining that this type of tag can be selected by it's name might be easier to identify.

Filter Tags:

• are interactive
• display metadata
• can have a close icon
• can multi-select to filter preferences to tailor and personalize experience based on needs
• can be used to to filter data items within the page
• can navigate you to other tags with the same metadata

---

Other use cases that we may or may not possibly cater to:

As a user I would like:

• To indicate status of an item such as “active”, “pending”, “completed” to provide immediate visual feedback on the state of elements.
• To provide a tag based on priority/urgency such as “high”, “medium” and “low”.
• To provide see who i’m sending an e-mail to and have the option to remove if needed. (text into tags)
• To single select a group of tag items to proceed or advance in a chat.
• To single select a group of alike tag items as an alternative to a radio button or single select to select a size for example in a check out experience. Or toggle button like “ship” or “pick up” options.
• To see at a glance whether something is “in progress”, “active”, “done”, “completed” or “shipped”.

[vavalos5]

Requested guidance review on first draft from @julauxen

[SeamusLeonardHPE]

I copied in the comment form the previous issue 3232 asking for 'label' component

The aim is to check if our suggested direction for adding varinats/types to tags would cover all use cases.

1- "Will our suggested tag variants work for these requests/needs" 2- "What modifications can we make to accomplish these needs"

https://www.figma.com/design/eDmqoyxVaHbMEai2NCZHmI/%234033-Tags-questions?node-id=207-3250&t=8jt9mVyfYiAqjnts-4

I feel the guidance is headed in a good direction but we might need a group or async session to get alignment of some of the outstanding questions

https://www.figma.com/design/eDmqoyxVaHbMEai2NCZHmI/%234033-Tags-questions?node-id=265-7983&t=8jt9mVyfYiAqjnts-4

[vavalos5]

Created v2 of guidance based on feedback and tagged @halocline @taysea and @SeamusLeonardHPE

[vavalos5]

V3 has new feedback implemented. Tagged @halocline @taysea and @SeamusLeonardHPE for review. Thank you 😄

[vavalos5]

Greg reached out to me about Tag progress. Including screenshots of Greg's asks. He will be sending a design by end of week.

[SeamusLeonardHPE]

@vavalos5 can you add the link that you shared with Gregg for context.

[vavalos5]

@vavalos5 can you add the link that you shared with Gregg for context.

Yea, it was the examples on the latest guidance page + I sent the latest type definitions.

[SeamusLeonardHPE]

Added a file for final review:

https://www.figma.com/design/IiBz42hz6zRVC9g2TFMlTU/%234033-TAGS-Documentation?node-id=2-7078&t=cxia6I5vGAj9eIMp-4

[SeamusLeonardHPE]

Tagged @britt6612 for help in the existing PR.

https://github.com/grommet/hpe-design-system/pull/4079

[SeamusLeonardHPE]

Pr for review:

https://deploy-preview-4079--keen-mayer-a86c8b.netlify.app/components/tag

Couple of notes

• Missing the examples component on page for each "type" of tag before the list items describing the type.
• Brittany says there is an enhancement required to grommet to allow form gradient border - is this a blocker or should we proceed with a edited view that removed the highlight type for now?

[SeamusLeonardHPE]

@halocline @taysea

Can you review this draft

https://deploy-preview-4079--keen-mayer-a86c8b.netlify.app/components/tag

• Excluding the required 'enhancement' to create the visual gradient border for "highlight" type
• We removed reference to designer using custom colors until we have an enhanced palette

[britt6612]

@SeamusLeonardHPE @taysea @vavalos5 @halocline

Originally when I had saw the Figma file with the highlight version it had a gradient for the border. see below: Image

I jumped the gun in adding border-image property to Grommet. border-image allows us to be able to pass that gradient color to the border. However once this functionality was added into Grommet I then realized that with our Tag component we are using border-radius to make the Tag round. Unfortunately, border-radius isn't supported with border-image and it's not ideal to find tricks to obtain rounded borders having a gradient. That being said we would have to try one of the following:

1. CSS Masks
2. Using SVG for Borders
3. Box Shadow with Inset Effect
4. have background the gradient then on the inner box with the content make the background white and adjust pad to push it out to just border.

none of these are super ideal for teams to copy/paste since we would be using more css then usual in a template.

I think we need to decide if we are committing to this style then should we move forward to explore these other approaches, or should we change the design.

Taylor reviewed the PR for content so Im thinking to move this along we can take out the highlight version and then merge while we decide on what to do next.

[vavalos5]

[sad] Avalos Campos, Vicky reacted to your message:

---

From: Brittany @.> Sent: Friday, September 27, 2024 2:20:06 AM To: grommet/hpe-design-system @.> Cc: Avalos Campos, Vicky @.>; Mention @.> Subject: Re: [grommet/hpe-design-system] Tag- Re-visit guidance (Issue #4033)

@SeamusLeonardHPEhttps://github.com/SeamusLeonardHPE @tayseahttps://github.com/taysea @vavalos5https://github.com/vavalos5 @haloclinehttps://github.com/halocline

Originally when I had saw the Figma file with the highlight version it had a gradient for the border. see below: Imagehttps://github.com/user-attachments/assets/efeab426-cec0-4c79-8da9-193cb82657b9

I jumped the gun in adding border-image property to Grommet. border-image allows us to be able to pass that gradient color to the border. However once this functionality was added into Grommet I then realized that with our Tag component we are using border-radius to make the Tag round. Unfortunately, border-radius isn't supported with border-image and it's not ideal to find tricks to obtain rounded borders having a gradient. That being said we would have to try one of the following:

1. CSS Masks
2. Using SVG for Borders
3. Box Shadow with Inset Effect
4. have background the gradient then on the inner box with the content make the background white and adjust pad to push it out to just border.

none of these are super ideal for teams to copy/paste since we would be using more css then usual in a template.

I think we need to decide if we are committing to this style then should we move forward to explore these other approaches, or should we change the design.

Taylor reviewed the PR for content so Im thinking to move this along we can take out the highlight version and then merge while we decide on what to do next.

— Reply to this email directly, view it on GitHubhttps://github.com/grommet/hpe-design-system/issues/4033#issuecomment-2378277197, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AOZ5MTVEJVYUNHZHSDWFD53ZYS6FNAVCNFSM6AAAAABLI234GOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZYGI3TOMJZG4. You are receiving this because you were mentioned.Message ID: @.***>

[SeamusLeonardHPE]

Saw this as a potential workaround - but if its too hacky for grommet lets just choose a border width and color from our palette for the highlight tag.

border: double 2px transparent;
background-image: linear-gradient(white, white), linear-gradient(to right, #00E8CF, #904DFF, #F740FF);
background-origin: border-box;
background-clip: padding-box, border-box;

Note that the "linear-gradient(white, white)" would need to inherit the BG color of the page or container to work

[britt6612]

Saw this as a potential workaround - but if its too hacky for grommet lets just choose a border width and color from our palette for the highlight tag.

border: double 2px transparent;
background-image: linear-gradient(white, white), linear-gradient(to right, #00E8CF, #904DFF, #F740FF);
background-origin: border-box;
background-clip: padding-box, border-box;

Note that the "linear-gradient(white, white)" would need to inherit the BG color of the page or container to work

Yes something like this would work however just "hacky" and not the cleanest. @taysea

[SeamusLeonardHPE]

The cheapest solution is to use Light/Primary/Blue or Light/Primary/Purple

Creating a follow up ticket to refactor the existing tag component in figma

[vavalos5]

Bummer we're unable to use a gradient @britt6612. Thanks for looking into fixes.

Thanks @SeamusLeonardHPE Although it is the cheapest solution, using color, due to the fact that our colors are not accessible, these colors wouldn't work. Borders on tags should meet accessibility standards, especially regarding color contrast. There isn't a strict minimum width for borders on tags specified in accessibility guidelines.

We also state that highlight tags aren't selectable, but since they are intended for marketing purpose and to serve a purpose of "hey look at me", we should make it a priority to have sufficient contrast to be easily read by users with visual impairments despite it not being clickable.

Here are our choices:

1. We use thicker border - currently tags use 1px border, this would go from 1px to 2px but color contrast would still not meet accessibility but enhance visibility.
2. We use our new accessible color palette that hasn't been implemented in our color palette. (suggesting this route)

I've tested a few colors from our current palette and tested against our backgroundcolors in both light and dark mode and also the background-back as we're moving in that direction (see image below). The idea was to have 1 color that could be used for light and dark modes to meet criteria now rather than later. Highlighted choice is what met accessibility for all background-colors.

I also tested our future color palette that Joelle tested against our backgroundcolors in both light and dark mode and also the background-back as we're moving in that direction (see image below). The idea was to have 1 color that could be used for light and dark modes to meet criteria now rather than later. Highlighted choice is what met accessibility for all background-colors.

Will share out during designer meeting tomorrow morning.

[vavalos5]

@SeamusLeonardHPE I think the guidance was completed and we can open another ticket to look into design rather than extending this one. I'm closing and adding a different ticket for highlight type in #4227