aeternity / aepp-components

deprecated: aepp-components to be used in all aepps.
ISC License
41 stars 14 forks source link

typeface for displaying addresses, hashes, names, and amounts #111

Open andi-apeunit opened 6 years ago

andi-apeunit commented 6 years ago

Introduction

We need to aim for displaying addresses, hashes, names (AENS), and amounts in the best possible way, which means readability in general and distinguishability when it comes to specific characters (glyphs and/or figures).

Lots of typefaces—including Roboto Mono which we’re using for this purpose right now—have huge problems when it comes to distinguishing between the characters 0 (zero), O (capital o), I (capital i) and l (lower case L).

Purpose

For our addresses we decided to use the hashing encoding scheme Base58, which excludes “the characters 0 (zero), O (capital o), I (capital i) and l (lower case L) as well as the non-alphanumeric characters + (plus) and / (slash)”—via Base58 (Wikipedia). But this doesn’t solve all problems, think of names (AENS), and our proposol for mnemonic user names which can be read about in another discussion concerning visual representation of addresses and hashes.

Thanks to @dadaphl we already had a short discussion about a Better concept for font-size.

Though—in addition to this concept in regards of font-sizes—we need to come up with another typeface which is not, or hardly, affected by the issues described above.

There’s lots of monospace typefaces—open source ones and commercial ones—and most of them are problematic in regards of this exact use case, or issue. Three of the four typefaces I could propose to you had some issues not related to the one decribed above, which is why—besides purchasing a license for a maybe modified commercial typeface—I’m suggesting we start using a slightly customized/modified version of an open source typeface called Source Code Pro.

Conclusion

The proposed customized version of Source Code Pro, lets call it æternity mono as working title, will have some of the default character glyphs—letters, figures, punctuation symbols—replaced by already existing alternate glyphs.

Accessing alternative glyphs by using OpenType features (via Matthew Butterick) is not possible in the software stack we’re using, and it’s also not that handy to always think about replacing specific characters, so creating modified font files which anyone could just download and “install” is a convenient solution.

Please feel free to comment and discuss, and also to ask any arising questions.

Find a screenshot which is comparing Roboto Mono (left) with æternity mono (right) below. Especially have a look at the characters 1 (one) and l (lower case L) and imagine looking at a name (AENS) like he11o.aet which just shows one of those characters and not both—and also not directly next to each other.

screen shot 2018-05-29 at 14 25 21

jsnewby commented 6 years ago

I like this font very much.

davidyuk commented 6 years ago

So, for addresses, this problem is solved by Base58 encoding, for mnemonic usernames, we can avoid this problem by defining a set of words that corresponds to paragraph B from BIP-39. Maybe will be more convenient to use usual fonts instead of monospace for names with variable length (including AENS) like most of the web browser does in the address bar. Also, we can show AENS names only in lowercase to increase the difference between i and l. I personally prefer Roboto Mono instead of making a custom font because of its popularity and not so strong existing problem.

andi-apeunit commented 6 years ago

So, for addresses, this problem is solved by Base58 encoding, […]

Unfortunately, no. This still depends on the typeface displaying the characters and figures. Please have a look at the figure 1 and the lowercase character l in the screenshot above (left character and figure set, first row).

[…] for mnemonic usernames, we can avoid this problem by defining a set of words that corresponds to paragraph B from BIP-39.

Thank you for that link. If I’m not wrong on this, when we’re talking about “mnemonic” phrase/secret/username, we ultimately mean that specification of a wordlist. Though unfortunately that does not solve the problem of the visual representation of those words and the typeface-specific distinguishability.

Maybe will be more convenient to use usual fonts instead of monospace for names with variable length (including AENS) like most of the web browser does in the address bar.

In my opinion that will make distinguishability even worse. For example check the previously mentioned characters and figures written in system typefaces like Roboto and San Francisco.

Also, we can show AENS names only in lowercase to increase the difference between i and l.

Displaying AENS names in lowercase should be—in my opinion—a must. Differentiation between i and l, especially between 1 and l , is still a problem.

I personally prefer Roboto Mono instead of making a custom font because of its popularity and not so strong existing problem.

The custom typeface is basically Source Code Pro—which is also very very popular—with just some glyphs swapped with their alternates. Plus, Source Code Pro is open source. There’s source files for Roboto on GitHub, but I did not find any source files for Roboto Mono.

davidyuk commented 6 years ago

Though unfortunately that does not solve the problem of the visual representation of those words and the typeface-specific distinguishability.

I mean that for the user should be obvious what character is used from the context. For example l in lemon cannot be read as capital letter i. Also, mnemonic words are don't contain numbers and usually lowercase, so there a no problems with 0 and O, 1 and I and l.

andi-apeunit commented 6 years ago

I mean that for the user should be obvious what character is used from the context. For example l in lemon cannot be read as capital letter i. Also, mnemonic words are don't contain numbers and usually lowercase, so there a no problems with 0 and O, 1 and I and l.

That’s totally correct. But we also need to think about AENS names, which for example would allow hello.aet and he11o.aet and there you’d have the problem of figure 1 and lowercase character l.

So the following … could easily be read as figure 1

screen shot 2018-06-04 at 15 51 38

The lowercase character l in the image below probably won’t ever be read as figure 1

screen shot 2018-06-04 at 15 53 17
davidyuk commented 6 years ago

The is no such problem in usual Roboto: screenshot from 2018-06-04 16-05-20 In this font all letters are distinguishable if make them lowercase: screenshot from 2018-06-04 16-12-04

andi-apeunit commented 6 years ago

That’s true. But no non-technical user can definitely know out of the box that we don’t use uppercase letters in our AENS names or unique personal user identifiers. They could guess so, but we want to be as precise as possible.

So, without knowing that you only used lowercase letters in the second image you provided, some user could think that the second character is an uppercase i

andi-apeunit commented 6 years ago

The aeternity mono font family for desktop and web can be found in the newly created repository github.com/aeternity/aternity-mono … enjoy testing and please report any issues you might maybe experience under certain circumstances.