Disambiguate label component from buttons

[lyubomir-popov]

Pattern to amend

The styling of the label component is too close to buttons, as flagged in this issue: https://github.com/canonical-web-and-design/ubuntu.com/pull/7741

Consider making them more distinct, e.g. by not using round corners, etc.

Previous design discussion for reference: https://github.com/canonical-web-and-design/vanilla-squad/issues/587

[spencerbygraves]

@cassiocassio @lyubomir-popov @clagom

In relation to the comments over here, the component labels were designed to be used in Vanilla docs, although we did use one recently for the "beta" label in Jaas, for speed really.

In that context there wasn't much need to make them different to buttons. I guess inevitably these will be used in other places though.

If we want these to be used more widely we should look at naming, which is currently specific to vanilla components:

• new
• deprecated
• in progress
• updated
• validated

I think "certified" and "verified" would need to be different to these.

[spencerbygraves]

Actually, we shouldn't lose these categories as they are serving a purpose.

If we need labels for wider use that can be something new.

[lyubomir-popov]

the uses outside of vanilla that I've seen are:

• affirmative / reassuring highlights
• beta versions of software

In some cases, an icon might help explain the purpose, so maybe labels should support icons? In most cases, exact colour doesn't matter, as long as it roughly matches - affirmative could be any shade of green or blue for example

in some rare cases (CVEs)? a qualitative palette of non-semantic colours might be needed, just because of the number of colours required. Ideally, a label should be able to accept such a color.

[lyubomir-popov]

Another use

[bartaz]

Github in their beta design go back to rounded times of web 2.0 with full rounded ('chip') labels:

[matthewpaulthomas]

(The GitHub beta design also greatly increases the roundedness of buttons, and flattens them too, so I’m not sure labels are any more distinct than they were before.)

the uses outside of vanilla

For UA renewals, we added a “Renewed” label next to the newly-extended end date, which was possible because it mapped well to the “updated” class.

in some rare cases (CVEs)? a qualitative palette of non-semantic colours might be needed, just because of the number of colours required. Ideally, a label should be able to accept such a color.

Yes, there were a few reasons we didn’t use labels for either priority or status, and one of them was that there weren’t enough distinct classes.

A couple of goofy ideas for making labels look less like buttons:

(For the second one I’m thinking of perforated label rolls.)

One more thing to consider is whether we can convey whether a particular label is clickable (as I just now discovered GitHub’s are). Probably labels that are clickable should look more like buttons than labels that aren’t clickable.

[lyubomir-popov]

• Validated
• In addition to @matthewpaulthomas 's label exmaple, @cassiocassio proposed matching the obliqueness of the ubuntu italic typeface
• benchmarking: https://semantic-ui.com/elements/label.html
• sufficent distinction between chips and labels, chips and buttons
• consider dismissable / clickable / non-clickable labels

[anthonydillon]

Could you add a link to what was validated?

On Mon, 13 Jul 2020, 13:55 Lyubomir Popov, notifications@github.com wrote:

• Validated
• In addition to @matthewpaulthomas https://github.com/matthewpaulthomas 's label exmaple, @cassiocassio https://github.com/cassiocassio proposed matching the obliqueness of the ubuntu italic typeface
• benchmarking: https://semantic-ui.com/elements/label.html
• sufficent distinction between chips and labels, chips and buttons
• consider dismissable / clickable / non-clickable labels

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/canonical-web-and-design/vanilla-framework/issues/3126#issuecomment-657543385, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKZDHQZDKUDTLL6T4O47ADR3L73JANCNFSM4N6GZRGQ .

[lyubomir-popov]

@anthonydillon no design to link to yet, we'll iterate based on the comments above.

[lyubomir-popov]

Another example from charmhub:

Mixed usage (some interative, others not) is also likeley, so it needs to be considered as part of the issue.

[spencerbygraves]

@clagom @cristinadresch can we also assign a UX designer to this when we do the work please. It would be good to cover all the types of label we need.

[clagom]

Let's discuss in planning

[rayito]

From 3800

After a workshop with @ziheliu214 @bartaz @lyubomir-popov @clagom and @wgx we decided the following:

• The "Label" component (.p-label) is going to be deprecated.
• The "Chip" component will take the place of the labels, with a rework and new styles.
• A new "Badge" component will be included for the simple, numeric labels.

Regarding the new Chips, the variants would be the following:

• Static chip
  • With icons
  • With numeric badges
  • With icons and badges
• Interactive chip
  • Hover
  • Toggle select (on/off).
  • Click

[clagom]

Include #3202 @rayito to work on the specs and discuss use-cases in design assembly. @lyubomir-popov to work on the visual

[ziheliu214]

@rayito Hi since the visual issue was completed (https://github.com/canonical-web-and-design/vanilla-framework/issues/3980) what's the next step?

@lyubomir-popov and I think its good to have a small documentation to classify "badges" and "chips" following the workshop decision. And some behaviors should be captured e.g. the number badge becomes "K" when its greater than 999 etc