[RFC] Grow with Design

[danilo-leal]

As we have discussed, I'll try to move the discussions from Notion to GitHub so it's easier to follow and track once they get settled. But first, it seems a good opportunity for laying out some of the context and motivations around them for supporting the decisions we'll have to make.

Context on the OKR

This quarter, we started using OKRs to guide our work. Essentially, it's a way to prioritize, organize and measure initiatives to move the company forward. One of the objectives I believe encompasses many of the initiatives we've been talking about is the Grow with design one, which was motivated by two main problems:

1. Material Design has grown old: even though it has evolved over the years, our implementation of Google's design system is mostly based on the initial 2014 release. Google used to use it more strongly in older Android versions but now even their own apps (Android and web) are way distant from that look and feel (maybe the principles still hold on, though). The public has also grown tired of it, we've seen people talking about it in our surveys and multiple channels here and there (Twitter, GitHub, Reddit, etc). Our library, to this point, I'd say is much bigger than a Material Design implementation but we can't avoid considering that MD's original design might scare people away and have them not capture other values we provide. Which, consequently, causes the second problem.
2. Material Design might be limiting our growth: even though we have other features enabling you to run away from MD, the components indeed carry baggage that is specific to its implementation. There's also a considerable problem with people being confused about what we are as a company. "Wait, you folks aren't from Google?". Hm, yeah, no... I had to explain that to people even before I was an employee here. I've seen this realization not only taunting apprehension and less trust (fortunately attenuated by the large community of contributors) but also promoting ongoing confusion regarding the places where we went to a different path than the official material.io guidelines, based on our (and the community) specific discussions and tradeoffs evaluation.

Therefore, two main broad initiatives will make us tackle the aging of Material Design and also enable us to grow out of it. First, rebranding the company to position it in a way that is larger than an MD's implementation. Second, releasing products that aren't strictly related to Material Design.

The new branding

Up to now, we've leveraged the traction that Material Design provided us. Since React is from Facebook, it seems like Google has somewhat of a resistance to giving MD official React support. We've been filling that gap. And the thing is, as I've said, we do so much more than only fill this gap. The point of rebranding is to create space for new things out of Material Design to happen and thus to position the company in a larger and clearer strategic path. There are some tasks following the rebranding epic:

• Company renames: we'll change officially from Material-UI to MUI. This means we'll have to change everything that is still Material-UI based: packages, GitHub org, social media accounts, and our website domain.
• New website: this is the main opportunity to tell a different story about the company and its products, positioning us in a broader space. An opportunity to better explain and share what we do and who we are.
• Documentation and package rearranging: these two are in order to create boundaries between the products and making them easier to consume, understand, and market. You won't need to necessarily understand A to use B.

The new products

Following the rebranding of the company, there are three main products on planning for us to expand the horizon and to reach larger audiences with different design and development needs.

An unstyled version of the Core components

This is making the vision of "material to build UIs" a reality. We will provide the components stripped from opinionated styles, with built-in accessibility support, enabling you to leverage its functionally and to apply whatever styling you think suits them better.

A second design system

We know that many people use today's Material-UI library not because of the design but rather because of its completeness and robustness. Fortunately, we've built a very strong theming solution that already enables developers to print whatever design language they need/want. However, it's not uncommon to receive feedbacks around customization complexity, which turns many away from using the lib. Developing a new design system is an opportunity to tackle that while providing new values:

• A great new design at first will enable more use cases for the library and also provide value more quickly with the default look being good.
• Rethought structures around customizing and styling the components, making it simpler and easier.
• Proving the value of the unstyled components since this new design system will be built on top of them, which can encourage people to do their own if they don't feel like using the 2nd DS.

A low code solution

Providing a low code product not only will open a new market for the company but it will enable quicker and simpler use of our components. People who aren't really developers will be able to prototype and build upon the library, capturing many of the values we've already discussed here.

How to roll it all out? (deprecated)

How to roll it all out?

Ok, context set! Even though we're still developing these initiatives, already discussing their rollout plan is a good practice to create a time constraint and also to position them into a cohesive release narrative/strategy.

However, I'll try to attain myself into only proposing a release order instead of actual deadlines. I think we can do that together. My main concern is to have a clear story being told followed by the given context. I'll also take into consideration the discussions we had these past few weeks on Notion and on meetings. But, of course, feel free to criticize it all!

From v5 to a new branding to new products

The plan for v5 has already been outlined for quite some time. As with any major release, it is packed with new stuff that probably has gaps from which bugs will come out. And we'll need to tackle it following its launch. So it's probably a good thing to reserve the beginning of Q4 (mentioning this specific deadline because it was already the plan) to rollout and take care of v.5.0.0 related issues.

I believe that releasing the new branding is what will open the gates for new products to come in. It's a shot at better explaining the products/company and to build excitement and hype for the indeed exciting stuff that's on the way. So, with that in mind, I believe that we should release it after stabilizing v.5.0.0 launch. By doing so, we have more time to stress and decide on the breaking changes (mainly the package renaming/rearranging), to polish the new website (which has several pages), and to settle on the documentation rearranging questions.

Finally, what also seems like an appropriate thing to do when releasing a new branding is to use it as an opportunity to also launch a new product. And if we're about to use the new branding as a vehicle to disassociate with Material Design, then releasing the first version of the 2nd design system and the unstyled package is doing that objectively.

Therefore, we tell a clear story: we're rolling out the Material-UI latest version as planned and then we'll become larger than Material Design, and here you have it, two different Material Design products that concretize it.

Update

This post was initially meant to be a discussion space around how to roll out the upcoming initiatives we have ongoing/planned. As we have released v5.0.0 stable and the new brand on September 15th, 2021, I have archived the "How to roll it all out?" section of this write-up — it's now a bit deprecated. But please check v5 and the new website and tell us what do you think! :)

Regarding the other initiatives mentioned above, a quick "update":

• Unstyled components: Development is ongoing strong! Feel free to contribute by leaving your input and stressing the already available components.
• Second design system: With v5 stable and the new brand released, it's time for doubling down on it. Stay tuned for more about that.
• Low code product: Still early days, nothing too solid to share as of yet. Keep a close eye though, more about it soon.

[alexplumb]

Is there going to be a path forward for those of us who do care that Material-UI was built upon Material Design, and who had hoped that the library would continue to be updated as the Material Design spec was updated? From the sounds of it, your support for this is now deprecated in favour of your new design language called "Joy".

Mui providing me components for Material Design is vastly more important to me than the DX. Otherwise I'd use any other library with its own design language like Bulma or Tailwind. What sets this project apart is its tight coupling with Material Design. I recognize that this is an open source project that I'm not paying for, but I'd really appreciate getting some direction or migration path for v6 and beyond.

[danilo-leal]

Hey @alexplumb! Thanks for leaving your position.

To clarify, we do not intend on deprecating Material Design support in favor of a second design system. We acknowledge that there are many other folks similar to you that value the library for being a very detailed MD implementation and we'll continue to make it so, especially now as Google is revisiting the system with Material You. We'll need to understand how/what to tailor of the current library to follow the new vision. This is all regardless of new company ventures.

However, this whole discussion is based on the understanding that MUI as a company, in order to reach broader/different audiences and leverage the strong foundation that has been built so far, needs to be more than a Material Design React library. The point is to continue serving you and also others that have different needs. That's why a second DS, with different approaches and experiments, comes into place. MD will probably continue to be our flagship product, it is what drove us here and what will most likely help to push us forward. But it will become one of our many product offerings, not the "only" one. (Using "only" with a grain of salt since the library currently already offers a lot of solutions that aren't at all coupled to MD).

As a general direction, as you've asked, Material Design will continue to be supported, no need to worry. Can't give you more details about v6 or any other future topics because I really don't have any. We're about to start doubling down efforts on the second DS as v5 stable (and other initiatives) are released and Q3 comes to an end. Hope that helps!

[oliviertassinari]

I would also add, that being over 10 people at the company now allows us to expend our scope. It wasn't possible before. Material Design was a full time job for 3 people.

It will be very interesting to see what's the trend towards Material Design in our next developer's survey. The last time we ran one, developers didn't seem to express pain as much as they used to. In https://material-ui.com/blog/2020-developer-survey-results/#comparison-with-last-year, we had 60% less people (comparison based adjusted) asking to prioritize Material Design a year ago, than we had two years ago.

[SomervilleTom]

I just want to be clear about my perspective: I'm happy and in fact eager to pay for a genuinely supported version of a Material-compatible React component library. For me, anything up to about $1K/year is at least possible depending on how successfully it delivers what it promises.

When I buy a tool like this, I do so in order to save myself the time of engineering and managing all that stuff myself. I have a long list of interesting projects that keeps me fully occupied. Chasing down arcane syntax to make JSX or CSX or whatever do the right thing when my user clicks on a BadgeAvatar that I've placed on my UserSelect page is a distraction for me. It isn't strategic for me. That's why I eagerly pay somebody else for whom it IS strategic.

I'm pretty sure that providing robust support for Material is a full-time job for way more than three people. I certainly expect that a competent business analyst can build a profitable entity based on selling that support with a Redhat/Wordpress business model.

I'm here ONLY because of Material. There are dozens and dozens of other choices for "novel" UIX frameworks.

Your most effective way at making money from me is to offer me a solid, reliable, and robust Material component library in exchange for a fair price (where "fair" includes a reasonable markup for your team and company).

[wwahammy]

Hey all, I'm a huge fan of MUI and I'm excited what you're working on. I'm also eager to have a low code solution using MUI so I'm glad you're moving in that direction.

I do have one request for the low code solution: please make is straightforward to create output which is fully open source. The open source projects I work on would be happy to pay something for the low code solution so we can speed up our dev but we need to make sure whatever is output and we include in our project is open source and only uses open source code. I appreciate not everyone will have that restriction but anything that can be done to support this specific use-case would be very valuable.

[oliviertassinari]

Thanks for the input Eric. Regarding the low-code initiative, it's still open-ended. The next phase for us is to run extensive user research, testing our hypotheses. If you are in, we would love to have a chat with you.

From a monetization perspective, we plan to follow https://www.metabase.com/pricing/, https://www.mongodb.com/pricing, https://www.elastic.co/pricing, etc. the standards in the space with a new open-source repository (codename MUI Studio). We aim to monetize as much as possible with the cloud version. For the developers that want to self-host it, we hope that only the most enterprise features will need to be "gated".

What we anticipate is as the revenue of the low-code grows, all the features of the components that we use in the low-code solution and that under the "Pro plan" will move to the Community plan. (We envision being able to capture, x10-x100 more value than we currently do with React components). I'm making myself a note in my agenda in 5 years to see if this prediction was true or false.

Regarding "outputting code", this is not our primary objective. We don't intend to build a https://doc.qt.io/qt-5/qtdesigner-manual.html, at least, not so far. Sure, webflow, draftbit allow you to export to code, but this is not the main value proposition.

[wwahammy]

That's good to hear and thanks for the clarification!

We just want to make sure we're not left in a situation where we have to abandon useful tools to comply with our requirements to be open source.

Please do keep up the great work :)

[SomervilleTom]

I've just spent the better part of a day attempting the migration from v4 to v5. While I think I followed all the guidance and ran all the transformers, I'm left with a completely broken app.

These all look to me like issues from deep within the components themselves buried in the node_modules directory. I am neither capable of nor willing to reverse-engineer and/or debug these.

My bottom line is that from my vantage point, this is no migration -- it is faster for me to do a rewrite from scratch of my app. Given what I find at the top of this page, I want to be very clear. If I do a re-write, it will be to replace ALL of the mui resources with something else.

The information I find at the top of this absolutely terrifies and repels me.

Let me be crystal clear: The ONLY reason I'm using ANY of this tooling is so that I can stay consistent with the Google/Material appearance and behavior. My clients and users expect that from the apps they get from me. If "MUI" or whatever you call yourselves now attempt to "rebrand" yourselves away from Google, you've lost me.

Inventing new UIX for the sheer sake of novelty is the epitome of shooting yourselves in the foot. UIX is HARD and takes time, resources, and discipline to do well. Surely the wealth of broken and half-broken apps scattered all over the web and our phones illustrates this. The most important function of any UIX is to be USEFUL to the user. Rolling your own UI is even more likely to fail than rolling your own security code -- I hope everybody understands that the latter is a really really bad idea.

Here's my takeaway:

• Your "upgrade" has broken my app. I'll revert to the old version and discard this attempt
• Your apparent direction tells me its time to start looking for a different UI framework. I certainly hope that Google itself offers something. I thought you were that something -- I am apparently mistaken
• The signal-to-noise ratio of React providers continues to get worse and worse.

I thought I was dealing with a reasonable stable and legitimate entity that existed to make the Google Material Design easily accessible to React apps. I've invested more than a year of my time in Material-UI. It looks very much like this was a huge mistake on my my part.

[danilo-leal]

Hey, @SomervilleTom thanks for leaving your input. As I've explained in a comment just a bit above this one, we don't intend on stopping the React implementation of Material Design. If you're here only because of it, then you're going to be fine because nothing's going to change about that. I'm happy that it has been serving you well.

This discussion is meant to present context as to why we are about to explore new design languages and approaches but to no detriment at all to Material Design. The company is growing, hiring more people, and because of that, we'll be able to address more than one or two challenges at once.

And as you've mentioned paying for the library - assuming it has been of value to you up to this point - you can always, at any time, contribute by becoming a backer, which costs only $5/month.

Regarding the problems with the v5 migration, I'd strongly recommend you open an issue so the team can help you in a more detailed way. As with any major releases, stuff like this is likely to surface but I'm confident that we can provide you support so your app is back on track, using v5. :)

[SomervilleTom]

Fair enough. I've just joined as a "Bronze Sponsor".

I'll try opening an issue for my migration, as suggested.

[danilo-leal]

Thanks for becoming a sponsor, I appreciate that!