Investigate long tags in task lists

[owenatgov]

What

Investigate the impact of long tags in task list components and apply affordances we feel are useful or necessary.

Why

During the audit of our components against the new typography scale (https://github.com/alphagov/govuk-design-system/issues/2299) we noticed that larger tags start to look a little squashed with the larger font sizes on smaller screens. It was unclear what the impact of very large tags would be on the task list and if we should force them to not break eg: using nowrap.

Timebox

half a sprint ie: 1 week

Who is working on this?

Developers, designers

Spike lead: TBD

Spike buddy: TBD

Questions to answer

• [x] How large a tag can the task list handle before it "breaks"?
• [x] Should we update the guidance to address use of long tags?

Done when

• [x] Questions have been answered or we have a clearer idea of how to get to our goal
• [x] Findings have been reviewed and agreed with at least one other person
• [x] Findings have been shared, e.g: via a write-up on the ticket, at a show & tell or team meeting

[CharlotteDowns]

Today (06/09/2023) we looked at the effects of long content in the tag component and task items within the new task list component.

Answers to questions

How large a tag can the task list handle before it "breaks"? A: It can handle long tags as long as it does not contain long words (no spaces between characters). A maximum of 30 characters split across the tag list item and the tag component is probably the maximum that the task list on 320px resolution can withhold.

Should we update the guidance to address use of long tags? A: Most definitely. We can make some css updates if needed but I think giving clear advice and awareness as to why not to do long tag names or use long words would allow our users to clearly troubleshoot implementation issues they come across.

---

First experiment

Add longer than normal text to the tag component, observing how it wraps on desktop and mobile resolutions.

Although a bit clunky visually, it did not 'break' anything else within the page.

Real service tag examples

Waiting for induction to be recorded

(36 characters) this tag has only been used in a table view and not a task list.

Second experiment

Add longer than normal words to the tag component, observing what happens on desktop and mobile resolutions.

In this experiment the column container width became larger than expected. Although on desktop words of this length probably don't exist to cause distortion, on mobile (320px resolution) long words used in both the task and the tag may cause issue.

Suggestions

Take an approach seen in earlier versions of a task list and move the tag onto a new line on smaller width resolutions.

[frankieroberto]

Just to summarise the conversation I had with @CharlotteDowns here... when designing the task list I think we deliberately decided not to stack the status labels beneath the task names on narrower screens, as it can make them harder to scan and if the tasks and labels don't contain long words, then they can fit quite happily side-by-side even on very narrow screens.

However clearly there’s a limit to this, if the screen is narrow and some of the words are very long!

Another option we discussed is forcing the browser to break the tag mid-word using something like overflow-wrap: break-word - but I'm not sure how well supported that is...

[owenatgov]

Thanks @CharlotteDowns for getting this evidence together and thanks @frankieroberto for the context. It sounds like from a design perspective, we're ok with tags getting squashed but less ok with them flowing off screen ala experiment 2.

Re: word breaking, it looks like support is fairly sound. This is amplified by the fact we'll be dropping IE11 support. I think we should do this regardless of what solution we take forward to reduce the risk of the tag going off-screen. I wonder if this is the only thing we need to do for the component itself?

Also I'll callout Char's suggestion above to update the guidance if it's not already on the cards.

[owenatgov]

I've done a quick test and I think breaking words is doable, with some light amendments to the solution.

Both overflow-wrap: break-word and overflow-wrap's alias word-wrap: break-word don't actually break the tag if it's overflowing. This is to do with the specifics of how break-word is calculated. Thankfully we have some alternatives that do work:

• overflow-wrap: anywhere (browser support)
• word-break: break-all (browser support)

If we apply both these rules to Char's second experiment above where the tag overflows, the outcome is identical:

Whilst we won't need to explicitly support IE from 5.0, I would still recommend using word-break on the basis of it's better browser support.

What do we think?

[github-actions[bot]]

Uh oh! @owenatgov, the image you shared is missing helpful alt text. Check https://github.com/alphagov/govuk-frontend/issues/3923#issuecomment-1715690396.

Alt text is an invisible description that helps screen readers describe images to blind or low-vision users. If you are using markdown to display images, add your alt text inside the brackets of the markdown image.

Learn more about alt text at Basic writing and formatting syntax: images on GitHub Docs.

[stevenjmesser]

@CharlotteDowns to review what @owenatgov's done.

[CharlotteDowns]

@owenatgov I'm happy with the tag overflow solution being word-break

[owenatgov]

We have a PR: https://github.com/alphagov/govuk-frontend/pull/4259

The next thing to do here is update the tag guidance to suggest avoiding long tags if you're able to. Looking at the guidance at the moment, I'm wondering if there's value in having a section on writing status messages as I can't think of another obvious place to put this. However, we have a section in the task list pattern guidance on what the statuses should be, maybe that's enough?

What do we think?

[frankieroberto]

We have a PR: #4259

Nice!

The next thing to do here is update the tag guidance to suggest avoiding long tags if you're able to. Looking at the guidance at the moment, I'm wondering if there's value in having a section on writing status messages as I can't think of another obvious place to put this. However, we have a section in the task list pattern guidance on what the statuses should be, maybe that's enough?

What do we think?

It’s also mentioned briefly in the component guidance (https://deploy-preview-1994--govuk-design-system-preview.netlify.app/components/task-list/ ):

If you are creating your own statuses, use adjectives rather than verbs if you are creating your own statuses. Use sentence case, and keep it short, so that it can be easily read and understood.

Is that enough or should it be stronger?

[owenatgov]

@frankieroberto That feels plenty to me. I'm happy for #4259 to therefore close this and us to commit to handling the documentation portion of the work in https://github.com/alphagov/govuk-design-system/pull/1994.

[CharlotteDowns]

@frankieroberto I think that's pretty clear. Might we be able to remove one of the 'creating your own statuses' from the first sentence so it reads a little clearer?

[frankieroberto]

@CharlotteDowns:

@frankieroberto I think that's pretty clear. Might we be able to remove one of the 'creating your own statuses' from the first sentence so it reads a little clearer?

Well spotted - I totally missed that. 🤦 Left a proposed edit here but let me know what you think: https://github.com/alphagov/govuk-design-system/pull/1994/files#r1340332277

[owenatgov]

With the PR merged, I'm going to close this issue and propose we move any further guidance chat to https://github.com/alphagov/govuk-design-system/pull/1994. Thanks both!