Bad user experience with long tags

[briancoburn]

The HPE Tag spec allows 128 characters for the Tag name and 256 characters for the Tag value. Longer Tags that approach these limits can cause ui problems and lead to a bad user experience.

Expected Behavior

Minimally, the Tag component should accept props for a character limit. If the limit is exceeded, the Tag component should truncate the characters exceeding the limit and display the entire string in a tooltip. Another approach would be to allow a user to override the internal Text elements in the Tag by passing their own custom elements as props.

Actual Behavior

See attached screenshot. For very long tag names, it might overflow the viewport and the user cannot even see the tag value. In the attached image, the Tag has white-space: no-wrap and width:fit-content styles applied. Without these, sometimes the Tag width matches that of the container rather than the content, and creates awkward line breaks that can result in a tag spanning many lines.

URL, screen shot, or Codepen exhibiting the issue

Steps to Reproduce

Create a Tag with a very long name(128 characters) and a very long value(256 characters). Put that Tag in a width-constrained container such as a cell in a Table Column. Note the Text elements in the Tag overflow the enclosing container

Your Environment

• Grommet version: 2.32.0
• Browser Name and version:Chrome 114.0.5735.133 (Official Build) (arm64)
• Operating System and version (desktop or mobile): Mac OS Monterey 12.6

[jcfilben]

Hey @briancoburn thanks for raising this issue! Could you share a use case where you do end up with really long tag names and values? I think seeing an actual use case will help us determine if this is something that is frequently happening as well as how best to handle it from a user experience perspective.

[briancoburn]

hey @jcfilben - the image I included demonstrates the issue. The use case is that we need to support the HPE tagging standard, which says we must support 128 character names and 256 character values for the Tag. The attached image shows what that looks like should the user create Tags with really long names and/or values. We don't yet have data as to how frequently this might occur, but the issue is that we need to allow the user to enter these long names and values, and if they do, it can break the ui. If the Tag component took props which allowed the name and value to be truncated and show a tooltip, the issues shown in the attached image could be avoided.

[samuelgoff]

Is there a consensus on what specific direction this solution might take? During Office Hours just now, I volunteered my team as tribute to help address this issue. We just need to understand which approach is preferred.

[samuelgoff]

Hey @briancoburn thanks for raising this issue! Could you share a use case where you do end up with really long tag names and values? I think seeing an actual use case will help us determine if this is something that is frequently happening as well as how best to handle it from a user experience perspective.

Hey @jcfilben the use case is the HPE tagging standard & back-end API support names up to 128 characters & values up to 256 characters, therefore we need to assume it will happen & design accordingly.

The most common use case for us (& many other teams, I would assume) is to display Tags inside a DataTable. This is what @briancoburn's screen grab demonstrates.

I would go further than simply saying this is bad UX. It actually is possible to break the overall UI by allowing the Tags to be used as-is, because the data can & will contain strings of this length.

[jcfilben]

Hey @samuelgoff thanks to you and your team for volunteering to help out on this issue!

Currently the theme structure for the Tag component has theme.tag.name and theme.tag.value properties, both of which accept any Text props. However, if you try to pass truncate as a prop, it will not work as demonstrated in this codesandbox. I think if we can get the theme props to work in such a way that if theme.tag.name.truncate = true and theme.tag.value.truncate = true the tag should truncate the name and value evenly so that the content fits within the width of the tag container. Note we should also support setting theme.tag.name and theme.tag.value to 'tip' to show the full string in a Tip.

I also think there is value in having a truncate prop at the Tag component level. This prop could be a boolean or set to 'tip' so that truncated content is shown in a Tip.

Hope that gives some idea of the general direction the team is envisioning. Happy to chat more on this.

[samuelgoff]

hey @jcfilben thanks for the feedback 🙏🏼 I've asked @briancoburn to look into this. Now that you've given us some more specific direction, I think this simplifies the process significantly. I'll let him direct any questions to you & team as necessary.

[MikeKingdom]

I'd definitely suggest we consider a truncate prop.

[samuelgoff]

Hey @MikeKingdom I agree with you. This shouldn't require the added complexity of passing in more complex props, & I don't think it makes sense to require the granularity of control that @jcfilben is suggesting. Simply adding a truncate prop to the component makes it possible to limit the complexity of the contract while giving the component what it needs to do. If it's an all-or-nothing sort of toggle, the logical behavior is that if there is any truncation going on, then the non-truncated text -- of both name and value -- should appear inside a Tip that is auto-generated by the Tag component. I don't think it makes sense to create the ability to truncate without being able to display the non-truncated value in this context.

[jcfilben]

I think mirroring the API we have for Text's truncate prop where we allow a boolean or 'tip' to be passed makes sense to me since this is a pattern we are already using and is documented. If we made it so Tip's truncate prop only accepted a boolean and the truncated string was always shown in a Tip we would box ourselves into this pattern since we must maintain backwards compatibility. Down the road if we realize we do want to support an option where the tag is truncated but not shown in a tip the API surface would get messy and also would not align with the other places in the codebase where we have a truncate prop.

[halocline]

And @jcfilben beat me to it. Posting my reply as well.

Hmmm... what I read was "keep the prop on Tag consistent with Text's truncate." I think there is value to keeping the API consistent for both a callers' point of view and from implementation/maintenance standpoint.

As follow on, for HPE apps does it make sense to to have truncate with tip the default behavior? If so, then the theme work would also be needed. If not, the responsibility will be on the caller for each instance.

[samuelgoff]

I think mirroring the API we have for Text's truncate prop where we allow a boolean or 'tip' to be passed makes sense to me since this is a pattern we are already using and is documented. If we made it so Tip's truncate prop only accepted a boolean and the truncated string was always shown in a Tip we would box ourselves into this pattern since we must maintain backwards compatibility. Down the road if we realize we do want to support an option where the tag is truncated but not shown in a tip the API surface would get messy and also would not align with the other places in the codebase where we have a truncate prop.

It should be noted, however, there is an important difference between the Text vs Tag: Text is 1 field of data, so the Tip only needs to include 1 field of data. Tag includes 2 fields of data -- each of which need to be truncated separately -- whereas the Tip needs to include both fields of data, combined.

As long the default behavior is to handle it this way, without the caller having to define this behavior, I would have no objection.

[MikeKingdom]

There's risk someone may really really only want to truncate the label or value but not both, however I'm going to argue a single prop should affect both and hopefully 99% of the time only 1 of those will end up getting truncated.

The typical risk of simplicity versus less typical cases...

[halocline]

There's risk someone may really really only want to truncate the label or value but not both, however I'm going to argue a single prop should affect both and hopefully 99% of the time only 1 of those will end up getting truncated.

The typical risk of simplicity versus less typical cases...

Agree. Let's let use cases drive the need. With proposed approach, we are not boxed in and have the ability to extend if needed in the future.