ThomasJockin / readexpro

Readex Pro is the world-script expansion of Lexend. Lexend is a variable font empirically shown to significantly improve reading-proficiency.
http://www.lexend.com
SIL Open Font License 1.1
505 stars 24 forks source link

Named styles should sort alphabetically and logically #10

Closed davelab6 closed 5 years ago

davelab6 commented 5 years ago

A product manager interested in this project is keen to have the static family (or the list of named instances in the variable font) be ordered logically when they are ordered alphabetically. I can see the value in that especially as most people don't know the order of the scale words used....

ThomasJockin commented 5 years ago

I very much appreciate the concern the PM offered, but I object on the following grounds:

  1. Font variables such as weight or width are not ordered alphabetically: Thin, Light, Regular, Bold, etc. I fail to see why the Lexend variable names must meet this burden when the other variables do not follow such a format.
  2. In terms of logical ordinal order, while it is true the alphabet is more commonly known, there is no reason a is before b outside agreed convention.

With that said, because of the potential opacity of the names for users, how users interact with Lexend in UI clearly needs the proper structure and design to communicate effectively.

What we can do is assign width values within the named instance fonts. This will ensure font menu interfaces will at least order the named instances in the correct ordinal order. Assigning inside the font table progressive width values will work because font menu UIs order by Weight, Width, and Slope as reported on Glyphs tutorial page

The change of width values does not have to be stated in the font name; We just need the font menu UI's to understand the ordinal order of the named instances. See attachment 2019-07-04 16 37 48

davelab6 commented 5 years ago

Sorry to say, Google Docs (a) doesn't support Variable Fonts, neither axes or named instances, (b) doesn't support width styles within a family, only weight (and roman/italic), (c) orders weights by number, and ignores the style names within a family.

What Docs does support is a set of single-style families, where all non-weight style information is baked in the family name. And family names are sorted alphabetically in Docs' font menu interfaces.

The only way for the Docs font menu UI to understand the ordinal order of the named instances is to name them in a way that an alphabetical sort matches the ordinal order. Eg,

ThomasJockin commented 5 years ago

Is there a reason we are focusing on Google Docs? Was the PM with the initial suggestion from the Google Doc team?

davelab6 commented 5 years ago

The majority of fonts available in GSuite are from Google Fonts, with a minority licensed (eg Comic Sans), and working well in GSuite is important to Google Fonts :)

ThomasJockin commented 5 years ago

Fair enough. I see how this is handled with fonts like Roboto:

Screen Shot 2019-07-10 at 11 56 09 AM

This would be a fair expectation if how users would select Lexend in the same manner. That is not the case. Users need the context of being prescribed a personalized setting that fits best for them based on fluency.

Especially in the context of a lack of VF support in Google Docs, this points to the need for a plug-in or API to give users the proper context to find the right Lexend font and have it apply to to GSuite. In the Lexend Arabic proposal, I spoke about this need/ direction in creating a fluency calibrator.

As you can tell, we will need way more discussions to see if this is even possible. And naturally, if such API or plug-in solutions are untenable, the naming solution will have to be reconsidered.

I believe to give users the best experience using Lexend, we need a more robust solution than to strip down the font names because of Google Doc built in limitations.

davelab6 commented 5 years ago

Sadly that's not viable as a blocker. I want to publish the font in Google Fonts this month, and while a Docs Extension can indeed act as a progressive enhancement to offer a fluency calibration UX (and @micahbrich should be capable to produce that as its all web stack stuff) it can't block the launch or be assumed to be available.

davelab6 commented 5 years ago

How about this?

Lexend Lexend 1 Deca Lexend 2 Mega Lexend 3 Giga Lexend 4 Tera Lexend 5 Peta Lexend 6 Exa

ThomasJockin commented 5 years ago

After talking it out with Bonnie and exploring other naming options, we have decided to stick with the orders of magnitude names, but order based on alphabet:

Deca (Regular) Exa Giga Mega Peta Tera Zetta

micahbrich commented 5 years ago

Oooooooh Zeta, that one's cute. ✨ -- Micah Rich https://micahrich.com

davelab6 commented 5 years ago

Great! This will annoy some nerds, but that's better for me. Please make this update so @m4rc1e can onboard them :)

m4rc1e commented 5 years ago

@ThomasJockin is it "Zetta" or "Zeta"? I'll change the names today.

ThomasJockin commented 5 years ago

Resolved with commit https://github.com/ThomasJockin/lexend/commit/c218ea9cdb31e4d762693a0cd17c02b9603646c0

m4rc1e commented 5 years ago
Screenshot 2019-08-01 at 11 19 07

Build updated