[docs] More space for theme builder

[oliviertassinari]

Give more space for https://mui.com/joy-ui/customization/theme-builder/.

Preview https://deploy-preview-38532--material-ui.netlify.app/joy-ui/customization/theme-builder/

---

In hindsight, compared to https://www.radix-ui.com/themes/playground and https://ui.shadcn.com/themes, it feels like we missed the product priority. This demo feels too advanced, not too far from the point where the persona it targets would prefer to do this in code or in Figma. I think the more important use case is quick high-level customization. And the most important: how do you even know if these values make sense? I think Developers should be able to better previous how values impact the look of the components.

So, I would be in favor of:

• create a https://www.radix-ui.com/themes/playground for Material UI and Joy UI
• For the sake of simplicity:
  • remove global docs change in https://mui.com/material-ui/customization/density/#explore-theme-density
  • remove https://mui.com/material-ui/customization/color/#playground
  • remove https://mui.com/joy-ui/customization/theme-builder/ or at minimum remove the global color customizer, and only keep the global variant tool

We would also have the Figma theme editor that @DavidCnoops is working on, but it's for advanced use cases. I think here the goal is when you create a side project, and internal tools (50% of the use cases?) you don't care so much, you want a quick easy way to customize the look & feel.

[mui-bot]

Netlify deploy preview

https://deploy-preview-38532--material-ui.netlify.app/

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against 66bf8b6

[danilo-leal]

it feels like we missed the product priority

@oliviertassinari I feel like we could've discussed this more clearly! 😬 I think more about it as a "non-prioritized big opportunity" ⎯ we haven't yet aligned on committing full force to it, even though I agree with all your suggestions. It might be something to discuss further to understand what we prioritize regarding tooling for building with Material UI/Joy UI. How about we keep evolving this topic, getting @zanivan's shaping doc as a foundation, so we're all on the same page?

[siriwatknp]

it feels like we missed the product priority

@oliviertassinari I feel like we could've discussed this more clearly! 😬 I think more about it as a "non-prioritized big opportunity" ⎯ we haven't yet aligned on committing full force to it, even though I agree with all your suggestions. It might be something to discuss further to understand what we prioritize regarding tooling for building with the Material UI and Joy UI. How about we keep evolving this topic, getting @zanivan's shaping doc as a foundation, so we're all on the same page?

Agree, feel like we should start from the design discussion first.

[zanivan]

I like this a lot, however, I feel we can explore some ideas and scenarios before committing into this. I left some thoughts on the shaping doc that really resonate with the points here, but I'd love more people joining the discussion.

[oliviertassinari]

A least, what seems very clear to me as constraints for https://www.notion.so/Joy-UI-theme-builder-baeb2344a9a34b6ebd6c453a6bf3aa9b and Material UI (almost the same):

1. We should focus on the high-level (meaning very simple and very frequent need) customizations use cases. Why?

• It feels enough to solve a significant problem, what Radix built feels like an obvious go-to for new projects. I would use it. With Material UI, we have been mostly relying on Material Design theme builder, which they have in v3: https://m3.material.io/theme-builder#/custom (I prefer their v2 versions though).
• Advanced use cases tend to be much better solved directly with code for developers and Figma for designers (the problem we are trying to solve with @DavidCnoops)

2. Users should be able to see in real-time the impact of their choices on the components. Why? Because you can't use the tool without it.