Hello :robot_face: I wrote a blog post on some opi...

[Nick Rout]

Hello 🤖 I wrote a blog post on some opinions/ideas about design systems in Jetpack Compose. All feedback welcome! If you're interested you can check it out here:
https://medium.com/@ricknout/dc579fde79b2

[eygraber]

I've felt this pain before, but I think a design system layer is really difficult to get right because it ends up constraining your implementation to whatever the layer determines the component is.

[Nick Rout]

Hmm, I don't see it as covering/governing every component in layers above it. Rather it's a base for common components and additional ones could be built from Foundation

[eygraber]

I mean it constrains the implementation of the individual components because of the base for common components.

The issue is that if you have an implementation that doesn't slot nicely into the base, and you have to start contorting it to fit.

[Nick Rout]

I'd say Material is doing that already, no? Just on a more exaggerated level

[eygraber]

Yes, but without the intention of being an extensible design system layer.

[agrosner]

I don’t think it makes sense. You can build your own design system layer. We have our own. Maybe community ones would suffice

[agrosner]

I do agree though, defaulting to material should not be the right way

[Nick Rout]

Yes, but without the intention of being an extensible design system layer.

I politely disagree :) That is (partly) the intention

[eygraber]

Within the material spec though.

[eygraber]

You can break out of it, but I don't think that was the intention.

[Nick Rout]

Within the material spec though.

Not always. Hence why guidance like this exists:
https://developer.android.com/jetpack/compose/designsystems/custom

[eygraber]

That always seemed like a bad idea to me 😬

[Kirill Grouchnikov]

Even the proposed base doesn’t handle the third button. And that’s before accounting for borders - color + brush + path effect + stroke width. And that’s before accounting for hover / select / press / focused colors with all possible combinations of those. And that’s before supporting dropdown and split modes. And that’s before allowing to pass in a custom Skia shader that is only supported in desktop variant, which then means that you can’t even put it into the common layer. And it keeps on going and going.

[Kirill Grouchnikov]

The more you pile onto that mega-flexible design layer (such as all of the above + elevation to make the Material button actually follow the Material spec), the more difficult it becomes to “hold” this API surface in your head - as an implementer of it but also as a user of it. When it gets to 15, 20, 30, 50 parameters that you can pass, even having “reasonable” defaults isn’t enough to make it work.

And every parameter that you add multiplies the complexity of implementation, so you have an exponential increase in complexity with every single addition as the developer and the maintainer of that layer.

[Nick Rout]

It doesn't because Modifier.shadow is too limited and influenced by Material 😉 And anyways the proposed base is very simplified, definitely agree it can get a lot more complex quickly. But Material isn't a good based right now, either. It's on the other end of the spectrum of being too inflexible. Could there not be a reasonable middle ground?

[Kirill Grouchnikov]

Material was opinionated from the very beginning, and wasn’t positioned to be the base for any other design library out there. As for making something reasonable that can be a better alternative? Sure, why not. I’m 100% certain that it will end up with its own “opinions” and “restrictions”, but that’s just my 2 cents. The best way to convince the non-believers is to make it happen as an actual project that can be poked and prodded to see how well it delivers on its promises.

[Nick Rout]

Sure, but that's how it's been used (and occasionally advocated for) IRL. And sometimes those opinions leak into other layers, like the shadow example. But yes I agree there will always be some level of opinion, just a matter of how much. SwiftUI is a good example, Compose Material feels overly opinionated in comparison IMO. But yeah I agree that the best way to test the feasibility is by putting my code where my mouth is 😛

[Stylianos Gakis]

Material was opinionated from the very beginning, and wasn't positioned to be the base for any other design library out there.

While that is true, I feel like we need to agree that it ends up being that in practice. I'm not talking for Duolingo or Tinder here, who probably have more Android devs than other companies have developers in general, but for all those other apps that have 1-3 Android devs. At the moment building on top of material 3 is what those teams do unless they have the time to invest in building everything on top of foundation, but that sounds like a herculean effort atm.

[Kirill Grouchnikov]

If product and design ambitions are to have a fully bespoke design system that is unique to that company, they should expect to match those ambitions on the engineering side by putting enough resources to support that vision

[agrosner]

I’d certainly argue it’s 10x easier to make your own system than it was in views, and may be worth blending both custom and some material use cases via an adapter layer to get what you need. Like your own button component and text component are actually not awful in practice

[agrosner]

I’ve worked on many small projects in past with react , and wrapping components in material ui relatively worked for most part. There were certainly weird situations trying to morph the components to match a different system

[agrosner]

Smaller team definitely is a challenge to make something fully custom

[Nick Rout]

Which real world apps — big or small — are realistically using Material 3 in its default form? I'd argue that most teams go custom and shouldn't need to invest that much into implementing their design systems

[eygraber]

I pretty much only use default Material 3, but I've never really had the support to customize it or make my own design system

[Nick Rout]

What do y'all think about Material in Compose Multiplatform?

[eygraber]

For hobby apps and non consumer apps I think it's fine.

Otherwise I think there needs to be either the native look and feel for the platform or an agnostic brand design system. Redwood can kind of help with both, but I think it does better for the latter.

[Mark Murphy]

> If product and design ambitions are to have a fully bespoke design system that is unique to that company, they should expect to match those ambitions on the engineering side by putting enough resources to support that vision
IMHO, Google claimed to support arbitrary Compose design systems, then "mailed it in" on the implementation. IOW, they whiffed on "putting enough resources to support that vision".

Robert Glass, in Facts and Fallacies of Software Engineering, wrote:

> There are two "Rules of Three" in reuse: (a) It is three times as difficult to build reusable components as single use components, and (b) a reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.
(courtesy of Coding Horror)

In the case of a situation like Compose design systems, a restatement of (b) is: you cannot claim to support arbitrary design systems unless you ship at least three such design systems in production form.

At the outset, Google shipped one.

Had Google made the investment in multiple design systems, I think Nick's concerns would have been addressed as a side effect. To be fair, they only had so much staff time... but the discrepancy with the "oh, just build your own design system" advice is a tough swallow for me.

Quoting Nick:

> In the absence of this, I can imagine a third-party “Compose Design System” library maintained by the Android/Kotlin/Compose developer community.
There are several independent design system implementations just in open source. If a few banded together, they might be able to identify where common pain points are and craft something to help with custom design systems. I don't know whether that is closer to a utility library or something more like Nick's design system layer.

[Zach Klippenstein (he/him) [MOD]]

Re: shadows specifically, they’re not just opinionated in material, android is opinionated about shadows deep into the graphics pipeline

[Marcin Wisniowski]

> android is opinionated about shadows deep into the graphics pipeline
I didn't notice for many years that shadows are actually dynamic and there is a simulated light source. I.e. if you have a scrolling list of cards with shadows, the shadows are slightly changing as the card moves on the screen.

[Kirill Grouchnikov]

Shadows are deeper towards the bottom edge of the screen