The conflicting needs of emoji

Mark E. Shoulson mark at
Fri Oct 14 16:43:25 CDT 2022

There are really two distinct animi(?) behind the push for 
ever-more-detailed emoji, or rather, two animi for using emoji, and they 
pull in different directions, almost opposite.

On one hand, people want an emoji that looks JUST like they want it to 
look.  Maybe not even only for people!  But of course we see it most 
with people.  People want an emoji that looks like _they_ look (do they 
really use it?  or do they just feel left out if it isn't available?  
I'm not a heavy emoji-user, so I'm no judge, but I bet the second 
motivation is non-trivial as well.)  So the really do want "tall 
ectomorph female physics teacher with dark hair in Princess Leia buns, 
an eyebrow piercing (right), and a birthmark on the left side of the 
chin."  This motivates the various suggestions of somehow encoding a 
teeny image and pretending it's somehow "plain text", or encoding a link 
to it or something.  I had what I thought were helpful ideas about the 
recent notions being floated at the last Unicode meeting I attended, and 
maybe they're even being thought about...  But although I've thought 
that maybe sending images like this was the best of the suggested 
solutions, it's still awful.

The other problem is the other animus involved.  Because it isn't just a 
picture that people want when they use emoji.  It isn't enough that 
there's a little picture of a person wearing a mortarboard hat or 
something, there's actual semantic information embedded in the encoded 
text as well.  It isn't just a picture, it's a codepoint(-sequence) that 
means something, a bit-sequence that _means_ "TEACHER."  Just like 
U+0065 means something more than the ink used to draw it in whatever 
font.  People want some snippet of "text" that not only looks like them, 
but also *means* them.  Hence in my example above, expressing some of 
the various physical traits are one thing, and you can represent TEACHER 
with some cultural convention like a mortarboard hat (or THIEF with a 
mask), but how do you get across "PHYSICS teacher"?  Or a dozen other 
subjects, arbitrarily finely divided?

When I think about it, I don't know that people would really be 
satisfied with image-sticker emoji.  After all, not everyone has the 
skill to draw them (which is why we rely on emoji-font artists in the 
first place), or make them Just So, and I really do think that people 
would feel the lack of semantic meaning.  A lot of messaging services 
already let you include little graphics images, but I don't think the 
people using them feel this desire for new emoji any less.  How many 
homedrawn emoji do you really think will be made?  How many used more 
than twice?  How many used by more than one person?  How many will even 
be understood by the recipient?

Asmus' point about comparing it to swapping out lego bits is 
well-taken.  There have long been these kind of "avatar engines" that 
let you swap around features to get something kind of like you (I 
remember one on the Wii way back when.)  And maybe there is some 
reasonable limit to how much customization can be provided (though I'd 
bet anything we'd take forever agreeing on it.)  And even within 
specific limits like hair-style and hats, there'll always be one more 
that we're lacking, one more Mr Potato Head piece people will push for.

(Actually, thinking about Asmus' line about "faces drawn on," how's this 
for an idea, combining raster with standard?  Instead of drawing some 
random picture yourself for an emoji, you have an image of, say, facial 
features that's to be projected onto a blank emoji-face, which can be 
any "standard" emoji or whatever.  Could have other distinct ways of 
specifying headgear images, etc.  The renderer would be smart enough to 
scale or transform the image appropriately for different kinds of emoji 
with faces in different places and orientations etc.  Probably a beast 
to implement, but I'm just floating ideas.  This one actually has signs 
of MAYBE bridging the gap between the two drives for emoji.)

Perhaps the best "generalized emoji" implementation is something along 
the lines of the Emoji Kitchen, where you can combine arbitrary emoji in 
arbitrary numbers and orders and the system does its level best to 
figure out SOME way for the resulting image to make sense.  This gives 
you some genericness, and you can express all kinds of shades of meaning 
by combining enough emoji, but retains the semantic meaning of them as 
well.  Of course, it puts you at the mercy of how the system chooses to 
combine things, how good the designers are, etc etc.  You have no 
control over what really emerges at the end.  (I suppose if this ever 
became something widespread there would develop conventions for 
combining with a little more control (like Egyptian hieroglyph combiner 
marks??  Probably not, but with some semantic similarities.))

Anyway.  Wanted to rant a bit on this "two desires" notion that I was 
thinking about since the last meeting.  I think it's important to 
remember the second one, which gets missed out on when people focus on 
controlling the picture just so (though it is what's behind the idea of 
using Wikidata codes.)  And the "images of features" notion occurred to 
me while typing this, and I think it's interesting.

I'm not really trying to suggest answers here (though I did remark on 
some things favorably); this is more asking the questions.  There's 
always going to be these two conflicting needs, and there'll always be 
people who want ever-finer distinctions in emoji, and there may simply 
not be any really good answers.  Emoji probably never should have been 
part of Unicode (not "plain text"), but that ship sailed long ago, and 
even there it's not cut and dried (webdings? map symbols?)



On 10/14/22 00:54, Asmus Freytag via Unicode wrote:
> People that grew up on games are used to character editors that allow 
> any avatar to be assembled from building blocks. Short of a common 
> "avatar engine" shared across all platforms, a limited set of 
> emoji-legos isn't that unreasonable.
> We have skin tones, male/female, some limited use of color (black + cat).
> Because of their small size, emoji faces would support more 
> customization; it's hard to create a full character emoji on the level 
> of detail of a game character. So you'd be limited to less detail than 
> you can implement with real lego blocks. (And yes, the ones for the 
> heads of the little figure have removable hair (and head gear). Plus a 
> variety of of faces (pirate) painted on.
> If that can be done in the physical world, there's no reason a subset 
> of that couldn't be supported in emoji rendering.
> People will intuitively sense that that should be possible and thus 
> the pressure to innovate in that direction won't stop.
> Just my $1/50.
> A./
> On 10/13/2022 4:38 PM, Mark E. Shoulson via Unicode wrote:
>> Again, this way lieth madness.  People aren't satisfied with an emoji 
>> for "female teacher with dark hair"; they want "TALL, THIN, female 
>> EYEBROW (GOLD RING)."  And if you give in on "welllllll, okay, we'll 
>> give in on the tall/short...," you're only encouraging them to beg 
>> for the rest.  ("How about only a _little_ tall?  How about 
>> broad-shouldered?  small-breasted?")
>> (Though my opinion isn't actually quite what that sounds like: even I 
>> admit that there probably *are* things that are appropriate to give 
>> in on, and I know we all can argue all the day long about them.)
>> ~mark
>> On 10/13/22 09:22, William_J_G Overington via Unicode wrote:
>>> Thank you for posting about this.
>>> Could one use variation selectors with this too, so as to have a 
>>> default style of glasses and various styles of glasses available?
>>> Or would one need to have separate styles of glasses each encoded 
>>> separately?
>>> If both approaches are possible, which one would be better?
>>> If it is to be encoded, and I hope it will be, it would be good to 
>>> go for the lot all at once. Lots of styles as glasses are in lots of 
>>> styles.
>>> In my opinion it is no use just doing one and leaving the rest for 
>>> some future time as that is often a recipe for the rest never 
>>> getting done.
>>> If the lot is done as one grand forward leap then that is the way to 
>>> keep Unicode thriving.
>>> William Overington
>>> Thursday 13 October 2022

More information about the Unicode mailing list