I like the idea of this, and I think it's fantastic for guiding the eye, but I think the organization is tangling the external resources up with the internal ones (and yes that was happening in the original docs but this layout exacerbates the issue, and there's probably a different way to describe than internal/external but they're categorically different):

External

• discourse, stack
• gitter
• mailing lists
• twitter/instagram

Internal:

• what's new
• api/faq/docs
• issues/PRS

Also, how much weight do we want to give to stack overflow?

@story645 I think stack overflow is fabulous and really is where folks should start a search. Pointing people to the tag is super helpful.

@jklymak I agree it's helpful (@ImportanceOfBeingErnest's answers are basically how I made something the other day), but the mpl dev team has no control over the site - which means its harder to response to answers that are not current, accurate, or best practice , and on a community site we have no control over interactions and so is notorious for feeling unwelcoming to coders from underrepresented groups. I'm not saying we shouldn't link to it, just that I dunno if we want to recommend it as the first stop.

@story645 Thanks for the feedback. I was hoping not to go into the details of the contents too much with this PR, and therefore took the bullet points as is 😎.

I agree that this is not the final state we want the website to be in, it's only a visual improvement not much a content improvement. IMHO already that step is worth it - I'm really turned off buy the bulky text when opening the webpage. I'm fine if we can replace this with something even better soon.

Content is a much larger discussion. IMHO in the end, we do not want to just display resources, but structure by actions (Install, get help, discuss, report a bug, view news, ...). These are not 1:1 correlated to the resources. I'm not worried too much about internal vs. external resources; for the average user it does not matter too much if he gets help from the docs, discourse or stackoverflow.

My motivation for there given order was:

1. Most important: Channels for questions -> Top 4 items
2. Mailinglists and github is more for the experienced developer -> bottom right corner is sufficient
3. Bottom left remainse for Docs and social media.

If you have any suggestions how to improve the order or other small things, I'm happy to include these. Let's go incremental. -> Is this better than before?

So my issue is that I don't think it's better than before because to me this visual layout gives me an expectation for where the links should be and that's making it harder for me to find the information. That's why in this change I really don't think we can seperate content from layout.

As a first pass, I either suggest the delineation I proposed in my comment above or using some kind of visual cue - different sections/borders/headers to make your proposed organization clearer.

Strongly agree that the icons should be links! Otherwise, I think this is an improvement while more work is done in the future.

• Icons: Not all icons can be links. Only the blocks for discourse, stackoverflow, gitter and github have a canonical URL we can reasonably link to. The other four entries contain multiple targets; e.g. there are three links to mailing lists. If it helps, I could make the icons grey, giving them less presence and sort of an "inactive" notion.

• Sectioning: I've introduced sections to roughly group by "Get help", "News", "Development". The distinction is not sharp, e.g. mailinglists cover all three to some extent, but it's may still be better to simplify than not group at all.

This is how it could look (code not yet commited as I will only inverst in providing clean code if this is leading somewhere):

@timhoffm I love the sectioning, thank you!

And I agree with putting all the mailing lists under dev since an end goal is to retire them in favor of discourse.

My only concern about this is that its massive on mobile. Not that our man page is particularly responsive on mobile (though it should be).

For reference: docs from CI

Responsive design would be nice, but it is second priority compared to having a good index page at all. I assume we get very little traffic from mobile (actually, do we have stats?).

I think it looks pretty nice on mobile, which I use heavily.

According to google analytics though, mobile is only about 4.9% of traffic, but it's 7.3% of traffic from new users. Tablets are <1% of traffic.

Made it a bit responsive so that, it's single column full-width for smaller screen sizes:

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

$ git checkout v2.2.4-doc
$ git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

$ git cherry-pick -m1 d7a39e459d6c662a00b440de6a4ffd92287c3f30

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

$ git commit -am 'Backport PR #16065: Nicer formatting of community aspects on front page'

4. Push to a named branch :

git push YOURFORK v2.2.4-doc:auto-backport-of-pr-16065-on-v2.2.4-doc

5. Create a PR against branch v2.2.4-doc, I would have named this PR:

"Backport PR #16065 on branch v2.2.4-doc"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free to suggest an improvement.

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

$ git checkout v2.2.x
$ git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

$ git cherry-pick -m1 d7a39e459d6c662a00b440de6a4ffd92287c3f30

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

$ git commit -am 'Backport PR #16065: Nicer formatting of community aspects on front page'

4. Push to a named branch :

git push YOURFORK v2.2.x:auto-backport-of-pr-16065-on-v2.2.x

5. Create a PR against branch v2.2.x, I would have named this PR:

"Backport PR #16065 on branch v2.2.x"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free to suggest an improvement.

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

$ git checkout v3.1.x
$ git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

$ git cherry-pick -m1 d7a39e459d6c662a00b440de6a4ffd92287c3f30

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

$ git commit -am 'Backport PR #16065: Nicer formatting of community aspects on front page'

4. Push to a named branch :

git push YOURFORK v3.1.x:auto-backport-of-pr-16065-on-v3.1.x

5. Create a PR against branch v3.1.x, I would have named this PR:

"Backport PR #16065 on branch v3.1.x"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free to suggest an improvement.

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

$ git checkout v3.1.1-doc
$ git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

$ git cherry-pick -m1 d7a39e459d6c662a00b440de6a4ffd92287c3f30

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

$ git commit -am 'Backport PR #16065: Nicer formatting of community aspects on front page'

4. Push to a named branch :

git push YOURFORK v3.1.1-doc:auto-backport-of-pr-16065-on-v3.1.1-doc

5. Create a PR against branch v3.1.1-doc, I would have named this PR:

"Backport PR #16065 on branch v3.1.1-doc"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free to suggest an improvement.

Skipping backporting to 3.1.x. Hoping that 3.2.0 will get out some time soon.

Backported to v3.1.x as 1607430 as we are doing a 3.1.3 release.