mcpField
U
ui-animation

ui-animation

github.com/mblodeデザイン・UI16910.5k 回インストール2 日前に更新
リポジトリ

ui-animation について

ui-animationは、UIモーションの設計と実装を支援するスキルです。動かす箇所の判断から、コーディング、レビュー、デバッグ、録画からの動きの再現まで扱い、パターン、性能、アクセシビリティ、コード出力の資料を備えています。

主な機能

  1. 01モーション設計の判断ガイド
  2. 02トランジションとジェスチャーのパターン
  3. 03アニメーションコードのレビューとデバッグ
  4. 04モーション計測とカーブフィッティング
  5. 05複数のUIフレームワーク向けコード出力
  6. 06アクセシビリティと性能の指針

活用シーン

  1. 01UIでモーションを使う箇所の選定
  2. 02ダイアログやメニューのトランジション実装
  3. 03遅い、または不揃いな動きの原因調査
  4. 04録画からモーションを再現

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mblode/agent-skills --skill ui-animation

インストール後、Claude Code で/ui-animationを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

evals/
discovery-mode.json
evals.json
evals/fixtures/
settings-panel.tsx
references/
choreography.md
clip-path-techniques.md
code-output.md
component-patterns.md
contextual-animations.md
curve-fitting.md
debugging-symptoms.md
decision-framework.md
gesture-drag.md
interface-sfx.md
measurement-guide.md
performance-deep-dive.md
review-format.md
scroll-animations.md
spring-animations.md
svg-animation.md
transition-recipes.md
vocabulary.md
scripts/
extract_frames.py
fit_curves.py
track_motion.py

詳細

UI アニメーション

  • 対象: UI モーション(スプリング、ジェスチャー、ドラッグ、イージング、CSS トランジション、キーフレーム、Motion)の設計、実装、レビュー、デバッグ、モーションによって実際にメリットが得られるタイミングがないかインターフェース全体をくまなく確認すること、録画からモーションを測定して(フレームの抽出、追跡、カーブのフィッティング)、コードと引き継ぎ仕様を出力すること、説明されたモーション効果に名前を付けること(語彙の逆引き)、およびインターフェースで控えめに使うサウンドを判定すること。
  • 対象外: 全体的なビジュアルの方向性、カラーパレット、タイポグラフィの選定(ui-design の Direction モードを使用)、ページ全体の UI 品質の監査(ui-design の Audit モードを使用)、または名前付きのテキスト効果の仕様(インストールされている場合は外部の animate-text スキルを使用)。

参照ファイル

ファイル読むタイミング
references/decision-framework.md基本:アニメーションを使うかどうか・その理由の判断、イージングの特性の選択。また、「どこをアニメーションさせるべきか」を探るディスカバリー調査
references/spring-animations.mdスプリング物理、Motion useSpring、スプリングパラメーターの設定、Appleの減衰値・応答値、開くときと閉じるときで異なる動きの特性、中断の仕組み
references/component-patterns.mdボタン、トースト、クロスフェード、リストの段階的表示と削除、ホバー、ステップ形式のフォーム、Motionのレイアウトモーフィングと自動高さ、3D
references/clip-path-techniques.md表示、タブ、長押しでの削除、比較スライダーに使うclip-path
references/gesture-drag.mdドラッグ、スワイプで閉じる動作、慣性、ポインターキャプチャ、速度の引き継ぎ、慣性の投影、回転ダイヤル/ノブのドラッグ、デテント、カルーセルのtouch-action
references/scroll-animations.mdスクロールをトリガーにした表示、スクロールに連動したアニメーション(animation-timeline、useScroll)、視差効果、スティッキー要素を使ったスクロールストーリーテリング、スクロールアニメーションを使うべきでない場合
references/performance-deep-dive.mdカクつき、CSSとJS、WAAPI、CSS変数の落とし穴、Framer Motionの注意点
references/debugging-symptoms.mdアニメーションに違和感があるものの、原因が特定できない場合:もたつく、ロボットのよう、安っぽい、跳ねる、意図どおりに動かないといった動きの症状別テーブル
references/svg-animation.mdベクター画像のアニメーション:線の描画(stroke-dashoffset)、SVGのtransform-originの落とし穴、パスのモーフィング、揺れ、環境に馴染む動き
references/review-format.mdアニメーションコードのレビュー:10の基準(それぞれに一目でわかる警告サイン)、変更前/変更後/理由のテーブル、ブロック/承認の判定
references/contextual-animations.md状況に応じたアイコンの切り替え、単語単位で段階的に表示するアニメーション、周辺要素の強調を弱める動き、固定オフセットでの退出
references/transition-recipes.mdCSSトランジションの導入:コンテナーのモーフィング、カードのリサイズ、バッジ、ドロップダウンとツールチップ(ライブラリ由来の変数を含む)、モーダル(@starting-styleを使った表示)、パネルとドロワー、ページスライド、アイコンの切り替え、数値のポップイン、オドメーター風のロール、テキストの切り替え、成功、アバターのホバー、エラー時の揺れ
references/measurement-guide.mdリバースエンジニアリング:測定対象、目視とスクリプト、metrics.jsonの読み方、ROIの選択
references/curve-fitting.mdリバースエンジニアリング:fit_curves.pyの出力の読み方、スプリングとベジェ、フィッティング誤差の評価、開くときと閉じるときの非対称性
references/code-output.mdリバースエンジニアリング:CSS、Motion/Framer Motion、SwiftUI、React Native、UIKit向けのコード生成
references/choreography.mdリバースエンジニアリング:複数要素・複数フェーズの動き:段階的な表示、移動前のぼかし、エッジごとの収束
references/vocabulary.mdユーザーが曖昧に表現した動きの効果の名称を特定する(「あの動きは何て呼ぶの?」)
references/interface-sfx.mdクリック音、インターフェースの音声、UI効果音、触覚フィードバックと音の組み合わせ、または「なぜウェブでは音が敬遠されるのか」

基本ルール

  • フィードバック、方向感、連続性、または意図的な楽しさを伝えるためにアニメーションを使います。「見た目がかっこいい」というだけで、ユーザーが頻繁に目にするものには使いません。
  • キーボードフォーカスと繰り返し行うナビゲーションは即座に応答させます。フォーカスやタスクの完了を待たせないのであれば、状態遷移をアニメーションさせてもかまいません。
  • 中断可能な UI には CSS トランジションを優先します。キーフレームは中断されると最初から再生されますが、トランジションは目標を切り替えます。キーフレームは、あらかじめ決められたシーケンスにのみ使います。
  • 実装の優先順位は、CSS トランジション > WAAPI > CSS キーフレーム > JS(requestAnimationFrame)です。負荷がかかっても CSS は滑らかに動作しますが、JS はフレーム落ちします。
  • タイミングに変化をつけます。ときどき行われる操作では、表示を少し遅く、終了を速くできます。高頻度で一時的な UI(ホバーのハイライト、ポップオーバー、パネルの切り替え)では逆に、表示は即座に行い(0ms)、終了時には短くフェードさせます(100-150ms)。こうすることで、操作が即座に反映されたように感じられます。
  • タップ可能なコントロールは :active で 0ms で押下状態にし、touch-action: manipulation を設定します。
  • DOM への追加には @starting-style を使います。未対応の環境では data-mounted 属性をフォールバックとして使います。
  • 小さな filter: blur(2px) を適用すると、コンテンツを入れ替える際の粗いクロスフェードが目立たなくなります。

モーションデザインの原則

  • 瞬間移動より連続性を優先します。 両方の状態で表示される要素は、その場で遷移させます。新しい要素をフェードインさせるのではなく、要素がある位置から展開します。永続する要素を複製したり、コンポーネントを共有するビュー間をハードカットで切り替えたりしてはいけません。ハードカットでは空間的な文脈が失われます。
  • 動く方向を位置に合わせます。 タブやカルーセルの遷移は、空間的なレイアウトに合った方向にアニメーションさせます(進むときは左から右、戻るときは右から左)。
  • トリガーから現れるようにします。 オーバーレイ、トレイ、パネルは、それを開いた要素から外側に向かってアニメーションさせます。画面中央から汎用的に表示すると、空間的な方向感が損なわれます。形状が合う場合は、さらに望ましい方法として、トリガー自体をサーフェスに変化させます(コンテナーモーフのレシピを参照)。
  • 隅ではなく、その場で結果を伝えます。 操作の結果は、その操作を引き起こしたコントロールに表示します。ボタンが「コピーしました」に変わり、その状態を保ってから元に戻るようにします。画面の反対側にトーストが表示されると、ユーザーは操作が成功したか確かめるため、たった今触れた要素から視線を移さなくてはなりません。画面上に発生元がない結果(バックグラウンドジョブの完了、受信メッセージなど)に限って、隅のトーストを使います。
  • 対になる状態は一緒にアニメーションさせます。 開くときにアニメーションさせるなら、閉じるときもアニメーションさせます。ホバーに動きがあるなら、フォーカス時と押下時にも同等のフィードバックを与えます。繰り返し行う操作の片側だけを磨き込んではいけません。
  • 操作の頻度が低いほど、楽しさを加えます。 まれな操作には個性を加え、高頻度の操作では動きを意識させないようにします。
  • モーションで体感速度を高めます。 同じ読み込み時間でも、滑らかな遷移はハードカットより速く感じられます。

アニメーションさせる対象

  • 動き:transform と opacity のみを使用します。レイアウトとペイントをスキップできます。
  • 状態のフィードバック:color、background-color、opacity は使用できます。
  • レイアウトプロパティ(width、height、top、left)はアニメーションさせないでください。フレームごとにレイアウトの再計算が発生します。(例外:意図的なコンテナのアニメーション。カードのリサイズとコンテナのモーフィングのレシピを参照してください。)
  • transition: all は使用しないでください。意図しないプロパティまでアニメーションし、将来追加されるプロパティも暗黙的に対象になります。対象を明示してください。
  • コアとなるインタラクションでは、filter のアニメーションは避けてください。避けられない場合は、ぼかしを 20px 以下にしてください(強いぼかしは、特に Safari で処理コストが高くなります)。
  • SVG:<g> ラッパーに transform-box: fill-box; transform-origin: center を適用してください。これがないと、キャンバスの原点を中心に回転/拡大縮小されます。線の描画、パスのモーフィング、Motion の SVG 原点オーバーライドについては、references/svg-animation.md を参照してください。
  • transform: scale() は子要素(アイコン、テキスト、枠線も比例して拡大縮小されます)も拡大縮小します。width/height とは異なり、押下時のフィードバックには便利ですが、内側の要素を固定サイズにする必要がある場合は考慮してください。
  • テーマの切り替え中はトランジションを無効にしてください([data-theme-switching] * { transition: none !important })。そうしないと、テーマに関連するすべてのプロパティが一斉にアニメーションします。切り替え後に再フローを強制し(void document.body.offsetHeight)、次のフレームでオーバーライドを削除するか、next-themes の disableTransitionOnChange を使用してください。

イージングのデフォルト値

要素期間イージング
ボタン押下時のフィードバック100-160mscubic-bezier(0.22, 1, 0.36, 1)
ツールチップ、小さなポップオーバー125-200msease-out またはエントリーカーブ
ドロップダウン、セレクト150-250mscubic-bezier(0.22, 1, 0.36, 1)
モーダル、ドロワー200-350mscubic-bezier(0.22, 1, 0.36, 1)
画面上の移動/スライド200-300mscubic-bezier(0.25, 1, 0.5, 1)
ページ遷移250-400msエントリーカーブまたは移動カーブ
ホバー(色/不透明度)、単一コントロール200msease
ホバー(transform/scale)100-150msエントリーカーブ
イラスト/マーケティング用途最大 1000msスプリングまたはカスタム

通常の UI は 300ms 未満にしてください。距離に応じて期間を調整します(全画面のスライドは 300ms を超えてもかまいませんが、ツールチップの 6px の移動は 150ms 未満にします)。

名前付きカーブ

  • エントリー: 登場時や transform ベースのホバーには cubic-bezier(0.22, 1, 0.36, 1) を使用します
  • 移動: スライド、ドロワー、パネルには cubic-bezier(0.25, 1, 0.5, 1) を使用します
  • ドロワー(iOS 風): cubic-bezier(0.32, 0.72, 0, 1)(開始が非常に急で、500ms でも遅く感じない理由です)
  • Expo out: 大胆な表示、カードのホバー、テキストの表示には cubic-bezier(0.19, 1, 0.22, 1) を使用します
  • 押下: ボタン押下時のフィードバックには cubic-bezier(0.25, 0.46, 0.45, 0.94) を使用します
  • 画面上の移動: 画面内にとどまる往復移動には cubic-bezier(0.645, 0.045, 0.355, 1) を使用します

UI では ease-in を避けてください。動き始めが遅いため、要素がユーザーの操作に遅れて追従し、もたついて感じられます。加速が緩やかで、きびきびした印象ではなく柔らかい印象になる組み込みの ease/ease-out よりも、easing.dev のカスタムカーブを優先してください。

トランジションの選択ルール

まず UI 要素を照合し、次に references/transition-recipes.md からレシピを選びます。

UI パターンレシピ
トリガー+浮かぶドット/件数通知バッジ
トリガーが、開くサーフェスへと拡大するコンテナのモーフィング
トリガー+位置が固定されたサーフェスメニューのドロップダウン
ページの前面に表示される中央配置のサーフェスモーダルダイアログ
既存のコンテナ内へスライドするパネルパネルの表示
リスト↔詳細、またはウィザードのステップページの左右スライド
要素の寸法が変化するカードのサイズ変更
テキストがその場で更新されるテキスト状態の切り替え
同じスロットにある2つのアイコンアイコンの切り替え
単独で現れる数字数字のポップイン
ユーザーが操作して変化させる数字オドメーター式の数字スクロール
確認/成功の瞬間成功の演出
横並びのスタックでホバーされた項目アバターグループのホバー
フォームの入力エラーエラー状態のシェイク

デザイン上 JavaScript によるオーケストレーションが必要な場合を除き、オーバーヘッドの小さいトランジション(CSS のみ)を優先します。

空間とシーケンス

  • ポップオーバーの transform-origin はトリガーの位置に設定します(モーダルは center のままにします)。ダイアログ/メニューの表示アニメーションは scale(0) ではなく scale(0.9-0.96) から開始します(小さなポップオーバーは範囲の下限、ダイアログ全体のような大きなものは上限にします。大きなサーフェスは絶対ピクセル数で大きく移動するためです)。スタッガーは30〜50ms(合計300ms未満)とし、最も重要な要素を先に動かします。詳細なルールとコードは references/transition-recipes.md と references/contextual-animations.md を参照してください。
  • ペア要素のルール: 一緒にアニメーションする要素(モーダル+オーバーレイ、ツールチップ+矢印、FAB+ラベル)は、同じイージングと時間を設定する必要があります。タイミングの不一致は、「何か違和感がある」と感じる原因としてよくあります。

アクセシビリティ

  • ホバー(動きと描画)は @media (hover: hover) and (pointer: fine) の内側に限定するか、タッチデバイスではタップでホバーを再現します。ゲートを追加する前に生成された CSS を確認してください。Tailwind v4 では hover: がすでに @media (hover: hover) で囲まれています。
  • 直接操作中は、イージングをかけずに要素をポインターに追従させます。イージングは操作後にのみ追加します。
  • インターフェースの効果音は任意です。控えめに使い、ジェスチャーによるロック解除後に再生し、確認音に限定します。references/interface-sfx.md を参照してください。

パフォーマンス

  • IntersectionObserver を使って、画面外ではループアニメーションを一時停止します。見えない状態でも GPU を消費します。
  • will-change は負荷の高い動きがある間だけ transform/opacity に対して有効にし、終了後に解除します。レイヤー昇格のたびにコンポジターのメモリを消費します。多数の要素を恒久的に昇格させるのは、まったく昇格させない場合よりも悪影響があります。
  • コンテナ上の CSS 変数を使ってドラッグをアニメーションさせないでください。更新のたびにすべての子要素のスタイルが再計算されます。移動する要素に直接 transform を設定してください。
  • 軸方向の移動やドラッグには、Motion の x/y 値がデフォルトで適しています(React の再レンダリングを回避できます)。複数の transform 関数を1つの所有者が組み合わせる必要がある場合、Motion 以外のコードと相互運用する場合、またはメインスレッドが混雑している状況でも滑らかに動かす場合は、完全な transform 文字列を使用します。省略形は requestAnimationFrame 上で実行され、動きがナビゲーション、データ読み込み、ハイドレーションと重なるとフレームが落ちます。そのような状況でも CSS/WAAPI は滑らかさを保ちます。
  • 動きがときどきカクつく(表示時、ナビゲーション中、データの反映中)場合、原因はたいていアニメーション自体の負荷ではなく、同じティックで実行される長時間タスクです。アニメーションの開始と負荷の高い処理を同じティックで実行しないでください。先に動きを開始して、1フレーム描画されてから処理を行うか、transitionend まで処理を延期します。
  • WAAPI、コンポジティングレイヤー、アニメーション中の長時間タスク、CSS と JS の比較表については、references/performance-deep-dive.md を参照してください。

アンチパターン

上記で触れていない、特に問題となる失敗例:

  • ユーザーの操作なしにマウント時にアニメーションする:予期しない動きはユーザーを戸惑わせます。ユーザーは何もしていないのに動き出すためです。
  • ドラッグの境界で急停止する:動作が壊れているように感じられます。摩擦や減衰を適用し、境界を越えると動きが弱まるようにしてください(gesture-drag のリファレンスを参照)。
  • コンテナーとその子要素の両方をアニメーションし、さらに子要素を順番に表示する:コンテナーごとに表示時のアニメーションは1つにしてください。パネルがスライドして表示されるなら、到着時点ですでに内容が表示されているようにします。
  • グループ内で最初のツールチップが開いた後もアニメーションする:後続のツールチップは即座に開くようにしてください。そうしないと、ツールバーの動作が遅く感じられます。
  • スクロールで製品 UI、ファーストビューのコンテンツ、またはページ内のすべてのセクションを表示する:スクロール時の表示は、マーケティングページで厳選した数か所に限り、各回1度だけ実行し、上方向へのスクロールでは再生しないでください(references/scroll-animations.md を参照)。
  • スクラブ操作(スクロール連動)の動きにイージングや時間を設定する:スクロール位置が時計の役割を果たすため、カーブや時間を設定するとスクロールバーに遅れて追従します。この場合に限り、linear かつ時間指定なしが正しい設定です。
  • CSS のみで視差効果を抑制する:Motion の JS 駆動アニメーションは @media (prefers-reduced-motion) ブロックを無視するため、CSS の制限を確認しても、空間的な移動はそのまま再生されます。アプリを <MotionConfig reducedMotion="user"> でラップするか、useReducedMotion() で分岐してください。逆に、視差効果の抑制時にグローバルな * { transition: none !important } を適用するのも過剰な対応です。視差効果を抑制しても維持される、不透明度や色のフィードバックまで取り除いてしまいます。
  • 新しい開発に framer-motion をインストールする:現在のパッケージ名は motion で、React のインポート元は motion/react です。古いパッケージも引き続き解決されるため、コードベースが混在していてもビルドは通り、ライブラリが2つ同梱されてしまいます。

ワークフロー

コピーして追跡します:

Animation progress:
- [ ] Step 1: Decide whether the interaction should animate
- [ ] Step 2: Choose purpose, easing, and duration
- [ ] Step 3: Pick the implementation style
- [ ] Step 4: Load the relevant component or technique reference
- [ ] Step 5: Validate timing, interruption, and device behavior
  1. references/decision-framework.md にある4つの質問に答えます:アニメーションさせるか?目的は何か?イージングは?速度は?
  2. 上記のイージングのデフォルト表から時間を選びます。値について意見が分かれる場合は、実際のコンポーネントを使って DevTools のベジェエディター(Chrome または Firefox。Safari にはありません)でリアルタイムに調整し、他のタイミング定数の隣に値をそのままソースへ貼り付けます。DevTools での編集はページ遷移で失われます。
  3. 実装方法を選択します:CSS transition > WAAPI > spring > keyframe > JS。
  4. 対象のコンポーネントまたは手法のリファレンスを読み込みます。
  5. レビュー時には references/review-format.md の厳格な手順に従います。10項目の基準に照らして測定し、Before/After/Why の表を出力したうえで、Block/Approve の判断で締めくくる段階別の評価を示します。

検証

各確認項目について、証拠を提示します(DevTools での観察結果。「問題なさそう」は不可)。

  • 差分を grep し、レイアウトプロパティの遷移(width、height、top、left)と transition: all を探します。
  • コンポーネントを素早く繰り返し切り替え、遷移が最初から再開するのではなく、新しい状態に向けて調整されることを確認します。
  • DevTools の Animations パネルで速度を10%に落とし、通常の速度では見えないタイミングや transform-origin の問題を見つけます。
  • will-change が恒久的に設定されるのではなく、アニメーションの前後で切り替わること、ループするアニメーションが画面外では一時停止することを確認します。
  • 実機でタッチ操作をテストします。シミュレーターでは、ジェスチャーやタップ時のホバーに関する問題が過小評価されます。
  • prefers-reduced-motion を尊重します。空間的な移動は即時の状態変化または控えめなフェードに置き換えます。ループする装飾は animation-play-state: paused で一時停止します(display: none で強制的に消さないでください)。ユーザーが明示的に起動したフィードバックは維持します。そのモードで同じタスクを実行して確認します。

発見ワークフロー

「どこをアニメーションさせるべきか」については、references/decision-framework.md の発見プロセスを実行します。目的と使用頻度で裏付けられた機会と、採用しなかった案を報告します。実装が作業範囲に含まれる場合に限り、提案を実装します。

リバースエンジニアリングのワークフロー

このブランチでは、画面録画から既存のアニメーションを計測し、それを再現するコードと引き継ぎ仕様を出力します。scripts/ 内のスクリプトが標準の決定論的な手順です。ロジックを独自に再構築せず、スクリプトを実行してください。

以下の scripts/ コマンドは、アプリケーションの作業ディレクトリではなく、インストール済みスキルのディレクトリを基準に実行してください。

依存関係: フレーム抽出には ffmpeg(brew install ffmpeg)、トラッキングと曲線フィッティングには pip install opencv-python numpy scipy でインストールした Python が必要です。適切に機能を縮退します。ffmpeg だけでもフレームを抽出して視覚的に分析できますが、トラッキングとフィッティングには Python パッケージが必要です。

Reverse-engineer progress:
- [ ] Step 1: Extract frames + contact sheet (per direction if open differs from close)
- [ ] Step 2: Vision pass: identify element, effects, phases
- [ ] Step 3: Decide precision (eye-only vs scripted)
- [ ] Step 4: Track motion and fit curves (if escalating)
- [ ] Step 5: Annotate choreography (delays, asymmetry)
- [ ] Step 6: Emit code for the target(s)
- [ ] Step 7: Validate against the recording
  1. 抽出します。 python3 scripts/extract_frames.py <video> <outdir> を実行します。--start/--duration でトランジション部分だけを切り出します。インタラクションに開く動作と閉じる動作の両方がある場合は、2 つの時間区間を切り出し、方向ごとにパイプラインを 1 回ずつ実行してください(ほとんどの場合、両者は鏡像にはなりません)。--fps はソースに合わせます(ffprobe で確認してください)。ソースのフレームレートを超えてサンプリングしてはいけません。最初に contact_sheet.png を開いてください。
  2. 視覚的に分析します。 動く要素、それぞれの効果(移動、スケール変更(異方性を伴うことがよくあります)、不透明度、ぼかし、角丸、シャドウ、色)、各フェーズを特定し、どのプロパティが先行し、どれが遅れるかを記録します。チェックリストには references/measurement-guide.md を使用してください。
  3. 必要な精度を判断します。 単純なフェードや線形スライドの場合は、コンタクトシートからタイミングを読み取り、ステップ 5 に進みます。弾性のある動き、スプリングのような動き、複数プロパティにまたがる動きの場合は、ステップ 4 に進みます(スプリングの目測は信頼できません)。
  4. トラッキングしてフィッティングします。 python3 scripts/track_motion.py <outdir> を実行して metrics.json を生成します(1 つの要素を分離するには --bbox X,Y,W,H を指定します)。次に python3 scripts/fit_curves.py <outdir>/metrics.json を実行して、スプリングのパラメーター、三次ベジェ曲線、プロパティごとのフィッティング誤差を取得します。抽出時と同じ --fps を指定してください。モデルの選択には references/curve-fitting.md を参照してください。どちらの誤差も大きい場合は、動きが複数フェーズに分かれているため、区間ごとに分割してフィッティングします。
  5. 注釈を付けます。 references/choreography.md を読み込みます。タイミングオフセット表を作成し、各プロパティの開始時刻と収束時刻を記録します。プロパティ間の先行/遅延の間隔とオーバーストレッチが、単一の曲線よりも動きの印象を左右します。
  6. 出力します。 references/code-output.md のテンプレートにフィッティングしたパラメーターを代入し、対象向けのコードを作成します。動きには transform/opacity を使用してください。開く動作と閉じる動作が異なる場合は、2 つのトランジションを出力します。また、動画がなくても実装できるよう、統合した引き継ぎ仕様も出力してください。
  7. 検証します。 アニメーションを再生して画面録画し、extract_frames.py に通し直して、コンタクトシートを並べて比較します。0.1 倍速に落として、フェーズの順序とオーバーストレッチが維持されていることを確認してください。コードがアニメーション化するのは transform、opacity、filter のみであることを確認します。

リバースエンジニアリングでの注意点:

  • fit_curves.py のデフォルトは --fps 30 です。60 fps で抽出してデフォルトのままフィッティングすると、duration_ms はすべて 2 倍になり、フィッティングされた剛性は 4 分の 1 に下がります。フィッティング時には必ず抽出時の fps を指定してください。
  • ソースのフレームレートを超えてサンプリングすると、フレームが重複します。24 fps の GIF を 60 fps で抽出すると、metrics.json に平坦な区間が発生し、フィッティング誤差が増加します。ソースのフレームレートを確認し、それに合わせてください。
  • 画面録画ではフレームが欠落することがあり、iOS/QuickTime のキャプチャは可変フレームレートです。連続する同一の行は一時停止ではなく、重複フレームです。平坦な区間が大半を占める場合は、より安定したフレームレートで録画し直してください。
  • 開く動作と閉じる動作は別々のクリップとして計測し、2 つの曲線を報告してください。片方をフィッティングして逆再生し、もう片方に流用してはいけません(references/choreography.md を参照)。フィッティングの error が 0.08 を超える場合は、信頼性に疑いがあるものとして扱ってください。

関連スキル

  • product-design:どのような状態があるか、アクションが何に影響するか、元に戻せるかを扱います。ジェスチャーによって操作が置き換わる場合は、まずこちらに進んでください。スワイプして削除や長押しして確定は、操作の動き方だけでなく、ユーザーができること自体を変えるためです。
  • ui-design の Direction モード:ビジュアルの方向性、カラーパレット、タイポグラフィを扱います。モーションを調整する前に、ビジュアルシステムを決定してください。
  • ui-design の Audit モード:ページ/機能レベルの UI 品質監査を行います。モーションの品質向上や修正はこちらで扱います。
  • 任意:インストールされている場合は、外部の animate-text スキルを利用できます。名前付きテキストエフェクト(タイプライター、行ごとの表示、段階的な表示)と、正確な JSON 仕様を提供します。

メンテナンス専用:evals/ には回帰シナリオ(evals.json と、Discovery のルーティングおよびゲート用の discovery-mode.json)とそのフィクスチャが格納されています。ユーザーのタスク中に読み込まれることはありません。

コメント