Google Cast Design Checklist

The design checklist below is provided to make the Cast user experience simple and predictable
across all platforms. Early research and experience with Google Cast has led to the development of
this checklist. Following these guidelines when designing your app will ensure the best Cast
experience for your users.

Also, for a video overview and general guidelines to developing user experience for Cast, see
UX Guidelines.

Before a Cast session can begin, both the sender device (e.g. Mobile phone) and the receiver
device (e.g. a Chromecast plugged into a TV) must be connected to the same WiFi network
or the receiver device must be in guest mode.

Sender app / device (e.g. YouTube app on mobile)
The sender initiates connecting to and / or casting (sending a content link) to a Google Cast
Ready receiver (a.k.a Cast receiver) on the same WiFi network or in
guest mode.

Cast terminology translations (e.g. "Stop casting" in Japanese is "キャストを停止")
Common phrases used for casting have been translated into many languages and are available in this spreadsheet. Use these translations if the app you are developing is localized.

The cast button invokes a menu to connect, control and disconnect from Cast receivers.

Note that the cast button is not specific to Google Cast; it can be used to represent both Cast and non-Cast receivers (e.g. bluetooth headsets). Cast receivers should always appear under the cast menu, and never under another menu.

Introducing the cast button helps existing users know that the sender app now supports Casting and also helps users new to Google Cast.

Required A Show a Cast introduction screen the first time Cast receivers are available
B Visually highlight the cast button (e.g. circle the button)
C Explain how the cast button works (e.g. "Touch to cast videos to your TV")

Android

Cast introduction

Receiver home screen

iOS

Cast introduction

Receiver home screen

Chrome

Required A When Cast receivers are available, the cast button must be visible from every screen in the sender app and located in a consistent position while browsing or playing content. It will also appear in Chrome's header for global control.
B In mobile apps, the cast button should be on the right side of the header.
C In Chrome, the cast button should be on the right side in the content media controls (e.g. embedded video). If the media controls contain a fullscreen button, place the cast button to the left of it.

Notes

Google Cast employs a multi-tasking model, which allows users to browse the sender app and other apps while casting. The cast button must be visible from every screen of the sender app, so the user doesn’t have to hunt to find where to pause or stop the content playing on TV.

In Chrome, the cast button will automatically appear in Chrome's header if the user has the Cast extension installed.

Android

Sender disconnected

Receiver home screen

iOS

Sender disconnected

Receiver home screen

Chrome

Required A Unavailable: While Cast receivers are not available, the cast button does not appear
B Disconnected: While Cast receivers are available, the cast button appears
C Connecting: While the Cast receiver is connecting, the cast button animates the waves in the icon progressively (for details, see note below)
D Connected: While the Cast receiver is connected, the cast button appears with a filled frame shape

Best practices
For each of the button states, use colors that match the style / functionality of other UI elements of your app.

Notes
The Connecting (animated) state appears when the connection to the Cast API takes longer than expected (the Android and Chrome SDK's will automatically animate the Cast icon). Once connected, the receiver app launches.

The ON / Connected state of the cast icon has been updated and now uses a solid fill within the
icon frame. Using a distinct highlight color for the ON / Connected state is now optional
(e.g. yellow). The new cast icon and icon templates are available at Developer
Resources.

The devices menu is shown whenever the cast button is pressed. The cast menu lets users connect, control and disconnect from Cast receivers. Apps must implement this menu in a consistent way, so that users recognize and trust it to function consistently across devices, apps and platforms.

Required (default behavior of Android MediaRouter):
A When the sender app is not connected to a Cast receiver, tapping the cast button shows the cast menu
B The cast menu title "Connect to device" is to the right of the cast icon
C The cast menu shows a list of available Cast receivers
D Each receiver in the list shows a state below its name. The receiver state is the device model.

Note the multi-user scenarios:

When another user connects to a receiver currently casting (e.g. "Office - Casting YouTube") from the same app (e.g. YouTube), the sender app provides controls for the content being cast.

When another user connects to a receiver currently casting (e.g. "Office - Casting YouTube") from an app that is not casting (e.g. Play Movies), the previous sender app (e.g. YouTube) disconnects and the new sender app connects.

Android

Cast menu, not connected

Receiver home screen

iOS

Cast menu, not connected

Receiver home screen

Chrome

Required A When the sender app is connected to a Cast receiver, tapping the cast button shows the cast menu
B The cast menu title "Receiver-Name" is to the right of the cast icon
C The cast menu shows a button to disconnect from the receiver (for more info about disconnecting, see: Sender stops cast)

Best practices
Providing a call-to-action (e.g. "Ready to cast videos from this app") within the cast menu when not connected is a great way to teach or remind users about what the cast menu is for.

Android

Cast menu, connected but not casting

Receiver app loaded / idle

iOS

Required A The cast menu title "Receiver-Name" is to the right of the cast icon
B The receiver / content currently casting is shown below the title
C Tapping a receiver / content item, closes the cast menu and shows the full controls and info for that content item
D An option to disconnect from the receiver is available (for more info about disconnecting, see: Sender stops cast)

Best practices

At it's best, the cast menu is a summary of what's casting. Show what's casting with a device name, content title / artwork and basic controls (e.g. Sintel, Casting to Living Room, play / pause).

For the best user experience, provide persistent controls in addition to the controls in the cast menu.

Android

iOS

Chrome

The sender app must provide expanded controls for the content being cast. These controls could be directly embedded in a content items page or presented as a full screen view of the persistent controls.

Required A Identify content being cast (e.g. show content title / artwork)
B Before playback begins, display a loading indicator (e.g. "Loading") and content title / artwork
C When content starts, identify the receiver & state (e.g. "Casting to Receiver-Name")
D Provide relevant controls (e.g. play / pause, next / prev)
E Identify elapsed time and content duration for media streams (e.g. streaming movie)
F Hide controls not relevant to casting (e.g. full-screen button)
G Do not disconnect or stop the cast when users navigate away from the expanded controls or content item page
H Provide an easy way back to the expanded controls when users navigate away
I Android only: Use the hardware buttons to change the volume level on the receiver. A visual volume slider (with a cast icon to the left of it) should only show when the hardware volume buttons are pressed.
J iOS only: Show a volume slider or button to open the volume, since iOS does not allow using the hardware volume buttons to control non-local media.

Chrome

Persistent controls should appear when the user navigates away from the current content page or expanded controls. Persistent controls provide instant access and a visible reminder for the current cast.

Required A A bar or box that shows what's casting appears near the bottom of the sender app. These controls persist while the user browses other content or sections of the app
B The controls work best when they are simple and communicate what is being cast (e.g. show content title / artwork and play / pause)
C Available in all screens of the app
D Tapping on the content area opens the expanded controls
E Provide any other controls relevant to immediate action (e.g. add to favorites)

Best practices
For the best user experience, provide controls in the cast menu in addition to persistant controls.

Android

Sender persistent controls

Receiver content paused

iOS

Sender persistent controls

Receiver content paused

Chrome

Required (Android only) A Display a notification only when the sender app casting is not currently in view (e.g. notification for Play Movies is shown when casting from Play Movies while browsing YouTube)
B Use the normal apps icon (not the cast icon) for the notification in the statusbar
C Identify which content is casting (e.g. show content title / artwork)
D Identify which receiver is casting (e.g. "Casting to Living Room")
E Provide basic content controls (e.g. play / pause)
F Provide a way to disconnect from the receiver (e.g. "X" button)
G Tapping on the app logo, content title / artwork should open the sender apps player controls.

Notes

Android only: it is not possible to implement this in iOS.

In Android Gingerbread (version 2.3), notifications will only show the app icon and text, not play / pause or "X".

Android

Required (Android only) A Identify content casting using content title / artwork
B Identify which receiver is casting (e.g. "Casting to Living Room"). This is not required for Music apps.
C Provide playback controls (e.g. play / pause)
D Provide access to the volume control via hardware buttons

Required for Android 4.4 KitKat:

App icon

Artwork (e.g. album cover)

Identify in text what content is casting (e.g. "Sintel")

Identify which receiver is casting (e.g. "Casting to Office")

Required for Android 4.3 Jelly Bean and earlier:

Artwork (e.g. album cover)

Identify in text what content is casting (e.g. "Sintel")

Identify which receiver is casting (e.g. "Casting to Office")

Notes

Android only: it is not possible to implement this in iOS.

The lock screen controls are required for Android 4.1 and later versions.

Different controls are available for different versions of the Android operating system, and the lock screen can accommodate only text fields. Generally, graphics and iconography more immediately describe the content than text.

Volume control hardware buttons should adjust the volume on the sender app when the phone is locked.

Android

A connected sender app should retain its connected state even after the app is exited and re-started.

Required A The cast button should be in the connected state
B If the sender app accidentally gets disconnected (sender
device battery dies, sender device network connection to the receiver drops), it should have the
Cast session context stored and be able to resume the session from that context when the sender
app is restarted.
C If the user taps the cast button before the sender reconnects, the list of receiver devices is shown. When the user selects the receiver currently casting, persistent or expanded controls should appear in the sender app.

Notes
The receiver app may also disconnect and stop running, due to a power failure or some other out-of-context interruption. This is treated as an ordinary session end, as described in Sender stops cast.

Android

iOS

Content which is cast to a TV continues playing until either the last connected sender disconnects, or until a sender casts something new.

Required A When the last or only sender is connected to a receiver, tapping Disconnect stops the app running on the receiver, and either continues playing or pauses on the sender device.
B When multiple senders are connected to a receiver, pressing Disconnect from one sender app does nothing to the receiver and removes Cast controls and notifications from that sender device. The remaining connected sender device(s) stay connected with cast controls available.
C When a sender app disconnects implicitly (e.g. sender
device battery dies, sender device network connection to the receiver drops), it does nothing to
the receiver, and removes the Cast controls and notifications from the sender device. The sender
app should keep track of implicit disconnections and attempt to reconnect to a receiver when the
sender app is opened again.

Notes
Depending on the sender apps business model, a second user may or may not be able to end a session by disconnecting her app instance.

In one scenario, disconnecting one of many app instances connected to the session may end the session only for that instance; content either continues playing or pauses on the sender device.

In another scenario, disconnecting one of many app instances connected to the session ends the session for all instances.

Android

Cast menu, disconnect button

Receiver playing content

iOS

Cast menu, disconnect button

Receiver playing content

Chrome

The receiver displays content (e.g. music) and reflects its state to the user (e.g. paused). The receiver must respond immediately to actions in the sender app (e.g. play = continue playing music). For example, when content is paused on the receiver, it displays a pause icon and when the user presses play on the sender app, the receiver starts playing the content and removes the pause icon.

Required A Place most UI elements within the lower 1/4 of the screen to respect the content
B Do not present elements as interactive controls (e.g. do not reproduce the sender UI on the receiver UI)

Best practices

Use transition (fade), transparency, and nuance to soften the visual effect

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 (e.g. when paused after a few seconds, all UI except the pause icon fades away).

Android

iOS

Chrome

Required A Identify what is playing when content starts (e.g. show content title / artwork for a few seconds when playback starts)
B Identify playback position when position is adjusted (e.g. user taps rewind 30 seconds in sender app)
C Identify that content is seeking when the playback position is changed and not yet playing (e.g. animated spinner)

Android

iOS

Chrome

Required A Identify that content is paused (e.g. show paused icon and playback position)
B Identify what content is paused (e.g. show content title / artwork)
C Identify which receiver app is loaded (e.g. app logo)

Best practices

Users will often pause content to examine it, so have unnecessary UI fade away when paused for a few seconds (e.g. only show pause icon).

Disconnect from the receiver app and stop it from running if idle for 20 minutes (or less). 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.

Android

Sender paused

Receiver content paused

Sender paused

Receiver paused, after 5 seconds

iOS

Sender paused

Receiver content paused

Sender paused

Receiver paused, after 5 seconds

Chrome

Buffering on the receiver happens when network latency or other factors cause a delay in playback.

Required A Identify that the receiver is buffering after a few seconds (e.g. show buffering spinner). Waiting a few seconds to indicate buffering will prevent the buffering spinner from appearing too frequently under bad network conditions.

Best practices
Identify what content is buffering if buffering continues after 5 seconds.