Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Accessibility?/UX] Default-generated user icons smehow feel unpleasant to look at #14433

Closed
ell1e opened this issue Jul 13, 2020 · 8 comments
Closed
Labels

Comments

@ell1e
Copy link

ell1e commented Jul 13, 2020

(This issue is forwarded from here: matrix-org/synapse#7826 )

Description

I don't know if it's just me, but I find the default-generated user icons are straining/painful to look at. I'm not a scientist so I am not sure why exactly this is, but I have identified a way to improve it:

Current generated icon:

Manual edit of mine that somehow feels way better for me (I just made the stripes 6px wide, from previously 1px):

I have no idea if it's just me, or why exactly these larger stripes are better. But at the chance that I'm not alone with this, I am hereby suggesting to collect more feedback from others and consider changing it because I find the current icons really strangely unpleasant to look at. So if I'm not alone, it definitely sounds like worth changing.

Steps to reproduce

    1. Open up riot and join any channel
    1. Observe the unchanged default icons of other users or channels where a custom one wasn't set

(screenshots see above)

Version information

  • Platform: web
  • Browser: Firefox
  • OS: Linux
  • URL: riot.im/app
@t3chguy
Copy link
Member

t3chguy commented Jul 13, 2020

Do you have resistFingerprinting enabled in your Firefox? Enabling that causes data read from canvases to look like random stripes like you have found. Default generated avatars are actually meant to just be solid colours generated by means of canvases for ability to integrate with various web APIs such as the Notifications API which need an image url

@ell1e
Copy link
Author

ell1e commented Jul 13, 2020

Interesting, that appears to be indeed the issue. But since allowing canvas access just turns the avatars into solid colors, why isn't riot just using plain background color divs? Seems like it's quite unnecessary to even require canvas access for this

@t3chguy
Copy link
Member

t3chguy commented Jul 13, 2020

just using plain background color divs?

Because things like the Notifications API do not support that https://developer.mozilla.org/en-US/docs/Web/API/notification/Notification

icon: A USVString containing the URL of an icon to be displayed in the notification.

So to be able to show that same icon in the notification it must be done in canvas

@ell1e
Copy link
Author

ell1e commented Jul 13, 2020

Couldn't the parts in the riot UI still use the div approach, or is that too much effort to implement? Because then it would at least look right everywhere but the notifications (which I have disabled anyway, not sure how common that is and whether that justifies a separate code path)

@t3chguy
Copy link
Member

t3chguy commented Jul 13, 2020

Having to make sure that two different codepaths for one underlying feature work just sounds brittle. It isn't the only place where canvases are needed so working around a browser with broken canvases sounds like a waste of time

@ell1e
Copy link
Author

ell1e commented Jul 13, 2020

Ok, then I'll close this. (even though from a user side I am kind of hoping you rethink this some day, but up to you)

@ell1e ell1e closed this as completed Jul 13, 2020
@t3chguy
Copy link
Member

t3chguy commented Jul 13, 2020

Canvases are required for local thumbnailing such as required in e2ee rooms and for videos, its especially bad when the browser returns false data rather than erroring like it used to. Firefox lets you whitelist sites nowadays though

@maskedriotuser
Copy link

See #14419 (comment) to allow only Riot / Element to access canvas data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants