WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Design interactive snippets

Design interactive snippets

機械学習Design
元の動画を見る

ハイライト

Snippet は App Intent が Siri、Spotlight、Shortcuts 上にポップアップさせるコンパクトなビューです。今年からボタン、ステート更新、確認フローに対応するようになりました。

主要内容

これまで App Intent の Snippet は read-only なカードに過ぎませんでした。ユーザーが Siri に一言話しかけると、Snippet が結果を表示して、それで終わり。「もう一杯」ボタンを足したい、Snippet 上で直接注文を確定させたい——そう思っても、開発者は App に戻すしかありませんでした。これでは Snippet 本来の「一目で分かり、その場で操作できる」という設計意図が崩れてしまいます。Siri を使う場面、Spotlight を使う場面、Apple Watch を使う場面では、ユーザーの注意は非常に限られていて、画面遷移のたびに離脱が起こるからです。

WWDC 2025 では Snippet にインタラクションが追加されました。Snippet 内にボタンを配置でき、そのボタンを既存の App Intent に直接バインドできます。Snippet 内のデータはその場で更新でき、Intent を再度呼び出す必要はありません。さらに Snippet は 2 種類に分かれました。Result Snippet は最終結果を表示し、ボトムには「Done」だけが置かれます。Confirmation Snippet は「確認してから実行する」シーンに使い、ボトムのボタンには「Order」「Send」「Search」のような動作を表す動詞を書けます。設計のねらいは、軽量で慣れ親しんだ操作を Snippet 内で完結させること——App Intent を「結果を出して終わり」の使い捨てカードから卒業させることにあります。

詳細

外観とレイアウト（01:13）。Snippet のフォントサイズはシステム既定よりも意図的に大きく取られていて、瞬時に重要情報を捉えられるようになっています。要素同士には十分な余白を確保し、カード全体に統一された padding を適用します。Apple は ContainerRelativeShape API の利用を推奨しており、これによりプラットフォームや画面サイズに応じてマージンが自動調整されます。高さについては明確な指針があります。340 points を超えるとスクロールが必要になり、「ひと目で読める」という Snippet の原則が崩れてしまいます。情報量が多い場合は Snippet 内に遷移ボタンを置き、App の完全なビューへユーザーを誘導するべきです。

コントラスト（02:46）。Snippet は他のコンテンツの上に浮かぶため、App のビジュアルアイデンティティに沿った鮮やかなグラデーション背景を使うことができます。ただし Snippet は遠距離から見られるシーンが多く（机に置かれた iPhone、StandBy モードなど）、通常のコントラスト比だけでは足りません。セッションでは、標準のコントラスト閾値を超えること、必要に応じて前景を濃く、あるいは背景を弱めることで可読性を確保するよう明確に推奨しています。

インタラクションとステート（03:28）。水分摂取トラッキングを例にしましょう。Snippet に「+」ボタンを 1 つ追加し、押下すると水量の数値がその場で更新され、scale + blur のアニメーションでフィードバックを返す。この「ボタン操作 → データ書き戻し」のループによって、ユーザーは App Intent に対する信頼を積み上げていきます。Snippet には複数のボタンや複数のデータ更新を同時に配置できます。たとえばイコライザのプリセット——現在のオーディオパラメータを表示しつつ、選択可能なプリセットをいくつか提示する、というように。インタラクションがない場合でも、Snippet はアニメーションで最新データをスライドインさせる演出が可能です。

2 種類の Snippet タイプ（04:48）。Result は「すでに完了済みで、後続のアクションが不要」なシーンに使います。たとえば注文ステータスの確認で、ボトムは「Done」のみ。Confirmation は「ユーザーの最終判断を経てから実行する」シーンに使います。たとえばコーヒーの注文では、Snippet 内で espresso のショット数を調整できますが、ユーザーが「Order」を押して初めて実際に注文が確定します。確認ボタンの動詞はいくつかのプリセット（Order / Send / Search など）から選べますし、カスタマイズも可能です。確認後はもう 1 枚の Result Snippet で結果を提示することで、「Intent を起動した → 完了したのが見えた」というループが閉じます。

Dialog と Snippet の関係（06:07）。Dialog は Siri が読み上げるテキストで、AirPods を装着して画面を見ていないユーザーには欠かせません。しかしセッションでは、ある種直感に反する設計原則が示されました。Snippet 自体が独立して成立すること——dialog が出なくても、聞き取れなくても、ユーザーがその Intent の挙動を理解できる必要があるということです。Dialog と Snippet で同じ情報を繰り返してはいけません。視覚と聴覚の両方が有効な状況では冗長に感じられてしまうからです。

重要ポイント

  • やること: App Intent の中から「高頻度かつ慣れ親しまれた操作」を見つけ、Confirmation Snippet として実装する。

    • なぜやる価値があるか: ユーザーが Siri や Spotlight 上で注文や記録を完結できれば、App に戻って操作するより 1 桁速く、Intent の再利用率を大幅に高めます。
    • どう始めるか: App 内でユーザーが日次・週次に行う Top 5 のアクションを洗い出し、その中から「パラメータが少なく、確認が必要」なもの（注文、記録の送信、メッセージ送信など）を 1 つ選び、Confirmation タイプで実装します。確認ボタンは動作を表す動詞にします。

  • やること: データ表示型 Snippet にもその場での更新アニメーションを加える。

    • なぜやる価値があるか: scale + blur は Apple のセッションが明確に推奨するフィードバックの組み合わせで、フェードイン・フェードアウトより直接的に「データが変化した」ことを伝えられ、ユーザーにボタンが本当に効いたことを実感させます。
    • どう始めるか: ボタンの action 内で State を更新し、外側を contentTransition で包む——インタラクティブな Widget で使う手法をそのまま流用します。Snippet 専用にアニメーション言語を作る必要はありません。

  • やること: App 内のすべての dialog テキストを棚卸しし、Snippet が dialog なしでも独立して成立するようにする。

    • なぜやる価値があるか: AirPods 利用時は dialog しか聞こえず、Spotlight 利用時は Snippet しか見えません——どちらの側だけでも Intent を伝え切る必要があり、かつ重複してはいけません。
    • どう始めるか: Snippet のスクリーンショットを音声なしで眺め、「この画像だけで何が起きたか分かるか」を自問します。次に dialog を読み上げ、「この一文だけでユーザーは十分か」を自問します。冗長な部分は dialog 側から削ります。

  • やること: Snippet のレイアウトに 340 points の高さラインをアラートとして引く。

    • なぜやる価値があるか: この高さを超えるとスクロールが必要になり、Snippet の「ひと目で読める」価値が損なわれ、ユーザーはそのまま閉じてしまいやすくなります。
    • どう始めるか: デザインカンプ上に 340pt の横線を引き、超過する部分はカットするか、App への遷移ボタンに置き換えます。Snippet 自体に完全なリストを背負わせないことです。

関連セッション

コメント

GitHub Issues · utterances