Proposal: New control to support Lottie animations for progress scenarios

[kathyang]

Proposal: Create control to support custom Lottie animations for progress scenarios

Relevant proposal for a Diagram control with Lottie animation

Summary

The framework currently has two progress solutions (ProgressBar, ProgressRing), but we have found that developers want to create engaging progress experiences that match their branding and design that are not well suited by the existing controls. This new control will provide developers with an option for branded, custom progress.

Rationale

• Support developers who are already using Lottie animations across different platforms
• Allow developers to use branded, custom progress animations
• Allow for more distinction and insight for app users to understand where the progress is occurring (example: map icon-styled progress bar to indicate that a map is loading)

Scope

Capability	Priority
Allow developers to use Lottie animations for determinate and indeterminate progress scenarios	Must
Distinguish AnimatedVisualPlayer from a separate AnimatedProgressUI control	Must
Provide developers an option to handle error scenarios	Could
Alter existing Progress controls (ProgressBar, ProgressRing) to need Lottie files	Won't

Important Notes

Download the Lottie Samples app to view code samples for common Lottie animation scenarios and view https://lottiefiles.com/to learn more about Lottie.

Below is what a custom progress Lottie animation could look like for indeterminate and determinate states:

Open Questions

1) How often do developers switch between indeterminate and determinate progress at runtime?

[shaggygi]

Referencing #792 as it was a similar (not exact) topic that was closed.

[michael-hawker]

🦙 Linking back to this PR when Lottie was added to ProgressRing as a lot of community discussion around customizations of the animation occurred there, especially in regards to traditional XAML based Visual State Management/customization & styling.

[MarissaMatt]

@michael-hawker thank you for linking the PR! That gives me a lot of context around the customization of animations. My main takeaway from the other thread is that we need to provide an easy way for a user to swap in their own animations if they want to use something that is not a bar or a ring. This is primarily true for indeterminate progress but can be applied to both indeterminate and determinate progress scenarios. @ranjeshj please feel free to add more context if I am missing anything!

[ranjeshj]

ProgressBar/Ring are expected to be compatible with the WUX version, so they will support custom templates that are storyboard based. The concern in the PR was that we were not going to allow customizing the template with storyboard animations which has been addressed. Lottie has advantages with perf because under the covers it is all comp animations and avoids creating lots of storyboard/xaml objects. It can also help taking an animation designed by a designer and quickly get it into code (instead of translating to xaml elements and animating them which can be quite time consuming). There are also a ton of community created ready to use animations (lottiefiles.com).

[MarissaMatt]

Hi everyone! I am picking this proposal back up from @YuliKl and @kathyang and since it has been several months since this proposal had activity, I updated the proposal with what we are currently thinking for this control. I also added an open question I was hoping to get some developer feedback on. @michael-hawker if you have any insight in to this that would be really helpful!

[mdtauk]

ActivityAnimation could be a more generic name and approach for this control.

Support for idle and progress animation loops, before having a completion animation?

The Android Bootscreens do this, and whilst this could be achieved with just the Lottie player control - it may be a relevant consideration for this control.

[mdtauk]

With the right naming of elements, it could also be possible to support Xaml brushes, for things like Light and Dark theming of a single animation, as well as a more traditional progress control scenario.

You could even override any colour directly in Xaml, to allow for reusing of existing Lottie animations, but customising without having to go back into After Effects, or the JSON and C code.

[ranjeshj]

@mdtauk If the animations expose the appropriate properties (foreground/background colors) then that could be done without edits to the lottie files/json.

One advantage of having a separate control over AnimatedVisualPlayer is that you would get the appropriate accessibility patterns with this control which are not on the player.

[mdtauk]

@mdtauk If the animations expose the appropriate properties (foreground/background colors) then that could be done without edits to the lottie files/json.

One advantage of having a separate control over AnimatedVisualPlayer is that you would get the appropriate accessibility patterns with this control which are not on the player.

This proposal is about providing more complex visual progress scenarios as I understand it. Some of these kinds of illustrations and animations, may need more than one or two colours applied.

Something like this, is used by Windows 10X for their OOBE experience.

It would be good to be able to supply a list of colours, and have them be applied to the animations.

[MarissaMatt]

ActivityAnimation could be a more generic name and approach for this control.

Support for idle and progress animation loops, before having a completion animation?

The Android Bootscreens do this, and whilst this could be achieved with just the Lottie player control - it may be a relevant consideration for this control.

@mdtauk thank you for the feedback! In reference to your suggestion about idle and progress animation loops, are you referring to a scenario where you might want to convey that something is about to load vs actively loading and swapping animations when you transition from one state to the next?

[mdtauk]

You could imagine various scenarios where that would be helpful to have. But I am just thinking out loud.

It should be the customers and experienced devs who's needs are met first.

[robloo]

@MarissaMatt stated:

we decided to make the determinate mode Lottie based to help improve performance and to create a consistent Fluent UI feel between the two modes that would be difficult to achieve with Storyboards. I agree that re-templating is an important part of the Xaml developer experience but re-templating progress controls has always been difficult. We want to provide a more generalized progress solution using customizable Lottie animations and we created a proposal for that feature here

Creating a specialized control for lottie animations of a progress bar/ring doesn't seem general purpose. If you are just displaying a animation with AnimatedVisualPlayer there is no issue once #1968 is closed. The problem starts occurring when you are passing brushes/colors or even progress state to an animation. I've seen nothing anywhere close to general-purpose.

This control seems to be a very specialized technique to solve 1 use case: progress bars/rings. What is the general-purpose solution 'glue' that can be used to link dependency properties / XAML with lottie animations? I've seen no solution for that yet.

[ranjeshj]

@robloo #2802 might be of interest to you.

[mdtauk]

Regarding my comment in another issue, where you would support a looping animation in the similar vein to an indeterminate progress control, then transitioning into a Completed animation.

I would like to cite the Android Boot Screens you see on phones. Whilst the OS is loading an animation plays, looping until the load is complete, where the final loop plays out the final part of the animation.

Being able to make an animation that can loop, and transition into another animation would require some easy to designate a series of frames to loop between, and any other series of frames to act as transitions or other loops.