Implemented UX issues with emoji panel

Neutral Singh

Well-known member
Thank you so much for taking care of smilie overlay UX on desktops... 👌👍👏

Well, I have been playing with smilies overlay on Galaxy Note 9 (one of the biggest screens?) and notice that the smilie overlay built into the xF acts erratic most of the times and destroys the UX of smoothly posting a message, even if only one smilie is being posted.

The attached video is self-explanatory.

View attachment xF Smilies 720.mov

  • The video starts with device's built-in keyboard pushed down after writing the text.
  • Now, pressing the smilie button usually takes 1-2 attempts for the overlay to show up. No idea why!
  • Pressing the first smile image, somehow triggers the mobile device's builtin keyboard every time. So, the xF smile overlay and the mobile device's built in keyboard literally fight with each other for space.
  • Now, pressing/clicking the smilies does not show if they are being typed into the xF reply box or not.
  • Then, I need to push the device built-in keyboard down and then click outside of the xF smilie overlay to view the reply box.
  • This happens all the time whenever I like to post a smilie and is pretty frustrating to say the least.
  • Now, towards the end of the video, you can see how easy it is to give input of smilies from the mobile device's keyboard, directly into the reply box, thus completely bypassing the xF smilie overlay.

Suggestion: On a mobile device or narrower screens, can clicking the smilie button trigger the mobile device's built in keyboard, thus bypassing xF smilie overlay? The mobile device's keyboard already has a smilie button built-in and is super fast to give input into the xF reply box. And you can easily see, which smilies are being posted in the reply box. This automatic triggering of mobile device's keyboard will result in smooth typing and experience overall.

Thank you
 
Upvote 1
This suggestion has been implemented. Votes are no longer accepted.
While there are still some issues, it's worth mentioning that I can tell from your video that your testing isn't on the current code, thus you're actually missing some of the tweaks that we applied there today, including specific changes relating to the keyboard behavior.

In terms of your last comment though: we basically can't do much of anything with the OS keyboard. iOS doesn't even expose when it's displayed. The easiest flow for emojis is almost always going to be something built directly into the input method itself.
 
I noticed yesterday the way the menu covers the editor blocking the emoji's being inserted, so had a look around to see how other places do it to see if it could be improved.

It's much smoother in native apps like Discord because they have a dedicated button next to the reply field that brings of the native iOS keyboard, which is ideal, but I guess not possible in a web browser.

187820

I tried out Discourse and their implementation is rubbish, it closes the overlay with each tap and refreshes content on the page moving a lot of stuff around.

IPS opens the menu and scrolls you straight to the search box, which is also quite annoying as it also closes the menu which each tap. So with each open and tap you're scrolling around a lot.

I much prefer this implementation to all the others I've tried, and I like that you can tap multiple smileys in a row on the XF version, but it would be nice if there was some kind of feedback with each tap, seeing as you can't see them appearing below the menu.

Maybe a very slightly zoom of the image on tap, or a background colour highlighting green that fades away, so show it was successful action.
Or a little green checkmark appearing and then fading out. I'm not sure. Or maybe a green background colour instead of blue, as the blue look like it's selected, but doesn't really relay a sense of successful insertion into the post (if that's all you have in your field of view on a small screen)
 
Or maybe closing the menu after each tap is best, which is why it's done that way elsewhere, as long as you don't get scrolled all over the place. A little subtle tap feedback would possibly be best.
 
If the background colour was green at the instant of the tap, then faded back to blue, that could be quite nice, and would provide feedback of multiple taps on the same icon.
 
While there are still some issues, it's worth mentioning that I can tell from your video that your testing isn't on the current code, thus you're actually missing some of the tweaks that we applied there today, including specific changes relating to the keyboard behavior.

Ok! played with the keyboard and I must say its a great improvement overnight and certainly a much much improved UX! 👌

If the overlay can be made a little transparent, this will allow users to see what is going on behind the overlay, without closing it. This will close the deal for me! :)
 
Last edited:
I noticed yesterday the way the menu covers the editor blocking the emoji's being inserted, so had a look around to see how other places do it to see if it could be improved.
I have the same point, it is annoying when I want to add smile in mobile and the overlay cover all the editor and I cannot even see my post nor relocation the smile. I prefer XF1 method.

It is much appreciated if you can rethink about it guys and find better way to use smiles specially in mobile.
 
Overall, I'm going to consider this implemented as we have made a number of improvements since the original suggestion. Most recently, we've added some feedback when an emoji is inserted.

Frankly, on mobile, any non-native implementation is always going to be very difficult given some of the limitations we have to deal with. Of course, you can still just use the native emoji keyboard then.
 
That's pretty cool Mike, nice one!

Your new emoji picker is still really useful on mobile as it allows you to search - which you still can't do on the native phone emoji keyboard (at least on iOS), so until Apple catches up in that department too then it's a very welcome new feature that will come in useful on desktop and mobile.

The whole implementation is definitely the slickest and most usable out of all the competition now, great work :)
 
Top Bottom