vmware-clarity / core

Clarity is a scalable, accessible, customizable, open-source design system built with web components. Works with any JavaScript framework, created for enterprises, and designed to be inclusive.
https://clarity.design
MIT License
161 stars 42 forks source link

Bring back loadingState transition/animation to cds-button #16

Open mathisscott opened 2 years ago

mathisscott commented 2 years ago

The clarity-angular loading button has a transition tied to the success state. This was not Clarion carried over to core because we did not have the animation library in place at the time.

And now that we have clarity motion we should use it to re-introduce the transition animation on the success state of the button.

We should consider whether the error state needs a transition animation as well.

CC: @colinreedmiller

To see the success state animation, go to the angular component docs (https://angular.clarity.design/documentation/buttons) and scroll down towards the bottom of the page for the loading button examples. Click on the "validate" button. You will see the checkmark fades in and grows.

API

This should just use the @animate() decorator and trigger an animation when...

@animate({
    loadingState: {
        "success": "name-of-fade-in-and-grow-animation",
        "error": "name-of-fade-in-and-grow-animation",
        "default": "name-of-fade-in-and-grow-animation"
    }
})
class CdsButton ...

The animation will probably need to run against a wrapper element inside the button. The most likely target would be .private-host.

Due to inheritance, this transition will also apply to icon buttons. With Lit 2+, animations are inherited. That's ok. No other button types inherit from CdsButton.

Conclusion

This would be a good issue for someone who is unfamiliar with clarity motion. It would be a good introduction to the animation library. The animation is simple and straightforward. The animation also only applies to an internal div inside the button. This means that there are minimal concerns about the transition affecting any child components. The transition involved is also easy to understand and interact with. I could see this as a 2-3 week focused engagement for someone new to the animations. Given meetings and distraction, it might run up to a month but I would not expect much longer than that. Someone who was already familiar with the animations library could probably implement this in a week or two.

colinreedmiller commented 2 years ago

The timing in NG feels a bit lethargic to me. Do we have a sense of how much snappier the Clarity motion values will be when applied here? We may want to create a custom value to remain in line with the subtext of high-performance. @mathisscott I believe it would be appropriate to use animation in error as well. Both have a strong UX functionality (Calling attention to important state changes).

mathisscott commented 2 years ago

We would/could/should use our motion design tokens. The current settings in Clarity Angular are...

      transition(':enter', [style({ opacity: 0 }), animate('200ms 100ms ease-in', style({ opacity: 1 }))]),
      transition(':leave', [style({ opacity: 1 }), animate('100ms ease-out', style({ opacity: 0 }))]),

the timing would correlate to our --cds-global-animation-duration-quick token. but the easing is obviously different. we could try it with a faster duration or one of our easing tokens.

colinreedmiller commented 2 years ago

I am all for using the existing tokens and believe they will be snappy enough - those values are quite quick. I just want to make sure that the assessment f the ng button animation as being a bit doggie is captured in this ticket for future reference.