I guess you mean skeuomorphic, with heightened 3D presence caused by heavy use of light and shadow - roughly, the sort of effect you would get from a static rendering of a cheap 3D model in a Unity mobile game.
I agree with you, although I will say that the current version of the Noto Color Emoji font is (IMO) the best up-to-date color emoji, because it mostly eschews this fake realism that feels uncomfortable and disconcerting in other emoji fonts. I'd prefer hyper-stylized "blobs", but I think they deserve some credit for avoiding the worst of skeuomorphic design.
See for example the "realistic" 3D rendering of the hand on the Apple emoji for "thinking face", it's firmly in uncanny valley for me. [1] The Noto emojis remain fairly stylized without being hideous like the Microsoft emojis.
Google also deserves from credit for drastically improving the rendering of many of these emojis over time. This has happened quietly enough that I doubt most people have noticed. They brought back the more blob-like turtle [2], which really deserves to be compared to the horrible, awkward plastic children's toy that is the Apple rendering. Or take a look at how awful the gradients are on the Android 8-10 emoji [3] and compare to more recent versions. [4]
I think we will look back at awkward 3D renderings in many emoji styles as a mistake. They remind me quite a bit of the terrible DreamWorks animation style [5] of the early '00s.
I'm surprised that Apple hasn't updated their skeuomorphic emojis.
They didn't look good even at the very beginning, and surely doesn't match Apple's design language/principle for.. at least 5 years. Apple is supposed to be the company that is obsessed with aesthetics yet they never update/redo the emojis.
Apple's emojis are fine. What's not fine is their treatment of them: apps can be rejected from the AppStore if they feature emojis on a screenshots, or have them on some button. What's worse, this rule is applied very inconsistently.
You realize not everyone thinks Apple emoji don’t look good? In particular in the younger demographic I’d be surprised if they were less liked than Android blob emojis. I mean, take GP’s comparison of the turtle, do you really think the Android ugly, and to be honest with a somewhat mentally challenged face, looks better than Apple’s turtle? Maybe you do, and maybe GP does too, but tons of people wouldn’t.
I’ve never used that many emoji in my messages than since I switched to iOS because their emojis carry way more meaning to me.
Looking good is subjective, I was more saying that it doesn't match/fit with Apple's general aesthetics today. Apple dropped skeuomorphic style from their UI a long time ago.
> I guess you mean skeuomorphic, with heightened 3D presence caused by heavy use of light and shadow
No, not really; the problem is more, taking things that were originally introduced with the intention of being abstract pictograms signifying emotions; and adding enough un-called-for detail (i.e. details not required by the Unicode codepoint description) as to make things like gender and race seem like a relevant or even necessary property.
Consider: in all modern implementations, "emotion" emoji are displayed with... heads. Opaque backing "vaguely skin-tinted" blobs at the very least; full-on human heads with ears and noses and hair in some fonts.
They don't need to be. Nothing about the Unicode codepoint for e.g. U+1F603 "grinning face with big eyes" says the "face" needs to even be visualized as being on a head. It could be doing a cheshire-cat-smile thing, just eyes and a mouth — ":D" but rotated 90 degrees. And, in fact, that's exactly what it was, in the DoCoMo image-font, one of the three that led to the Unicode introduction of emoji!
But for some reason, now we don't just have skeuomorphism (shiny eyes, pink mouths with tongues, blushing cheeks); we have these heads, and ears, and hair; and before you know it, people wondering why the head is yellow rather than some actual skin tone; or why the increasingly-less-generic face shape seems to be more masculine than feminine; etc.
Why not just cut the Gordian knot? Get rid of the "head" part. Get rid of any part that's not required to communicate the concept. Make an image-font of only the Minimum Viable Pictograms for what each of the Unicode codepoint descriptions describes.
Which is orthogonal to skeuomorphism, mind you. This isn't about whether a tongue has a tongue-ish texture to it. It's about whether you should include a tongue at all.
> They don't need to be. Nothing about the Unicode codepoint for e.g. U+1F603 "grinning face with big eyes" says the "face" needs to even be visualized as being on a head. It could be doing a cheshire-cat-smile thing, just eyes and a mouth — ":D" but rotated 90 degrees. And, in fact, that's exactly what it was, in the DoCoMo image-font, one of the three that led to the Unicode introduction of emoji!
Okay, one vendor opted to do simpler emoji, but the other two displayed faces, right? Moreover, Japanese carriers don’t have the monopoly on inventing small images expressing emotions. The "Western" world had ICQ, AIM, MSN Messenger, Yahoo Messenger, and other IMs (say, Poland’s Gadu-Gadu). And all those had emoticons: typing ":D" would turn into an image of a yellow circle with eyes and a grinning mouth.
And personally, I would prefer the colorful, lively emoji, as opposed to plain punctuation turned 90 degrees. I guess all the current emoji vendors think this way.
I remember when my perfectly clear :) became one picture in yahoo messenger and another in AIM. You should have seen my face when the little <3 my boyfriend and I texted to each other became a gaudy, beating red heart right before my eyes. It's gotten easier to opt out of over the years, but there was a while there when none of the SMS apps allowed you to just send the text without converting it to whatever picture they thought you should want. I think if we'd never gone through that stage, I would hate them less. As it stands, we've made this a whole lot more complicated than it has to be and the art of interpreting the text emoticons is basically lost.
Also, I've got an ex-coworker in her late 40's who apparently now types in sentences where the majority of the parts of speech are replaced by an emoji. "Radishes are 'thumbs down' 'vomiting face'" and other statements built with the same grammar. She's an idiot and that was apparent long before this started, but it's gotten worse over the last 4-5 years.
Basically, I'd like to opt out of picture emojis. I'm not sure anything worthwhile has been communicated with them. Well, maybe leave out grandparents. My husband's grandmother isn't a fast typer, so she sends messages mostly made of sweet emojis and you know it's sent with love. But anyone actually trying to make a point with them irritates me. It feels like they're talking like a baby, but in print.
I absolutely agree with you.
I see no need for emojis. Maybe it was fun when some IM apps started to turn text (like :-* ) into little images, but now we have software for making emojis, software for rendering emojis, thousands of utf8 codepoints for every possible emoji, emojis of all races and genders, bugs in software because it was supposed to have text input and can't handle emojis correctly, whole sites and fonts and keyboards made specifically for emojis… Did humanity really waste thousands of hours so that people can send a little poop image?
Can people just explain their feelings as they always did in the past, or if that's for some reason not possible, just send a photo or a jpeg of a smiling cartoonish face? Do we really need emojis as they are, sequences of bites that have to be standardized and render correctly on every device and any font?
I just don't get this obsession with emojis. It started as a fun toy, but now it's a huge waste of time for thousands of developers.
Emojis exist in Unicode because people have written emotion-face pictograms inline in text documents (even before the advent of computers!), and Unicode needs a way to encode those existing documents such that one ":D rotated 90 degrees" is machine-readably-identical to another ":D rotated 90 degrees." For the sake of e.g. screen readers, sentiment analysis, etc.
But there's no reason that said pictograms need to have a rendering like anything more than what people would draw them as on paper. The Unicode ellipsis exists to encode the separate intent of "writing an ellipsis" from just writing three dots — but it's still just rendered as three dots.
It also transports the idea of "turtle" better - especially when you deal with people who are unaware of the difference between turtles and tortoises, or who know not all turtles have extraordinary large giraffe-style necks. Not every turtle is a Galapagos tortoise.
But do we need these distinctions? I mean, in French we don’t even have the nuance between turtles and tortoises, both are « tortues ». So whether it’s a long neck or short neck turtle, who cares? Do you often need to use specifically a turtle (not tortoise) emoji where the sense of what you mean radically change? Even if you use a Galapagos turtle emoji to talk about your non Galapagos pet turtle, is that so important to your story?
With symbols, it is often better to have simplified, general-purpose representations as compared to highly specific ones. E.g. it's better to have a highly stylized "aircraft" emoji [1] than a tiny, but screw-accurate variant of a weird little plane like the Edgely Ocular [2].
Yes! (And it seems like many others agree with me.)
To be clear, I do recognize that the Google one is "stylized" in a way that is not going to appeal to everyone. However, I claim that there is something objectively (or almost objectively) wrong and upsetting about the Apple style here. If you're going to do the whole "3D render" style, you simply have to do a better job than Apple has done here. As I said in my OP, it looks like a poor model from a mobile game or a early 00s DreamWorks film. It's simply not good enough work, regardless of whether you like "realistic" emoji art or not.
Back in the day when they were standard in Androids we received tons of complaints about our chat app from users, "why do you use these fugly blob emojis? Can't you have nice ones like on iPhones?"
I guess it’s very subjective and while I’m sure the blobs had fans, they just looked weird to me. And it probably didn’t help that WhatsApp had their own emoji on Android.
Note that Microsoft also had to do a refresh of all their emoji for Windows 11.
For now the Apple/WhatsApp like aesthetic is king. But it’s so fashion driven, you never know what’ll be in tomorrow.
Telegram also used Apple's emoji, and what's unclear to me how they got away with it: I did search hard and could not find any information on Apple Emoji licensing or whether they can be used on other platforms at all.
Fun fact: Noto = No Tofus, referring to the blank rectangular frames you get when your font is missing a character. The Noto fonts are particularly awesome for multilingual text because they do indeed cover everything.
Interestingly, there is no actual "tofu" emoji, despite a huge variety of other foods having emoji representation. It was evidently proposed at one point, but rejected for some reason: https://unicode.org/emoji/emoji-requests.html (page contains link to Google Doc with status of requests).
Google already had a black and white emoji font. I think from before color fonts were a thing. However they stopped updating that in 2015 (https://github.com/googlefonts/noto-emoji/commits/2f1ffdd6fb...). This is likely a descendant of that rather than completely from scratch.
It's also interesting they call out emoji being too detailed as a problem. For some characters like Pistol (apple-fied into Squirt Gun) they've copied Apples style -- presumably to avoid confusion. So acknowledging that not all fonts need to look the same is a bit refreshing there.
Though of course the black and white pistol still looks like a squirt-gun
> This is likely a descendant of that rather than completely from scratch.
Given they're both called Noto Emoji, it's fair to assume so. Especially considering the new version also has gumdrops which are a classic of old Google emojis.
I also think that was the reason. Although it doesn't make sense, since on dark background (unusual on paper, but otherwise not to rare nowadays with dark mode in every phone) it would be the other way round. (The problem with blobs is that they can't display male/female faces. I assume they all just look the same then.)
Who is at fault here? The cowards at Google who fear a PR disaster and self-censor in advance? The extremist minority which often generates similar outrage about such pseudo issues on Twitter? Or the journalists who willingly and uncritically spread and blow such outrage out of proportion without mentioning that the original source of the outrage was just a small group of social justice activists on Twitter, not "the public"?
They aren't a new thing. They were (though more colourfully) the default android emoji representation for a fair few years. For this font they probably started from an older one rather than from scratch, and decided not to recreate everything that could instead be human rather than more abstract.
I hope these become more popular. I'm not a fan of the way cartoonish emojis have become so ubiquitous. I don't care for the aesthetic being plastered all over the things I use, but I do like the ability to use symbols to express emotion and other non-verbal things in written form.
That's the thing, a lot of things bundle their own emoji "fonts" and allow no way to override. Your (custom) system font will only be displayed when the "raw" emoji is displayed as text without any modifications.
I don't use a lot of emojis privately but I especially do not use them in a professional environment. I think one of the reasons being that I dislike the aesthetics, which plays into another reason, which is that they "feel" unprofessional. (Although there is probably nothing inherently unprofessional to them, it's basically just a novel way of communicating).
The blog post mentions increased interpretability and adaptability but I think making emojis more professional and aesthetically pleasing "in a professional setting" might be a big step as well.
I don't know what's weirder, the idea of classy black and white emojis somehow being more professional, or the fact that I 100% agree. Seems sort of strange, but apparently color is a major factor in what I consider to be "professional".
"Professional X" is just you getting paid to work on X instead of X being a hobby or pastime for you. "Professional" doesn't mean you have to be serious 100% of the time, let's lighten up!
It seems to me that emojis are pretty much required in many professional environments nowadays. E.g., if you don't tack an emoji reaction onto enough Slack messages you won't be seen as an enthusiastic participant, which could have negative consequences.
To play devil's advocate (?), I use them all the time at work, I could argue that it makes me more efficient. Easier to react with a thumb emoji and grinning emoji than than saying "thank you very much for that". However if I argue that it's not strictly true, I use them because they're quick yes, but I also thin they're fun too.
Edit - In the (?) I put a goblin and clipboard emoji to represent 'devil's advocate' but it got stripped out, if you were wondering what that was.
I have no problems with emoji in messaging, work or personal. Of course they need to be context appropriate, I don't want :kiss-face: from my boss.
Emojis in source code and program output, eh, not my style but it's harmless.
I've read of a project here that _requires_ emoji tags in the commits, instead of using "chore", "bugfix", etc. — that's a little too much for my taste.
I used to place emojies in our critical failure message box. Basically I have a list of 'bug' emojies, and would randomly select one to display in the message box.
Ideally no-one except developers ever saw this box, but gave myself a laugh at least whenever our app crashed in a bad way.
This should prove quite suitable for rapid web development, where most currently use svg-based alternatives like heroicons etc. I wanted to do a similar project in the past myself but stopped after realizing the enormity of the emoji set; I was also unable to come up with a way to deal with the lack of color in emojis like flags and as such have to tip my hat to their solution of just using country codes. Good work.
Am I missing something or is there some overlooked redundancy here? I was really confused reading the title. “What does less color mean in the context of ‘black and white’? Less grayscale, maybe?” I thought.
You are not. At the very end of the article, right after "Happy emoji-ing!" I had to zoom in to see what they were. Previously, I could have seen them without issue due to the color variation. This is a step backwards.
Some of them seem specially hard to read. I mistook the phone emoji for a "missing character" symbol, the baby emoji for a hand and the dancing emoji for an Among Us crewmate with Elvis hair. The monkeys at the end also looked like some sort of ear at first glance. I like the idea, and most of the emojis featured in the article seem to be mostly fine at small sizes, but some of them don't really seem optimized enough to be recognizable at smaller text sizes.
They removed emojis with human faces. Likely they were afraid of pushback of activists who would say the faces are now all white (on white background) and therefore racist.
Or¹ they started with the older Noto Emoji which already had the blobs because they were the Android default until ~2017. And some genuinely prefer the abstract/cutesy/less-human forms.
[1] far more likely unless you are determined to be offended if a white human isn't the default representation of everything everywhere everywhen.
Emojis have always been yet another way to hijack attention on the screen. It is exactly why they've been so successful. I say "hijack" because the capturing of attention on the internet in 2022 is primarily a function of ad driven platform capitalism, the tactics used by players in this system being dishonest, nefarious, harmful.
And while they succeed at this singular purpose they fail at the thing that actually made emoticons beautiful communication tools: their ambiguity. For example see the way the emoji lexicon had to be expanded in order to be racially inclusive. Emoticons never had this problem. A smiley is a smiley, simple, universal and forever. :)
Two comments regarding flags: it looks a bit awkward, that the letters are staggered instead of deformed according to the flag curving. A whole other idea, of how countries are identified without colors are the oval car sticker symbols. On cars they are getting less common, but they are still commonly used in printed international instruction manuals and warranty notes and sometimes even on product packaging.
> it looks a bit awkward, that the letters are staggered instead of deformed according to the flag curving
The curving is supposed to indicate z-axis movement - a flag billowing in the wind. The deformation would be of a bulge/pinch variety and not just following the curve. Either way, it's going to be a lot less legible.
> oval car sticker symbols
Yeah, that would have been ideal. They wouldn't be flags anymore, but I think it's a better compromise. And like you observed, instantly useful.
Unicode already has a way to specify that emoji should be rendered black-and-white for consistency with surrounding text: affixing the combining character U+FE0E VARIATION SELECTOR-15 (examples[0]). Some touch keyboards have the text-style variations in the flyouts.
This only works on emoji for which a variation sequence is defined. Some emoji render the text presentation by default; you can choose the emoji presentation for those using U+FE0F VARIATION SELECTOR-16. Sequences also exist for ideographic variations like single- or double-storey 'a' and 'g', unified CJK, and miscellaneous ones such as serifs for certain mathematical characters.[1]
Edit: An easy way to add the variation selector without a method for Unicode input (though there's a registry hack for Windows to enable Unicode alt codes): put the emoji in an address bar, then add the URL-encoded variation selector,
For example, there is no text style "pizza" emoji.
This particular project is an attempt to provide a black and white emoji rendering for all emoji, which is distinct from the Unicode approach of allowing specific text / emoji stylizations for certain emoji.
That's Segoe UI Symbol: https://docs.microsoft.com/en-us/typography/font-list/segoe-.... The reason these exists is for backwards compatibility: fonts that bring their own colors is a weird thing that is brought from the future, so Microsoft has always these fallback fonts. Ironically, the biggest consumer of these is Google Chrome until they bothered to fix their browser to render color fonts (emoji fonts are very messy - Apple uses PNG-in-OTFs, Google uses a proprietary bitmap format, Adobe and Mozilla supported SVG-in-TTFs, and Microsoft having a custom vector format). Also, there are other contexts where color is a bad thing, so this set is used instead.
> Sequences also exist for ideographic variations like single- or double-storey 'a' and 'g', unified CJK, and miscellaneous ones such as serifs for certain mathematical characters.[1]
I couldn’t find the variations for a and g in the text file. Are you sure these are standardised variations?
They aren't! Good catch; I'd assumed from the example. Another slip-up: ideographic should modify unified CJK, not the Latin letters.
Variation sequences for double-storied 'a' and 'g' were proposed, as part of the only Unicode proposal with substantial Latin glyph variations,[1] to address the problem raised by the answer to the FAQ,
Q: Can all glyph variations be represented with variation sequences?
…that there are separate codepoints for only the single-storied glyphs, meaning only fonts that assign the double-storied glyphs to the original ASCII codepoints can contrast the variations. The proposal went through two rounds of UTC,
It did leave an extensive debate as precedent for what glyph variations are to be used for,[2] namely not localization as the proposal had largely intended. A shorter discussion in retrospective occurred when it was brought up again in 2018.[3]
I know this is morbid, but the first thing that popped into my head was tombstone engraving. Maybe it’s because I work in b/w thermal printers all-day every-day reminding me of the limitations of monochrome … and the shortness of life.
A related issue: Some random old, normal symbols are, for some reason, nowadays displayed by many fonts as emojis, i.e. as colored pictures. For example, the "left right arrow" symbol, commonly used in formal logic for "if and only if", now often appears white with a blue background: ↔. While others have been left untouched, like "left arrow": →. This is so annoying if you actually need that symbol in a logical context! Basically, they have made the symbol unusable in many fonts. They should have added a special emoji symbol if they wanted picture arrows...
More amusingly is that this is platform dependent. For example, on macOS ↩ U+21A9 LEFTWARDS ARROW WITH HOOK shows up as monochrome but on iOS it is rendered with colors.
I also see the the color image on Android. That explains why some links (jumping from endnotes back to the text references) on old websites sometimes have this "emoji" in them...
That is more a problem on mac. Windows still defaults these to white and black version, unless you prepend variant selector to optin into the emoji version.
Some softwares do intentionally ignore the default and turn they into emoji (discord for example), but that is a software thing.
And also, white and black rendering can be forced with variant selector if you absolutely don't want them to be emoji. (again, if software don't mess them up intentionally)
BTW, windows used to have a bug that its emoji keyboard outputs arrow without variant selector, so it is not even a emoji when displays on windows, but it is now fixed. Proper selector (0xfe0f) have been pretended to the character.
On Android the problem also occurs. The variation selector for text (︎) does not work for me either:
Neither after symbol: ↔
Nor before symbol: ↔
I think you're stuck with the emoji arrow for that font: neither U+2194 ↔ LEFT RIGHT ARROW nor U+2B0C ⬌ LEFT RIGHT BLACK ARROW have any defined variation sequences. ⇔ and ⟺ are probably text-style, but you can't change existing content.
This isn't entirely random. When Unicode started including colourful emoji rather than just monochrome glyphs they added an attribute to each character to say whether it should be rendered in colour by default. And they retrospectively gave a bunch of existing symbols the colourful attribute.
As you noted, this broke a bunch of existing use cases. It is infuriating.
150 comments
[ 2.3 ms ] story [ 150 ms ] threadassume a human is a frictonless sphere. given the skin color "default", solve for emotion rolling_on_the_floor_laughing
I guess you mean skeuomorphic, with heightened 3D presence caused by heavy use of light and shadow - roughly, the sort of effect you would get from a static rendering of a cheap 3D model in a Unity mobile game.
I agree with you, although I will say that the current version of the Noto Color Emoji font is (IMO) the best up-to-date color emoji, because it mostly eschews this fake realism that feels uncomfortable and disconcerting in other emoji fonts. I'd prefer hyper-stylized "blobs", but I think they deserve some credit for avoiding the worst of skeuomorphic design.
See for example the "realistic" 3D rendering of the hand on the Apple emoji for "thinking face", it's firmly in uncanny valley for me. [1] The Noto emojis remain fairly stylized without being hideous like the Microsoft emojis.
Google also deserves from credit for drastically improving the rendering of many of these emojis over time. This has happened quietly enough that I doubt most people have noticed. They brought back the more blob-like turtle [2], which really deserves to be compared to the horrible, awkward plastic children's toy that is the Apple rendering. Or take a look at how awful the gradients are on the Android 8-10 emoji [3] and compare to more recent versions. [4]
I think we will look back at awkward 3D renderings in many emoji styles as a mistake. They remind me quite a bit of the terrible DreamWorks animation style [5] of the early '00s.
[1] https://emojipedia.org/thinking-face/
[2] https://emojipedia.org/turtle/
[3] https://emojipedia.org/google/android-10.0/
[4] https://emojipedia.org/google/android-11.0/
[5] https://en.wikipedia.org/wiki/Shark_Tale
They didn't look good even at the very beginning, and surely doesn't match Apple's design language/principle for.. at least 5 years. Apple is supposed to be the company that is obsessed with aesthetics yet they never update/redo the emojis.
I’ve never used that many emoji in my messages than since I switched to iOS because their emojis carry way more meaning to me.
No, not really; the problem is more, taking things that were originally introduced with the intention of being abstract pictograms signifying emotions; and adding enough un-called-for detail (i.e. details not required by the Unicode codepoint description) as to make things like gender and race seem like a relevant or even necessary property.
Consider: in all modern implementations, "emotion" emoji are displayed with... heads. Opaque backing "vaguely skin-tinted" blobs at the very least; full-on human heads with ears and noses and hair in some fonts.
They don't need to be. Nothing about the Unicode codepoint for e.g. U+1F603 "grinning face with big eyes" says the "face" needs to even be visualized as being on a head. It could be doing a cheshire-cat-smile thing, just eyes and a mouth — ":D" but rotated 90 degrees. And, in fact, that's exactly what it was, in the DoCoMo image-font, one of the three that led to the Unicode introduction of emoji!
But for some reason, now we don't just have skeuomorphism (shiny eyes, pink mouths with tongues, blushing cheeks); we have these heads, and ears, and hair; and before you know it, people wondering why the head is yellow rather than some actual skin tone; or why the increasingly-less-generic face shape seems to be more masculine than feminine; etc.
Why not just cut the Gordian knot? Get rid of the "head" part. Get rid of any part that's not required to communicate the concept. Make an image-font of only the Minimum Viable Pictograms for what each of the Unicode codepoint descriptions describes.
Which is orthogonal to skeuomorphism, mind you. This isn't about whether a tongue has a tongue-ish texture to it. It's about whether you should include a tongue at all.
Okay, one vendor opted to do simpler emoji, but the other two displayed faces, right? Moreover, Japanese carriers don’t have the monopoly on inventing small images expressing emotions. The "Western" world had ICQ, AIM, MSN Messenger, Yahoo Messenger, and other IMs (say, Poland’s Gadu-Gadu). And all those had emoticons: typing ":D" would turn into an image of a yellow circle with eyes and a grinning mouth.
And personally, I would prefer the colorful, lively emoji, as opposed to plain punctuation turned 90 degrees. I guess all the current emoji vendors think this way.
Also, I've got an ex-coworker in her late 40's who apparently now types in sentences where the majority of the parts of speech are replaced by an emoji. "Radishes are 'thumbs down' 'vomiting face'" and other statements built with the same grammar. She's an idiot and that was apparent long before this started, but it's gotten worse over the last 4-5 years.
Basically, I'd like to opt out of picture emojis. I'm not sure anything worthwhile has been communicated with them. Well, maybe leave out grandparents. My husband's grandmother isn't a fast typer, so she sends messages mostly made of sweet emojis and you know it's sent with love. But anyone actually trying to make a point with them irritates me. It feels like they're talking like a baby, but in print.
Can people just explain their feelings as they always did in the past, or if that's for some reason not possible, just send a photo or a jpeg of a smiling cartoonish face? Do we really need emojis as they are, sequences of bites that have to be standardized and render correctly on every device and any font?
I just don't get this obsession with emojis. It started as a fun toy, but now it's a huge waste of time for thousands of developers.
But there's no reason that said pictograms need to have a rendering like anything more than what people would draw them as on paper. The Unicode ellipsis exists to encode the separate intent of "writing an ellipsis" from just writing three dots — but it's still just rendered as three dots.
To be clear, you’re saying that Google’s version looks better?
It also transports the idea of "turtle" better - especially when you deal with people who are unaware of the difference between turtles and tortoises, or who know not all turtles have extraordinary large giraffe-style necks. Not every turtle is a Galapagos tortoise.
Consider what turtles are usually looking like, according to Google Images: https://www.google.com/search?q=turtle&source=lnms&tbm=isch&...
I agree with the sentiment though.
[1] https://emojipedia.org/airplane/
[2] https://en.wikipedia.org/wiki/Edgley_Optica
To be clear, I do recognize that the Google one is "stylized" in a way that is not going to appeal to everyone. However, I claim that there is something objectively (or almost objectively) wrong and upsetting about the Apple style here. If you're going to do the whole "3D render" style, you simply have to do a better job than Apple has done here. As I said in my OP, it looks like a poor model from a mobile game or a early 00s DreamWorks film. It's simply not good enough work, regardless of whether you like "realistic" emoji art or not.
Note that Microsoft also had to do a refresh of all their emoji for Windows 11.
For now the Apple/WhatsApp like aesthetic is king. But it’s so fashion driven, you never know what’ll be in tomorrow.
Whatsapp just used Apple's emoji font on android too, for a long time. Eventually they drew their own, often mirrored, versions in the same style.
But poutine was declined? That's an outrage.
It's also interesting they call out emoji being too detailed as a problem. For some characters like Pistol (apple-fied into Squirt Gun) they've copied Apples style -- presumably to avoid confusion. So acknowledging that not all fonts need to look the same is a bit refreshing there.
Though of course the black and white pistol still looks like a squirt-gun
Given they're both called Noto Emoji, it's fair to assume so. Especially considering the new version also has gumdrops which are a classic of old Google emojis.
Who is at fault here? The cowards at Google who fear a PR disaster and self-censor in advance? The extremist minority which often generates similar outrage about such pseudo issues on Twitter? Or the journalists who willingly and uncritically spread and blow such outrage out of proportion without mentioning that the original source of the outrage was just a small group of social justice activists on Twitter, not "the public"?
The blog post mentions increased interpretability and adaptability but I think making emojis more professional and aesthetically pleasing "in a professional setting" might be a big step as well.
Edit - In the (?) I put a goblin and clipboard emoji to represent 'devil's advocate' but it got stripped out, if you were wondering what that was.
Emojis in source code and program output, eh, not my style but it's harmless.
I've read of a project here that _requires_ emoji tags in the commits, instead of using "chore", "bugfix", etc. — that's a little too much for my taste.
Only they do not indicate anything critical. Not everyone has emoji-capable fonts installed.
Ideally no-one except developers ever saw this box, but gave myself a laugh at least whenever our app crashed in a bad way.
> less color
Am I missing something or is there some overlooked redundancy here? I was really confused reading the title. “What does less color mean in the context of ‘black and white’? Less grayscale, maybe?” I thought.
[1] far more likely unless you are determined to be offended if a white human isn't the default representation of everything everywhere everywhen.
And while they succeed at this singular purpose they fail at the thing that actually made emoticons beautiful communication tools: their ambiguity. For example see the way the emoji lexicon had to be expanded in order to be racially inclusive. Emoticons never had this problem. A smiley is a smiley, simple, universal and forever. :)
The curving is supposed to indicate z-axis movement - a flag billowing in the wind. The deformation would be of a bulge/pinch variety and not just following the curve. Either way, it's going to be a lot less legible.
> oval car sticker symbols
Yeah, that would have been ideal. They wouldn't be flags anymore, but I think it's a better compromise. And like you observed, instantly useful.
Unfortunately, international vehicle registration codes are NOT compatible with ISO country codes. It's not even close, IVH are variable-lettered.
This only works on emoji for which a variation sequence is defined. Some emoji render the text presentation by default; you can choose the emoji presentation for those using U+FE0F VARIATION SELECTOR-16. Sequences also exist for ideographic variations like single- or double-storey 'a' and 'g', unified CJK, and miscellaneous ones such as serifs for certain mathematical characters.[1]
[0] https://en.wikipedia.org/wiki/Miscellaneous_Symbols_and_Pict...
[1] https://unicode.org/faq/vs.html
I find this tool handy for listing the Unicode characters in a string.[2]
[2] https://qaz.wtf/u/show.cgi?show=%F0%9F%8C%8D%EF%B8%8E
Edit: An easy way to add the variation selector without a method for Unicode input (though there's a registry hack for Windows to enable Unicode alt codes): put the emoji in an address bar, then add the URL-encoded variation selector,
For example, there is no text style "pizza" emoji.
This particular project is an attempt to provide a black and white emoji rendering for all emoji, which is distinct from the Unicode approach of allowing specific text / emoji stylizations for certain emoji.
https://i.imgur.com/S101VQD.png
Stock in Windows 10. I'm not sure how, but so far, the ones that didn't work were zero-width-joined.
Here along with FIRE EXTINGUISHER, which doesn't: https://qaz.wtf/u/show.cgi?show=%F0%9F%8D%95%EF%B8%8E%F0%9F%...
(Actually, Segoe UI Emoji (https://docs.microsoft.com/en-us/typography/font-list/segoe-...) does have also the fallback B&W emojis, but the proper way is to refer to Segoe UI Symbol first.)
I couldn’t find the variations for a and g in the text file. Are you sure these are standardised variations?
Variation sequences for double-storied 'a' and 'g' were proposed, as part of the only Unicode proposal with substantial Latin glyph variations,[1] to address the problem raised by the answer to the FAQ,
…that there are separate codepoints for only the single-storied glyphs, meaning only fonts that assign the double-storied glyphs to the original ASCII codepoints can contrast the variations. The proposal went through two rounds of UTC,- first as agendum C.4 of UTC 126 (http://unicode.org/L2/L2011/11015.htm),
- then rescheduled (https://www.unicode.org/cgi-bin/GetL2Ref.pl?126-A79)...
- as agendum C.21 of UTC 127 (https://unicode.org/L2/L2011/11115.htm),
- but ultimately wasn't acted upon (C.21.1 of https://unicode.org/L2/L2011/11116-pre.htm)
It did leave an extensive debate as precedent for what glyph variations are to be used for,[2] namely not localization as the proposal had largely intended. A shorter discussion in retrospective occurred when it was brought up again in 2018.[3]
[1] L2/10-280 / L2/11-059 (https://www.unicode.org/L2/L2011/11059-latin-cyr-var.pdf)
[2] https://unicode.org/mail-arch/unicode-ml/y2010-m08/thread.ht...
[3] https://www.unicode.org/mail-arch/unicode-ml/y2018-m07/threa...
https://ibb.co/G30YR3R
Some softwares do intentionally ignore the default and turn they into emoji (discord for example), but that is a software thing.
And also, white and black rendering can be forced with variant selector if you absolutely don't want them to be emoji. (again, if software don't mess them up intentionally)
See also: https://en.m.wikipedia.org/wiki/Variation_Selectors_(Unicode...
BTW, windows used to have a bug that its emoji keyboard outputs arrow without variant selector, so it is not even a emoji when displays on windows, but it is now fixed. Proper selector (0xfe0f) have been pretended to the character.
What do you see here? https://qaz.wtf/u/show.cgi?show=15%3A%E2%86%94%EF%B8%8E+16%3...
Edit:
I think you're stuck with the emoji arrow for that font: neither U+2194 ↔ LEFT RIGHT ARROW nor U+2B0C ⬌ LEFT RIGHT BLACK ARROW have any defined variation sequences. ⇔ and ⟺ are probably text-style, but you can't change existing content.
Hmm… U+2192 → RIGHTWARDS ARROW doesn't vary either, but U+27A1 BLACK RIGHTWARDS ARROW does: https://qaz.wtf/u/show.cgi?show=15%3A%E2%86%92%EF%B8%8E+16%3...
…and as the only one of the four in the Dingbats block, is stripped by HN.
As you noted, this broke a bunch of existing use cases. It is infuriating.