Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document download options better #350

Closed
nsemrau opened this issue Aug 20, 2020 · 4 comments
Closed

Document download options better #350

nsemrau opened this issue Aug 20, 2020 · 4 comments

Comments

@nsemrau
Copy link
Contributor

nsemrau commented Aug 20, 2020

I saw that the release output is now more intricate than the older releases. I thought that people usually not caring about fonts and/or software distribution in general might be puzzled what to download. This thought comes from remembering PR #240, and from noticing that there are now two types of compression formats, with the actual font files now being pushed into sub-folders.

I therefore propose these amendments to the Download section of the README for better discoverability of the font files:

  • Document that for accessing the font files one only needs to either download the [version].zip file or the identical [version].xz.
  • Document that the actual font files lie under /static/OTF/ in the archive.
@alerque
Copy link
Owner

alerque commented Aug 20, 2020

Thanks for the ideas. Here are my thoughts.

  • My theory on the *.zip vs. *.tar.xz is that the only people that know what to do with compressed tar archives are going to recognize it and grab it. Everybody else (i.e. All Windows and most macOS users) are going to see ZIP and go "Ahha! I know what to do with that" and grab it. I seriously think over documenting the cornucopia of options would make it even less obvious what to download.

    My real concern related to this is that Github offers no way to add more visual separation from the git archive generated source download links, but I think having the project name and version load and clear on the actual release download probably puts the focus on it just enough.

  • I'm pretty sure than anybody that knows to look for font files in a zip is going to find what they even in the nested structure. The additional complexity comes from wanting to standardize on something that is workable not just for this project but for a range of projects, many of which distribute lots of different formats. I'm going to look at re-adding TTF & WOFF builds to this project someday, and this paves the way for that to be relatively easy.

    Given how many other font projects have various directory structures in their downloads (I reviewed hundreds) in setting up this default for Fontship) I honestly don't think people are going to get lost there and documenting answers before they even get to the question can just make it sound harder than it is. The bigger issue will be documenting which of TTF vs. OTF to use if we ever have both.

    In the long term my plan is no add instalation instructions to the packages, but that is a job for Fontship. See upstream issue: Generate font installation instructions and include with font bundles theleagueof/fontship#34

@alerque
Copy link
Owner

alerque commented Aug 20, 2020

Oh yes one more thin re №240 — that issue dated from a time when the repository itself had a pile of OTF files visible from the main landing page because they were at the top level of the repository. Not knowing there was a ZIP would have been an easy mistake to make then. Now the (still documented high in the README) Releases page is the only place to get them. The biggest risk of confusion now is the download/clone button Gituh has above the file listing on the landing page that offers the git archive download in ZIP format. Unfortunately we have no way to catch people before they go there if that's the first thing they find, all we can really do is hope they actually read the README.

I may consider a "download latest" link or something above even the specimen in the README as a way to catch those folks that don't read...

@nsemrau
Copy link
Contributor Author

nsemrau commented Aug 21, 2020

Thank you for your thoughtful answer.

I had similar thoughts regarding "too much documentation", and I was hesitant to open the issue at first because of that. I went with it due to my experiences with working with non-technical people, so I tend to err on the side of a low common denominator.

Thinking more about it, I came to the realization that newbies usually rather come in contact with fonts through "easier" re-distributors like font catalogues or bundles in office suites.

I agree with adding a "download latest" link as a closing result to this issue. This would function as a general shortcut and possibly a help for font-searching newbies.

@alerque
Copy link
Owner

alerque commented Aug 21, 2020

Fixed via 2cd906f and c249116.

Thanks again for the feedback. I'm definitely still willing to review this, especially when it comes to particularly on this issue about bundling install instructions. Platform specific directions (and even install scripts) bundled with font downloads seems like a good thing if they are put together cleanly enough not to be too confusing. If you have ideas or want to contribute copy towards that it would be awesome.

@alerque alerque closed this as completed Aug 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants