I believe we want to have a help function of some description - so that user’s can see the emojis that are at their disposal. Over to @sam to please describe this (and any other aspects of the emoji feature) more fully and provide his point of view on implementation.
The main reason I would like to have https://github.com/discourse/discourse/tree/master/vendor/gems/discourse_emoji have a traditional gem dependency there is so we can get all the latest and greatest emojis.
Currently we have a year old fork of gemoji it is missing all sorts of classics like
I think before that we need better auto-translation of common ASCII smileys to their emoji equivalent. At the very least the ones that begin with a colon! For example when I type I really should get
:wink automatically inserted on my behalf and when I type I should get
:stuck_out_tongue and so forth…
(I can’t type it properly with colons on both sides because we do not hoist preformatted blocks out before the emoji plugin runs… sigh. So assume I have typed a colon on either side of the words please.)
:o :open_mouth :p :stuck_out_tongue ;) :wink :/ :confused :) :smiley :D :laughing :( :frowning :| :expressionless :$ :blush :# :grimacing :'( :cry :x :no_mouth
As you can see, it’s pretty hard to remember some of the emoji words here, but the ASCII smiley patterns are well known and almost all of them start with colon, except wink! So why not have the substitution and auto-completion of these common ASCII patterns plus the emoji words? Best of both worlds…
Canon is here for validation of common colon-plus-other-character patterns:
Use more standard smiley codes (`:)` instead of `:smile:`)
Add smiles button to composer panel
So there are a few issues I’ve come across after spending some time investigating
- The way
gemojipopulates an app with emojis is via a rake task: https://github.com/github/gemoji/blob/master/lib/tasks/emoji.rake and this appears to be hardwired to copy images into a
public/imagesdirectory. To truly have
gemojiwork as a dependency to
discourse_emojiwe want the target directory to be
vendor/assets/images- looks to me like we may need to fork
gemojiand use our own fork as the dependency.
- Helper methods like
gemojiappear to be useless to us. We seem to need js and css and as far as I can tell, we’re not doing anything with emojis in Ruby.
So … if the intention is to keep up to date with the emojis then it seems to me that we’re probably better off spending the effort to periodically update
discourse_emoji (by hand) to use the emojis that are in
gemoji. There are a couple of js libraries (see the README of GitHub - WebpageFX/emoji-cheat-sheet.com: A one pager for emojis on Campfire and GitHub) that appear to bring in emojis and they seem to adopt the same approach of replicating all the images etc. locally.
Perhaps I’m just missing the point completely but after the end of several hours of looking at this, I don’t see how having a traditional gem dependency on
gemoji helps at all. Please help set me straight
Also, I don’t see this classic box/package thingy in any of the emoji lists - what is it?(!)
Before we even consider this we need to properly hoist PRE blocks etc.
Also there is a fair amount of risk that you would introduce a smiley where you did not intend to, it should definitely be a plugin option not on by default imho.
I am ok with that, if there is not clean way to add the dependency we should not jump through too many hoops to add it.
Not sure where that emoji was, saw it in one of the later gemoji commits.
We are also missing a number of basic smiley type emoji. We’re missing a lot…
So I’ve updated the emojis from
gemoji in this PR
Will work on the help/search feature next. I see something similar done in GitHub - rhardih/gemoji-chrome: Chrome plugin for finding and inserting gemoji shortcodes. Any comments regarding the UI suggested there?
Update: I’ve been working on a search feature that follows the gemoji-chrome plugin. Have a proof of concept working but there is still much to do and unfortunately, I’ve run out of time for now. I plan on returning to this by mid August and finishing it by the end of August.
This work-in-progress is here:
Before you get too far, I have to say I am not a fan of that UI. I do prefer the way iOS does it, by grouping the emoji (by tabs) into a couple basic top level categories at least rather than throwing them all into one giant bucket of noise. I don’t want 3 levels of categorization, that’s insane, but one giant list is just as insane.
The other thing that’s essential here is being able to search for synonyms, that is, should also be findable not just as “open mouth” (seriously, wtf?) but as “:o” and “surprised” or “shocked” as well.
I find one thing I dislike deeply about the emoji, although I generally like them a lot, is that one person got to decide a single English name for the icon that may make absolutely no sense at all to me.
Between this and commentary about synonyms etc., it sounds to me like this feature needs design input and consensus on its requirements. I’m downing tools on this for now. If anyone else is interested, please feel free to pick up and run with it.
Did anyone ever manage to make any progress with this? I am trying to use the Gemoji in an Android app, but I am having massive problems finding some way of getting the gemojis sorted into their categories (short of manually renaming and sorting 1,000 icons!).
Please let me know if you have any ideas! Thanks!
It’s worth nothing that @eviltrout addressed my primary complaint here by auto-translating common ASCII smileys to emoji words now so when I type
:) I get
As for the rest, here’s a screenshot of how iOS does it – some kind of basic grouping by “type” is a good start:
As you can see, the emoji are broadly grouped by the tabs at the bottom there:
- recently used (clock face)
- faces (face icon, 9 pages)
- plants and animals (plant icon, 6 pages)
- objects and things (bell icon, 11 pages)
- places and houses (car icon, 5 pages)
- words signs and symbols (speech bubble icon, 10 pages)
Interestingly, each page is also generally themed. For example the first 3 pages of plants and animals are animals, then a page of plants, then a page of moon and stars, then a page of weather icons.
I still maintain that searching by word is important like “faces”, but that would require us to create and maintain synonyms for all of them. Might be easier to just copy the groupings wholesale from iOS to start with.
Thanks for the reply! I agree with your point about auto-translating, the problem is, as you say, with manually adding synonyms to each icon.
The problem I’m having is grouping them; we can’t just “copy” the groupings from iOS, we have to manually rename and sort each emoji icon into the “correct” Apple category.
Another possible improvement. Slack has a really excellent emoji autocompleter, probably the best I’ve seen to date:
The horizontal layout is vastly superior for autocomplete browsing:
And clicking the smiley brings up a sorted navigator, sort of like how iOS does it, but a bit better still:
Very welcome to PRs in this area along those lines, starting with the horizontal autocompleter.
One step closer to Emoji Dick…
iOS 8.3 changed the Emoji keyboard a fair bit…
It scrolls horizontally and the categories have been adjusted.
- Huge pain to change category in 4 inch devices. It’s hard to touch the right button…
- Only iOS 8.3 shows Unicode 8 which is not yet released.
Anyway, it’s much easier to find the right emojis.
A huge change I would like to see in Discourse is the various flavors of skin tone for emojis, it is unfortunately a very complex change.
It does solve the “Mario, 1 black cop and a bunch of white cops problem”
Off-Topic but related