The conflicting needs of emoji

[Mark E. Shoulson]

On 10/14/22 18:28, Adib Behjat via Unicode wrote:
> I second Mark’s sentiment and really like the suggestion. I also do 
> think it would be wiser if this process was handled and managed by 
> OSs/Apps versus Unicode.
>
> After reading Mark’s suggestion, I was reminded of a game where you 
> combine basic/generic elements to create more complex elements (e.g. 
> https://littlealchemy.com/).
>
> For example, if someone wants to generate “Physics Teacher”, a user 
> can type in their device:
> 🧑‍🏫⚛️

Yes, this is essentially the "emoji kitchen" approach.  It has definite 
appeal and could work... and also distinct downsides: lack of control 
over what you actually mean, different people thinking of different 
formulæ, etc.  No scheme is perfect.  Those alchemy games are indeed a 
good example of this kind of thinking, but it has its ups and downs.

~mark

>
> And based on this combination, the OS/App can give the user the option 
> to generate a custom avatar to represent Physics Teacher. With regards 
> to rendering, tools like DALL-E (or other similar diffusion models) 
> can enable this capability. In addition, this process will help 
> encourage the introduction of more generic emoji characters to help 
> expand the foundational building blocks for these tools.
>
>
>> On Oct 14, 2022, at 2:43 PM, Mark E. Shoulson via Unicode 
>> <unicode at corp.unicode.org> wrote:
>>
>> 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?)
>>
>> Thoughts?
>>
>> ~mark
>>
>>
>> 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 PHYSICS teacher with dark hair IN PRINCESS-LEIA BUNS AND A 
>>>> PIERCED 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
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20221019/e3290d33/attachment.htm>