Why it’s important to test on the devices your users use, and a little about Emoji

For me, this is the first article, I will try to write everything intelligibly and interestingly. Enjoy!

A little bit about yourself

As I already said, my name is Danil, and I am a web developer, originally from Kudymkar, a small Komi-Permyak town, now I live and work in Samara. I am developing a DARM system interface.

Since MegaFon is a huge company, it is necessary to process a huge flow of requests from different channels. Here is how we solve this problem:

• at the moment we support 5 channels (VK, MegaFon application, our website, mail and SMS);

• the system is omnichannel, that is, the user can start communication in the application, continue on the site, and the operator will see this and seamlessly continue the conversation without leaving the cash register.

History of Emoji

Let’s dive a little into the history of emoji to understand what we’re dealing with.

Difference between Emoticons and Emoji

Emoticons (smiley) is a combination of symbols, a pictogram depicting an emotion, created from different typographic signs.

Japan has its own emoticons, they are called kaomoji (from the Japanese kao – “face”, and moji – “sign, hieroglyph”) – they are distinguished by increased complexity and decorativeness.

Emoji are specific ideograms laid down in the Unicode standard. To convey an emotion with a smiling face, you need a special emoji, and if you use emoticons, then we have an infinite number of options that are limited only by fantasy.

In short, an emoticon is a set of characters, and an emoji is a finished picture.

First appearance of Emoji

The very first emoji set was invented in 1999 by Shigetaka Kurita. He designed it for the Japanese telephone operator NTT DoCoMo. In total, he drew 176 12×12 pixel emojis representing people, places, and objects. As planned by Kurita, it was a set of “symbols that conveyed the full range of human emotions.”

Due to the fact that this was an internal standard of the NTT DoCoMo operator, only clients of this operator could send and receive such emoji. After a while, other companies also began to make their own emoji, and only users within a particular system could use them. It was not possible to transfer them between clients of different companies. And only in version 6 of unicode (2010), emoji was included in the standard. Now it is possible to transfer emoji between systems, and their popularity has skyrocketed.

Magic emoji

Emoji have one magical feature, they can, like rangers, unite into one big ranger.

Combined emojis, such as family, occupations, etc., are actually combinations of simpler emojis, with zero-width joiner (U+200D) ZWJ characters in between. Thus, different sets of families, professions, country flags, as well as emoji with different skin colors are obtained.

From history to problems tasks

Our users (operators) are constantly trying to somehow enliven the dialogue with the client, find a common language with him and emoji are perfect for this. Not a single conversation can do without them. 😎 Before we started adding the keyboard, we were told that the operators used a Word document, where they had some emoji prepared. If necessary, they copied emoji and pasted them into the input field. We were very surprised by this and decided that it was time to make a keyboard. And, oddly enough, this task is not as trivial as it seems.

Emoji are pictures, which means they weigh a lot. Since emoji is a unicode standard, it means you can make fonts with them. Every system has a built-in emoji font. There are also other emoji fonts from third party font designers that are not installed by default. If you wish, you can even include them on the page as ordinary fonts, but they can weigh ~ 10mb, which is a lot, LOTS OF.

Google emoji font size

It is clear that there is no way to use them on the web, since it is very painful to load such a volume over the network, no user will have enough patience. Therefore, it remains possible to use only system fonts. But this option has a problem that on each system emoji look different and can be interpreted differently.

Here is an example of a yellow face screaming in fear, an emoji meant to represent horror and fright. At Apple and Google, they look similar, everything is more or less good, but at Samsung, umm, something went wrong here, the character was not horrified, but it seems to have expired. At Microsoft, the character just shouts to someone in the distance.

This is how aliens differ. Samsung is more like an octopus.

Still, I want the emoji in the project to be the same regardless of the runtime environment, so that there are no conflicts, and the interface just looks nice. And how to do it?! 😵‍💫 I’ll tell you about it a little later… And now let’s get back to our task.

What do we have?

We knew that our users only use windows, since the system is internal, so we decided to use the system font, which was quite tolerable for us.

As a result, our keyboard looked like this:

Why did it happen?

The fault was a different version of windows used on the operators’ clients. Operators work through VDI (remote desktop), where windows server 2012 was used, in fact, this is windows 8. Windows 8 did not yet have a colored emoji font, such a font appeared only in windows 8.1, before that a character font was used.

Here is a comparison of emoji from SegoeUI Symbol font from windows 8 and Noto Color Emolji from Google.

Well, in the history of weird emoji. Here’s a funny misunderstanding of designers I found while looking for material for this article – this is the legendary hairy heart from android 4.4.

What are the solutions?

And so, now we will discuss the solutions. Having studied similar topics on the network, we came up with the option to replace emoji on the client with pre-drawn pictures. How can I do that?

To begin with, let’s figure out how best to store them, we found two options:

1. Separate file for each emoji:

We save all emoji into separate pictures of different sizes, and then we get the idea of ​​​​accessing emoji like this: /64/U_1f60d.png. The principle is to put image files in folders for different sizes, and for file names we use the emoji number, in Unicode.

pros

Minuses:

• The network is heavily clogged with a large number of requests, and this is very scary. For example, because of this, we may pause some other more important requests (content pictures, scripts or basic fonts).

2. Bundle file for all emoji:

We glue all emoji of the same size into a large picture. Then we will have several pictures: 64.png, 128.png, etc. Here the filename is the emoji resolution. The size of the font differs dramatically, for regular text, a size of 20px is enough, it weighs 500kb.

Pros:

• All emoji of a certain size are loaded at once.

• Uploading is done in one request, and if another emoji of the same size is required, then re-uploading is not required.

Minuses:

• Extra emoji are loaded that may not be used, we drive extra traffic.

• Here we need another file for the markup of the bundle, in order to understand in which place, which emoji (can be automated through assemblers like webpack).

Further through RegeXp we find all the emoji in the text and replace them.

What to replace there are also two options:

1. span wrapper

This option involves wrapping each emoji with a span tag and inserting our image as a background image. If we don’t have a replacement, then the native emoji will be rendered as a fallback value.

<span
    aria-label="🤫, partying_face"
    style="
        width: 22px;
        height: 22px;
        vertical-align: middle;
        display: inline-block;
        background-image: url(https://example.com/static/emoji/20/U_1F973.png);
        color: transparent;
    "
>
    🤫
</span>

so or so

<span
    aria-label="🤫, partying_face"
    style="
        width: 22px;
        height: 22px;
        vertical-align: middle;
        display: inline-block;
        background-image: url(https://example.com/static/emoji/20.png);
        background-size: 5700% 5700%;
        background-position: 67.8571% 80.3571%;
        color: transparent;
    "
>
    🤫
</span>

Pros:

Minuses:

2.img

This option involves replacing all emoji with the img tag and using alt to prescribe the native emoji. It’s the same with fallback.

<img
    src="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw=="
    alt="🤫"
    draggable="false"
    style="
        vertical-align: middle;
        cursor: text;
        display: inline-block;
        background-image: url(https://example.com/static/emoji/64.png);
        background-position: 75% 10.7143%;
        background-size: 5700% 5700%;
        height: 22px;
        width: 22px;
    "
>

so or so

<img
    src="https://example.com/static/emoji/20.png"
    alt="🤫"
    draggable="false"
    style="
        vertical-align: middle;
        cursor: text;
        display: inline-block;
        height: 22px;
        width: 22px;
    "
>

Pros:

Minuses:

• If you use the option with the emoji bundle, then the image will have to be inserted through the background, and a stub should be inserted into the src.

Now we have chosen a bundle, since we found ready-made bundles on the network (there are no resources and no desire to keep this database up to date), and we decided to insert it through img. As a result, our system now looks like this, the same beautiful emoji are everywhere, we are satisfied, the operators too).

How could we prevent the problem?

This is all good, of course, we found a rather interesting solution, we were able to implement it, well done, in a word. 🙌 But it would be nice if we didn’t immediately screw up in front of our users, and it was very easy to do it, you just need to test the task right away in the environment where the operators work. We would have immediately noticed that something was wrong with emoji and returned the task from testing to development.

Also, after debriefing, we added a collection of metrics for screen resolutions of our users in order to also test on the most popular resolutions, we found several problems with the layout that went wrong.

Summary and tips:

• Collect screen resolution metrics where your system is used, then you can take a range of the most popular resolutions, this will help you understand where and how your product is used. And also take this into account in testing, and in the subsequent rendering of layouts. For example, you draw basic layouts for FullHD screens, and your system is used on terminals with 4×3 screens, as a result, you end up with extra work and a loss of potential.

• Collect metrics for the operating systems and browsers your system runs on. It will also help you understand your audience, what needs to be supported, and which browser issues to focus on first.

• Test your product on the most popular configurations among your users. For example, you are developing your product on a powerful machine, where even in dev mode everything flies, and your system is used mainly or to a large extent on low-power configurations.

Share in the comments your experience with operators and using emoji? Or are words and caps lock enough for you?