[RFC] Blog index page

[siriwatknp]

The first iteration for building the index page of MUI blog.
The pull request: #30121

Purpose

• Give developers a place to browse MUI content & learn
  • get more lead to the site
  • spread the knowledge and reduce some repetitive issues (that are not bugs) in the future
• Prep the infrastructure for an incoming developer advocate
  • starting a new post should be easy and straightforward
  • able to leverage the repository code to build interactive demo if needed

MVP

• blog should be included in the search (currently, /blog/ is excluded)
• design of the page (let's start with the simple version without fancy UI)
• able to filter by tags (eg. company, how-to, styling, data-grid, material-design, etc.)
• filter on the client for MVP (currently, there are ~30 posts in docs/pages/blog/. We can think about other approaches when the number of posts is huge.
• show published to date, author
• subscribe to blog? (should it be the same as the newsletter?)

Examples

• https://stripe.com/blog
• https://nextjs.org/blog (very simple and clean)
• https://www.gatsbyjs.com/blog/

...what else? cc @mui-org/core @mui-org/x

[alexfauquette]

Sounds to be a nice MVP

I'm wondering, why having huge posts could lead to a bottleneck? For filtering, we only need article metadata. So the limitation will come from the number of articles.

[siriwatknp]

My bad. I mean "number of articles" is huge. I have updated the wording.

[oliviertassinari]

I had benchmark more examples in Notion:

• https://www.apollographql.com/blog/
• https://www.hashicorp.com/blog

[MOYASIGamesNight]

gg

[flaviendelangle]

I think we must aim for simplicity to avoid spending to much time on the blog structure and focusing on the content of the articles (and their SEO).

In the blogs listed, I see a clear distinction between blogs with an article list (the NextJS one is the most straightforward implementation of this approach) and blogs with a card list, hierarchy between articles, sections, etc... (the Hashicorp one)

For me the list approach is simpler. It requires no mandatory illustration for articles, no advanced classification of the articles.
It's best for a blog with just a few articles and where the users read the last one but rarely go to older ones

But it we see the blog as a knowledge database, then the classification starts to make sense. Because with a flat list you will have a hardtime finding an old article.

[siriwatknp]

I think we can start with the list so that we don't need to do the design (improve in the next Quarter).