Work on better emoji support

feature
1

Hi everyone,

in the next weeks I will work to improve the emoji support of Discourse :raised_hands: (planned for Discourse Version 1.9)

Here is what I’m planning to do:

  • Update the emoji.rake script to parse the 5.0 emoji spec (Full Emoji List, v13.1) It also implies an updated folder hierarchy for skin tones of emoji images. I intend to follow this one:

We would have baby.png and baby/2.png, baby/3.png… Following the skin tones levels.

  • Improve the UI to be close to the Twitter UI and notably allow for skin tone selection!

Low fidelity expected UI:

  • the filter is probably to be discussed more or for a later time
  • I moved the favorite emojis to its own line, to be on par with Twitter UI, we should probably discuss this

Questions:

Other notes:

V2 Work:

14 Likes
2

Since :baby: is :baby:, what about :baby:3:?

2 Likes
3

Slack uses: :baby::skin-tone-5:

4

No reason to not support that as well, but I like mine, it’s shorter :slight_smile:

5

Yeah looked at it and I think it’s too verbose

6

Will the default skin tone (used for :baby:) be customizable? Site-wide or per user?

1 Like
7

Why not both? :slight_smile:

2 Likes
8

Even better! I try not to be too demanding when suggesting features…

9

:baby: should always use the default cartoon yellow.

The selected emoji skin tone should persist in DB, so when you use the modal to select an emoji it tries to apply the current selected skin tone if available.

8 Likes
10

If I understand correctly, @tophee was not requesting to choose the meaning of each skin tone, but if the default checked could be a different one than (1).

I can understand people would want this, I think it can come in a later time.

3 Likes
11

Very excited to see this moving forward!

Here’s a screenshot of the (web based, since on mobile you have keyboard emoji support) Twitter emoji picker this will be based on

image.png556×692 82 KB

And let’s not forget search…

image.png554×693 51.8 KB

5 Likes
12

Can’t wait for the search/filter. I’ll have to give the twitter version a bash to see how it works from a purely keyboard perspective (without using the mouse).

Fleshing out the suggestion on specifying skin tone a little further with respect to the suggested option to change the default at a board and/or user level.

I would suggest the ability to specify the skin tone explicitly in a comment/post (what’s the discourse terminology?), but if you were to use the default, without specifying the skin tone, then the board default skin tone would apply to a non-specific-skin-tone-emoji, with a user preference overriding that.

##Example

:woman:   → 👩 – woman
:woman:1: → 👩 – woman
:woman:2: → 👩🏻 – woman: light skin tone
:woman:3: → 👩🏼 – woman: medium-light skin tone
:woman:4: → 👩🏽 – woman: medium skin tone
:woman:5: → 👩🏾 – woman: medium-dark skin tone
:woman:6: → 👩🏿 – woman: dark skin tone

Should the board default be changed to skin tone 5, then the following would result

:woman:   → 👩🏾 – woman: medium-dark skin tone
:woman:1: → 👩 – woman
:woman:2: → 👩🏻 – woman: light skin tone
:woman:3: → 👩🏼 – woman: medium-light skin tone
:woman:4: → 👩🏽 – woman: medium skin tone
:woman:5: → 👩🏾 – woman: medium-dark skin tone
:woman:6: → 👩🏿 – woman: dark skin tone

So basically, :woman:X: are specific and never change no matter what the board or user defaults are, they’re constants essentially.

Whereas :woman: is a variable and follows the board default, which can then be overridden at the user level.

Just thinking out loud here, and I have no idea what kind of level of complexity this would add to Discourse and whether or not it is desirable.

3 Likes
13

This is awesome, so happy you are making good progress here.

I think there is an order of operations that is a bit critical here:

  1. We need to choose a syntax for skin tone. Cause this is going to feed in to all of the work. Update auto completer to support new syntax.

  2. We need to update our emoji sets to absolute latest and update all the rake tasks, fine for moving the aliases around so they are centralized if it makes sense.

  3. We need to revamp the emoji picker.

  4. Investigate if there is any way we can normalize our emoji picking so the new minimal version of the control can also be used for : completion.

Each one of these can be shipped by itself and each builds on the previous task.

I think the first super critical task in the list is picking syntax.

We have a few options

  1. :man::skin-tone-5:

  2. :man::st5:

  3. :man:st5:

  4. :man:tone5:

  5. :man:t5:

  6. :man:5:

Personally, I prefer :man:t5: for very subtle but important reasons.

  • I type : and the emoji picker pops up, I type m a and press ENTER on man.

  • Cursor is placed here: :man:^

  • I type t a new picker pops up and lets me pick between the tones

  • I type ENTER

  • Profit :dollar: :money_mouth: :sunny: :moneybag:

The succinct version :man:1: does not give an opportunity to pick a tone visually, which is very annoying. The other forms are just too verbose.

I am strongly against supporting multiple syntax forms here, we got to pick a winner.

Strongly recommend against even trying to tackle this, it creates a situation where every markdown document needs attached metadata about defaults, otherwise it is not interchangeable. Changing defaults is a nightmare cause you need to rebake everything.

I think longer term the apple approach is pretty sane but also quite tricky to implement. What they do is, if I last selected :man:3: next time it will try to pick :man:3: when I type :man but it is also riddled with complexity.

10 Likes
14

Hey, where’d that poll go?! :smiley:

I can absolutely live with the tX syntax, it’s still nice and short :slight_smile: I also think that since it is so nice and short, it lessens the need for board and/or user defaults on skin tone.

I still think a user default would be nice, just on its own. Perhaps this is extension territory?

15

Defaults are extremely problematic if this leads to inconsistent markdown.

If :man: means :man:t1: one board and :man:t2: on another board we have a huge interoperability problem. People replying via email don’t know what they are going to get, people copying and pasting stuff between boards do not know what they will get.

If the defaults merely hint at how the auto-completer functions and do not amend the semantics based on the board you are on I am more open to it. But this would be a V3 thing, not a V1 thing.

7 Likes
16

definitely, the way autocomplete works makes :baby:t3: a clear winner for me, I think you are right.

7 Likes
17

As much as I love the enthusiasm and excitement here, please make sure admins have the ability to disable skin tone selection and keep things as they are. I can see how some people might consider it unpleasant having to choose the tone. Also, it opens some room for delicately racial joking.

I prefer that all people are symboled by emojis whose skin is yellow as in the Simpsons, no matter what color they really are. It’s quite beautiful in fact when you come to think about it!

4 Likes
18

I am super mixed here, this is all part of the emoji standard. You can’t really disable :eggplant: despite the fact that John Oliver uses it weekly to make offensive jokes.

I think if a community is using skin tones as an abuse vector you might as well just disable emoji globally. You have bigger problems.

2 Likes
19

Well over the period of one and half years we have had one racial joke as far as I can remember, so we don’t have a real problem. Especially as that guy got himself permanently suspended after he was released from the suspension. The racial joking was supposed to be a sidenote in my post.

Still, it’s obviously the wrong forum for my argument then and I am also many years late. I must live it with. Carry on. :slight_smile: (yellow)

20

Is the numbering of skin tones part of the emoji standard? It looks like a ranking to me as described above in this thread which sits uncomfortably with me.

I’m with @rizka on an admin setting to disable skin tone, or at least to give skin tone less prominence in the UI so it’s not used except by those who look for it and find it as an advanced feature.