Hi all,

I've collected all Animations and Transitions (both global and decision tokens) in the same spec sheet, trying to mix both Animations and Transitions in the same Motions section since I think is easy to the user to read all the information about these tokens in the same section, both will be used for add move to the components. If you agree, we could do the same in Codex and have one Motion section with 2 subsections: Animations and Transitions.

Decisions to be made:

• Timing-Function nomenclature. I used the following names: 1. Progress, 2. User (instead of human), 3. System
• Should we finally add Timing-Delay transition tokens @Volker_E ?

Here you can view the Figma spec sheet with all documented tokens.

cc: @iamjessklein

@bmartinezcalvo Need to clarify two questions before code clarification: We don't [[ https://codesearch.wmcloud.org/search/?q=ease-in&i=nope&files=&excludeFiles=&repos= | need ease-in AFAICT as there's no use for it]]. With that we probably don't need a progress timing function.
Left same comment and another one in Figma

In T304443#7847085, @Volker_E wrote:

@bmartinezcalvo Need to clarify two questions before code clarification: We don't [[ https://codesearch.wmcloud.org/search/?q=ease-in&i=nope&files=&excludeFiles=&repos= | need ease-in AFAICT as there's no use for it]]. With that we probably don't need a progress timing function.
Left same comment and another one in Figma

@Volker_E as I've commented in Figma, ease-in (transition-timing-function-300) is being used in the determinate variant of Inline Progress Bar.

We need to differentiate between determinate and indeterminate, ease-in could make sense for an indeterminate Progress Bar.
Currently (OOUI) we don't have it for the indeterminate and the indefinite is also not going left to right and vice-versa.
For a determinate it is not recommended as it would falsify system feedback to the user.

(Copying from Figma)

I think I introduced the confusion here. I specified the determinate version of the inline progress bar based on a code prototype that applied ease-in. That's what triggered the question of whether we should introduce that timing-function in the system. Now, I think that ease seems to work fine with the determinate inline bar (tried it in this Codepen), so we could use that instead with that component and avoid using ease-in for now.

@Volker_E deleted ease-in transition from our tokens. We will finally use ease for progress bars too.

You can view the Figma spec sheet with the last versions of tokens here.

@Sarai-WMDE Thanks for your overview of the transitions and the ease-in-out for indeterminate. So much better!

@Volker_E We're currently not documenting ease-in-out as a token, although I agree that it works better with the indeterminate version of the progress bars (it's so smooth!). Would you say we should include this extra timing-function, or stick to the decision of applying ease everywhere?

@Sarai-WMDE Ha, I was remembering seeing ease-in-out at one of your iterations in this CodePen.
For something system-induced, while bouncing, like the inlined ProgressBar, also the Bouncing Dots progress indicator (already featuring it), ease-in-out seems to fit best.

In T304443#7853455, @Volker_E wrote:

@Sarai-WMDE Ha, I was remembering seeing ease-in-out at one of your iterations in this CodePen.
For something system-induced, while bouncing, like the inlined ProgressBar, also the Bouncing Dots progress indicator (already featuring it), ease-in-out seems to fit best.

I agree that this ease-in-out is perfect in cases where the element is like bouncing, so I would add it as token. I've created this new version adding it as global (transition-timing-function-300) and decision (transition-timing-function-bouncing) tokens. I prefer to add a new token in this case instead of using another token that is more rigid for such this specific bouncing case.

Thank you both for the quick feedback and iteration! Thanks Bárbara for updating the designs so fast. I'm really glad we decided to include ease-in-out.

Just a couple of final comments:

• (Sorry for bringing this up again but..) I'm not sure that using numbers to name the global timing function tokens is very semantically accurate. Should we find a different approach? Or even use the CSS value? Please ignore this in case it's just me.

• I think that "Bouncing" implies an up and down movement and is too much of a reference to the BouncingDots loader component (thus excluding the indeterminate inline progress bar use case). Since in both cases the animation indicates an indeterminate amount of progress/remaining waiting time, what if we named this token transition-timing-function-indeterminate?

I'm fine with either approach here, I don't think we have to reuse the timing function theme tokens very often, so numbers are okay-ish. Possibly CSS value inherited names are a small for devs.

Bouncing is a movement not bound to any axis, could be up/down or left/right. I think it's good to use bouncing as it describes what it is.

Change 784080 had a related patch set uploaded (by VolkerE; author: VolkerE):

[design/codex@main] tokens: Use 'user' as name for human initiated timing function token

https://gerrit.wikimedia.org/r/784080

Change 784081 had a related patch set uploaded (by VolkerE; author: VolkerE):

[design/codex@main] [WIP] tokens: Add design-first transition tokens

https://gerrit.wikimedia.org/r/784081

Change 784080 merged by jenkins-bot:

[design/codex@main] tokens: Use 'user' as name for human initiated timing function token

https://gerrit.wikimedia.org/r/784080

Remaining open question for transitions is on how to deal with shorthands (f.e. transition-base), which are a necessary simplification for devs.

Change 787340 had a related patch set uploaded (by VolkerE; author: VolkerE):

[design/codex@main] tokens: Add design-first animation tokens

https://gerrit.wikimedia.org/r/787340

@Volker_E based on you last comment in Figma about adding animation-timing-function, I've added the linear animation value to use in progress bars.

Added the following:

• Option: animation-timing-function-100
• Decision: animation-timing-function-regular

@bmartinezcalvo latest patch includes the timing-function. As mentioned in Figma comment, instead of 'regular' we should reuse terminology and call this 'base'

In T304443#7888539, @Volker_E wrote:

@bmartinezcalvo latest patch includes the timing-function. As mentioned in Figma comment, instead of 'regular' we should reuse terminology and call this 'base'

@Volker_E updated it from "Regular" to "Base"

@Volker_E I've also replaced transition-property-all with transition-property-opacity since we are not using all and we are already using opacity for the message component (T284843)

Not sure about "Full" decision name. We can update it with a clearer name which explains that element disappears by adding opacity from 100-0.

This should best-possibly for now be transition-property-message then. Actually we use opacity at one other place in Codex already: The TypeaheadSearch button fade in and fade out. :/

Given a further look into how we apply the tokens best-possibly while at the same time have modular code output, I have come to the conclusion, we better don't use transition shorthands properties at all. See T307259: Settle on `transition` code handling across components for a longer explanation.
With that, we don't need shorthand tokens either. This should simplify our token architecture.

Change 784081 merged by jenkins-bot:

[design/codex@main] tokens, styles: Add design-first transition tokens

https://gerrit.wikimedia.org/r/784081

Change 787340 merged by jenkins-bot:

[design/codex@main] tokens: Add design-first animation tokens

https://gerrit.wikimedia.org/r/787340

Published Motion tokens spec sheet in both OOUI and Codex Figma libraries.