-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[website] Copyedit Docs and Product menu taglines #43075
Conversation
Netlify deploy previewhttps://deploy-preview-43075--material-ui.netlify.app/ Bundle size report |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me! :)
@@ -148,14 +148,14 @@ const coreProducts = [ | |||
{ | |||
id: 'joy-ui', | |||
name: 'Joy UI', | |||
description: 'Beautiful foudational components.', | |||
description: 'Delightful modern components.', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this wouldn't be closer to the product vision, so clearer. Thoughts?
description: 'Delightful modern components.', | |
description: 'Material UI with a modern look.', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that mentioning Material UI there could be confusing, as users might expect the same API with a different look. For now, I believe the current approach works better, since we don't have a long-term vision for Joy UI yet. Therefore, I wouldn't position it closer to Material UI—who knows, in the future it might become something like 'Base UI with copy-and-paste styles.' 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The upside with referencing Material UI could be:
- it will make it clear why there are two libraries that seems to do the same thing
- it will speak more directly to the people used to Material UI (from the perspective of my friend who uses Joy UI, both are more or less equivalent in terms of API / learning curve)
we don't have a long-term vision for Joy UI yet
True, not completely, what we defined as a cap is that it won't exist standalone. It will either be rewritten as a skin of Material UI, and MD3 will be another skin, or be a styled extension of Base UI. Long term, what Joy UI and Material UI are today will be skins of each other under one brand.
Fix typos, eliminate repeated words, standardize descriptions, match style and structure across the menus.