←back to thread

178 points dgl | 4 comments | | HN request time: 0.728s | source
Show context
strogonoff ◴[] No.44364169[source]
The issue with the emoji, at least in their current depictions, is that they are guaranteed to be higher in visual hierarchy (among the few things of undying relevance that we were taught in university) than any surrounding text. They stand out thanks to their different nature and a lot of visual complexity (intricate features).

Good visual hierarchy means you end up looking first at what is important. Good visual hierarchy sets correct context.

Bad visual hierarchy adds mental overhead. Bad visual hierarchy means that any time you look, even when you don’t consciously realize it, you end up scanning through hierarchy offenders, discarding them, then getting to the important part, and re-acknowledging offenders when it comes to them in appropriate context. This can happen multiple times: first for the screen as a whole, then when you focus on a smaller part, etc. As we encounter common visual hierarchy offenders more and more often, we train ourselves to discard them quicker, but it is never completely free of cost.

There are strategic uses for symbols in line with visual hierarchy principles. For example, using emoji as an icon in an already busy GUI is something I do as well.

However, none of those apply in terminal’s visual language of text and colours, and unlike a more or less static artifact fully under designer’s control (like a magazine or a GUI) in a fluid terminal screen where things shift around and combine in different ways it is almost impossible for software author to correctly predict what importance what has to me.

Those CLI tool authors who like to signify errors with bright emoji: have you thought that my screen can be big, and after I ran your program N times troubleshooting something there can be N bright red exclamation marks on my screen, N-1 of which are not even remotely close to where the message of interest is? have you thought that your output can coexist in a multiplexer with output from another program, which I am more interested in? should other programs compete for attention with brighter emojis? and so on.

As to joyful touches, which are of course appreciated, those can be added with the old-style text-based emoticons.

replies(7): >>44364628 #>>44364715 #>>44365364 #>>44365386 #>>44366298 #>>44366575 #>>44366806 #
1. amelius ◴[] No.44365386[source]
Ok, noted. Unicode needs an escape code to specify the level of the visual hierarchy.
replies(2): >>44365499 #>>44376663 #
2. colejohnson66 ◴[] No.44365499[source]
Just add a few more ZWJ-based sequences to the ever growing list
replies(1): >>44367706 #
3. WorldMaker ◴[] No.44367706[source]
They sort of already exist, many emoji are turned "on" (colorful presentation or Emoji Presentation) with Variation Selector 16 [0] and many can be forced "off" (monochrome presentation) with Variation Selector 15 [1].

(Not all fonts handle all variations, though, in both directions.)

[0] https://codepoints.net/U+FE0F [1] https://codepoints.net/U+FE0E

4. strogonoff ◴[] No.44376663[source]
Thank you, I chuckled.

On a pedantic note (I know, as if anyone asked for more of that), hierarchy is not a single-dimension metric, it’s quite a bit more involved than just colour/internal visual complexity. A large part of it is positioning of an element relative to the viewport and other elements, negative space around it, etc. Unfortunately, in terminal output there is barely any control over that—unless you consider TUIs.