https://kotlinlang.org logo
Join Slack
Powered by
The amount of <special-casing> that seems to be ne...
# compose
z
The amount of special-casing that seems to be needed specifically to support ripples – someone at google must have very strong feelings about them 😂 Do any other compose operations happen on the render thread (e.g. 
graphicsLayer
changes that don’t require recomposition perhaps)?
i
RenderThread does not run arbitrary work, nor does it have the APIs to do so
So ripples are indeed a very special case
z
I’m admittedly not familiar with this, but some quick googling points to some documentation indicating that some 
View.animate()
operations use the render thread, and a reveal animation helper?
Seems like stuff that would be an implementation detail of `RenderNode`s or something
r
Ripple is definitely a special case for a special reason
Clicking a button (thus showing a ripple) often leads to starting a new Activity or other large chunk of UI
Which keeps the main thread busy
So moving the ripple to the render thread was a way to keep the UI looking responsive while that new chunk of UI is being built/presented
z
makes sense. seems like a disproportionate amount of engineering effort required for such a subtle part of the design system – i would love to have been a fly on the wall for the early eng/design discussions about the tradeoffs 😅
r
This is coming in beta06? (If I interpret the linked to page correctly.)
a
eh, I'm not sure I'd call it subtle; the perception of responsiveness or lack thereof that results is pretty huge
👀 1
➕ 2
z
interesting – i’m sure there were some fascinating user studies there. I don’t know any other mainstream design systems that have something like ripples (probably due to the the evident engineering challenges), so it seems (to me) like it was a fairly arbitrary decision to make it such a core part of Material. And I also think it’s relatively subtle compared with something like the background blurring that is so prominent in iOS’s design system – that blur is everywhere, they lean on it super heavily, vs the ripple which is almost exclusively used for button clicks. I’m not trying to say it was a bad decision, but given the amount of engineering effort clearly required to implement it, I am surprised it ended up being so important as to justify all that investment.
Anyway, this is a cool approach with the view pool.
a
if you want to talk engineering effort for subtlety, let's talk about shadows 😄
😅 10
r
Yeah it’s not subtle
Seeing the animation lock up for several frames really made the system feel less responsive than it actually is
Now those shadows on the other hand… :))
z
For sure, ripples not working when they are expected is noticeable – but if the design system hadn’t included ripples at all, and we weren’t used to them, it would still be pretty much the same design system.
Joking aside, shadows do seem more “general” in a sense - they are used by many different components to indicate different kinds of separation, and different levels of it. Feels like they can carry more “signal” in a way.
I can easily believe that it turns out people really value highly-visual button feedback specifically, and the impact is just not obvious until you actually do the user studies.
c
I don't know if arbitrary is the right word to describe the ripple effect. The ripple is certainly distinct from other design systems but it is an intentional visual effect and choice from Material Design to emphasize touch feedback, to make the user feel the UI is responsive on any element that can be deemed interactive (not just buttons). Visual design is always subjective. I love the blur effect in iOS, wish it was easier to do in Android, but is it more or less arbitrary than the ripple or shadows?! I can't definitively say so. I think design rationale can be made for every visual effect in a design system, but like I said, visual design is highly subjective. In our case, the ripple is a marquee visual element we want to have for developers out of the box so one doesn't have to implement it themselves. And as we can see, it's non-trivial to get right. 😅
That being said, the reality is many Android/Google apps have the ripple effect since they follow Material. And because of that, many developers will ask "how do I make my app look like that??" So from the Compose POV, we wanted to be Material first, out of the box, so that things like ripple are there and just work for you.
r
Shadows are more general but the particular implementation we use is incredibly complicated for an effect that:
1. is often very subtle
2. makes some devs think there’s bug (shadows move as items move across the screen)
😅 1
(I still want to ship my raytraced version)
🙏 2
z
Whew, I didn’t really mean for this to turn into a high-level discussion about design philosophy, but since we’re here… 😅 Yea, in a sense almost all design is arbitrary, at least within its constraints. But within constraints, usually visual designs are balanced with implementation effort. It is theoretically easy to argue for a significant amount of eng effort to meet external constraints (e.g. small ram/processor imposing constraints on animation APIs in early android), but typically more debate around design decisions that aren’t hard external requirements but still need a significant amount of eng effort. Ripples, shadows, blurs both seem like the latter to me. Clearly, validated empirically, so definitely not arbitrary any more at this point. Which makes me wonder, if these are such valuable features, why have other prominent design systems not done this stuff before? Probably engineering constraints? Ripple, shadows, and blur all clearly require a lot of clever tricks and eng effort, but also probably are just not feasible on hardware from even 10 years ago?
r
Blur is expensive and existed in our first phone actually because there was a dedicated chip that could do it at the windows level
Ripples are not expensive
Shadows, it depends. A shadow can be implemented as a blur 😛
Our version is somewhat expensive because it computes proper umbra/penumbra by casting an area light through an occluder
today i learned 1
c
But within constraints, usually visual designs are balanced with implementation effort.
Indeed. I think though given the ripple effect is for a design system for an app platform, the ROI is different since we’d like to help all developers avoid the cost of doing it themselves.
z
For sure, can’t imagine this being justifiable at all by smaller teams for individual apps 😅
😅 1
2 Views
Open in Slack
PreviousNext
Powered by