Element-web/desktop 1.11.41 nickname & default avatar colors changed to way bright in dark theme

[olmari]

To reproduce the "comparison":

1. Observe "matching" dark'ish nickname colors on Element-web/desktop at version 1.11.40
2. Update Element to 1.11.41
3. Observe those colors being way too bright for dark theme

What did you expect?

Generally dark theme nickname colors being as they were earlier, or even more generally being at least dark in dark theme.

What happened instead?

Nickname colors being too bright.

There is some changes done in 1.11.41 regarding nickname coloring, currently apparently mainly in matrix-org/matrix-react-sdk#11470 and further in light theme .pcss /~https://github.com/matrix-org/matrix-react-sdk/pull/11470/files#diff-25d914aa3cafa5e681d885720f022d1715020b4d521da2d34954cd74650e2f9e

Issue is that dark theme doesn't define own definitions but inherits the light theme ones as the best I can tell, but now the nickname color are way too bright for dark theme.

Old version:

New version:

[Sancus]

This change also reduced contrast in dark mode which seems to make accessibility worse.

[IF-Adin]

@Sancus Confirmed, the accessibility is awful. It is very hard to read now.

[rda0]

I have troubles distinguishing between nick colors or between nick colors and white message text on my screen. Please restore the old colors.

[nadonomy]

Echoing the discussion from the Element Design room into this issue too:

• The new colour palette is generated using Adobe Leonardo, which has some of the best perceptive colour contrast science and thinking and application. The accessibility complaints (in the technical, contrast sense) are a bit of a misnomer - more likely it's legibility.
• We definitely won't revert to the old palette or maintain the old functionality under flags or settings or similar. It's unsustainable and needless debt. The new palette is part of a wider push for accessibility. If you do have really individual needs, like using a specific palette, it's probably best to maintain this in a theme.
• The feedback on the colours feeling too neon is noted. We're monitoring a bunch of different feedback sources, including this one, and the input really is heard & helpful. We'll iterate on the hues we're picking from the new palette based on continued feedback - but we need to observe to gather wider feedback, over time, from multiple sources.

[olmari]

While there are multiple things that has changed at same time in the background, for me personally all I really care for is that nickname colors in dark theme would not be this screaming light, one could argue they're less readable now because of that. What exact colors used I don't kind of care, but dark should be not light ;)

[IF-Adin]

@nadonomy It's really refreshing to see a response to users that complain about not able to access your stuff properly by correcting their use of words. Something needs to be legible to be accessible.

And i don't care if the pope made that color palette, it's awful.

[nadonomy]

@nadonomy It's really refreshing to see a response to users that complain about not able to access your stuff properly by correcting their use of words. Something needs to be legible to be accessible.

No intention to correct anyone else's words. This issue tracker is the canonical place we work from, and the distinction is really important for the team working on this. In the context of colour in content - claiming something to be inaccessible has an exact, technical meaning - that it's failing the specified colour contrast ratios. This isn't true.

[tsukasagenesis]

The fact is, you decided to change a 3 years old dark theme color by a new one, and then dismiss people complain about the change and saying it's all for the best, it follow some "best perceptive colour contrast science and technology", did you made a pool or something about it to confirm this ?

Honestly it's difficult to read now, background is gray (not black), name are grey color, and I did try to revert to old version but got auto update ...

[nadonomy]

and then dismiss people complain about the change and saying it's all for the best

on this specifically - just to re-iterate from my previous comment:

The feedback on the colours feeling too neon is noted. We're monitoring a bunch of different feedback sources, including this one, and the input is helpful. We'll iterate on the hues we're picking from the new palette based on continued feedback.

Again - the input is helpful, and not dismissed. We expect to iterate on things like this. But we do so by monitoring multiple feedback sources over time.

[IF-Adin]

@nadonomy So wait, you are forcing this on us without allowing an alternative, until it works right? That's the plan?

[tsukasagenesis]

A/B testing / pool ? Or make the change in a new beta design maybe (since you already support some theme il labs) ? Just saying their is other option than force change to every users ...

[nadonomy]

@nadonomy So wait, you are forcing this on us without allowing an alternative, until it works right? That's the plan?

@IF-Adin This comment isn't really constructive. I've explained the source of the changes, recognised the feedback, indicated that we'll monitor for more feedback and iterate based on a more rounded view. I would indicate some kind of timing but it depends on the temperature of feedback from multiple sources, overall bandwidth, and scheduling.

If you need an alternative or a specific palette, per this comment it sounds like theming or rolling an older version might be your best bet while the above plays out. It's non official but a member of the core team deploys Element Web versions to https://riots.im/ - if you don't want to self host and want to stay on an older version that could be another option for you.

A/B testing / pool ?

We don't split test stuff like this - mostly to preserve privacy in decentralised/self hosted environments.

[tsukasagenesis]

We don't split test stuff like this - mostly to preserve privacy in decentralised/self hosted environments.

Like what ? The app chose locally on 10% of the time to apply the new theme, store the odd on locak storage/cookie like you probably already do ? What privacy could possibly leak ? legitimate question.

If you need an alternative or a specific palette, per #2046 (comment) it sounds like theming or rolling an older version might be your best bet while the above plays out.

on this specifically - just to re-iterate from my previous answer:

Honestly it's difficult to read now, background is gray (not black), name are grey color, and I did try to revert to old version but got auto update ...

see this can be done but not easy

[nadonomy]

We don't split test stuff like this - mostly to preserve privacy in decentralised/self hosted environments.

Like what ? The app chose locally on 10% of the time to apply the new theme, store the odd on locak storage/cookie like you probably already do ? What privacy could possibly leak ? legitimate question.

For sure this can work for some stuff. From there though, figuring out how to analyse the different cohorts in a privacy preserving way then becomes challenging. For quantitive analysis the metrics would need to be phoned somewhere. For qualitative analysis (e.g. prompts/surveys) again that needs to go somewhere.

It can be done, but it takes some great care to avoid pseudo anonymization, and so on. Also there other things to consider, like users expectations when they use the app cross-platform, and whether the ROI for all of the above is worth it in the first place, depending on the feature and general risk.

[tsukasagenesis]

@nadonomy I dont think the information about which theme you like need that much of consideration about anonymization honestly, their is nothing "private" about this data.

Anyway I will download an old version and block the update, have to download the exe from a side website since it's not available on element/riots.im, thanks for your answer nevertheless, will see with time how many people dislike this change or not.

[nadonomy]

@nadonomy I dont think the information about which theme you like need that much of consideration about anonymization honestly, their is nothing "private" about this data.

It's not so much the data on it's own, but what happens to it afterwards.

Anyway I will download an old version and block the update, have to download the exe from a side website since it's not available on element/riots.im, thanks for your answer nevertheless, will see with time how many people dislike this change or not.

👍. Thanks for discussing in good faith! For sure we'll iterate on all of this, but we also need to take a wider, more balanced view than the one we can get from GitHub issues alone, so the course of action isn't as simple as immediately reacting & implementing based on passionate discussion here.

[rda0]

The new colour palette is generated using Adobe Leonardo, which has some of the best perceptive colour contrast science and technology available. So, the accessibility complaints are a bit of a misnomer - more likely it's legibility.

OK, but for me (and others that I know of) this change effectively reduced the color contrast on the computer screens.

We definitely won't revert to the old palette or maintain the old functionality under flags or settings or similar. It's unsustainable and needless debt. The new palette is part of a wider push for accessibility. If you do have really individual needs, like using a specific palette, it's probably best to maintain this in a theme.

Thank you for the suggestion to use a theme to fix this. I think this is a very good idea. There is probably no solution that works for everybody and there will always be people who have other visual preferences or needs as in element-hq/element-web#14651. It would be best if theming becomes a stable feature, but custom themes are currently behind a Labs flag and there are some other open issues:

• Document the new theming attributes (please 🙈) element-web#20342 The theming docs should be updated. Some o f the mentioned files do not exist, some custom theme properties have no effect, some are missing.
• Better theming documentation element-web#18741
• fix theming by no longer hardcoding color values, and switching to new default font element-web#17348 Hard-coded color values

I tried to recreate the previous look using a custom theme. Add this to the config.json, enable feature_custom_themes in labs and enable it in Settings > Appearance:

"setting_defaults": {
    "custom_themes": [
        {   
            "name": "d4rk",
            "is_dark": true,
            "colors": {
                "accent": "#129a78",
                "alert": "#fd3e3c",
                "links": "#4187eb",
                "secondary-content": "#808994",
                "tertiary-content": "#646b75",
                "quaternary-content": "#3c3f44",
                "quinary-content": "#26282d",
                "system": "#1d1f24",
                "panels": "#1d1f24",
                "strong-input-border-color": "#656c76",
                "accent-color": "#129a78",
                "primary-color": "#4187eb",
                "warning-color": "#fd3e3c",
                "sidebar-color": "#1a1b1e",
                "roomlist-background-color": "#1d1f24",
                "roomlist-text-secondary-color": "#61708b",
                "roomlist-highlights-color": "#282a2f",
                "roomlist-separator-color": "#101317",
                "header-panel-text-secondary-color": "#c8c8cd",
                "timeline-background-color": "#101317",
                "timeline-text-color": "#ebeef2",
                "timeline-text-secondary-color": "#808994",
                "timeline-highlights-color": "#26282d",
                "username-colors": ["#368bd6", "#ac3ba8", "#03b381", "#e64f7a", "#ff812d", "#2dc2c5", "#5c56f5", "#74d12c"],
                "avatar-background-colors": ["#ac3ba8", "#0dbd8b", "#368bd6"]
            }
        }   
    ]   
}

It is close to the old original, but some details are not possible because of missing variables or hard-coded colors. Unfortunately it is not possible to override some values only (such as username-colors), most of them need to be defined in the custom theme.

Some variables appear to have no effect or I could not find where they are used:

                "primary-content": "#00ff00",
                "system-transparent": "#00ff00",
                "background": "#00ff00",
                "panel-actions": "#00ff00",
                "roomlist-text-color": "#00ff00",

• input-border-color is hard-coded and wrong color (probably from the light theme)
• inlinecode-border-color and inlinecode-background-color are hard-coded
• avatar-background-colors has no effect

For reference:

• I found the undocumented variables in /~https://github.com/matrix-org/matrix-react-sdk/blob/develop/res/themes/light-custom/css/_custom.pcss

Update:

• I think the actual username colors were "username-colors": ["#4187eb", "#c560cf", "#129a78", "#f4427d", "#da670d", "#0093be", "#9171f9", "#389b20"],

[WolfspiritM]

My color is completely different now and in conversations I always think I've a new message.
Especially confusing is that a friend has now a similar color I had before and I have now a color he had before.
Blue just became purple and purple became blue for example...

I always think I got a new message cause I got used to my color...

The reason is that the hashcode way that was implemented before worked differently.
(I still hope that there will be a way to set a custom color someday... (for everyone to see))

I think the old way was better cause it prevented someone with "misspelled" username to impersonate someone else. The new way produces the same color no matter in what order the letters are:

[CsatiZoltan]

I am coming from element-hq/element-web#26155 (comment). With the new theme (Element web, Element version: 1.11.42, Olm version: 3.2.14, Firefox 117.0, Linux), there is little contrast between the avatar background and the dark theme colour. Here is the same avatar in light and in dark mode:

[Sancus]

Echoing the discussion from the Element Design room into this issue too:

* The new colour palette is generated using [Adobe Leonardo](https://leonardocolor.io/), which has some of the best perceptive colour contrast science and technology available. So, the accessibility complaints are a bit of a misnomer - more likely it's legibility.

This seems to be relying on contrast ratios. Unfortunately, increasing contrast ratio on Dark Mode doesn't universally improve legibility. People with astigmatism(and certain other conditions) have greater difficulty with brighter colors on dark backgrounds due to it causing haloes around the text. The result is you need a contrast ratio somewhere in the middle for best legibility in these cases.

That said, I think it's reasonable that no colors can possibly work for everyone and that theming is the correct long term solution.

[CsatiZoltan]

All right, I am not a color scientist and I believe that it's the "best" based on whatever measure Adobe uses. But what about offering a way to the user to change the palette?

[nadonomy]

This seems to be relying on contrast ratios. Unfortunately, increasing contrast ratio on Dark Mode doesn't universally improve legibility. People with astigmatism(and certain other conditions) have greater difficulty with brighter colors on dark backgrounds due to it causing haloes around the text. The result is you need a contrast ratio somewhere in the middle for best legibility in these cases.

@Sancus Thx for the tip off with this medium article. The colour saturation is already lower in the base colour themes, but I think we have more work to do here. If you know of any other interesting resources please do share!