Not long ago, Gravatar crawled back out from the shadows and relaunched with a snazzy new service (backed by Amazon S3) that lets you claim multiple email addresses and host multiple gravatars with them for $10 a year.
The beauty of their service is that it makes it possible to centrally control the 80 by 80 pixel face that you put out to the world and to additionally tie a different face to each of your email addresses. And this works tremendously well when it comes to leaving a comment somewhere that a) supports Gravatar and b) requires an email address to leave a comment.
Now, when Gravatar went dark, as you might expect, some enterprising folks came together and attempted to develop a decentralized standard to replace the well-worn service in a quasi-authoritarian spec called Pavatar (for personal avatar).
Aside from the unnecessary invention of a new term, the choice to create an overly complicated spec and the sadly misguided attempt to call this effort a microformat, the goal is a worthy one, and given the recent question on the OpenID General list about the same quandary, I thought I’d share my thoughts on the matter.
For one thing, avatar solutions should focus on visible data, just as microformats do — as opposed to hidden and/or spammable meta tags. To that end, whatever convention is adopted or promoted should reflect existing standards. Frankly, the hcard microformat already provides a mechanism for identifying avatars with its “photo” attribute. In fact, if you look at my demo hcard, you’ll see how easy it would be to grab data from this page. There’s no reason why other social networks couldn’t adopt the same convention and make it easy to set a definitive profile for slurping out your current avatar.
In terms of URI locating, I might recommend a standard convention that appends avatar.jpg to the end of an OpenID as a means of conveniently discovering an avatar, like so. This concept follows the favicon.ico convention of sticking the favicon.ico file in the root directory of a site, and then using this icon in bookmarks. There’s no reason why, when URLs come to represent people, we can’t do the same thing for avatars.
Now, off of this idea is probably my most radical suggestion, and I know that when people shoot me down for it, it’s because I’m right, but just early (as usual).
Instead of a miserly 80 pixels square, I think that default personal avatars should be 512 pixels square (yes, a full 262,144 pixels rather than today’s 6,400).
There are a couple reasons and potential benefits for this:
- Leopard’s resolution independence supports icons that are 512px square (a good place to draw convention). These avatars could end up being very useful on the desktop (see Apple’s Front Row).
- While 80 pixels might be a useful size in an application, it’s often less than useful when trying to recognize someone in a lineup.
- We have the bandwidth. We have the digital cameras and iSights. I’m tired of squinting when the technology is there to fix the problem.
- It provides a high fidelity source to scale into different contortions for other uses. Trying blowing up an 80 pixel image to 300 pixels. Yuck!
- If such a convention is indeed adopted, as
favicon.icowas, we should set the bar much higher (or bigger) from the get-go
So, a couple points to close out.
When I was designing Flock, I wanted to push a larger subscribable personal avatar standard so that we could offer richer, more personable (though hopefully not as male-dominated) interfaces like this one (featuring Technorati’s staff at the time):
In order to make this work across sites, we’d need some basic convention that folks could use in publishing avatars. Even today, avatars vary from one site to the next in both size and shape. This really doesn’t make sense. With the advent of OpenID and URL-based identity mashed up with microformats, it makes even less sense, though I understand that needs do vary.
So, on top of providing the basic convention for locating an avatar on the end of an OpenID (http://tld.com/avatar.jpg), why not use server-side transforms to also provide various avatar sizes, in multiples of 16, like: avatar.jpg (original, 512×512) avatar_256.jpg, avatar_128.jpg, avatar_48.jpg, avatar_32.jpg, avatar_16.jpg. This is similar to the Apple icon .icns format … I see no reason why we can’t move forward with better and richer representations of people.
Onward!
Factory Joe 
nice idea always considered why not on the Microformats photo class as an avatar. I like the idea of combining it into open id, makes sense. Problem with the 512×512 avatar is
YOU have the bandwidth.
YOU have the digital cameras and iSights.
What about considering the rest of the internet that is not on massive bandwidth pipes like in parts of the US and the EU.
Don’t assume the world is like your user experience. As we are reminded constantly, it’s not.
I think this is a great idea. Creating standards like this allows for better innovation and computability. Most problems stem from the lack of a standard (for example the idea of moving from social network to social network being difficult because you need to re-add all of your friends.)
If there were standards for these types of things, along with OpenID these things could be fixed.
ie.
domain.com/friends.xml
domain.com/avatar.jpg
domain.com/favicon.ico
domain.com/hcard.xml
etc
@Gary: I take your point, but think that a 512px avatar isn’t actually that heavy when compared to the kind of video being passed around the web today. And, even the worst digital cameras don’t take photos less than 640×480.
So, I think that you’re right in that we should be sensitive to the fact that not everyone has the same access, but on the other hand, I did provide a method for grabbing smaller files — and think that this concept is more about future proofing against a standard like 80px square which you can’t resample up from.
@Ludwig: if I could tweak your suggestions… there’s no reason why you couldn’t combine all the pieces you mentioned into one
hcard.html(HTML, not XML filetype) — with the avatar, person details and friends depicted with XFN. Again, part of the other goal is to focus on visible data, not hidden meta data. But absolutely — this gets one step closer to a portable persona and friends network.@Chris – Very true, no reason why everything should be spread around and separate from each other.
May I ask what’s the this truthiness rating from 30Boxes? I googled but couldn’t find anything. Do you know how it works and what type of rating is good? (I’m guessing 9 is good and 1 is bad since you are a 9 😀 )
I have no drama with a 512 pixel square avatar – I just want to never have to re-make one to suit the particular size requirements that whatever particular site I’m using has seemingly randomly decided on. 🙂
“why not use server-side transforms(…)”
Why not let the server side do what it do best, serve, and let the client do the math? And at the same time dodge the problem of bandwith Gary was talking about.
Let say the client, a blogging platform, got an OpenID and needs an avatar the size of 80×80. The easy way would be to embed a php-script in an image tag like such:
-img src=”getavatar.php?openid=[openid]” height=”80″ width=”80″-
Then the getavatar.php-script appends avatar_80.jpg to the openid and requests it, assuming square 80×80 px dimensions. If the script got a response, all is good, cache and output. If the script got a 404, the script tries to append the default “avatar.jpg” and request it, assuming 512×512 px. If response, resize to 80×80, cache and output. And if the server still doesn’t answer, the script outputs some default graphics, “no avatar” (or perhaps “baby”).
This results in one/two request which may be 200, 404-200, 404-404. And the openid-owner with expensive bandwith (Gary) only serves a cheap tiny 80×80 at the cost of manually maintaining all the avatar_xxx.jpg desired. The openid-owner who has all the bandwith money can buy (or is just plain lazy) simply maintains a single avatar.jpg which gets transformed all over the world.
This translates nicely to some other client wanting a 256×256 avatar, a third one wanting some random 49×49, and so-on. It even scales upwards with some random client wanting a 1024×1024. If the openid-owner is using such a client/service and knowing that provides an “avatar_1024.jpg” all is good. Then of course the client can’t fall back on avatar.jpg since it is 512×512. Tough luck. No avatar. You could even argue format-choice with clients requesting something like: “avatar_xxx.png”, “avatar_xxx.jpg”, “avatar.png”, “avatar.jpg”. More requests tho that might produce an awful lot of 404-footprints.
My vote is with 512×512 as a standard for “avatar.jpg” given that Leopard-argument and that a face can be decently compressed to about ~50k with those dimensions and even as low as 20k (if your face is compatible with jpeg-artifacts).
Chris, I like this idea. How do we get the various Internet bigwigs to try it out though?
Great idea!
Just one thing: the client should really do the appropriate sizing, not the server.
Just one more thing: For some idiotic reason, web browsers *suck* at resampling images. They all use bilinear filtering rather than something reasonable like bicubic or lanczos or, really, anything that looks decent.
You’d think this would have been remedied in at least Firefox by now, but no such luck. (SmugMug would gladly pay some hacker to do it if anyone is up to the task. Drop me a note.)
I’m not set up with an OpenID yet and still I got so inspired that I created a php-script that will generate various avatar dimension from a password protected form upload. It’s pretty basic and more of a PoC on managing several avatar dimensions on your own web site.
http://tools.randomuse.org/avatargenerator/
A simple solution and probably workable for the simple cases, but I’m at least one of the people who would want to have more than a single avatar available despite utilising the same openid. Ideally, anyway …
@Alison: Couldn’t that special need be handled by some more specialized service, like gravatar? One openid, one avatar.jpg, one hcard.xml, etc. = a “standard”, in the web sense, that could be extended with non-standard additions. These non-standard additions then becomes new standards if everyone decides to use them. But there has to be a first and Chris’ suggestion seem like a damn good start to me.
It’s sounds like a good idea!
Fixed URIs like
robots.txtandfavicon.icoare bad, but otherwise I love the idea. Perhaps something along the lines of feed autodiscovery would be workable?(Also, somethings messed up with your OpenID auth — I’ve had to leave that field blank in order to comment at all.)
I agree with Edward that magic URLs are something that we should probably be avoiding.
Personally, I’d rather see people linking to a FOAF file (or hCard or RDFa if you prefer) and from there provide links to the various resolutions of avatars.
While FOAF can be difficult at times for the average user, a couple highly ranked tutorials providing people the text that they can copy/paste would take care of that.
Yeah, I now believe that magic URLs are also a bad idea and that something more like rel-avatar or rel-photo in the context of an hcard should suffice.
It was fantastic. I too was thinking about Avatars in the same way. Magic URLs are really not good. With RubyonRails, Codeigniter and similar ‘next gen’ web frameworks won’t support serving a JPEG from web root (ocourse u can hack it though). Probably Mattias’ idea must work better. I look forward to see how it goes.
But ultimately we need a reputation management and aggregation system which does all these (friends,avatars,profile,geolocation). Will MySpace think this way? Will they setup openIDs for members (like AOL did)?
Let’s just do this.
We wanted to include avatars on our weblog FourStarters.com and my friend Cristiano added some kind of plugin to pull these from MyBlogLog.
We had some minor issues configuring mybloglog, but why should we use yet another third party site to store profile information when most of this is already in OpenID. FourStarters supports OpenID for comments (with wpopenid) already, pulling in the avatars from there looks like a tiny step.
hCard already has class=”photo”. So what to do? Embed or link hCard to your openid?
omg i was searching ‘avatar’ in Google images and yours popped up…. weird. lol
how the hell you been?