I still find the dark blue jarring (sorry to be a PITA). How about viridis?

nav.main-nav{
    background-image: linear-gradient(to right,  #481567, #33638D, #20A387, #95D840);
    font-family: 'CarlogoRegular', 'Carlito', sans-serif;
    font-size: 16px;
  }

We don't build docs in Fedora (yet), but Debian does. I would guess they would prefer to patch in their existing copy of the font, which seems easy enough. cc @sandrotosi

Please also document how you converted from ttf to woff(2). Are they really that much smaller or are they subsetted somehow?

This pushes the home page from 300K to 600k and it looks like cloudflare / github set things to be cached for 8 days on the client side.

For reference, the examples page currently weighs 15MB ( ~9M from cloudflare because they apply some extra compressions to the pngs).

To look at this change, I suggest flipping between https://25936-1385122-gh.circle-artifacts.com/0/home/circleci/project/doc/build/html/index.html and https://25954-1385122-gh.circle-artifacts.com/0/home/circleci/project/doc/build/html/index.html

I definitely think it looks better with the new font, I am leaning to it being worth the extra weight.

@QuLogic Note that this also puts the modified ttf in our font directory as it is mostly zero cost to do so. I assume fedora is going to want to do something about that. Might be worth moving that to another PR.

But can’t we let the user download the fonts from googleopolis or something?

Font type

The Carlogo font looks good!
But just saying: We basically have free choice for the website font.

Having the same font as in the logo can sometimes be nice for consistency, but is really optional. Logos serve a distinctly different purpose and thus may result in different font preferences. For example, while the facebook page uses Helvetica, the logo font is something proprietary (https://boostlikes.com/blog/2016/01/facebook-font-logo).

So if there are other considerations like delivery and bandwidth that would suggest something else, we're not tied to Carlito/Carlogo by design.

Font style

Carlogo is a quite dense front I'd apply letter-spacing: 1px to the nav, and letter-spacing: 0.5px to the headings.

before:

after:

Nav color

I'm really undecided if I like the viridis gradient. Hovering between too playful and a good design element.

I found making the lettering gray also makes it pretty hard to read. I swapped the hover color and it was easier to read even without more spacing

But can’t we let the user download the fonts from googleopolis or something?

I'm worried about user in-bound not our out-bound which is the same no matter where it comes from.

Please also document how you converted from ttf to woff(2). Are they really that much smaller or are they subsetted somehow?

From https://www.w3.org/TR/WOFF/

“A WOFF file is simply a repackaged version of a sfnt font with optional compression of the font data tables. The WOFF file format also allows font metadata and private-use data to be included separately from the font data”

We basically have free choice for the website font

This is true, and probably worth doing in the future. However, picking a totally new font is more challenging to do well, and represents a bigger change from the bit of consistency already on the site.

I still find the dark blue jarring (sorry to be a PITA). How about viridis?

This is really good idea, and I think there is way we can implement this in a way that’s less “playful” and more inline with the current feel of the site. I’ll play around with this a separate PR.

Also, not a PITA. Critical feedback usually makes for better designs. FWIW, I'm finding PRs designed for code reviews are kind of an awkward way to provide design feedback. Tom and I were chatting about this over coffee earlier today.

I found making the lettering gray also makes it pretty hard to read. I swapped the hover color and it was easier to read even without more spacing

I’ll look for a different hover effect :)

Re design hard over PRs that’s probably true. Being able to see a bunch of mock ups is probably the best way to go. But really hard to make 20 active versions of the website. How do other projects do it? OTOH there aren’t too many nice open source project webpages out there.

For the gradient it might be good to make it unbalanced so that it has blue/purple for longer and then fades green/yellowish on the right hand side over a shorter length.

I think our “brand” is somewhat tied to c0, c1, c2,... and viridis. Ie you can recognize matplotlib plots partly by their predominant use of those colours. I like that the existent website makes use of that palette.

I think our “brand” is somewhat tied to c0, c1, c2,... and viridis. Ie you can recognize matplotlib plots partly by their predominant use of those colours. I like that the existent website makes use of that palette.

It's nice that it feels like this for you. But the plot design and website design have actually evolved completely independent. Our current color cycle is based on the original tablau palette. Before v2.0, it was MATLABs RGBCMY standard colors. But even then we had the same website style - https://matplotlib.org/1.5.3/. The website is based on the original sphinxdoc theme. Viridis again was created as a jet replacement and design choices were mainly concerned with the perceptual properties like uniformity and grayscale compatibility.

https://26036-1385122-gh.circle-artifacts.com/0/home/circleci/project/doc/build/html/index.html

Concerning hover, what about a classic button-like effect:

(my screenshot tool is always removing the cursor, but I'm hovering on "Examples" here.)

Please also document how you converted from ttf to woff(2). Are they really that much smaller or are they subsetted somehow?

From https://www.w3.org/TR/WOFF/

“A WOFF file is simply a repackaged version of a sfnt font with optional compression of the font data tables. The WOFF file format also allows font metadata and private-use data to be included separately from the font data”

The question is more about the how, not the why. In a year, it's going to be forgotten if not written down somewhere.

Re design hard over PRs that’s probably true. Being able to see a bunch of mock ups is probably the best way to go. But really hard to make 20 active versions of the website. How do other projects do it? OTOH there aren’t too many nice open source project webpages out there.

It can be done entirely over GitHub and associated tools, without a bunch of PRs. You would have to enable CircleCI for your fork, push a bunch of branches with the different options, then grab all the artifact links and post them in a single issue. Unfortunately, no easy toggle between them, but opening in separate browser tabs/windows might be enough.

How do other projects do it?

We are exploring how to manage this process together :) Part of this is effort is the extra web-site specific calls we have been having. @dorafc has longer more articulate thoughts about to merge more traditional web design workflows with how we do things on the library side.

Before this gets merged I think we should

• add notes about how the conversion was done to the commit the woff come in via
• remove the 'add ttf to the main library' commit from this PR (but add it in a follow up PR) as I don't think we should backport adding the font to 3.1 and not doing it here seem simpler than hacking up the backports PRs to remove it).

How do other projects do it?

There are collaborative web design tools, but I don't think anybody is doing this with sphinx-based sites.

Random thoughts:

• We could take a generated version of the documentation as static set of HTML pages and discuss all changes based on that. When design is done, these changes would have to be backported to the sphinx framework.
• If we need sphinx builds and freedom of commiting and branching for different ideas, we could do the design/development on a separate fork so that we don't pollute the main repository.

It's less about tools, and more about how to come to decisions about the design direction before putting together mockups

here's the woff generator: https://www.fontsquirrel.com/tools/webfont-generator (in process of adding to initial commit message)

Will merge (and shepard backports) when CI is green.

You would have to enable CircleCI for your fork, push a bunch of branches with the different options, then grab all the artifact links and post them in a single issue.

@QuLogic is there a way to see the artifacts after the fact or do you just need to grab them all manually?

I'm sorry, I don't understand the question. All artifacts are after the fact by definition.

Sure but can we find the links after a new ci run?

Oh, sure, as long as you've pushed them separately so that the CI is triggered (and not cancelled by fast-finish). I don't believe they have any default expiry implemented.