すべてのフレームを完璧に
(tonsky.me)- UIは、ユーザーがアプリの品質を判断するほぼ唯一の表面であり、どの瞬間にスクリーンショットを撮っても画面の状態に筋が通っている必要があり、そこで信頼が積み上がる
- 完成度の高いUIは、開発者が磨き込みの時間をかけたというシグナルになり、コード品質も同様に磨かれているだろうという合理的ヒューリスティックになる
- 実際の基準は、画面遷移の間の白い点滅、部分的な読み込み、読み込み中の再レイアウト、状態メッセージの不一致、不正確なアニメーションをなくすことにある
- 開始状態と終了状態が良くても途中のフレームがずれていれば、コンポーネントが同期していない印象を生み、Photosの事例のように実際には変化がない遷移でも偽の感覚を生むことがある
- アニメーションは遷移の理解を助けるものであるべきで、始点と終点だけでなくその間のすべてのフレームまで管理してこそ、精密な道具のようなUIになる
核心原則
- Waylandの明示的な目標である“every frame is perfect”は、現代のGPUスタックの複雑さの中で制御権を取り戻そうとする技術的目標である
- 同じ原則はUIにも適用され、アプリのどの瞬間をスクリーンショットに撮っても画面が自然で一貫していなければならない
- ユーザーはコードを見ることができないため、UIがアプリの品質を判断する唯一の表面となる
- UIがよく磨かれていれば、開発者がポリッシュの時間をかけたというシグナルになり、コードも同じ水準で磨かれているだろうという判断につながる
実際の基準と事例
- 完璧なフレームのためには、画面間で白い点滅が起きてはならず、コンテンツが部分的に読み込まれた状態や、読み込み中のレイアウト再配置があってはならない
- UI内部の状態は一貫しているべきで、ある部分が“1 update available”と言っているときに、別の部分が“Checking for updates...”と言っていてはならない
- アニメーションはしばしば忘れられがちで、開始状態と終了状態が良くても、その間がぎこちなければ途中のスクリーンショットは意味の通らないフレームになってしまう
- Safariの事例では、プレースホルダーテキストは中央から動くのに、カーソルは左の位置からアニメーションするため、2つのコンポーネントが互いに同期していない印象を与える
- Photosの事例では、CropとAdjustモードを切り替えるとき、写真は即座に元の位置へ移動する一方でクロップ枠はアニメーションするため、モード切り替え中に何かが微妙に変わっているような偽の感覚を生む
- 検索UIの事例では、遷移の理解を助けるはずのアニメーションが、かえって虫眼鏡の動きを追いにくくしている
- Youtubeの事例では、長方形をある位置から別の位置へ動かすという単純な作業でも奇妙な動きが生じ、理由にかかわらず結果は完璧ではないフレームになる
- Previewアプリの拡大アニメーションまで含めて、核心は開始状態と終了状態だけでなく、その間のすべての瞬間にも注意を払わなければならないという点にある
2件のコメント
Hacker News の意見
著者が挙げた例の一部が悪いアニメーションであるのは確かだが、記事の前提には賛同しにくい
コンピュータグラフィックスは人間の視覚システムの特性を活用する分野であり、動いているものと静止しているものは異なって知覚される。切り離して見ると「間違った」フレームでも、実際の時間の流れの中では最も良く見えることがある
映画でたとえるなら、高速なトラッキングショットはモーションブラーのせいで個々のフレームが悪く見えることがあり、広角ショットは歪みのせいで物体が「間違って」見えることがあるが、劇場で意図した芸術的効果を生み出せるなら正しい選択である
正しいブラーを動きに加えると、より鮮明に感じられるが、静止画として見れば当然より鮮明ではない。要点は、正しいモーションブラーが、その速度で人間が知覚可能な動くディテールの範囲でだけ鮮明に見えることを保証する点にある。したがって、静止したモーションブラーのフレームを鮮明さや解釈可能性の基準で評価するのは誤りである
記事の残りは実装の細部に集中しているが、そもそもこうしたアニメーションの一部が存在すべきかを問う機会を逃している。動きは限定的に使えば良いアフォーダンスになりうるが、今では使いすぎを超えて、ユーザーの視界や認知負荷を侵害している場合もある。デザイナーやPMはこれを「洗練された現代的UX」の印のように見ているが、実際には良いデザインではなく、良いデザインをまねた流行的な装飾へと劣化した面がある
提示されたアニメーションの一部は明らかに改善の余地がありそうだ。こうした小さな楽しさをさらに押し進めるのにAIはかなり向いているように感じる。以前は優先順位が低く、時間を割きにくかったからだ
アニメーションの中間フレームが少し「おかしく」見えても論理的には正しいことと、中間状態が実際に筋が通っておらず、ただアニメーション中に何が起きているかに注意を払っていない結果であることは別だ。後者なら、むしろアニメーションをなくすか、もっと単純にしたほうがよいと思う
UIの完成度をソフトウェア品質の代理指標として見る記事の観点はよく、悪いアニメーションを指摘したのもその通りだ。ただし、フレームごとの一貫性はアニメーションの「良さ」を測る最良の物差しではない
まだSonomaの端末もあるが、ひたすら退化しているとしか言いようがない
保存ダイアログは少し揺れるものの、例のように混乱するほどではない。Notesのボタンはパネル間を完全に滑らかに移動する。Safariバーを繰り返しフォーカスして解除するとアニメーションがたまに崩れるが、カーソルはテキストと正確にタイミングが合っており、テキストが左への移動を終えてから初めてフェードインする。Previewのバグも最近の問題らしく、再現しない
https://streamable.com/kx7op6
Apple、Sony、IBMのような会社がごく小さなディテールに気を配っていた時代が懐かしい。特にAppleはiPhoneで今の価値を手に入れたが、当時のWindows MobileやSymbian PDAと比べて特別にすごい機能を持っていたわけではなく、むしろ機能面で劣っている部分もあった。それでも数分使って壁に投げつけたくなるようなものではない、オールタッチの端末だった。今のこうしたアニメーションは、まさにWindows MobileやSymbianの感覚を呼び戻す
SteveがOS Xのアニメーションをどれほど気に入っていたかを覚えている。ステージ上で何度もスローモーションで再生していた。今のものは、iPhone 4のアンテナ担当者が受けたような運命を、それを作った人たちに与えてもおかしくないレベルだ
こういう不完全なフレームのないUIのほうが良く感じられそうではあるが、そろそろ誰かが各クリップを修正して、実際にどう見えるのかを示してほしい
同時に、なぜすべてに動きが必要なのかも疑問だ。私の理解では、動きはトーストのように、ユーザーが操作を始めた位置とは別の領域でUIが微妙に変化するときに使うのが正しい
ここで出ている遷移のかなり多くは不要に見え、即座に切り替わって即時の再配置が起きるだけでも十分に良く感じられそうだ
カーソルが左に現れるのは、ユーザーが実際にその位置から入力を始めるからだ。UIに慣れた人なら、おそらくそこを見る。カーソルを画面中央に出してから移動させるのは不要で気が散る
プレースホルダーテキストが左へ滑るのは、慣れていないユーザーの注意を引くためだ
$BRANDのデザイン言語が他より優れていると自慢する口実を与える例の大半は、アニメーションがなければもっと良く感じられる可能性が高い。ボタンを押したなら結果を見せればいい。踊ってから見せるのではなく、そのまま見せてほしい
動きがないと、更新のたびに脳がページ全体をもう一度見渡さなければならないことが多い
この記事の議論は弱い提示に見える。より良い代案もなく、提示されたものがなぜユーザーにとって否定的なのかも実際には説明していない。否定的ではありうるが、メディアのスミアフレームや転換点を指さして批判する空虚なやり方に近い。
「すべてのフレームが成立していなければならない」という基準も負担が大きすぎる。不可能だと思うし、ウィンドウのリサイズ中であってもすべてのフレームを完璧に保つにはどうするのか聞いてみたい。
著者自身も、自分の言う基準を実践するより、欠陥のあるフレームを指摘するほうが簡単に見える。ブログのヘッダーリンクを押すと、クリックが終わったあとにアニメーションが再生される。本人のUIプロジェクトを見ると、テキストやオブジェクトがコンテナ内に収まっていない箇所もある。こうした原則に従うべきだと言うなら、自分で示せるはずだ。
もっときちんと書かれた記事なら、提示したものがエンドユーザーになぜ悪いのか、代わりにどう扱うべきかに集中していただろう。良い批判は「何」だけでなく、なぜ、どうするかまで含むべきだ。
記事は解決策ではなくアイデアを提示している。それを見落として、いくつもの藁人形論法を立てて批判しているにすぎない。
さらに重要なのは、記事が断定的に書かれていない点だ。「I think」「Next thought:」「Probably」「So yeah.」のように慎重な書き方になっている。これはある人が自分の考えを共有した文章であり、かなり練られていて、複数の理性的な人が同じ方向に考えるきっかけになる程度には完成している。
著者が解決策を示していないからといって、必ずそうすべき理由はない。そんな基準は奇妙で不合理だ。
著者のサイトを攻撃するのもあまり良く見えない。好みの隔たりはよく知られているし、概念的な貢献が実装技術に先行するからといって罰するのはかなり不快だ。
もっとまともな批判なら、このコミュニティの精神に合うよう、もっと寛容だったはずだ。
著者が解決例を含めてくれたらよかったのに、という反応をいくつか見た。最近、この文章ととてもよく似た記事を書いていて、ここでのようにアニメーションの問題を詳しく扱ったうえで、どう改善したかも説明していた。
興味があればここで見られる: https://www.thisischris.dev/projects/project-6/
後の完璧なフレームより、今の不完全なフレームのほうがよいと思う。あらゆるUIでレイテンシが最優先であるべきだ。レイテンシが十分低ければ、自分の身体の一部のように感じられ、認知負荷が下がる。アニメーションはここで特に有害で、数百ミリ秒の遅延を追加するからだ。
ポジティブな例も、否定的な例と同じくらい一緒にあればよかったと思う。今のところ得られる結論は、アニメーションを避けるべきだということだけだが、著者が実際に言いたいのはたぶんそこではない。
良いアニメーションは、すべてのフレームで完璧に見えるというより、動いている最中に少しごまかしを使うことが珍しくない。カートゥーンのスミアフレームのように、止めて見るとおかしいが、全体のアニメーションの中では動きを視覚的にもっともらしく見せる、というものだ。
開発者ではないが、アイコンやウィンドウが以前のように、あるいは当然そうあるべきやり方で配置・移動していないと感じる領域があった。
この継ぎはぎ感は時間が経っても変わらなかった。OSとアプリ全体に「前からそうだった」と言いたくなるほど例は多いが、実際にはそうではなかった。Appleは基準を設け、その基準は高く、品質も優れていた。
SwiftUIで同じUI配置やアニメーションを実現しようとすると、多くのハックが必要になるように感じる。
最後によく思うのは、アナログの創作は本当に難しく、今もそうだということだ。デジタルではあとで手直しできると思われがちだが、実際にはそうならず、悪いものの上にさらに悪いものを積み上げてしまうことが多く、残念だ。
[1]: https://youtu.be/vIdeGmN__Pw?t=550
アニメーションがまったくないアプリはひどく感じられるはず。Android があるなら開発者設定でアニメーション速度を 0x にして自分で試せる。即時の変化はかえって不快で、何が起きたのかを脳が処理するのにむしろ1秒ほどかかり、その過程はアニメーションがある場合より遅いことさえある
自分の設定は 0.5x で、それで十分だと感じている。十分速いままだが、アプリが開いたり閉じたりするのは見える
0x の問題は、UI の 90% くらいにしか適用されていないように見える点だ。まだアニメーションするものがあって、そのせいでリズムがかなりおかしく感じられる
0.5x だと、アニメーション速度設定の影響を妙に受けないものがあってもそれほど気にならない
ちゃんと動くなら 0x を使うだろう
必要なら処理に1秒使うほうがまだましだし、実際にはそれすら必要だとも思わない。アプリがページを切り替えるたびにアニメーションのせいで1秒ずつ遅くなるより、よほどましだし、移動していると何もかもが糖蜜のようにもっさり感じられる
この記事には共感したが、良い例もあればよかった。口調が不満っぽく読めたわけではないが、良い UI 設計についてあまり知らない立場としては、何を 北極星 にすべきかが前より明確になった感じはしなかった
興味があればここで見られる: https://www.thisischris.dev/projects/project-6/
Lobste.rs の意見
この記事の基本前提は間違っていると思う。こういうアプリをフレーム単位で使うことはない。
基本的なアニメーションの授業を受けるだけでも、動きを認識する仕組みは静止画像とは違うと学ぶ。"squash and stretch" のデモを探してみれば、各フレームごとに見るとあるオブジェクトの寸法は単体ではめちゃくちゃでも、動きの中では美しく機能しているのが分かる
しかもトリミングの例のように、プログラムの状態を誤って表示することさえある。ユーザーはUIが再構成される3分の1秒ほどの間、頭を空っぽにして待ってからでないとプログラムを使い続けられない
Wayland プロジェクトが言うフレーム完全性は、こういう意味ではまったくないと思う。
むしろウィンドウサイズ変更のような、より低レベルな技術的詳細を指しているに近い。たとえばコンテンツが非同期にリサイズされるとか、垂直同期が崩れてティアリングや奇妙な斜めのアーティファクトが発生するとか、損傷領域の報告が長方形の部分領域単位で行われる場合などだ。
もちろん、低レベルの詳細も高レベルのアニメーションも、どちらもフレーム単位で完全なのが望ましい
こうしたアニメーションをテストし、時間が経ってもこうした特性が壊れないことを確認するテストを書きたいとしよう。
今日のWebアプリやネイティブアプリで、こうした性質をテストする最新の手法は何だろうか？ イベントループを制御できないせいで、書きたい特定の種類のテストが事実上不可能、あるいは非常に難しいこともあるのだろうか？
あるいは Paparazzi のようなツールで、遷移全体を Animated PNG として記録し、自動回帰テストを行うこともできる
そうすれば両方の地点をそれぞれ検証し、最後に最終状態だけ確認すればよい。アニメーションは時間入力に固定されるのではなく、外部から段階的に駆動できるべきだ
YouTube の例は、View Transitions の事例としてほぼその通りだと思う。
「この要素が変わったら自動的に形を変えろ」と宣言する方式で、結果として技術的には印象的だが、ややぐにゃぐにゃした見た目の遷移になり、要素がふわふわ漂って互いに変形する。
とてもクールな技術だが、ナビゲーション時の小さな強調効果以外で見事に見える例はほとんど見たことがない。あまり気が散らないようにするには、かなり節度を持って使う必要がある