DC Desktop default chat avatar colors

An old friend, artist programmer, saw the default avatar DC Desktop shows for chats(when no one has set an image) and said the colors don’t look good. He said something about “saturation”. I don’t have access to him anymore. But I also think the default colors are not good.

image

For instance in the image above, the first one from top really looks bad. The two other are better but not still very good. I can just say if it looks bad or good. But I can’t say what is the problem with these colors, and that how we can fix them.

I think that’s subjective. But it might make sense if users could choose the background color and the color of their nickname themselves. For example, my name is dirty brown, which I don’t like. :joy:

Why is the “G” of your lowest profile shifted so far upwards?

I’d say tell your contacts to set an avatar image.
Also colors are the same on all platforms and generated from the contact’s identity/address.

1 Like

But it is dirty brown! :sob:

the colors are generated by some standard even, see Implement Consistent Color Generation (XEP-0392) by link2xt · Pull Request #2228 · chatmail/core · GitHub

while there are always better or worse colors, they’re pretty good in general, esp. if you look at the number of colors.

before, we had some manually curated colors, they might have been nicer when looking at a single one, but not overall.

also note, the colors need to fulfil quite some criterions: contrast to black and to white, work as a text-color on light and dark backgroound, being noticable on a map and harmonize together while being different enough. tweaking a single parameter for some presentation (eg. “saturation”) will have drawbacks in other parts

there are not really plans to iterate here.

as pointed out above - if one is not happy with ones color, set an avatar.

My complaint was not 100% serious. :slightly_smiling_face:

1 Like

Related to UI issues with default avatars, I noticed the avatar with letter X looks like the “cancel” button, which can be confusing because the first reaction to seeing an avatar any time with letter X is to think it is the cancel button. Stylizing the letter X could solve this issue, but people can also set an avatar as it has been pointed out, so it might not be worth addressing if there are more important things to work on.

We use XEP-0392: Consistent Color Generation with saturation set to 100% and lightness to 50%. Lightness cannot be easily changed because we then need to set it to different values for dark and light theme, while 50% always looks good. Saturation can indeed be reduced.

You can play with it on https://www.hsluv.org/, set L to 50%, S to some value (currently it is 100%, but we can set it to 50% or 70% if it looks better) and then make sure it looks good for all values of H which we don’t control.

I played a bit with it, and even with 75% saturation it looks worse to me. It also affects the color of the names displayed in group chats and as the names turn greyish it is more difficult to read them on white background.

Another problem with fixed colors is, that if you have similar colors in one group, let’s say green and slightly darker green, you can not distinguish the paths in the location service. I know a case were someone keeps creating accounts to get a unique group color to be able to get another color for its location line. :grin:

How about making the default avatars a hash of the key or key fingerprint, not the username? Even the most ignorant user would then rightly suspect, when the avatar changed, that they were talking to a different person.

Separately, another programmer-artist made a program to hash forum usernames to pictures of cartoon cats, subsequently extended to hash usernames to birds (also in Rust), and to hash usernames to foxes, squid, and abstract art. These seem to have about 15 bits of entropy. Not enough to avoid malicious collisions, but enough to avoid almost all mistakes.

I highly support such a change here. Tho I’m not sure about which animal, or if it should be an animal at all :slight_smile:

And I certainly think the current system is not good. Not the colors nor the font there. The colors aren’t good looking. I’m not an artist to answer why. I think for the first step, changing the current color generation thing to support more colors, and pretty ones.

I’m not sure about opinion of DeltaChat team on this. I’m no longer a team member but rather an outsider who cares. r10s has already given a negative vote. And if I had a vote, I would have a very positive one.

But in the end, the votes of the team is because DeltaChat lacks resources in general, and now they also lack funding. We can discuss here what new standard could we use instead of XEP-0392. Then ask DC team if they are positive if someone does a PR, or sponsors such a change so someone else can do it. Because again, they lack manpower. If you ask me, given the small team, they have done a great job, if not extraordinary.

So TLDR, let’s find a new standard which generates both good looking colors and so many of them. Then get the team’s vote. And finally someone will need to do a PR to add support for it.

The little jewel-toned blocks in many chat GUIs, bubble shooters etc. are probably designed to be addictive rather than informative. Copying existing UIs has its limits. Perhaps some academic interface researchers might be interested? If they have funding that would be great…

I played a bit with using OKLCH model instead of HSLuv. First producing HSL color, then converting OKLCH, then adjusting OKLCH chroma to 0.2 and lightness to 0.5.

Before:

After:

Draft PR: feat: replace HSLuv colors with OKLCH by link2xt · Pull Request #7132 · chatmail/core · GitHub

Well, I’d say it’s a matter of taste. I find the new colors too dark. The gray envelopes are bad enough, please don’t make DC even more dreary. :joy:

1 Like

This OKLCH color space makes sense technically. If you compare the screenshots, you can see that in the first screenshot of current DC colors are not equally saturated: some colors (11, 6, 9, 3) are very colorful, but some colors are more greyish (12, 8, 5, 2, 1).

In the second screenshot they all look equally uncolorful. It is also possible to make them more colorful by increasing “chroma” to values higher 0.2, but then you hit the problem that colors don’t fit into sRGB space anymore and even get impossible to display on some or all devices. This can be partially solved by not converting to sRGB and passing OKLCH color as is to the UI, but I don’t know what happens when the color is not representable on the device anymore.

1 Like

If we give up on compatibility with existing colors (you will have different colors on different devices until you upgrade everywhere) and XEP-0392 (which is not important anyway if we generate colors from key fingerprints and not addresses) and simply generate OKLCH colors with 0.5 lightness, 0.2 chroma and random hue/angle, we get this:

Noooooooooooooo! I wanted to do this :frowning:

anyway, I think the last screenshot looks the best, but it still needs more tweaks. How many colors do we get with this?

Random hue might not produce the best diversity of distinct colors; human spectrum perception is spectacularly non-linear. The misuse of colour in science communication | Nature Communications

It might make sense to use dissimilar hues on profiles with the same initial.

Oh, and about 1-in-20 users will have some colorblindness. The avatars should ideally be distinct in greyscale.

1 Like

Colors for contacts and groups are chosen independently, we cannot change colors based on which other colors are already used. We are currently using XEP-0392: Consistent Color Generation for color generation, it works similarly.

Doesn’t OKLCh account for this? Hue component in HSLuv and OKLCh representation is different.

Thank you! I’m sorry, I didn’t know that was the system.

I’m not honestly upset by the current colors. I usually get as near-collison, two similar colors, in groups of about five of more. I find emojis and Hanzi are more useful in distinguishing contacts than single Latin letters.