Material-ui: [Feature request] Implement page transitions (spec: Choreography)

[owencm]

I've noticed is that when building an app with material-ui there is no obvious way to do page transitions which are an important part of the overall UX.

Can we add page transitions in to backlog for future releases, or is there a recommended complementary library?

[nathanmarks]

@owencm if you've got any good references, that'd be wicked 👍

https://www.google.com/design/spec/animation/meaningful-transitions.html

etc etc

[nathanmarks]

@owencm

PS: I've almost got an implementation ready using react transition group for this material design enter/exit animation of a grid:

https://material-design.storage.googleapis.com/publish/material_v_4/material_ext_publish/0B08MbvYZK1iNTGRLb2Zud2RUNFE/animation-meaningfultransitions-hierarchicaltiming-4do_large_xhdpi.webm

[owencm]

I'm actually more concerned with whole page transitions -

If you open any app and tap buttons you'll notice that the title bar and content all fade in or move in from some direction in some smooth way. I'd love to make it easy to do that with Material UI.

See this example for one very specific set of navigation transitions done in React Native. Something like this that supports a general set would be awesome: https://youtu.be/3W58KampkXc?t=19m3s

I note that some Routers have transition support, for example see https://github.com/maisano/react-router-transition. For that reason I'm not 100% sure yet where these transitions should be implemented. I presume if we want more intelligent transitions that have e.g. different effect on title bar to the contents it will need to be in Material UI directly?

[oliviertassinari]

I'm actually more concerned with whole page transitions

I'm also quite interested in this topic. That's definitely something missing to compete with a native app.

for example see https://github.com/maisano/react-router-transition

We have tried using this lib at @doctolib without any luck. The approach used is too simple.
Applying the right transition depending on the using actions is far from being a simple problem.
The first thing that we learned is that we need to split the concern. We have build

1. one module to handle the transition state problem. It's pretty much answering the following question: which transition do I need to apply, based on the history / touch / network events.
2. one module to actually apply that transition. The material specification adds an extra complexity layer if we compare to the iOS model, as the transition is _context aware_. E.g. What makes a good transition?

For that reason I'm not 100% sure yet where these transitions should be implemented.

From my point of view, we should be focusing on addressing the point 2.
Actually, you might be interested in a talk I have given earlier this year: screen-transitions-with-ease.
We are using https://github.com/doctolib/react-router-transitions to solve point 1.

[owencm]

I agree. Focusing on applying transitions is a problem more coupled to this library too.

I can imagine a far future where we utilize something like FLIP.js to allow devs to specify an element in the 'before' state and one in the 'after' state and then have us ensure those transition nicely, while using a standard transition for the rest of the screen. It is my understanding that this is roughly how these transitions are implemented in Android (although I've not verified that myself and am not an expert).

For now I'd rather focus on the simpler page transitions since that's far lower hanging fruit. Something close to what you describe in your talk with a bunch of preset transitions would be a great start.

I would personally be super happy if we can create an API (with flexibility for adding complexity in the future) with initial support for the following:

1. Whole page transitions where everything (including the AppBar/BottomNav etc) is transitioned (with correct history/contextual direction etc)
2. Transitions where the main 'page' contents (minus the AppBar/BottomNavigation etc) are transitioned via a simple transition, with a secondary transition for the other components, e.g. a fade for the AppBar.

[xsh2047]

Hello, i'd like to know if the v1-alpha branch would have need for transitions such as the ones located here:
Choreography - Material Spec
I realized that they are grouped into three categories, namely: radial, continuity and creation.

Note: Continuity closely resembles the transitions achieved with the Popover component however with Modals, the origin of the transition is from the top instead of the bottom as shown in the demo on the page. Would this require a change?

[madou]

Hi @oliviertassinari! I develop a library called yubabajs (see: yubabajs.com) - which is primarily inspired by material animations. I think it would fit lovely with material ui (the landing example is built with it, actually!).

These days you don't want to re-make everything yourself - yubaba has been made to be small (within reason, its tree shakeable at least - if its not small enough lets talk), performant, and powerfully customisable - let's talk?

[oliviertassinari]

@madou Thanks for sharing your work. I like that: https://twitter.com/olivtassinari/status/1126261655124496389.
I only wish the demo transition duration was faster. How did you pick the value?

We have no plans to work on the transitions for v5 (6-12 months from now).
How do you think that we can help each other? :)

[madou]

Thanks for sharing your work. I like that:

thanks!

I only wish the demo transition duration was faster. How did you pick the value?

so the it's transition based - but it's all dynamic based on how big the elements are, how far they're moving, and if they're expanding or collapsing.

i take the base values from https://material.io/design/motion/speed.html#duration, implementation here https://github.com/madou/yubaba/blob/master/packages/yubaba/src/lib/duration/index.tsx#L36 it's quite simple atm.

currently the dynamic stuff can't be tweaked via a public api but anything can be changed if it's more correct.

We have no plans to work on the transitions for v5 (6-12 months from now).
How do you think that we can help each other? :)

tbh yubaba's origins have always been about re-creating material motion on the web - so i think it kind of goes hand in hand with a material library hehe.

right now i have a roadmap going through the material motion catalog to implement new animations (and changing the core of the library if it needs) here https://github.com/madou/yubaba/issues/49 which i'll be slowly working through.

i've already shown one example of a transition working with the library - considering material-ui isn't planning on working on transitions for the next major version perhaps i can do more examples using public apis? a cookbook showing how a consumer of material-ui could get motion today which would be a page on the material ui website or something.

i think the holy grail though would be out of the box motion using yubaba though, for consumers.

what to do you think?

cheers 😄

[mbrookes]

Looks really nice from skimming the demos.

I have to agree on the speed issue though. Perhaps something to look at. I believe that following the spec, a particular type of transition takes a certain amount of time, regardless of the size; so it is time, not speed that counts. I might be wrong though.

Does the name 'yubaba' hold special meaning? You might find more traction with a more descriptive name like 'material-motion'.

[madou]

I have to agree on the speed issue though. Perhaps something to look at. I believe that following the spec, a particular type of transition takes a certain amount of time, regardless of the size; so it is time, not speed that counts. I might be wrong though.

all fair points! it can be very easily tweaked - the main thing i'd want personally is something out of the box that works great. no configuration needed ideally. as a rough feel how faster do you think it should be?

material-motion

ohh that's a good suggestion! "yubaba" doesn't hold any special meaning that i wouldn't want to let go of tbh. always struggled with names.

oof it's a google lib though haha https://www.npmjs.com/package/material-motion

@material-motion/core
@material-motion/animations

maybe

[mbrookes]

it's a google lib though

Ah, sorry, I didn't check. I was just throwing out a random suggestion. There will be something along those lines available I'm sure!

[mbrookes]

as a rough feel how faster do you think it should be?

As I understand it, you are scaling the transition time according to the size of the element / distance to be moved. If I am interpreting the spec correctly, you should instead be using fixed durations regardless of the size or distance.

If that's too rigid, the scaling factor should still be minimal.

[madou]

scaling the transition time according to the size of the element / distance to be moved

yeah that's right - ill make a issue to investigate it over here https://github.com/madou/element-motion/issues/121 to reduce to noise here ✌️

[madou]

so it turns out that example had a fixed duration of 600 - removing it makes it a little faster and more to spec 👍

anyway my question to you both - do you think element-motion (renamed the library 😅) would provide any value to material-ui - and if yes would you be interested in me writing up interop examples to be referenced in docs?

[mbrookes]

Sounds good to me!

[PedroBern]

I'm actually more concerned with whole page transitions -

(...)

I note that some Routers have transition support, for example see https://github.com/maisano/react-router-transition. For that reason I'm not 100% sure yet where these transitions should be implemented. I presume if we want more intelligent transitions that have e.g. different effect on title bar to the contents it will need to be in Material UI directly?

@owencm I've made a library react-tiger-transition that implements whole page transitions, but it also allow to define specific transitions for each component.

As @oliviertassinari defined it on #18392:

It seems to be a generic navigation library, it's not directly related to Material-UI.

It's easy to implement, here is an example preview of animated tabs, available on the documentation.

This example leverages the transitions of the module without using other components, although these other component actually make the navigation easier, because they provide the necessary css layers to build these transitions and integrate with react-router-dom.

Here is an example of whole page transitions:

[oliviertassinari]

I'm closing the issue, it has been open for +3 years but didn't get a lot of traction. I think that we can defer the concern to a third-party library.