The emoji search in GNOME Characters is frustrating because it relies on exact keyword matches. For example, searching for “happy face” doesn’t return relevant results, forcing me to guess emoji names or try multiple terms. This approach is inefficient, especially for users who aren’t familiar with the precise keywords for each emoji. A more intuitive search would enhance usability and speed.
IMPLEMENTATION
Simplest would be to expand the search to accept multi-keyword queries, like “happy face” or “thumbs up.” However, a more effective solution would be to implement simple ML models, such as basic classifiers or k-nearest neighbors (KNN), to better interpret natural language queries. I suspect that even these basic ML models would significantly improve search results and adapt over time to user behavior, offering more relevant suggestions for queries like “I want a happy emoji” or “thumbs up for approval.” or “person shrugging”.
@daiki @cdavis I’d like to take this up. Could you assign this to me? Of course first there has to be consensus, so what do you all think of this, do you agree it’s useful?
I’ll duplicate my response from Reddit here with some additions.
I see no need for ML/NL models if emojis will simply have a lot of tags or aliases. There are only so much words that can describe every single one of them, so it’s an inherently finite list. Search itself could also support synonyms if we will go an extra mile. Emoji selector should provide smooth experience and adding more computations under the hood will make it much worse on slower computers.
I also didn’t encounter the issues with finding thumbs up or shrugging. And while “happy” didn’t yield any results, when I started to type “smiling”, I got relevant ones after just a few letters. There’s an issue though with “smile” and “smiling” yielding different results, but it’s fixable with adding more aliases/tags.
I find the solution implemented in Telegram reasonable enough and they just use word search with more than one name/alias/tag for every emoji. To see what I am talking about, type a colon (:) and start entering the emoji name. Somewhat similar solution is implemented in Slack, but with lesser amount of aliases (as I see it).
Example from Telegram with “happy”:
So there’s really no need in ML stuff implementation, more aliases (like with “happy” for smiling ones) with better word search that accounts for different word forms (to address the issue like smile/smiling yielding different results).
Utilising an ML model for that is, of course, interesting, but it will lead to:
- Bigger computational load for the operation that should ideally be instant.
- Additional work to ensure the correct work in all supported languages.
- Need to maintain this feature in subsequent releases. It’s much easier to maintain the list of aliases rather than ML model.
It’s also worth noting that search queries like “I want a happy emoji” are a bit too verbose (“I want…”) and likely out of scope of this project. They aren’t widely supported in other similar selectors, so there are no user expectations for them to work this way. Such verbose queries require a way to separate the query itself from the rest of the sentence since words like “i want” are irrelevant for the search itself.
There’s also a native emoji picker that is invoked by Ctrl+; It is intended to be a primary way to pick emojis in GTK apps. It can find shrugging and thumbs up, but still doesn’t have as many aliases as other emoji pickers.
GTK has a pretty nice emoji search integration, which might be possible to replicate in Characters.
GTK currently uses Emojibase, which fetches data from multiple sources. If you look at its data, it does have a lot of keywords for each emoji already:
1 Like
@bragefuglseth Thanks for pointing to the source. Indeed, Emojibase has a lot of keywords, but they don’t seem to be used in a picker. Implementing it should improve the situation.
Emoji has “happy” in the keywords list
It doesn’t find it by “happy” in a picker
