The Basics of Legibility: A Short Guide for Non-Typographers
nubero.ch
nubero.ch
You've probably already guessed: the lovely font used for the code made O and 0 indistinguishable, as well as I, l, and 1.
UX designers forget that functionality is more important than beauty. If you can achieve both, that's great. But without functionality, a beautiful UI is useless.
It's the reason grid layout ICs don't have rows I, O, Q, S, X or Z.
ofc i know this because im writing a jvm for my thesis :/
0xDEADBEEF is even more evocative. OxB00B is, well, problematic.
It sounds like were you working on this project you would’ve unnecessarily compromised. And given that you’re seeking to make some generalised point about “UX designers”, it honestly sounds like you both undervalue UX design (since you’re looking for the first opportunity to dismiss design in an instance where the real issue is that ambiguous characters are being used in the first place), and don’t understand the bounds of UX design as a skill set (because any good, and note that I’m not saying “very good”, UX designer, will consider exactly what you said).
Sorry that you used a crappy website but I don’t think it’s justification to generalise a profession.
And, for the record, I’ve never been as much as a front end developer, let alone a designer. My speciality is certainly much more under the hood than that. I’m just…aware that those people do good, important work.
Sure, DIN or the typefaces used at the airport to guide pilots are extremely legible, and less ambiguous in their context. But the difference between Fraktur and SF Pro is much bigger than between SF Pro and DIN for example. Plus, being on hundreds of millions of devices made it common so people got used to it.
Reminds me of the difference between Kai and Song font types in Chinese.
Is there any research with a graph of legibility over fonts? Any idea where the point of diminishing return is for different activities?
I do like a good programming font, but if I’m honest with myself, as long as the foundation is right, most differences are to accommodate one’s taste. I’ve yet to found a case where there was a bug because my font threw me off, or something.
Side note: I recall the first time I read digits written in the English style, and got tripped because the 7 looks like a 1 in my culture, because we all add a little horizontal bar in the middle. You can used to it, but on hand written notes, nobody would write an English 7, yet virtually all computer fonts only offer one version of it (Berkeley Mono offers both, in a mono space font!)
There is plenty of data available on type face legibility.
It's not for everybody to fret about serif vs non-serif, and that's OK, you don't have to if you don't want to. But if you want to do mass communication that stuff starts to become important.
A "crossed seven" if anyone is curious:
* https://en.wikipedia.org/wiki/Arabic_numeral_variations#Othe...
* https://en.wikipedia.org/wiki/7#Evolution_of_the_Arabic_digi...
That said, while the typographic pedant in me enjoyed this, the semantic pedant very much also in me very nearly screamed at not one, but two, uses of “extend” where “extent” should be.
> The term "keming" is sometimes used informally to refer to poor kerning (the letters r and n placed too close together being easily mistaken for the letter m).
The 1. in San Francisco seems to have plenty of personality to me, and while there's not a lot of examples on the page and I think I'd need to see more, it doesn't seem like FF has particularly more personality.
From the rest of the article it seems like purpose = legibility in the context of UI. I wouldn't disagree that it's hard to distinguish I and L, but using German location signboards as an example seems wrong - iOS is not dealing with German locations for the most part. Is SF particularly bad for German?
For an article that aims to lay down conclusive arguments for why one font face is better, with the authority of someone who has studied fonts in school for four years, I'm not quite convinced...
I would like to see a real example (not a constructed one like "Illiad" in the article) where the legibility is restricted.
But I agree that it would be nice with an example from the UI where it’s actually a problem.
Anecdote: For some time San Francisco had the wrong glyph for the German character Capital Sharp S - the „ẞ“.
SF rendered the glyph as a ligature of two combined S letters, you can see this in this screenshot of a Wikipedia page compared to SF in Safari’s UI:
Pretty much every other font which included a Capital Sharp S uses a shape which is more similar to the lowercase ß – and there were over time a lot of variation proposed:
https://web.archive.org/web/20141024232352/http://www.signog...
For non German speakers: There exists an orthographic rule in German to render the lowercase ß as SS in uppercase in low fidelity environments and sometimes also for line breaks. For some reason English speakers sometimes interpret „ß“ and „ss“ as interchangeable, which is somewhat wrong. But I can see how an English speaking monolinguist tries to optimise things.
Most of the time that orthographic rule works. But it is after all a low fidelity variant, similar how the ü → ue pattern loses some information. To always use an SS ligature robs the reader of discrimination: Is „MASSE“ an uppercase variant of „Masse“ or of „Maße“? That’s particular significant for personal names which should be written exact, even in uppercase. There are reasons why typography introduced an „ẞ“, it then got encoded into Unicode - it fills a small need.
Apple had this wrong glyph in San Francisco from Mac OS El Capitan up until Mojave and elsewhere, including its web sites. It was rather absurd to report this bug to Apple: Radar/Feedback dialogue wasn’t really equipped to report a font bug and secondly both the Feedback reporter and Apple’s developer website used San Francisco at its font, making illustrating the report with glyphs rather annoying. And of course, as usual with bug reports to Apple: You’ll never get feedback.
So you can transform text with CSS to be upper case (text-transform: uppercase). It turns ß to a double-S glyph as well in all browsers! Firefox now has a feature flag for it (layout.css.text-transform.uppercase-eszett.enabled). Why: Because unicode still defines it though in casing guidelines:
> # The German es-zed is special--the normal mapping is to SS.
> # Note: the titlecase should never occur in practice. It is equal to > titlecase(uppercase(<es-zed>))
> https://unicode.org/Public/UNIDATA/SpecialCasing.txt
And given that ẞ only made it into German orthography in 2017 and San Francisco is release in 2014 and Mojave only 2018, I don't think it is that big of a mess-up. That they only supported it after. I bet there are loads of fonts that still don't support the character and having double-S is better than nothing.
Edit: Kind of proud how I am using css-transforms and a few more CSS hacks to get it working on my mom's website in the title: https://gutshaeuser-ostpreussen.de/gutshaus/details/gross-bl...
Edit to the Edit: Even the DIN 1451 doesn't support uppercase ẞ and e.g. the popular FF DIN (which San Francisco seems to be based on) is turning ẞ into double-S.
As a character it was proposed first in 2004 and encoded in 2007.
> I bet there are loads of fonts that still don't support the character and having double-S is better than nothing.
Oh yes, of course. But those then don’t display „SS“ instead of „ẞ“ but either a missing glyph or a glyph from a fallback font.
> Edit: Kind of proud how I am using css-transforms and a few more CSS hacks to get it working on my mom's website in the title: https://gutshaeuser-ostpreussen.de/gutshaus
That’s a nice hack! Congratulations.
(gutshäuser-ostpreußen.de or rather xn--gutshuser-ostpreuen-1tb6g.de is still free, if you’ll want a new challenge. But I advise against using an IDNA domain with an „ß“ for e-mail. Evergreen browser are now updated for the IDNA2008 algorithm, which supports the „ß“, but for a long time first IDNA2003 didn’t support „ß“ in internationalised domains, then browser didn’t update to IDNA2008 until late in 201x. And other internet software like mail clients are even more behind. Sadly.)
There is an old proposal for the CSS WG floating around to enable custom alterations for text-transform or even custom transformations, since it is useful in other languages. That then would be a non-hacky way:
https://wiki.csswg.org/ideas/at-text-transform?rev=145951992...
https://specs.rivoal.net/css-custom-tt/
I first asked the CSS WG back in 2011 and they already knew about the problem. That proposal sadly still doesn’t seem to go anywhere.
This annoyed me though:
> there is a problem that I call the “Japanese Sword Fallacy”: The Japanese made the best swords in the world, far better ones than anyone else. They were lighter, yet sturdier than their western counterparts, sharp like a razor and so forth.
That is not actually true. They had more amazing sword marking techniques, but these were only needed at all to compensate for the lower quality of their steel. Everyone else (at least Europe, Middle East, South Asia - probably other places too) had at least equally good swords, but because their steel was better the swords were easier to make.
https://www.youtube.com/watch?v=W8a7gpoSPbY
the other has details about how it was made and a link to a paper about the steel:
https://old.reddit.com/r/AskHistorians/comments/3btp60/why_d...
https://old.reddit.com/r/AskHistorians/comments/2ge3ew/why_a...
https://old.reddit.com/r/AskHistorians/comments/1qd1x2/where...
https://old.reddit.com/r/AskHistorians/comments/1vjzpa/was_t...
https://old.reddit.com/r/AskHistorians/comments/1rr0qj/were_...
Unlike what some say there, the fascination of Westerners for Japanese swords has not started after WWII. Already during the 19th century, the first Europeans and Americans who could visit Japan were all extremely impressed with the Japanese swords, as demonstrated in test cuts but also by cutting parts of human bodies in some incidents.
Even if in the more distant past there have been many places where swords of very high quality had been made, e.g. the Toledo swords or the Damascus swords, by the time of the 19th century such techniques had been forgotten for a long time and the remaining production of swords was oriented to the mass production of cheap but low quality swords. Such swords were more resistant to mishandling than the Japanese swords, but they could not compete in hardness and sharpness.
The same travellers who were impressed in Japan by the Japanese swords were not impressed at all by the swords encountered in the other countries of the region, e.g. by the Chinese swords.
At least by the time of the 19th century, in no other place were there smiths willing to spend so much time with the sharpening and polishing of extra hard steel.
Even today, when everybody knows modern metallurgy, using Japanese kitchen knives is a very different experience from using European kitchen knives (at least for me, one much more pleasant), due to the Japanese preference for maximum hardness and sharpness, despite the fact that such blades require much more care during use and maintenance.
Because the rest of the world used rifles as a battlefield weapon, maybe.
The main thing I've heard is that in Europe all the best swords used spring steel, which is hard enough to cut really well while also being able to flex without getting chipped, broken or bent. Japanese smiths couldn't make spring steel for various reasons, so as a workaround they used differential hardening, etc. to make the cutting edge super hard, while the back & sides ended up more ductile. It works pretty well, but the cutting face is still a little bit brittle & the sword as a whole ends up heavier & vulnerable to getting bent b/c it doesn't snap back into shape like spring steel would
The popular association between Fraktur (and similar blackletter scripts) and rightwing-associated bands is ironic given the NAZI attempt to outlaw them as of Jewish origin: https://blog.waldenfont.com/2019/06/26/the-history-of-the-ol...
Is the picture referenced here missing from the blog post?
For a blog post that talks about improving legibility by making a wise choice of fonts, this choice of non standard display of images -- requiring clicking or reading of footnotes ro figureout -- takes away from the seriousness of the message.
What was gained by hiding the second image under a click -- instead of simply placing images one after the other like any other blog post?
By your logic even the core message of the blog post itself could be rejected saying ..it helps if the readers knew how to read various fonts of text and stopped complaining about a non existent problem. Or why not just add a footnote under every button that sports fancy illegible text.
“Take a look and click around” it says above the next clickable example. Another hint.
As for what is gained: The example with white space inside letters works much better when clickable. In separate images, the effect is lost.
SF Pro has usability issues, but FF Unit has aesthetic issues.
Another factor comes to mind: UIs are places you spend a fair amount of time, and repetitively. Whilst there are “new” UI elements in an OS from time to time, you in fact see the same ones over and over, much more often. Users of OSs also tend to have time on their side when interacting with the UI, when compared with drivers reading road signs. My take is that you don’t need to optimise for legibility as strongly when designing for an OS UI as you do when designing for road signs.
It was developed by the Braille Institute of America in 2019 for visually impaired. I think it's good font overall.
For monospace you need something else. Aribus designed a great font called B612 mono except that O0 are too easy to mix.
This is why I've been spending a lot of time (ab)using Emacs's browser, eww, in conjunction with follow mode: The two together allow me to view most things in an efficient columnar display, letting me take better advantage of the width of my screen. (It's hard to rotate a laptop's monitor.)
When you zoom in, you lose context of the surrounding data and controls. So I want to save negative space, and hope to have controls or links closer to the content they operate on. You can't always scroll, especially with an OS where the elements are in fixed places (until you move the window, which you have to find by pan+scan).
I accept I'm an edge case.
Stopped reading at this point. As the hook of the article is based on a falsehood deeply entrenched in pop culture, I can safely assume the rest is written with the same amount of care.