Motion audit - design-motion-principles

Busabase node handoff - continuity before flourish

A focused audit of the four-node flight into the Busabase workspace sidebar, observed at 8.307 seconds. The concept is strong; the landing implementation breaks object identity at the exact moment the transformation should become legible.

What it isProduct launch motion graphic, one-time narrative beat
StackHyperFrames HTML + seek-safe GSAP timeline
Overall

The idea reads: external tools become trusted workspace nodes. The strange feeling is implementation-specific. A source chip and a destination row are visible in different places at the same time, while four easing segments repeatedly change the chip's velocity. Fix identity first, then shorten and simplify the wave.

01

How each practitioner reads the motion

Weighted for a polished product video: continuity and production finish first, speed and restraint second, experimentation only where it strengthens the one-time transformation.

LensVerdictOne-line read
Production PolishJakub KrehelPrimaryProblemThe landing is a crossfade between two different objects, not a continuous transformation.
Restraint & SpeedEmil KowalskiSecondaryConcernA 580ms flight is split across four eases and restarted every 240ms, making the wave feel fussy.
Experimentation & DelightJhey TompkinsSelectiveStrongThe converging wave is worth keeping; it is the right place for expressive motion in this scene.
02

Where the timings land

The total 580ms can work for a cinematic transformation. The problem is its internal structure: four speed resets, a 101ms dual-visible landing, and a new node launched before the prior one settles.

0100300500600ms 123456 duplicate window sits inside the stagger
  1. 1Lift80ms
  2. 2Dual-visible overlap101ms
  3. 3Final landing140ms
  4. 4Handoff crossfade180ms
  5. 5Node stagger240ms
  6. 6Total flight580ms
What's off

At 8.307s the App source is about three quarters through its child fade, while the App row is already near its final opacity. Both remain readable because they occupy different coordinates.

03

Jakub Krehel - Production Polish

Primary lens

Problem

What's working well
  • +Source and destination use the same icons and semantic names, so a convincing shared-element transition is available without redesign. 14-trust/en/index.html:332
  • +The movement uses transforms and opacity rather than layout properties. 14-trust/en/index.html:538
Issues to address
CriticalJakub

The landing creates two Apps instead of transforming one App

WhatThe source node's children fade from at + .40 to at + .58. The destination row begins entering at 44% of that same handoff and is nearly opaque before the source is hidden. At 8.307s the old App chip and the new App row are visibly separate.

Why it mattersThe scene's claim is continuity: work from each tool becomes a Busabase node. Two simultaneous objects read as duplication, not transformation.

Recommended motionKeep one source icon alive through the entire flight. Reveal the row shell and copy during the last 120ms, but keep its icon hidden. At the exact landing coordinate, swap source icon to target icon over one or two frames. A FLIP/shared-element handoff is ideal; a deterministic overlay proxy also works.

14-trust/en/index.html:544-545 and 14-trust/en/assets/motion-system/index.js:55-60

One icon, one landing420ms flight + 120ms row reveal
loop
APP
APPAppWorkspace nodeUI
CriticalAccessibility

Reduced-motion CSS does not reduce the GSAP camera or node flight

WhatThe media query disables CSS transitions on later evidence elements only. The registered GSAP timeline still runs the large camera move and all four node flights.

Why it mattersThis is full-frame zoom and translation. The audit contract treats a missing reduced-motion alternative as critical, especially for a browser-previewed composition.

Recommended motionBuild a second seek-safe timeline under gsap.matchMedia('(prefers-reduced-motion: reduce)'): set the camera to the workspace framing, reveal the four rows with a short opacity-only sequence, and skip all large x/y/z travel.

14-trust/en/index.html:100 and 14-trust/en/index.html:537-547

Opacity-only fallback120ms each, no camera travel
loop
DatabaseBase
SkillAgent
AppUI
Opportunities
  • +Stage the destination as shell, label, then badge during the final 120ms. Keep the destination icon reserved for the shared-element swap. 14-trust/en/index.html:332-335
Through Jakub's lens

The vocabulary is already polished; the identity contract is not. Finish the handoff as one continuous object and the same design will read as intentional.

04

Emil Kowalski - Restraint & Speed

Secondary lens

Concern

What's working well
  • +The flight is a one-time narrative beat, so it earns more time than a repeated product interaction.
  • +The 240ms offset clearly communicates a wave rather than four unrelated events. 14-trust/en/index.html:547
Issues to address
ImportantEmil

Four easing segments make one object restart its velocity four times

WhatThe same node moves for 80ms with sine.inOut, 180ms with power2.in, 180ms with power2.inOut, then 140ms with power3.out. Scale and z also change at every boundary.

Why it mattersEvery boundary creates a new acceleration profile. Near the sidebar this reads as a shrink, tug, and settle rather than a single confident arrival.

Recommended motionUse one 420ms continuous transform with one strong in-out curve. Put the arc on a motion path or a nested y-channel, not four sequential tweens. Scale once from 1 to the exact destination icon scale, then perform the identity swap at rest.

14-trust/en/index.html:539-543

Single-curve arrival420ms, cubic-bezier(.65,0,.35,1)
loop
App
APP
Opportunities
  • +Shorten each flight from 580ms to about 420ms while keeping a 200-240ms offset. That limits the screen to two active transfers and creates a readable hold before the next scene. 14-trust/en/index.html:547
Through Emil's lens

Keep the wave, remove the internal ceremony. One curve and one landing communicate more than four mini-beats packed into half a second.

05

Jhey Tompkins - Experimentation & Delight

Selective lens

Strong

What's working well
  • +The converging wave makes the abstract claim visible: distributed tools become one workspace. It is a worthwhile expressive beat.
Issues to address

No additional issue from this selective lens.

Through Jhey's lens

Do not remove the playful convergence. Make the transformation technically cleaner so the expressive idea is what viewers notice.

06

In the order to fix them

Identity first, then comfort, then speed. The source files for English and Chinese mirror this implementation and should change together.

Critical - must fix2
IssueFileFix
Source chip and destination row are simultaneously visible in different placesen/index.html:544Shared-element landing; swap icons only at the same coordinate
Reduced motion does not affect the GSAP flight and cameraen/index.html:100Alternate opacity-only GSAP timeline via matchMedia
Important - should fix1
IssueFileFix
One flight restarts velocity across four easing segmentsen/index.html:539One 420ms curve or shared-layout tween
Opportunities - could enhance2
EnhancementWhereImpact
Reveal destination shell and copy separately from its iconen/index.html:332Makes the transformation legible without duplication
Shorten flight while preserving the waveen/index.html:547At most two simultaneous transfers; cleaner next-scene handoff
07

Which lens carried this audit

Referenced most

Jakub Krehel - Production Polish

The visible defect is a craft gap: two representations appear where viewers expect one continuous object. Jakub's shared-layout and subtle staging lens therefore drives the first fix; Emil simplifies the speed profile; Jhey protects the useful expressive concept.

  • Lean JakubBuild the landing as a shared element and stage row chrome around it.
  • Lean EmilCollapse the flight to one curve and shorten it to about 420ms.
  • Lean JheyKeep the collective wave, but spend delight on its shape rather than extra object states.