Page MenuHomePhabricator

Document Motion tokens (animations and transitions)
Closed, ResolvedPublic

Description

Background/Goal

We need to document in our design system all the animations and transitions that we are currently using.

User stories

  • As a designer, I need to know what transitions and animations I can in my designs.
  • As a system designer I need to know what transitions are being used in our system and what transitions I can use to create components.

Figma

Figma spec sheet here.

Acceptance criteria (or Done)

Design

  • Document motion tokens:
    • Animation tokens
    • Transition tokens
  • Add motion tokens documentation in our Figma library

Code

  • Implement and document all
    • animation tokens in Codex and
    • transition tokens in Codex

Related Objects

StatusSubtypeAssignedTask
Duplicate STH
InvalidNone
ResolvedVolker_E
OpenNone
OpenNone
ResolvedNone
Resolvedbmartinezcalvo
ResolvedVolker_E
ResolvedVolker_E
ResolvedVolker_E
ResolvedVolker_E
Resolvedldelench_wmf
ResolvedVolker_E
Resolved EUdoh-WMF
ResolvedSarai-WMDE
ResolvedDAbad
ResolvedVolker_E
Resolvedbmartinezcalvo
Resolved KieranMcCann
OpenNone
DuplicateNone
ResolvedVolker_E
ResolvedDAbad
ResolvedVolker_E
ResolvedDAbad
ResolvedSarai-WMDE
ResolvedCatrope
OpenNone
Resolvedovasileva
ResolvedBUG REPORTVolker_E
ResolvedVolker_E
ResolvedVolker_E
ResolvedVolker_E
ResolvedVolker_E
ResolvedSarai-WMDE
ResolvedVolker_E
Resolvedbmartinezcalvo
ResolvedCatrope
ResolvedDAbad
ResolvedVolker_E

Event Timeline

bmartinezcalvo renamed this task from Document the Animation tokens to Document Motion tokens (animations and transitions).Mar 24 2022, 1:05 PM
bmartinezcalvo updated the task description. (Show Details)

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

As the design proposal was sent I move the task to Ready for development and I leave the task free to be assigned by whoever starts with its development.

@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

@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.

Captura de pantalla 2022-04-12 a las 10.17.38.png (772×682 px, 196 KB)

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.

@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.

Captura de pantalla 2022-04-14 a las 12.09.35.png (950×1 px, 230 KB)

Captura de pantalla 2022-04-14 a las 12.09.46.png (906×814 px, 269 KB)

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?
STH renamed this task from Document Motion tokens (animations and transitions) to [Ready for Development] Document Motion tokens (animations and transitions) .Apr 15 2022, 9:15 PM

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

Captura de pantalla 2022-04-28 a las 12.40.19.png (900×678 px, 245 KB)

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

@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"

Captura de pantalla 2022-04-29 a las 13.01.24.png (988×870 px, 317 KB)

@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.

Captura de pantalla 2022-04-29 a las 14.24.38.png (1×1 px, 375 KB)

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.

STH triaged this task as High priority.May 1 2022, 12:54 PM

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

Volker_E removed a project: Patch-For-Review.
Volker_E updated the task description. (Show Details)

Both token groups have been merged into Codex. Assigning to @bmartinezcalvo to the final step of publishing the Figma tokens.

Volker_E renamed this task from [Ready for Development] Document Motion tokens (animations and transitions) to Document Motion tokens (animations and transitions) .May 10 2022, 9:47 PM

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

bmartinezcalvo updated the task description. (Show Details)
Catrope claimed this task.