[Design Language] Motion token

[alex-page]

This token needs a lot of context that is now missing. Not sure when but @johanstromqvist will be looking into this. It might even be multiple tokens, such as easing curves and duration.

Known values

What does motion look like in the masterbrand?

Suggested tokens

What are the token values and names?

[johanstromqvist]

Is there any particular context missing from a systems perspective?

Easing
From design perspective, the naming convention default, appear, and disappear are more descriptive aliases to the technically correct and more conventional ease-in-out, ease-out and ease-in. The "aliases" will likely work +95% of the time, but on occasion those descriptions won't make sense. Ideally we can use the aliases in docs and communication, and it will allow designers and developers to choose easing curves confidently and coherently, while we also have ease-in-out, ease-out and ease-in available for cases where they are needed.

If we want no layers of abstraction in the tokens then they should be follow convention and easings should be called ease-in-out, ease-out and ease-in.

We also need an easing-linear that either can reference standard css value linear or cubic-bezier(0, 0, 1, 1) for sake of consistency.

  - name: easing-default
    value: 'cubic-bezier(0.4, 0.22, 0.28, 1)'
  - name: easing-appear
    value: 'cubic-bezier(0, 0, 0.13, 1)'
  - name: easing-disappear
    value: 'cubic-bezier(0.5, 0.1, 1, 1)'

Duration
Durations aren't as conceptualized as easing, and I don't think we'll ever have any clever naming convention for those values. If we do anything clever it's more likely some dynamic calculation.

From a design perspective we're likely to need durations from 0ms to 400ms with at least 50ms increments in the short term. How we shape and name meaningful tokens may depend more on system needs. I could for example see it work like a type scale where changing one base value will change all outputs. However, this is just speculative.

[LauraAubin]

Detailed info regarding rationale, specification, usage, and naming convention here.

[johanstromqvist]

Thoughts
Thinking around duration is less mature than around easing, but here are some thoughts:

• Our current naming convention slow, fast, faster, etc is quite convoluted and arbitrary.
• We currently don't have any other clever convention that implies how duration values should be applied.
• Until we have a system for duration, designers will to a greater extend need to use their best judgement.
• Examples and guidelines are needed to guide such judgement decisions.
• There are ideas and hypotheses on such guidelines, but currently no time set aside to document and validate those.

Suggestion
Meanwhile, my suggestion is that we'll create tokens along the lines of the following:

 - name: duration-100
    value: '100ms'
 - name: duration-150
    value: '150ms'
 - ...
 - name: duration-300
    value: '300ms'

• I don't have a strong opinion on the naming convention; dur, duration, etc.
• We will need increments of 50 ms.
• ~99% of the use cases will fall within the range of 100-300ms.
• If we wanna cover 99.99%, we could extend the range to 500ms.
• If we want to use duration to set delays, we should include the 50ms value in the range.
• At a minimum [100, 150, 200, 250, 300]
• Or at full range [50, 100, 150, 200, 250, 300, 350, 400, 450, 500]
• If there are no particular cons with the full range, I suggest going with that.