WWDC Quick Look 💓 By SwiftGGTeam
Design hover interactions for visionOS

Design hover interactions for visionOS

元の動画を見る

ハイライト

このセッションでは、visionOS における視線追跡をベースとした 3 つのインタラクション機構、すなわち Custom Hover Effects、Look to Scroll、そして Persistent Controls について解説します。


主要内容

よくあるペインポイントを想像してみてください。visionOS 上で動画プレイヤーを開発しており、コントロールは展開後に数秒で自動的に非表示になる仕様だとします。ところが、ユーザーがプログレスバーを注視して時間を確認している最中にコントロールが消えてしまうのです。あるいは Safari のタブグリッドで、見た目を整えるために閉じるボタンを隠しておき、注視されたときに表示するとしましょう。すると、ユーザーの視線は突然出現したボタンに本能的に引き寄せられ、結果としてタップ時に意図しないタブを閉じてしまうことになります。これらの例はいずれも、空間インタラクションの新しい原則、つまり「ユーザーの視線そのものが入力シグナルである」という事実に起因しています。

WWDC25 の本セッションで提示された Apple の解決策は、「見る」という行為を 3 段階の異なるフィードバック強度に分けることです。すなわち hover アニメーション、スクロールの駆動、そしてコントロールの永続化です。前提となるのは visionOS のプライバシーアーキテクチャです。システムはユーザーがどこを見ているかを App に伝えません(03:00)。hover effect は App プロセスの外でレンダリングされ、App は View の「標準状態」と「hover 状態」という 2 つの外観を宣言するだけで、ユーザーが注視/視線を外した際にシステムが自動的に補間します。この制約から直接的に導かれる結論として、hover はアニメーションのみを駆動でき、アクションのトリガーには使えません(03:21)。ダウンロードボタンが hover でファイルサイズを表示することは可能ですが、ダウンロードというアクション自体はピンチジェスチャーを待つ必要があります。


詳細

視線入力の基本ルール00:35)。重要なコンテンツは視野の正面に配置します。インタラクション可能な要素は角丸の形状(円、カプセル、角丸長方形)を優先します。視線は形状の中心に引き寄せられるためです。各要素には最低 60 points のスペースを確保します。要素自体はそれより小さくても構いませんが、有効な注視領域は十分な大きさが必要です。3D オブジェクトの場合、1 メートルの距離における 60 points は約 4.4 cm に相当します。インタラクション可能なすべての要素には highlight effect を付与する必要があります。標準コンポーネント(メニューなど)は自動的にハイライトされますが、カスタムコンポーネントでは手動で追加し、ハイライトの形状がコンテンツの形状にフィットすることを保証する必要があります。

Custom Hover の 3 種類のアニメーションカーブ04:01):

  • Instant:注視と同時にトリガーされます。Mindfulness のボタンは注視されると即座に矢印アイコンを表示し、標準動画プレイヤーのプレイヘッドは注視されるとすぐにタイムスタンプを表示します。「軽量・コンテキスト依存・インタラクション不可」な小さな情報に適しています。
  • Delayed:遅延トリガーです。Tooltip が典型的な例で、遅延を設けることでユーザーが素早く視線を走らせている際にあちこちでポップアップが出現するのを防ぎ、継続的な注視があった場合のみタイトルを表示します。Safari のプロファイルボタンも同じパターンを採用しています。
  • Ramp:段階的なトリガーです。Home View の環境アイコンが好例です(05:04)。注視した瞬間にゆっくりと拡大を開始し(「もう少し見続ければ展開される」というヒントを示し)、注視が継続されると spring で素早く完成形まで弾けます。推奨されるカーブは、ゆっくりとした ease-in で立ち上がり、素早い spring で締めくくる形です(05:43)。「展開してより多くのコンテンツを明らかにする」シーンに適しています。

Custom Hover の設計原則05:53)。アンカーとなる要素を提供します。一部のコンテンツ(タイトルなど)は位置を固定し、ユーザーにコンテキストを与えます。hover は可視要素からトリガーされる必要があります。隠れた要素は、ユーザーが隣接する可視要素を注視した際に浮かび上がるようにします。たとえばウィンドウの角にあるリサイズコントロールがそうです(06:42)。高頻度の要素(ツールバーボタン、リストの行)は標準の highlight で十分です。頻繁にインタラクションが発生する場面でカスタムスケーリングを行うとかえって邪魔になります。エフェクトは可能な限り小さくし、写真全体のような大面積の View にカスタムエフェクトを付与することは避けます。また色を薄めることも避けるべきです。画像や 3D オブジェクトには、まず highlight してからフェードアウトして実際の色を見せる方が望ましいアプローチです(07:55)。

Look to Scroll09:38)。ユーザーがスクロールビューの端を注視するだけでスクロールできる機能です。縦方向のビューでは上下端、横方向のビューでは左右両端が反応します。この機能はデフォルトでは無効化されており、App が能動的に opt-in してどの View で有効化するかを選択する必要があります。判断のポイントは次のとおりです。読書や閲覧系の View(Safari の長文記事、TV のおすすめコンテンツ)は有効化に適しています。一方、UI コントロールが密集した View(設定項目、Notes 左側のリスト)は適しません。そういった場所ではユーザーは順次読み進めるのではなく、素早く視線を走らせる必要があるためです。View はウィンドウの幅または高さいっぱいを占めることが望ましく、ユーザーに明確な端を視認させます。埋め込み型の View であれば、明確な境界の提示が必要です(11:34)。パララックスやカスタムのスクロール速度を持つページは Look to Scroll に適しません。予測可能性を損ねるためです。

Persistent Controls12:18)。ルールは非常にシンプルです。浮かび上がった UI は遅延後に自動的に非表示になりますが、ユーザーがそれを見続けている限り表示されたままになります。視線が外れたとき(たとえば動画本体に戻ったとき)に初めて非表示になります。標準動画プレイヤー(inline / windowed / immersive の 3 形態)はこの挙動を自動的に備えています。カスタム動画コントロールを使用している App では、手動で有効化する必要があります。FaceTime の通話コントロール、Mindfulness のセッションコントロールはいずれもこの機構を採用しています。「遅延後に自動的に非表示になる」UI はすべて永続化に対応すべきです(13:13)。

実機デバッグ09:01)。Simulator では視線追跡をシミュレートできず、動画を見ても効果は体験できません。hover の設計は Vision Pro 上で繰り返しイテレーションする必要があります。


重要ポイント

  • 何をするか:動画やメディア系 App のカスタムコントロールを Persistent Controls の挙動に対応させる。

    • なぜやる価値があるか:ユーザーの体感が最も強く、かつ実装コストが最も低い項目です。フラグを有効にするだけで、「コントロールを見ているのに消えてしまう」という頻発するフラストレーションを解消できます。
    • どう始めるか:App 内のすべての「遅延後に自動的に非表示になる」UI(動画コントロール、再生キュー、イマーシブ体験の退出ボタンなど)をリストアップし、それぞれ永続化すべきかを判断します。標準動画プレイヤーを使用しているページはそのまま挙動を獲得でき、カスタムコントロールはドキュメントに従って有効化します。
  • 何をするか:App のメインコンテンツのスクロール View に Look to Scroll を有効化し、UI リストは手動スクロールのままにする。

    • なぜやる価値があるか:長文の読書やメディア閲覧といったシーンでは、視線スクロールにより「コンテンツを読み終えると自然に下に進む」体験が無意識に行えます。一方で Settings のようなリストで強引に有効化すると、かえってユーザーの操作を妨げます。
    • どう始めるか:App 内のスクロール View を「読書・閲覧」vs「コントロール操作」に分類し、前者にのみ opt-in します。同時に、有効化するスクロール View はウィンドウの幅または高さいっぱいを占め、パララックスなどの非線形スクロールを使用しないことを確認します。
  • 何をするか:Custom Hover のデフォルトカーブとして Ramp アニメーションを採用する。

    • なぜやる価値があるか:Instant は素早い視線移動の際に各所で展開してしまいやすく、Delayed は即時のフィードバックに欠けます。Ramp の「最初はゆっくり、後で弾ける」挙動はフィードバックを提供しつつ視線移動を妨げず、visionOS のシステムレベル UI で主流の選択肢となっています。
    • どう始めるか:Home View の環境アイコンのような Apple のシステム標準サンプルからカーブを逆算します。前半は ease-in でゆっくり拡大してヒントとし、後半は spring で素早く確定させます。まずはカードの展開やボタンが追加情報を明らかにするようなシーンで試してみてください。
  • 何をするか:hover で情報を表示し、tap でアクションをトリガーする。両者を混在させない。

    • なぜやる価値があるか:これは visionOS のプライバシーアーキテクチャがもたらす厳格な制約であり、違反すると特定の OS バージョンで App が静かに失敗する可能性があります。
    • どう始めるか:App 内の「一目見るだけで実行される」インタラクション(自動クローズ、自動再生、自動ジャンプ)をすべて見直し、アクション部分はピンチジェスチャーへ移行します。hover はアニメーションフィードバックと情報の開示にのみ使用します。

関連セッション

  • Design widgets for visionOS — visionOS 26 における widget の設計ガイドライン。hover フィードバックと同一の視線言語を共有しています。
  • What’s new for the spatial web — visionOS 26 上の Web の空間機能。Web ページレベルでの hover 対応を含みます。
  • Design for spatial input — 2023 年の視線・ハンド入力の基礎セッション。本 Session でも前提となる予習として複数回引用されています。
  • Build immersive web experiences with WebXR — visionOS 上の WebXR によるイマーシブ実装。Persistent Controls の考え方と関連があります。

コメント

GitHub Issues · utterances