I disagree with the response, assuming that the original question was using the original icon font (Font Awesome) as a supplement for their buttons. That is, buttons and other UI elements were composed of a combination of both icon and text. I think that is a likely interpretation given that they have hidden the icons from screen readers.
In that situation, I think that it’s perfectly acceptable. The ambiguity is mitigated (if not entirely removed) by the text next to the icon. Even with the “risk” that the emojis look out of place compared to the rest of the website, I think it’s still fine. (I’m also of the opinion that websites should conform more to the client’s OS rather than fight against it. That websites should blend in with the rest of the native applications rather than look distinct.)
I agree. The answer is responding to a strawman. The question wasn’t if replacing text with emojis was a bad idea, but rather if it was a good idea to replace icons with emojis.
Secondly, the response is commenting that older devices or OS might not have the required support, but the question does specify that this is an internal app, so presumably they have control of what devices and what versions of OS the app will run on and can make a decision based on that.
Thirdly, the answer is conflating bad design and emoji use. The question is asking if a button with an emoji, for example [✔ OK] would work well as an interface, yet the answer manages to present this as an example where that could be misinterpreted:
often 👥 will misinterpret emojis that their peers 📦️➡️ to ➡️👥. ➡️👤 do ❌ 🙏 to have a sudden misunderstanding between 🆗 ➕ apparently also 🆗 emoji like this: 🙆;
And finally, they seem to believe the emojis would be inserted in the middle of text strings instead of being consistently formatted as a pictogram for buttons or messages.
A major problem with using emojis in a UX is that the font provider has a lot of control over what they look like on any particular user’s screen. It’s well known that every major smartphone OS provider changed its emoji font over the course of a few years to change the gun emoji from a real gun to a squirt gun (at different times, without coordination). It’s a pretty big change in meaning, if a message you wrote with a real gun emoji shows up on the other party’s end as a squirt gun (or vice versa!). I’d use the FontAwesome icons that the app developer has control over, so they know that what the user is seeing is what the developer intends.
Please don’t use FontAwesome either. If the user disables remote fonts (and there’s a lot of good reasons to do that), you’re liable to just have random boxes or letters scattered around your ui.
Instead, use svgs. And remember, the ui needs to be understandable for people who don’t know the icons too.
The question was posted to StackExchange 3 years ago, and I have not seen emoji turn up in UX in any significant amount since then. So I don’t think the wider UX community thinks it’s a good idea.
If its text mixed with emojii, it looks bad but a fair warning about what kind of people you are dealing with. If its a link or button that only contains emojii, its not going to render at all for some people.
In what context would it not render at all? The only case I can think of is an embedded platform too resource-constrained to have an emoji font, which seems kind of niche. (Not to mention the original post was about a native iOS app.)
A native app using emojii for labels or buttons seems like only a potential accessibility problem. As for websites, no, emojii fonts are not ubiquitious. If browsers aren’t required to bundle them then the only safe assumption is that they aren’t there..
Apple’s text-to-speech reads out descriptions of emoji (just have Siri read you your text messages sometime.) I’m sure other assistive tech does too.
Platforms aren’t required to have fonts covering the rest of Unicode either, but if you follow that line of reasoning, you can’t use math symbols or any non-Roman alphabet in web pages. ¯\_(ツ)_/¯
The one environment I just ran across that doesn’t support emoji is the full-screen console mode of a Raspberry Pi. I have a server I wrote that uses some emoji in its output, and I noticed they don’t show up when I run it on my Pi outside a windowing environment. I’m not taking them out though :)
The original post was about a native (iOS) app. By “full-stack” I think you mean web, which is a different context with different issues, like visual variance between platforms.
I disagree with the response, assuming that the original question was using the original icon font (Font Awesome) as a supplement for their buttons. That is, buttons and other UI elements were composed of a combination of both icon and text. I think that is a likely interpretation given that they have hidden the icons from screen readers.
In that situation, I think that it’s perfectly acceptable. The ambiguity is mitigated (if not entirely removed) by the text next to the icon. Even with the “risk” that the emojis look out of place compared to the rest of the website, I think it’s still fine. (I’m also of the opinion that websites should conform more to the client’s OS rather than fight against it. That websites should blend in with the rest of the native applications rather than look distinct.)
I agree. The answer is responding to a strawman. The question wasn’t if replacing text with emojis was a bad idea, but rather if it was a good idea to replace icons with emojis.
Secondly, the response is commenting that older devices or OS might not have the required support, but the question does specify that this is an internal app, so presumably they have control of what devices and what versions of OS the app will run on and can make a decision based on that.
Thirdly, the answer is conflating bad design and emoji use. The question is asking if a button with an emoji, for example [✔ OK] would work well as an interface, yet the answer manages to present this as an example where that could be misinterpreted:
And finally, they seem to believe the emojis would be inserted in the middle of text strings instead of being consistently formatted as a pictogram for buttons or messages.
I give the answer a massive 👎
A major problem with using emojis in a UX is that the font provider has a lot of control over what they look like on any particular user’s screen. It’s well known that every major smartphone OS provider changed its emoji font over the course of a few years to change the gun emoji from a real gun to a squirt gun (at different times, without coordination). It’s a pretty big change in meaning, if a message you wrote with a real gun emoji shows up on the other party’s end as a squirt gun (or vice versa!). I’d use the FontAwesome icons that the app developer has control over, so they know that what the user is seeing is what the developer intends.
Or worse, sending a squirt gun emoji and it being interpreted as a real gun.
Or worse, you send U+130BA and it looks like U+130BA…
Please don’t use FontAwesome either. If the user disables remote fonts (and there’s a lot of good reasons to do that), you’re liable to just have random boxes or letters scattered around your ui.
Instead, use svgs. And remember, the ui needs to be understandable for people who don’t know the icons too.
FontAwesome provides (and recommends) SVGs.
Hey fellow full-stack devs, designers and Internet users, what’s your opinion on this?
The question was posted to StackExchange 3 years ago, and I have not seen emoji turn up in UX in any significant amount since then. So I don’t think the wider UX community thinks it’s a good idea.
If its text mixed with emojii, it looks bad but a fair warning about what kind of people you are dealing with. If its a link or button that only contains emojii, its not going to render at all for some people.
In what context would it not render at all? The only case I can think of is an embedded platform too resource-constrained to have an emoji font, which seems kind of niche. (Not to mention the original post was about a native iOS app.)
A native app using emojii for labels or buttons seems like only a potential accessibility problem. As for websites, no, emojii fonts are not ubiquitious. If browsers aren’t required to bundle them then the only safe assumption is that they aren’t there..
Apple’s text-to-speech reads out descriptions of emoji (just have Siri read you your text messages sometime.) I’m sure other assistive tech does too.
Platforms aren’t required to have fonts covering the rest of Unicode either, but if you follow that line of reasoning, you can’t use math symbols or any non-Roman alphabet in web pages. ¯\_(ツ)_/¯
The one environment I just ran across that doesn’t support emoji is the full-screen console mode of a Raspberry Pi. I have a server I wrote that uses some emoji in its output, and I noticed they don’t show up when I run it on my Pi outside a windowing environment. I’m not taking them out though :)
The original post was about a native (iOS) app. By “full-stack” I think you mean web, which is a different context with different issues, like visual variance between platforms.