Skip to:
Content

BuddyPress.org

Opened 5 years ago

Last modified 20 months ago

#5715 new enhancement

Profile image placeholders

Reported by: sooskriszta Owned by:
Milestone: Awaiting Contributions Priority: normal
Severity: normal Version:
Component: Extended Profile Keywords: dev-feedback
Cc: sooskriszta

Description

Have you used Gmail on your mobile lately? One cool Metro-ish thing they have adopted is profile image placeholders.

So, if the email sender does not have a profile image, then instead of putting up the same old boring placeholder, they put up the first letter of the name in block letters up. They also use various background colors so one could quickly distinguish between Adam and Anna for instance.

Could/Should we implement a similar scheme in BuddyPress?

Attachments (4)

new-gmail.png (212.5 KB) - added by sooskriszta 5 years ago.
Gmail mobile interface
path_5715.zip (999.0 KB) - added by web24coder 4 years ago.
Archive to a folder of images of letters and patch
profile-text-avatar#7.zip (3.8 KB) - added by abweb 3 years ago.
Archive contains updated patch file,text avatar instead images support
5715.diff (8.8 KB) - added by boonebgorges 3 years ago.

Download all attachments as: .zip

Change History (22)

@sooskriszta
5 years ago

Gmail mobile interface

#1 @DJPaul
5 years ago

  • Milestone changed from Awaiting Review to Future Release

I think this is worth considering for when we eventually build out new template parts, and also when we next spend some more time on our Gravatar integration (i.e. we'd avoid a lot of HTTP requests to Gravatar for placeholder images if we somehow cached if the user had a Gravatar at all, for example).

#2 @sooskriszta
5 years ago

Might be worth considering before rewriting Gravatar integration as it would provide a quick, easy, painless, and light alternative to Gravatars for all the non-tech communities that are not familiar with/signed up for Gravatars.

@web24coder
4 years ago

Archive to a folder of images of letters and patch

#3 @web24coder
4 years ago

  • Version set to 2.2.3

The patch contains the functionality to replace the default avatar on avatar "First letter". The setting takes place in the admin. panel buddypress. You must place the folder "letters" with a picture of the letters in the directory "wp-content\plugins\buddypress\bp-core\images\". The patch and a folder with images attached.

#4 @sooskriszta
4 years ago

  • Keywords has-patch needs-testing added
  • Version 2.2.3 deleted

#5 @sooskriszta
4 years ago

Patch works in my testing.

#6 @DJPaul
4 years ago

  • Keywords dev-feedback added

Not sure if we want to add a new gravatar-type alternate to BuddyPress core.

#7 @sooskriszta
4 years ago

I like this (obviously) because it works when gravatars don't, is lightweight and good looking :-)

#8 follow-up: @boonebgorges
4 years ago

Aesthetically, I like this much better than Gravatar's fallbacks (mysteryman, etc).

We'd need to think carefully about character sets. How does this work in non-Latin scripts? Alphabetic scripts (Cyrillic, Greek, etc) should just need another set of first letters. I don't know enough about names in non-alphabetic scripts to know how/whether something similar could work.

Is it possible to build the letters dynamically, instead of shipping a directory of images? (Especially since those images would need to include other scripts.) Maybe use a font + CSS? Or maybe package a library that builds SVGs or CSS to represent characters?

As DJPaul notes, we'd need to think carefully about how/whether the feature would integrate with Gravatar. Maybe the easiest option is a toggle that disables Gravatar in favor of the letters. More sophisticated is a workflow like this: if a user has a local avatar, use it; else if the user has a Gravatar, use it; else use the letter. The main problem here is that we want to avoid calls to gravatar.com, so we'd want to cache the fact that a user doesn't have a Gravatar. But if a user who doesn't have a Gravatar then creates one, we need to bust our local cache of their Gravatarlessness.

It'd also be nice to allow users to set their own background color.

Perhaps as a first pass, this could be built as a plugin that is an alternative to Gravatar. This would give us a chance to explore some of the issues discussed above.

#9 @r-a-y
4 years ago

I kind of remember @henrywright building something like this.

Edit: Sorry. Henry's plugin was for identicons.

Just found the BP plugin for letter avatars:
https://wordpress.org/plugins/buddypress-first-letter-avatar/

Last edited 4 years ago by r-a-y (previous) (diff)

#10 in reply to: ↑ 8 @sooskriszta
4 years ago

Replying to boonebgorges:

Aesthetically, I like this much better than Gravatar's fallbacks (mysteryman, etc).

Glad

We'd need to think carefully about character sets. How does this work in non-Latin scripts? Alphabetic scripts (Cyrillic, Greek, etc) should just need another set of first letters. I don't know enough about names in non-alphabetic scripts to know how/whether something similar could work.

Probably won't work with some Asian languages, which are more pictoral and character-based. Should work similarly with Cyrillic (Greek seems exactly same as Cyrillic :-P and extended Latin)

As DJPaul notes, we'd need to think carefully about how/whether the feature would integrate with Gravatar.

I think at the moment Gravatars take precedence. If no Gravatar exists then this one steps in. So this replaces mystery man, not Gravatars. I agree we should cache Gravatars, but I suppose that's a completely separate issue.

It'd also be nice to allow users to set their own background color.

I actually disagree. I would rather discourage them from falling back on anything except their real photo.

#11 @DJPaul
4 years ago

  • Component changed from Appearance - Template Pack to Appearance - Template Parts

@abweb
3 years ago

Archive contains updated patch file,text avatar instead images support

#12 @boonebgorges
3 years ago

@abweb Thanks for your patch, and thanks for making it work without a bunch of image files. 5715.diff is a version that applies cleanly to a BP checkout.

I just spent a bit of time looking at the buddypress-first-letter-avatar plugin linked by @r-a-y above. A couple things to note about it. One, it uses images instead of text :) I assume there is a good reason for this. Two, it appears to have fairly extensive support for character sets (Latin, Cyrillic, Arabic), as well as a number of edge-case treatments that are probably the result of extensive testing. Three, people really seem to like this plugin.

So, I'm going to go out on a limb and ping the authors of that plugin - @dev49net and @danielagw - to see if they'd like to chime in on this thread. Specifically, I'd like to hear about why they opted to go with static images instead of dynamically generated CSS icons. (I'm guessing it has to do with the weird ways that character sets behave in different environments.) Also, if we're going to pursue something like this in BuddyPress, I'd like to have them on board, as we'd be stealing the market for their plugin :-D

@boonebgorges
3 years ago

#13 @Dev49.net
3 years ago

Hi guys, I am the author of the BuddyPress First Letter Avatar plugin.

@boonebgorges

One, it uses images instead of text

Yes, I thought since we are replacing avatars, it would be best to replace it with images. Two reasons: we can be sure they are all always displayed properly and two, we don't have to worry about various alphabets we have around the world. Although png was probably a mistake and the way to go is probably svg these days. I still wouldn't go with pure CSS.

if we're going to pursue something like this in BuddyPress, I'd like to have them on board, as we'd be stealing the market for their plugin

Having this functionality natively in BuddyPress would be great, so don't mind stealing the market from me :-)

Dan

#14 @DJPaul
3 years ago

  • Component changed from Appearance - Template Parts to Templates

#15 @sooskriszta
3 years ago

@DJPaul So, any thoughts about merging this?

#16 @DJPaul
2 years ago

  • Component changed from Templates to Extended Profile

#17 @DJPaul
20 months ago

  • Milestone changed from Future Release to 3.0

Moving to 3.0 for consideration if/how we want this. Sorry we didn't properly address this two years ago.

#18 @DJPaul
20 months ago

  • Keywords has-patch needs-testing removed
  • Milestone changed from 3.0 to Future Release

It might be interesting to look at this. The avatar code has never been rewritten since its original implementation, and it's very tied to Automattic's Gravatar service.

The 5715.diff patch is a good proof of concept (not to mention the plugins mentioned above). It shows how low-impact such a change could be. However, I think we've all learnt enough nowadays that we can do better, both technically and from a web page performance perspective.

With this "letter-initial avatar" pitch, getting the first letter from a word doesn't work very well globally, especially with non-Latin alphabets. Perhaps Google has the resources to tackle this, we don't, but we can avoid making incorrect assumptions.

(I am sure to be oversimplifying and this is only accurate to my very limited knowledge, so I apologise to everyone who's about to call me wrong. That's not my intent!)

e.g. I'm reliably informed that in Chinese, names are typically three glyphs long. The first glyph tends to be the surname (e.g. li, wong, chan, lee, xe) and the second and third glyphs make up the first name (e.g. "jen" and "ny" for "jenny"). You can't parse glyphs into "letters", so it's impossible to grab a "J" from that; we'd have to show the whole glyph, and, e.g. that might only be half the sounds of someone's name. We'd butcher it!

e.g. I'm reliably informed that in Cyrillic, and especially Bulgarian, you can only use the first letter if it's a vowel (or starts with one). I think even then, there might be exceptions based on how that letter sounds when pronounced.

I think:

  • A new system needs to be designed so that people can add support for a custom avatar type efficiently (e.g. a specialised Chinese extension), or disable them entirely.
  • bp_core_fetch_avatar() would remain the entry point, but I can see that function being totally gutted. It does too many things at the moment. We should not add more complexity to it.
  • We'd ship with a Gravatar avatar type to start with.
  • Our own "BP profile photo" feature would integrate into this new system as an avatar type extension -- just like Gravatar.
  • For all avatar types, but especially Gravatar, we can enhance fallback support. We can fix/bring back the ability to use a local fallback image (e.g. on a domain that Gravatar can't access).
    • For Gravatar, we'd do this by caching if the user's email has a Gravatar set. If not, use the local fallback (or choose to use Gravatar's fallback).
    • Specifically with Gravatar, we'd also save a ton of HTTP requests if our defaults were smart.
Note: See TracTickets for help on using tickets.