Which name and size should the emojis have?

All I had to add was already said, so I’m just here to say thank you for tackling this and I’m looking forward to the emoticon support being updated and preferably extended into emoji.

I agree that tilted and Konqi shouldn’t be the default, but would very much like to see them done. As for Konqi avatars – yes, please!

andreas_k wrote:Which name and size should the emojis have?

The Glass theme currently uses 22x22.

Edit: I forgot to add in the last post that a general conceptual problem with recipient-side string replacement is that it requires the sender side to type ":P". If your native alphabet is not Latin, that already requires you to do a mode switch to input an emoji.

hein wrote:I think adding the Unicode and DoCoMo mappings to KEmoticons is an OK stopgap solution. I think KEmoticons isn't a reasonable approach to *display* emoji even mid-term, though (we'd end up duplicating the complexity of the font rasterizer). I think as a Framework KEmoticons may live on to do the sender-side replacement and offer a simple emoji IME (e.g. a button you can put next to a text field to bring up a popup with emoji, and possibly supports selection by string, just like Pinyin-based IMEs for Chinese do ... or we could work with upstreams to integrate this into ibus, fcitx & co and make sure they look good on KDE). Recipient-side replacement will stick around mainly for backwards compat then.

Okay sorry, I seem to not have made myself clear on this: I'm not a developer, so I don't really understand, let alone really care about what happens on the technical side.
What I care about is that unicode emoticons are correctly displayed, but certain latin character combinations are also still transformed into pretty emoticons. Whether that's done via bitmaps, SVGs or font rendering is outside my territory. Whatever you techies say works best under the hood certainly is best and I won't challenge that

From here on out, whenever I comment on stuff, please keep in mind that I'm a psychologist. I'm quite good at using computers, but I know hardly anything about how to program them, so you can be pretty sure that my comments aim only at what the user sees or does in the end, not about the inner workings behind that.

And keep in mind that people's habits are changing fast because the mobile platforms do emoji input this way, and you probably don't know some of the most-used IM and chat apps out there (do you use KakaoTalk or Line? because tens or hundreds of millions of people do).

That's a perfectly valid reason for supporting unicode emoticons (which I do agree with, 100%), but I don't see emoticons in the form of latin character combinations going away either, as long as there are still people writing messages with a keyboard, because there it's a lot more convenient than clicking something in the GUI.
On a virtual keyboard, things are completely different. There, it's easier to tap an icon that directly represents an emoticon rather than a combination if characters that together form one.
That's why we should support both, and the recipient should not even notice whether the sender has entered unicode character 1F600 or : D

andreas_k wrote:on the left picture without gradients and right with gradients (nearly every colour had a gradient.


The benefit would be that you can "script" every icon, when you don't have gradients also the shadow was not necessary.

The ones on the left look perfectly fine to me! We also have to take into consideration that emoticons are usually way smaller than what we see here, so in practice the difference will probably be even less noticeable.

colomar wrote:That's a perfectly valid reason for supporting unicode emoticons (which I do agree with, 100%), but I don't see emoticons in the form of latin character combinations going away either, as long as there are still people writing messages with a keyboard, because there it's a lot more convenient than clicking something in the GUI.
On a virtual keyboard, things are completely different. There, it's easier to tap an icon that directly represents an emoticon rather than a combination if characters that together form one.
That's why we should support both, and the recipient should not even notice whether the sender has entered unicode character 1F600 or : D

You know, I don't really object to any of this, so I don't think we actually disagree .

Basically I'm just making two points:

* As a Framework used by app devs, KEmoticons should probably evolve into a direction where it helps chat apps send Unicode emoji instead of strings that must be replaced recipient-side. This is an implementation detail, and it's orthogonal to still supporting recipient-side replacement. It's relevant to this design-focused thread only in the sense that once you have Unicode emoji in text, you have more options than KEmoticons' current approach for display. But moving to sender-side replacement (i.e. turning <whatever means of input> into <Unicode char>) is important because it creates more flexibility for how input can happen, including making it Latin-independent (a mostly analogous example: most writers of Chinese input Han characters by typing Latin strings to select them from a set; many Japanese writers type the same characters using kana syllabic keyboards instead).

* And on the note of those display options, we'll likely end up transitioning towards rendering emoji through the font stack, instead of the raster asset substitution KEmoticons is doing, for all the cited reasons (one of them being that the "emoticons are usually way smaller than what we see here" in your message is only true on your and similar monitors).

andreas_k wrote:

colomar wrote:Actually, that shadow from the eyes looked like a mistake to me, as I don't see why it should be there. I think it should be removed. The gradient in the mouths doesn't offer enough benefit from my POV to warrant giving up compatibility for it, either. Therefore, I think those emojis can leave out all the gradients without losing anything substantial.

on the left picture without gradients and right with gradients (nearly every colour had a gradient.


The benefit would be that you can "script" every icon, when you don't have gradients also the shadow was not necessary.

I think that looks good without the gradients, too.

hein wrote:You know, I don't really object to any of this, so I don't think we actually disagree .

Basically I'm just making two points:

* As a Framework used by app devs, KEmoticons should probably evolve into a direction where it helps chat apps send Unicode emoji instead of strings that must be replaced recipient-side. This is an implementation detail, and it's orthogonal to still supporting recipient-side replacement. It's relevant to this design-focused thread only in the sense that once you have Unicode emoji in text, you have more options than KEmoticons' current approach for display. But moving to sender-side replacement (i.e. turning <whatever means of input> into <Unicode char>) is important because it creates more flexibility for how input can happen, including making it Latin-independent (a mostly analogous example: most writers of Chinese input Han characters by typing Latin strings to select them from a set; many Japanese writers type the same characters using kana syllabic keyboards instead).

* And on the note of those display options, we'll likely end up transitioning towards rendering emoji through the font stack, instead of the raster asset substitution KEmoticons is doing, for all the cited reasons (one of them being that the "emoticons are usually way smaller than what we see here" in your message is only true on your and similar monitors).

Exactly, we fully agree

Just some weird sketches of Emoji's that aren't turned facing the camera with "ROFL", "LOL" and "Smile" in that order

Um... those look like a Xenomorph smiley just jumped in front of the normal smiley...

But on second look it seems that it's just the nose and shading which confuses me. They look kinda nice, but I'm thinking they're too artistic and detailed to be used as emojis?

PS: Actually, I imagine they look like what Picasso would have painted if he was designing smileys.

Haha! Xenomorph, dude you've been watching waaay to much aliens
But yes, will redo them the idea being that we should pay around a little with the form.
We can use whatever that conveys the message so there is a lot of room to play

Sounds good.

But are there any limits to how detailed emojis can be? I mean, as long as they have to be inline, they can't be larger than the font itself, so that would put a limit on the height dimension at least.

I'll be totally honest and say that I haven't a blessed clue but let's assume what you said is true and roll with that for now

jensreuterberg wrote:Just some weird sketches of Emoji's that aren't turned facing the camera with "ROFL", "LOL" and "Smile" in that order

Keep in mind that as hein pointed out, for compatibility reasons, emojis should use no shadows or gradients.

jensreuterberg wrote:I'll be totally honest and say that I haven't a blessed clue but let's assume what you said is true and roll with that for now

It is generally agreed upon between my developer friends that I don't have a clue about design, so just so we're clear, I reserve the right to be the most ignorant of us!

I'm just imagining that unless you want to go the way of certain chat-programs (facebook, Line, etc.) and include humongous smileys, then we really have to stay within the same height as whatever font is used.

veqz wrote:

jensreuterberg wrote:I'll be totally honest and say that I haven't a blessed clue but let's assume what you said is true and roll with that for now

It is generally agreed upon between my developer friends that I don't have a clue about design, so just so we're clear, I reserve the right to be the most ignorant of us!

I'm just imagining that unless you want to go the way of certain chat-programs (facebook, Line, etc.) and include humongous smileys, then we really have to stay within the same height as whatever font is used.

As can be read in the thread though we currently don't have scaling and are locked into 22x22px anyway. The other consideration mentioned was gradient use.