Tag design changes

[frankieroberto]

This updates the design of the Tag component.

Design changes:

• no longer uppercase
• no longer bold
• remove 1px extra letter spacing
• increase font size to 19px
• change colours to use lighter background colours

These changes are to improve the accessibility and readability of the tag text, and to make the tags look less like clickable buttons.

These changes were originally designed as part of the 'status' component of the upcoming Task list component (#2261) – however feedback from the working group suggested these changes should also be applied to the Tag component for consistency.

[paulrobertlloyd]

While I like the current tag design, it certainly isn’t without problems; using UPPERCASE always seemed to go against general design principles and accessibility best practice.

However, there’s something that feels a little too ‘undesigned’ about this, to the extent that tags look more like selected text (which in rare situations may cause confusion).

Some ideas to consider:

• Using slightly larger padding on the left and right sides, to feel a bit more balanced
• Increasing the overall padding, so element feels less constrained (while appreciating not wanting it to appear clickable)

I had a quick play with this idea, and looked at using standard spacing values. I changed inline padding to 10px, and block padding to 5px. Also, and potentially not without side-effects, added block margin of -5px:

Before	After

Of note, adding negative top and bottom margins means the height of a table row isn’t increased if it contains a tag.

Perhaps there’s a middle ground, like 4px/8px padding and -2px negative margin. It’d be nice to see a bit more investigation done around the different options we could play with here.

[frankieroberto]

@paulrobertlloyd thanks for looking at this!

I should clarify that @steve-oconnor led most of the design work on this, following a x-gov workshop which explored lots of different options. I think the key constraints were accessibility and making the style distinct enough from buttons to not look 'clickable' (even though in the new task list component the whole row is clickable, so this is less of an issue).

I had a quick go at using your suggested spacing tweaks in the 2 contexts I think we know the Tag is most used.

Phase banner

Task list

What do you think?

In the phase banner, I think it probably stands out too much (especially as Beta means nothing to users). Although this is partly because the font size has been bumped up to 19px as it's no longer bold, but the rest of the line is still 16px. I'm not sure what we'd do about that - should there be a variant of the Tag with smaller text, just for the phase banner?

Looks ok in the task list to me, but perhaps marginally more like buttons, and maybe the margins are quite tight? I don't have a strong feeling either way though!

@christopherthomasdesign any thoughts from you and the Design System team?

[querkmachine]

My quick 2 pence:

I'm not a fan. It looks too... unintentional, for want of a better phrase.

Or, I guess, it doesn't look like it's a component that exists to serve a specific, unique purpose—it just looks like regular body text that's had a background colour added to it.

Some ideas, presented in isolation but could probably be combined if it's useful.

Mockup	Description
	Increase contrast. At the moment the text just looks a bit 'lost' in the background colour. Increasing the stroke width might help with that. Alternatively, tweaking the colours to increase the contrast between text and background might work, though we'd then risk the background becoming undiscernable to users with poor vision.
	Adding a border. Adding a border (potentially in the same colour as the text) would make it feel a bit more distinct and intentioned. Mainly taking inspiration from the NHS Design System's equivalent here.
	Adding border radius. Rounding off the corners to make a 'pill' shape would certainly make it distinct, and create a resemblence to how tags and status indicators in other UIs are often presented (e.g. notification badges).
	Something else entirely? The ONS Design System uses coloured dots and plain text to indicate status, rather than changing the colour and background of the text itself.

Admittedly many of these start veering back into the realm of 'could be a button', but I also feel that it's kind of impossible to put a box around some text and not have someone think it's clickable. I think our goal is to distinguish them from the few existing buttons found in the Design System, rather than try and divorce them from the concept of buttons entirely.

[frankieroberto]

Or, I guess, it doesn't look like it's a component that exists to serve a specific, unique purpose—it just looks like regular body text that's had a background colour added to it.

For the task list, that was arguably the intention. HMRC decided to do away with the tag style altogether and just use regular text:

Within the task list working group we reached a position of using regular text for completed tasks, and "highlighted" text for tasks yet to be completed, in order to draw more attention to those.

There was a debate about whether the task list statuses needed to use the same style as the Tag component at all. We initially deviated from the tag component styles, but the Design System working group thought they should be consistent.

I’m open to all ideas – although the Design System team get the final say!

Would be good to come to a resolution fairly soon though, as this is blocking the release of the task list component.

[paulrobertlloyd]

That’s the word @querkmachine: intention. The current proposal feels too unintentional, almost like a bit of CSS hasn’t loaded.

As to the other ideas:

• Increase contrast: I agree, I think the text still feels a bit washed out. Not sure if the text needs to be emboldened, but if there was an additional weight in the font palette between regular and bold, I’d be suggesting that. Given there isn’t, it's a case of having to choose between the 2 weights.
• Adding a border: This might be an option. Make the border too dark though, and it adds visual noise, and can affect layouts that already have a lot of borders and boxes, leading to cases of lots of nested boxes. I think I’d be playing around with options that were so faint as not to bother.
• Adding a border radius: I wondered about this as well, but GOV.UK isn’t a round corners site. That said, the icons added to the revised accordion component start to go a bit in that direction, and as I mentioned in relation to that, there are circles in the GOV.UK Crown logo.
• Something else: I’ve created a separate component in the past with a dot to the left of text, but that was more to indicate a status, whereas the tag component is used more broadly.

Which brings us on to the Phase banner. Hmmmmm, this is tricky, and starts to pull on a horrible thread of consequences. The font-size mismatch isn’t great. Options:

1. Create a small variation of the tag component (which I’ve done on a number of occasions in the past anyway) and use that – not unprecedented either as radios/checkboxes have small variation
2. Try and massage the tag component so that it works in all these different contexts, and not be too concerned that text isn’t aligned to baselines and appears at different sizes
3. Use a bespoke design for the phase banner… and congratulations you’re now redesigning three different components!

Think I’d be tempted to go for option 1.

I think my changes would be:

• adjust padding on tag component to make it feel more intentionally designed, and look less like highlighted text
• increase text contrast on tag component a tad more
• add a small variation to the tag component, and use that in the phase banner component

[paulrobertlloyd]

Looking back at my earlier suggestion for padding, I think the values I gave leaned too far towards the large (and possibly button-y) size. Have revised it to use block padding of 3px (2 less than 5), inline padding of 8px (2 less than 10) and top/bottom margin of -3px:

[steve-oconnor]

@querkmachine We did go over most - if not all - of those particular ideas, but we had specific constraints at the time and what we ended up with was voted the best option. The constraints may have shifted a little now.

All colours where contrast checked (when I did them anyway!) so that they met AA+ standards.

@paulrobertlloyd I personally prefer your second design - less buttony! Keeping them looking like highlighted text and not like buttons (as current tags do, according to user research) was a deliberate design aesthetic.

[steve-oconnor]

I still think it is better for the less important tags to go without a background colour. Most important being 'Not started', 'In progress', and '[Whatever problem]' as these are the listings that need attention. Completed needs no highlight of any kind.

[steve-oconnor]

I'm not sure where all the extra colour options came from either! 4 pairs of the designs being shared look almost identical. The original idea was to have a limited palette as each task list design we saw had a limited set of tags. If a particular team wanted to extend the palette, they could - with testing to back it up.

Each colour represents a type of tag, not a specific tag name. This should be written up in the guidance.

The green tag on one task list might be "New", on another it might be "Active". Blue might be "In progress" on one task list, "Pending" on another. Most users will not be using all the possible task lists, and where there are multiple task lists that the same people might access, that particular set should follow the same pairings pf colour and words.

[querkmachine]

@steve-oconnor Thanks for the context! This is the first time I'm seeing this, personally, so I'm not clued up on any prior considerations.

The extra colour options are to reflect the options already present in the Design System, viewable on the Tag documentation page. If we're changing the design of the component, we probably want to keep accommodating all of the existing colour options, as they might've been used by a team somewhere already.

[steve-oconnor]

@querkmachine Or it could be an opportunity to do some research on them :D

[frankieroberto]

I'm not sure where all the extra colour options came from either!

As @querkmachine corrected guessed, there are already a bunch of different tag colours, so when I copied over the colours you did for the task list @steve-oconnor, I just reused the existing colours, with the exception of "light blue" (which had to be added), and the "text colour" and "secondary text colour" ones.

Both the existing tag guidance, and the draft task list component guidance suggest using as few different statuses and colours as possible, so hopefully that would dissuade teams from using all of them at once...

[paulrobertlloyd]

This PR also adds 2 new ‘tags’, which appear heavily tied to the implementation for the task list component, without any clear indication how they might be used outside of it:

• govuk-tag--text-colour
• govuk-tag--secondary-text-colour

Perhaps this verges too far into discussion about the task list component, but do these exist because that component expects each status to use a tag? Where might you use these variations outside the confines of the task list component?

(FWIW, a broader application utility class like govuk-!-secondary-text-colour would be massively helpful, and perhaps such an addition would aid in the design/development of the task list component).

[owenatgov]

This looks technically sound to me 👍🏻 Since it doesn't impact the component API or markup in a destructive way and isn't a design change that could disrupt any design structures, visual or otherwise, that this doesn't need to be a breaking change and can go into a minor (0.X.0) change at a minimum.

Being pedantic, I would like us to clear up the commit history. Probably it can be squashed into one commit. I am in particular keen for changes to be reflected in tests in the same commit if we can help it.

[frankieroberto]

@owenatgov thanks. I'm happy to help clean up the git history and look at the tests.

@christopherthomasdesign any thoughts on the design? @paulrobertlloyd’s second iteration looks good to me.

[christopherthomasdesign]

Yeah I think Paul's second set looks good @frankieroberto I think those make them look a bit more solid – want to apply those?

[frankieroberto]

@christopherthomasdesign @owenatgov ok I've updated the pull request with the extra padding from @paulrobertlloyd’s design, fixed the conflicts with main and squashed all the commits.

I've also done another pre-release so that this preview for the PR on the design system website repo has been updated: https://deploy-preview-2733--govuk-design-system-preview.netlify.app/components/tag/

Let me know if there’s anything else to do!

[paulrobertlloyd]

Ah, nice! The new tag design will take a bit getting used to, but overall a big win for legibility and accessibility. 🚀

I’d still like to challenge the inclusion of the govuk-tag--text-colour and govuk-tag--secondary-text-colour variants however, certainly at this stage. These are coupled to design of the task list component and I can’t see a use case for these variants outside of that.

I think there could be some better, more broadly scalable options for addressing the styling of ‘non-coloured’ statuses in that component, rather than depending on these 2 specific tag variants (which I described in the discussion thread for that component).

[owenatgov]

Great work folks! As a prompt, it may we worth checking how this looks against the new typography scale. In this case, all it'll mean is that on small screens, instead of dropping to 16px it'll instead remain at 19px (with rem equivalents). I suspect that this won't be a problem based on how simple the tag component is but it may be worth checking to be sure you're happy with it and propose any necessary changes.

[steve-oconnor]

Looking good!

The only thing I'm still not sold on is the use of the grey "inactive" tag rather than the text with no highlight. The original intention was to have guidance to explain how coloured tags should be used to highlight items that need attention, plain text for items that don't require attention.

So all the inactive statuses in the example would be plain text - unless it was more important to know who was inactive rather than active, then the highlight would be reversed.

We also talked about whether or not specific words should be included in the displayed colours. People will automatically assign those words to those colours and start querying if they can change them. It hints at that in the text under "Using colour with tags" but it could be stronger.

[frankieroberto]

Re-squashed the commits and force-pushed. I think we’re there?? Anything needed for release notes etc, or do those only get written when preparing a release?

[owenatgov]

@frankieroberto Good shout! Completely slipped my mind 🙃 I reckon let's do something in the changelog now for reference and we can refine this when we get into the release notes phase of 5.0. A heading saying that the design's been updated, noting that folk's spacing may move around and then link to the PR will do.

[christopherthomasdesign]

Have had a good nosey and am all happy with it from a design point of view 👍

[frankieroberto]

@owenatgov:

let's do something in the changelog now for reference and we can refine this when we get into the release notes phase of 5.0. A heading saying that the design's been updated, noting that folk's spacing may move around and then link to the PR will do.

Done in 625532f 👍

[owenatgov]

Re-approving for the changelog entry. I'm going to follow due process and ask another dev to provide a 2nd review and then, finally, we can merge!

[frankieroberto]

🏷️ 🏷️ 🏷️ 🏷️ Big thanks to @36degrees @christopherthomasdesign @colinrotherham @owenatgov @paulrobertlloyd @querkmachine @steve-oconnor! 🏷️ 🏷️ 🏷️ 🏷️