Documentation layout refresh

[ststimac]

• Increase body width to 74rem
• proposed: move the actions div into a third column and position sticky so they're accessible as user scrolls.

Working on mockup now.

[ststimac]

@molant something like this. "Have a suggestion" box is stickied to the page on desktop but on mobile we can keep the current implementation with the buttons below the title. Though on mobile it might make more sense to have them at the bottom of the article. Thoughts?

[molant]

This looks like a good starting point. Some comments:

• We should probably use another icon for "Signal Issue" so it's a bit more balanced with the GitHub one.
• The gray background looks a bit out compare with the rest of the design. Don't know if it should be a different color, transparent or what.

Re about shrinking the header I was thinking of the following:

The edit/signal issue links could be in the top (same height they are right now, next to the title?) and/or bottom of the document.

[ststimac]

When you're talking about the header you're referring to the menu/nav blue bars correct?
Because the rest of the site & CSS for layout is all based around the current width and reducing that width is going to cause issues elsewhere trying to resize things and re-align to fit a smaller width.

[molant]

reducing that width is going to cause issues elsewhere trying to resize things and re-align to fit a smaller width.

Most of the pages we have are documentation or have content to the left only (governance, faq, etc.). The ones that are more unique are the homepage and the scanner (and we have to review the scanner anyways).

Here's what other projects do (2 and 3 column examples) to take inspiration:

webpack

Parcel

docs.microsoft.com

[ststimac]

I like what MS does. Especially with the "in this article" which could be useful for documentation since some pages have many subsections.

I don't want to shrink the width of overall container of the site body. I get that most of our pages are documentation pages, but the ones that aren't will suffer from a lack of space and the changes will domino effect down to changing font sizing and margins between content modules etc. I think time is better spent ajusting the documentation pages.

[molant]

I like what MS does

Can you propose something for sonarwhal?

[ststimac]

I just want to point out that for some odd reason the website wasn't loading the Source Sans Pro font for the paragraphs. If you look at the screenshots above, the table of contents is loading the correct Source Sans Pro font, but the documentation body copy is larger and different. This is the fallback font.

This doesn't change anything with what I'm doing but I just wanted to make a note since there's no reason the body font should load for only the TOC and not the rest of the paragraphs. Will keep an eye on this.

But the fallback font Verdana is very different from Source Sans Pro, so I will probably update it to Arial.

[ststimac]

For reference: what the body copy of the page should look like compared to the screenshots/mockups in this issue posted earlier:

[ststimac]

Looks like Source Sans Pro was removed at some point from the font list so that would be why it's not loading. I just downloaded it locally which is why it's now rendering properly.