[UX] Improve labels system

[andersonjeccel]

Q	A
Bug fix? (use the a.b branch)	[❌]
New feature/enhancement? (use the a.x branch)	[✅]
Deprecations?	[❌]
BC breaks? (use the c.x branch)	[❌]
Automated tests included?	[❌]
Related user documentation PR URL	mautic/mautic-documentation#...
Related developer documentation PR URL	mautic/developer-documentation#...
Issue(s) addressed	Fixes #13158

Description:

This PR adds a set of new tags/label styles for devs to use while building new features.
It also changes some labels to avoid primary, warning and success being used where they are inadequate.
These tags have hover effect to improve user experience.
Aiming to provide consistency, I also added an operational tag to be triggered when .has-click-event is being used. This way, clickable tags will have a darker border color to indicate for users that they're interactive.

(company score was just the number, no styles before)

chosen (library) now follow a standard, which indicates these labels are selectable/in the context of filtering options

Steps to test this PR:

1. Open this PR on Gitpod or pull down for testing locally (see docs on testing PRs here)
2. Go to Companies > Create > Back to the list > See
3. Go to Emails > Create one, save and close > See how it appears on the table
4. Go to Contacts > Create > Save & Close > Scroll down to Filters > Add one
5. Go to Categories > Create one with color > Back to list and see
6. Go to Assets > Create one > Assign the colored category > Back to the list and see
7. Go to Campaigns > Create one > Assign the colored category > Back to the list and see
8. Go to Dynamic Content > Create one > Assign the colored category > Back to the list and see
9. Go to Forms > Create one > Back to the list and see the Submissions count
10. Go to Contacts > Import > Select a file > Proceed with the import > Select to import in the background > Then go to the imports list to see the labels
11. Go to Points > Triggers > Create new > Back to the list to see its color

[RCheesley]

Thanks for the suggestion on the rounding of corners more uniformly. I'm on the fence as to whether rounding is preferential to squared corners, but putting that to the side, some general points I noticed:

I think these should be centre aligned instead of left? In both Contact and Companies list view.

Also on contact profiles in the tabs:

Also, the tag text seems a bit misaligned with the closing cross icon? (May have always been like this but I notice it more with the rounding)

I noticed that form results still seem to use the old style:

Also landing pages is the same:

I found this random blob of colour which I first noticed in points triggers (which I found represented the contact colour) quite confusing, as it was almost like it was meant to be a label (given its shape) but there was no text. Maybe this shouldn't be rounded? I feel the same about the Categories list, given there's no column header in either view it's a bit ... weird?

[andersonjeccel]

Tasks

• Check why text alignment is present only on dev environment
• Check which classes and libraries have been used in contact profile
• Change Results from xs buttons to operational tags for Forms, Landing pages, Segments and other relevant listings
• Check additional classes used to represent entity color
• Standardize elements and classes used for entity colors on all tables (Twig templates)
• Make sure entity colors are easily distinguished/probably a perfect circle

[LordRembo]

The view contact # is distorted on the company listing page.

@andersonjeccel It would be best to prevent line breaks within individual tags, eg. using white-space: nowrap; That should force tags to be 1 single line and the column to stretch to accomodate.

[LordRembo]

I added a comment to one of the committed files. Basically, some of the labels in cells do have white-space: nowrap, other do not. Would be best to check all the twig files with labels in cells, and fix the ones that are missing.

[shinde-rahul]

LGTM!!!

it seems there are color changes as well for the background.

Thank you @andersonjeccel!!!

[shinde-rahul]

While testing this, I found an issue with the Lead and Segment listing pages. The problem is that the action drop-down disappears when selecting all or a few from the list.

• When nothing is selected
  
• When selecting all
  
• When selecting a couple of contacts
  

Here is the short video as well:
https://github.com/mautic/mautic/assets/1046788/8f7e73a1-c938-4438-92e7-917f2a015357

@andersonjeccel, I'm not sure where to post this issue, as it was not there on the 5.x.

[andersonjeccel]

@shinde-rahul This disappearing bug is fixed on another PR, I’ll mention you there!

[LordRembo]

A thing that's been bothering me, is the structure and naming of the css classes. These should be named after their function (as design systems usually do), rather than the style they add. Eg. before this, you had a base class 'label' and variants were something like 'label-danger' because it suggests a level of importance.
Using colors for names, makes it impossible to later introduce any kind of customization or even making a dark theme version without either mis-naming the colors, or having to replace the color property in all elements that use that variable instead of just changing the value of the css-variable.
The order of the words is also important, as you should be going from most generic/general, to least generic (eg. inlabel-danger, the variant goes at the end and the standard name at the beginning). Consistency like this is important.

So I suggest looking at how many variants there are, what their purpose is and thinking of (simplified) functional variant names as much as possible. Depending on how complex the variants are, it could just be tag tag-01 tag tag-02 etc… but it could be more descriptive (like levels of importance eg. tag-level-1). It could be the tags are named after their source eg. tag-contacts tag-segments and so on.

Looking at the CSS variables, there's a dozen color variants, which seems like a lot. If you really need a rainbow of colors, you would use 2 lists:

• generic color names, eg. color-teal color-teal-border` etc…
• the tag referencing variables eg. --tag-contacts or --tag-level-01, which then references to the generic color variable: var(--color-teal). You can be even more generic, if the same color is used on a lot of elements. Eg. in the past, I've used color-primary and color-secondary when working with a stylguide. But depends on how many variants you have of course. Could just be numbered or named after something else.
  That way, you can easily override just the tag variable when a color change is needed and don't have to touch the color variables. Eg. if you have a dark theme, and there is a dark blue tag that needs to be light blue or an entirely different color, you change the color reference in the tag variable: --tag-contacts: var(--color-dark-blue) becomesvar(--color-light-blue).

[andersonjeccel]

@LordRembo
Thanks for pointing the tag vs label standard, I've committed a fix.

Since this PR extends the labels system, it's adding exclusively 2 enhancements:

• More colors, neutral, not related to dangerous situations or states like these. So the main focus is to avoid devs using HEY THIS IS A STRONG YELLOW WARNING LABEL ON THE ROW BECAUSE... 20% of the leads had read this email. This is why we're using new subtle colors, while keeping the original label-success, label-warning, label-danger etc for appropriate moments
• A differentiation of clickable labels vs read-only ones, so people know when to interact or not

---

Regarding light/dark theme, these variables are magical.

Light theme, the default look:

:root {
  --label-background-red: #ffd7d9;           // a kind of red
  --label-color-red: #a2191f;
}

Dark theme, which can be set appending color-theme="dark" to the <html> attributes like <html color-theme="dark">. When this happens, another set of rules overwrite the default ones, activating the dark theme:

:root[color-theme="dark"] {
  --label-background-red: #a2191f;         // another kind of red but for dark backgrounds
  --label-color-red: #ffd7d9;
}

This can be achieved through JS by watching a button for click event, then appending the attribute and saving the user preference on the browser's local storage.

All variables have the same name on both themes, but since the color-theme="dark" attribute appears, everything comes dark because of the order they're placed on the CSS. This way we avoid creating specific classes for each element, or creating a different set of variables or having to build a complex replacing tool.

The approach above is what makes the dark theme possible while keeping the cleanest code possible, so you don't need to modify the tag variable when a color change is needed and also don't have to touch the color classes, only add the attribute to the HTML and the CSS system will do everything for you, automatically, on literally the entire interface.

What do you think about this perspective?

[RCheesley]

I came back to re-test this but it looks like now we don't have any colours at all, is that intended?

[andersonjeccel]

@RCheesley

Now it's working, forgot to change classes after Rembrand request, sorry

[LordRembo]

@andersonjeccel I can see how you'd change specific colors based on, for example, there being a dark mode, that's fine. The situation that this does not address, is if these colors don't exist in a variant or rebranded theme.

Example:

.label-mautic-blue {
      border: 1px solid var(--label-border-mautic-blue);
      background-color: var(--label-background-mautic-blue);
    }

Using color-named variables and color-named classes to style elements directly is asking for trouble. If anyone starts customizing themes (eg. branding a Mautic for Coca Cola, for example), and they don't use blue, you need to either rename the classes and the variables, or set colors that don't match the name. (eg. label-border-mautic-blue is actually a kind of red color for the Coca Cola branding). For that reason, any functional item, like a label, messages, … should have classes named after their function + colors set using a functional or more generic name.
In a lot branding-related situations, you'd design using a stylebook and have a list of 2 or 3 or more base colors that reoccur across the site. So you'd give them a name based on their importance (eg. 'primary', 'secondary', …) or you assign them numbers, levels, variations, …

.label--primary {
    border: 1px solid var(--color--primary-border);
    background-color: var(--color--primary-background);
}

By default, that border color, could be blue, so you have this in :root -> color--label-primary-border: var(--color-mautic-blue). If someone then does a rebranding or a variant theme, you only need to override 1 color variable: color--label-primary-border: var(--color-mautic-red)

You can still maintain a long list of color variables to use, but you need another variable inbetween the original color and the class it will be used in, that has a more generic or functional name. And similarly, you should have a functional class name.

Right now you have about 4 or so label classes that are actually in use, so I'd suggest renaming those to be functional/generic and using 'intermediate' variables names, as I explained. All the other label classes that are not in use, can be removed. Keep the color variable names for use when new (functional) class names are needed.

[LordRembo]

See comment above

[andersonjeccel]

@LordRembo now I got what you mean

I’ll commit a fix soon