非タッチ レシーバー アプリ
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
レシーバーはコンテンツを再生し、その状態をユーザーに反映します。受信側は、送信側アプリのアクションに直ちに応答する必要があります。たとえば、レシーバーでコンテンツが一時停止されると、一時停止アイコンが表示されます。ユーザーが送信側アプリで再生ボタンを押すと、レシーバーでコンテンツの再生が開始され、一時停止アイコンが削除されます。
レシーバー UI のフィードバックの例:
- 再生中
- 一時停止
- 再生位置 / シーク
- バッファリング
必須
ほとんどの UI 要素を画面の下 1/4 に配置し、他の UX と一貫性を保ちます。
B 要素をインタラクティブなコントロールとして表示しない。たとえば、送信側の UI を受信側の UI に再現しないでください。
おすすめの方法
- トランジション（フェード）、透明度、ニュアンスを使用して、視覚効果を和らげます。
- ユーザーはできるだけ多くのコンテンツを見たいと考えていることを考慮します。ユーザーはコンテンツを一時停止して確認することが多いため、可能な場合は不要な UI をフェードアウトします。
Android
送信者 UI
Receiver UI
iOS
送信者 UI
Receiver UI
Chrome
送信者 UI
Receiver UI
レシーバーが送信者に接続されていても、キャストされていない場合、レシーバーにアイドル画面が表示されます。
必須
どのレシーバー アプリが読み込まれたかを特定する
おすすめの方法
- アイドル画面を使用して、送信側アプリのコンテンツや機能を宣伝します。
- コンテンツを 30 ～ 60 秒ごとに変更して、より多くのコンテンツを表示し、画面の焼き付きを防ぎます。
- 5 分間アイドル状態の場合、レシーバー アプリから切断し、実行を停止します。停止すると、レシーバーのホーム画面が表示され、画面の焼き付きを防ぐことができます。
Android
キャスト ダイアログ、接続済みだがキャストしていない
レシーバー アプリが読み込まれた / アイドル状態
iOS
キャスト ダイアログ、接続済みだがキャストしていない
レシーバー アプリが読み込まれた / アイドル状態
ユーザーがレシーバに接続すると、レシーバアプリは、アプリのアイドル状態を表示したり、コンテンツの再生を開始したりする前に、まず読み込まれる必要があります。
必須
A アプリのロゴを表示して、どのレシーバー アプリが読み込まれているかを特定する
B アニメーションの読み込みスピナーを表示して、レシーバー アプリが読み込まれていることを特定する
Android
送信側が接続中
レシーバー アプリの読み込み
iOS
送信側が接続中
レシーバー アプリの読み込み
Chrome
送信側が接続中
レシーバー アプリの読み込み
受信側アプリが読み込まれると、コンテンツの受信側へのストリーミングを開始できます。
必須
A コンテンツのタイトルまたはアートワークを表示して、読み込まれているコンテンツを特定する
B アニメーションの読み込みスピナーを表示して、コンテンツが読み込まれていることを特定する
ベスト プラクティス
一時停止したコンテンツを再開するときは、送信側から受信側への移行中に視聴者がコンテンツを見逃さないように、再生を 5 ～ 10 秒巻き戻します。
Android
送信者のコンテンツの読み込み
レシーバーのコンテンツの読み込み
iOS
送信者のコンテンツの読み込み
レシーバーのコンテンツの読み込み
Chrome
送信者のコンテンツの読み込み
レシーバーのコンテンツの読み込み
必須
A コンテンツの開始時に再生中のものを特定する
B 位置が調整されたときに再生位置を特定する
C 再生位置が変更されたが、まだ再生されていないときに、レシーバーがコンテンツをシークしていることを特定する
Android
送信者が再生位置を調整する
レシーバー コンテンツのシーク
iOS
送信者が再生位置を調整する
レシーバー コンテンツのシーク
Chrome
送信者が再生位置を調整する
レシーバー コンテンツのシーク
必須
A 一時停止アイコンと再生位置を表示して、コンテンツが一時停止していることを示す
B コンテンツのタイトルまたはアートワークを表示して、一時停止しているコンテンツを示す
C アプリのロゴを表示して、読み込まれているレシーバー アプリを示す
おすすめの方法
- ユーザーはコンテンツを一時停止して確認することが多いため、一時停止アイコンを表示して、一時停止してから数秒後に不要な UI をフェードアウトさせます。
- レシーバー アプリは、ユーザーから再生開始（再開、キュー内のアイテムのスキップなど）の明示的なリクエストがない限り、コンテンツの再生を継続すべきではありません。
- 20 分間アイドル状態の場合、レシーバー アプリから切断して実行を停止します。停止すると、レシーバーのホーム画面が表示され、画面の焼き付きを防ぐことができます。一時停止した位置を保存して、ユーザーが後でその位置から再生を再開できるようにします。
Android
送信者が一時停止しました
受信者のコンテンツが一時停止された
送信者が一時停止しました
受信側が一時停止しました（5 秒後）
iOS
送信者が一時停止しました
受信者のコンテンツが一時停止された
送信者が一時停止しました
受信側が一時停止しました（5 秒後）
Chrome
送信者が一時停止しました
受信者のコンテンツが一時停止された
送信者が一時停止しました
受信側が一時停止しました（5 秒後）
受信側のバッファリングは、ネットワーク レイテンシなどの要因によって再生が遅延した場合に発生します。
必須
数秒後にバッファリング スピナーを表示して、レシーバがバッファリングしていることを識別します。 バッファリングを示すために数秒待機することで、ネットワーク環境が悪い場合にバッファリング スピナーが頻繁に表示されるのを防ぐことができます。
ベスト プラクティス
5 秒経過してもバッファリングが続く場合は、どのコンテンツがバッファリングされているかを特定します。
Android
送信側が受信側のバッファリングを示す
レシーバーのコンテンツ バッファリング
iOS
送信側が受信側のバッファリングを示す
レシーバーのコンテンツ バッファリング
Chrome
送信側が受信側のバッファリングを示す
レシーバーのコンテンツ バッファリング
再生が停止またはタイムアウトした場合は、レシーバー UI で送信側アプリで利用可能な他のコンテンツや機能を表示する必要があります。
必須
アプリのロゴを表示して、どのレシーバー アプリが読み込まれているか、またはアイドル状態であるかを特定する
おすすめの方法
- 再生後にアイドル画面を使用して、直前にキャストされたコンテンツに基づいて送信側アプリのコンテンツや機能を推奨する
- 画面の焼き付きを防ぐため、アイドル画面のコンテンツを 30 ～ 60 秒ごとに変更する
- 5 分間アイドル状態の場合、レシーバー アプリから切断し、実行を停止します。停止すると、レシーバーのホーム画面が表示され、画面の焼き付きを防ぐことができます。
Android
送信側アプリがアイドル状態
レシーバー アプリがアイドル状態
送信者の接続が解除されました
ホーム画面をキャストする
iOS
送信側アプリがアイドル状態
レシーバー アプリがアイドル状態
送信者の接続が解除されました
ホーム画面をキャストする
Chrome
送信側アプリがアイドル状態
レシーバー アプリがアイドル状態
送信者の接続が解除されました
ホーム画面をキャストする
このデザイン ガイドで使用されている画像は、Blender Foundation の提供によるもので、著作権またはクリエイティブ・コモンズ ライセンスに基づいて共有されています。
- Elephant's Dream: (c) copyright 2006, Blender Foundation / Netherlands Media Art Institute /
www.elephantsdream.org
- Sintel: (c) コピーライト: Blender Foundation | www.sintel.org
- Tears of Steel: (CC) Blender Foundation | mango.blender.org
- Big Buck Bunny: (c) copyright 2008, Blender Foundation / www.bigbuckbunny.org
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-07-26 UTC。
[null,null,["最終更新日 2025-07-26 UTC。"],[[["\u003cp\u003eReceiver UIs should be minimally intrusive, displaying playback status and content information primarily in the lower quarter of the screen, without replicating sender app controls.\u003c/p\u003e\n"],["\u003cp\u003eWhen the receiver is idle or loading, clear app identification and loading indicators are crucial for a smooth user experience.\u003c/p\u003e\n"],["\u003cp\u003eContent loading and playback states should be clearly communicated to the user, with provisions for buffering and seeking.\u003c/p\u003e\n"],["\u003cp\u003eThe receiver should transition to an idle state when paused or playback is complete, displaying app branding and potentially promoting content to avoid screen burn-in.\u003c/p\u003e\n"],["\u003cp\u003eThroughout all states, visual feedback such as icons, spinners, and content metadata contribute to an intuitive and responsive user interface.\u003c/p\u003e\n"]]],["The receiver displays content and mirrors its state based on sender actions. Key actions include playing, pausing, seeking, and buffering, each visually represented on the receiver. When idle, the receiver shows the app logo and may promote content. When the app is loading or content is loading, it also displays its logo along with a loading spinner. When the receiver stops casting, it reverts to an idle state promoting other content or features.\n"],null,["# Non-Touch Receiver App\n\nThe receiver plays content and reflects its state to the user.\nThe receiver must respond immediately to actions in the sender app . For example, when content is\npaused on the receiver, it displays a pause icon and when the user presses play on the sender app,\nthe receiver starts playing the content and removes the pause icon.\n\nExamples of receiver UI feedback:\n\n- Playing\n- Paused\n- Playback position / seeking\n- Buffering\n\n### [Receiver UI](#receiver-ui-elements)\n\n\n**Required**\n\n\nA Place most UI elements within the lower 1/4 of the screen\nand keep it consistent with your other UX's.\n\n\nB Do not present elements as interactive controls. For\nexample, do not reproduce the sender UI on the receiver UI.\n\n\n**Best practices**\n\n- Use transition (fade), transparency, and nuance to soften the visual effect.\n- Consider the fact that users want to see as much of the content as possible. Users will often pause content to examine it, so fade away unnecessary UI when possible.\n\n### Android\n\nSender UI \nReceiver UI \n\n### iOS\n\nSender UI \nReceiver UI \n\n### Chrome\n\nSender UI \nReceiver UI \n\n### [Receiver app idle](#receiver-ui-idle)\n\nAn idle screen is displayed on the receiver, when the receiver is connected to a sender but not\ncasting.\n\n\n**Required**\n\n\nA Identify which receiver app is loaded\n\n**Best practices**\n\n- Use the idle screen to promote content or features from the sender app.\n- Change the content every 30-60 seconds to display more and prevent screen burn.\n- Disconnect from the receiver app and stop it from running if idle for 5 minutes. When stopped, the receiver home screen appears and will help prevent screen burn.\n\n### Android\n\nCast dialog, connected but not casting \nReceiver app loaded / idle \n\n### iOS\n\nCast dialog, connected but not casting \nReceiver app loaded / idle \n\n### [Receiver app loading](#receiver-player-loading)\n\nWhen a user connects to a receiver, the receiver app must first load before it can display the\napp idle state or begin playing content.\n\n\n**Required**\n\n\nA Identify which receiver app is loading by displaying the\napp logo\n\n\nB Identify that the receiver app is loading by displaying\nthe animated loading spinner \n\n### Android\n\nSender connecting \nReceiver app loading \n\n### iOS\n\nSender connecting \nReceiver app loading \n\n### Chrome\n\nSender connecting \nReceiver app loading \n\n### [Receiver content loading](#receiver-content-loading)\n\nOnce the receiver app has loaded, content can begin streaming to the receiver.\n\n\n**Required**\n\n\nA Identify what content is being loaded by displaying the\ncontent title or artwork\n\n\nB Identify that content is loading by displaying an\nanimated loading spinner\n\n\n**Best practices**\n\n\nWhen resuming paused content, rewind playback 5-10 seconds so the viewer doesn't miss anything\nduring the transition from sender to receiver. \n\n### Android\n\nSender content loading \nReceiver content loading \n\n### iOS\n\nSender content loading \nReceiver content loading \n\n### Chrome\n\nSender content loading \nReceiver content loading \n\n### [Receiver playback](#receiver-ui-seek)\n\n\n**Required**\n\n\nA Identify what is playing when content starts\n\n\nB Identify playback position when position is adjusted\n\n\nC Identify that the receiver is seeking content when the\nplayback position is changed, but not yet playing \n\n### Android\n\nSender adjusting play position \nReceiver content seeking \n\n### iOS\n\nSender adjusting play position \nReceiver content seeking \n\n### Chrome\n\nSender adjusting play position \nReceiver content seeking \n\n### [Receiver paused](#receiver-ui-pause)\n\n\n**Required**\n\n\nA Identify that content is paused by displaying a paused\nicon and playback position\n\n\nB Identify what content is paused by displaying content\ntitle or artwork\n\n\nC Identify which receiver app is loaded by displaying an\napp logo\n\n**Best practices**\n\n- Users will often pause content to examine it, so have unnecessary UI fade away when paused for a few seconds by displaying a pause icon.\n- The receiver app should not continue content playback unless there is an explicit request from the user to begin playback such as resume, or skipping an item on the queue.\n- Disconnect from the receiver app and stop it from running if idle for 20 minutes. When stopped, the receiver home screen appears and will help prevent screen burn. Store the paused location so that the user can resume playback from that point at a later time.\n\n### Android\n\nSender paused \nReceiver content paused \nSender paused \nReceiver paused, after 5 seconds \n\n### iOS\n\nSender paused \nReceiver content paused \nSender paused \nReceiver paused, after 5 seconds \n\n### Chrome\n\nSender paused \nReceiver content paused \nSender paused \nReceiver paused, after 5 seconds \n\n### [Receiver buffering](#receiver-ui-buffer)\n\nBuffering on the receiver happens when network latency or other factors cause a delay in playback.\n\n\n**Required**\n\n\nA Identify that the receiver is buffering after a few\nseconds by displaying a buffering spinner. Waiting a few seconds to indicate buffering will\nprevent the buffering spinner from appearing too frequently under bad network conditions\n\n\n**Best practices**\n\n\nIdentify what content is buffering if buffering continues after 5 seconds. \n\n### Android\n\nSender indicates receiver buffering \nReceiver content buffering \n\n### iOS\n\nSender indicates receiver buffering \nReceiver content buffering \n\n### Chrome\n\nSender indicates receiver buffering \nReceiver content buffering \n\n### [Receiver stops cast](#receiver-ui-complete)\n\nWhen playback stops or times out, the receiver UI should promote other content or features\navailable in the sender app.\n\n\n**Required**\n\n\nA Identify which receiver app is loaded or idle by\ndisplaying an app logo\n\n**Best practices**\n\n- Use the idle screen after playback to recommend content or features from the sender app, based on what was just cast\n- Change the idle screen content every 30-60 seconds to prevent screen burn\n- Disconnect from the receiver app and stop it from running if idle for 5 minutes. When stopped, the receiver home screen appears and will help prevent screen burn.\n\n### Android\n\nSender app idle \nReceiver app idle \nSender disconnected \nCast home screen \n\n### iOS\n\nSender app idle \nReceiver app idle \nSender disconnected \nCast home screen \n\n### Chrome\n\nSender app idle \nReceiver app idle \nSender disconnected \nCast home screen \n\n**Images used in this design guide**\nare courtesy of the Blender Foundation, shared under copyright or Creative Commons license.\n\n- Elephant's Dream: (c) copyright 2006, Blender Foundation / Netherlands Media Art Institute / www.elephantsdream.org\n- Sintel: (c) copyright Blender Foundation \\| www.sintel.org\n- Tears of Steel: (CC) Blender Foundation \\| mango.blender.org\n- Big Buck Bunny: (c) copyright 2008, Blender Foundation / www.bigbuckbunny.org"]]
