Platform Feature Requirements

This document details the unique platform feature requirements that your app must meet to deliver a seamless and consistent user experience.

Sign-in and authentication requirements (AR)

AR-01 Sign in via pairing code or DIAL (via casting)

Customers with existing sign-in credentials should be able to sign-in successfully using a pairing code or casting from an alternative device.

Additional notes:

• Note on URL for PIN pairing: This must be a friendly URL in the form partnerweb.com/subpage and be no longer than 30 characters. It must have search engine optimization to cater for users who enter it in their search bar.

Acceptance criteria

As a user that has existing app credentials, I want to sign in to app via pairing code using a browser on an alternative device or to cast from the app on a mobile or tablet device or use a QR code to speed up the sign-in flow.

OR

OR

AR-02 Sign-in via keyboard

Users must be given the ability to enter their credentials (e.g. email address and password) using an on-screen keyboard.

Acceptance criteria

As a user that has existing app credentials, I want to the ability to sign in to app via on-screen keyboard, so that I don’t have to switch devices.

AR-03 App sign-in response: success & fail

The app should successfully sign in quickly, or present a relevant invalid response. This is so that users can start accessing content as quickly as possible.

Additional notes:

• This requirement does not depend on whether the user has subscribed to the app via the app platform or directly with the app partner themselves.

Acceptance criteria

As a user, I want sign-in to be quick, so that I can start browsing and accessing content as soon as possible.

• Given the user has entered in invalid sign-in credentials within the app,
• When they select sign-in,
• Then the app must not sign the user in and display a relevant error message (e.g. "username / password not recognised") within 1 second.

Deep linking requirements (DL)

The app Platform uses key intents when deep-links are selected from the app Platform experience and passed to an app to determine the right behavior for the user. Below are the intents used on the app Platform:

• The EntityIntent goes to an entity or Show page. When a user has yet to engage with a show, we pass the entity intent.
• The PlaybackIntent goes straight into the playback of the selected asset. When a user has engaged with a single asset or episode from a series, we pass the Playback intent for that asset.

DL-01 Direct playback deep linking from cold start

• When your app is in the unloaded state and a user selects to watch content from a show center or a content tile, then your app needs to load first before the content starts playing.
• When a user selects a deep link and your app has loaded, then the user should be placed in the correct place within your app.

Acceptance criteria

As a new user, when I select a specific piece of app content from the platform UI, I want to access that piece of content within the app, so that I can start watching the content I desired.

Scenario prerequisites:

1. I'm signed in if applicable
2. Metadata ingested or editorial direct playback deep-links are being used (Playback Intent)

DL-02 Show page deep linking from cold start

When your app is in the unloaded state, and a user selects your app content tile, then your app needs to load first before your app content show page displays (within your app).

Additional notes:

For apps we ingest metadata the only instance where this might be possible is if we have not ingested metadata for a particular title yet but we still want to merchandise it.

Scenario prerequisites

1. I'm signed in if applicable.
2. Editorial shows page deep link used or Watch action from ingested metadata (Entity Intent).

Acceptance criteria

As a new user, when I select a specific piece of app content from the platform UI, I want to access that piece of content within the app, so that I can start watching the content I desired.

DL-03 Direct playback deep linking from inactive state

When your app is in the inactive state, and a user selects the 'watch' button from your app titles show center or your app content tile, then your app needs to start full screen playing. Your app should not reload.

Acceptance criteria

As a new user, when I select a specific piece of app content from the platform UI, I want to access that piece of content within the app, so that I can start watching the content I desired.

Scenario prerequisites

1. I'm signed in if applicable.
2. The app is in inactive state.
3. Metadata ingested or editorial direct playback deep-links are being used (Playback Intent).

DL-04 Show page deep linking from inactive state

When your app is in the inactive state, and a user selects your app's content tile, then your app needs to full-screen display the show page within your app. Your app should not reload.

Acceptance criteria

As a user, when I am in an app and dismiss out of the app via the back button to the platform UI, I want to be able to access back into the app from where I left off so that I can continue my journey within the app.

Scenario prerequisites:

1. I'm signed in, if applicable.
2. The app is in the inactive state.
3. Editorial show page deep link used or Watch action from ingested metadata (Entity Intent).

DL-05 Direct playback deep linking from background active state (mini-tv)

When your app is in the background active state and the 'watch' button is selected from your app's show center or content tile, then your app must be made visible in full screen and start playing the selected content.

Acceptance criteria

As a user, when I am in an app in mini-tv, I want to be able to access back into the app from where I left off so that I can continue my journey within the app.

Scenario prerequisites

1. I'm signed in if applicable.
2. The app is in background active state (mini-tv).
3. Metadata ingested or editorial direct playback deep-links are being used (Playback Intent).

DL-06 Show page deep linking from background active state (mini-tv)

When your app is in the background active state and the user selects your app content tile, then your app content displays in full screen.

Acceptance criteria

As a user, when I am in an app in mini-tv, I want to be able to access back into the app from where I left off so that I can continue my journey within the app.

Scenario prerequisites

1. I'm signed in, if applicable.
2. The app is in background active state (mini-tv).
3. Editorial show page deep link used or Watch action from ingested metadata (Entity Intent).

DL-07 Direct Playback deep linking from Foreground Active state

When your app is in foreground active state and the user selects your app content tile, then your app content will remain in full screen and the content will start playing.

Acceptance criteria

As a user, when I am in an app in Foreground Active state, I want to be able to access back into the app from where I left off so that I can continue my journey within the app.

Scenario prerequisites

1. I'm signed in if applicable.
2. The app is in foreground active state (full screen).
3. Metadata ingested or editorial direct playback deep-links are being used (Playback Intent).

DL-08 Show Page deep linking from Foreground Active state

When your app is in the Foreground Active state and the user uses voice search for an app title, then your app will display the app content in-app in full screen.

Acceptance criteria

As a user, when I am in an app in full screen, I want to be able to access back into the app from where I left off, so that I can continue my journey within the app.

Scenario prerequisites

1. I'm signed in if applicable.
2. The app is in Foreground Active state (full screen).
3. Editorial show page deep link used or Watch action from ingested metadata (Entity Intent).

DL-09 App Launch

When a user selects your app's launch point, then your app should load and the intended screen should become visible.

Acceptance criteria

As a user, when I am in the platform UI, I want to be able to select the app launch point so I can browse the app and/or engage with content in the app.

Scenario prerequisites

1. The app is available on the device.
2. I'm signed in, if applicable.

App UI requirements

UI-01 App Synopsis

Example: App Synopsis UI

You must have a clear description of your app up to 180 characters long.

Additional notes:

• We recommend up to 180 characters but can go up to a maximum of 200 pending review on the app platform.
• See image guidelines for additional asset specifications.

Acceptance Criteria

As a user, I want a synopsis for an app, so that I understand what the app is and what content it offers.

UI-02 Content Synopsis

Example: Content synopsis UI

You must have a clear description of your content up to 200 characters long. This appears alongside the content hero image.

Quick start feature requirements (QS)

QS-01 Foreground Active to Background Active (when pressing 'home' on remote)

Your app must transition from the Foreground Active state to the Background Active state appropriately without issue when the user presses 'home' on the remote.

Additional notes:

• This transition does not require the app to support Firebolt Lifecycle states; this is a platform level capability.

Acceptance Criteria

QS-02 Background Active to Foreground Active

Your app must transition from the Background Active state to the Foreground Active state appropriately without issue.

Additional notes:

• This transition does not require the app to support Firebolt Lifecycle states; this is a platform level capability.

Acceptance Criteria

QS-03 Background Active to Inactive

Your app must transition from the Background Active state to the Inactive state appropriately without issue.

Acceptance Criteria

QS-04 Inactive to Foreground Active (Quick Start launch)

Your app must transition from the Inactive state to the Foreground Active state appropriately without issue.

Additional notes:

• The app does not need to have integrated with Firebolt Lifecycle States to support this transition.
• If the app had transitioned into the Inactive state from an Active state within the last 60 seconds, the app must reopen at the same place within the app UI that the user was in previously. The exception is if the app is being launched via a deep link, in which case it will transition to Foreground Active to the content playback or showpage the link relates to.
• If the app supports in-app profiles, then the app should keep the same profile logged in.
• If the app had transitioned into the Inactive state from an Active state after 60 seconds, the app must transition to the app homepage.
• If the app supports in-app profiles, then the app should take you to a Profile Selection screen. The exception is if the app is being launched via a deep link, in which case it should transition to Foreground Active to the content playback or showpage the link relates to, using the most recently used app profile.

Acceptance Criteria

QS-05 Unloaded to Foreground Active (cold start launch)

Your app must transition from the Inactive state to the Foreground Active state appropriately without issue.

Additional notes:

• The app does not need to have integrated with Firebolt Lifecycle States to support this transition.

Acceptance Criteria

QS-06 Foreground Active to Inactive (when pressing 'dismiss' on remote)

Your app must transition from the Foreground Active state to the Inactive state appropriately without issue when the user presses 'dismiss' on the remote. There are two methods of exiting the app and placing it into the Inactive state fromthe Foreground Active state:

1. Pressing 'dismiss' on the remote.
2. Launching content that exists outside of the app via voice command or DIAL.

Additional Note

• Pressing the 'dismiss' button on the remote will exit the app, placing it into the Inactive state. Pressing 'home' on the remote does not exit the app completely, despite the app not being in the foreground. This instead places the app into the Background Active state (see QS01 Foreground Active to Background Active transition).

Acceptance Criteria

QS-07 Full System Reboot

Your app must begin in the Inactive state after a reboot if your app was the last app launched prior to the reboot. Your app must also follow the same acceptance criteria as the QS-04 Inactive to Foreground Active transition.

If your app requires authentication, and the user has successfully authenticated prior to a full system reboot, the user must remain authenticated so that the next time your app is launched they can access your app without being asked to sign in again.

QS-08 App Crash from Active Foreground / Background

If your app is in a Foreground Active or Background Active state and detects a crash, then your app should issue a Lifecycle.close() with reason as Error. The app should launch from a cold start state when it launches next (see QS-05 for cold start launch requirements).

QS-09 Glance mode while app is in Foreground Active

This is only applicable for users in the UK.

If your app has been running with no activity from the user after 3 minutes while in the Foreground Active state, then Glance mode should not trigger.

QS-10 Glance mode while app is in Unloaded, Inactive, or Background Active

This is only applicable for users in the UK.

If your app has been running with no activity from the user after three minutes while in the Unloaded, Inactive or Background Active state, then Glance mode should trigger.

QS-11 Lifecycle on XiOne (DE & IT) devices

This requirement is only applicable to distribution with Germany (DE) and Italy (IT)

If your app is on a XiOne device (DE & IT), then the lifecycle behavior must match the requirements outlined in QS-04 through QS-07, and QS-08. However, the following changes will apply:

1. There will be no Background Active state. The states for Q will either be Unloaded, Active, or Inactive.
2. There is no Switcher rail in the UI.

Lifecycle requirements QS-01 through QS-03 will not apply to these devices.

Trickplay Behavior Requirements (TP)

TP-01 Play

Your content should play or resume as expected when the user selects to play content. This includes playing from the content tile, fast-forwarding / rewinding content, or when the content is paused.

Acceptance criteria

As a user, I want to be able to forward or rewind so that I can control my playback in the app consistently.

Scenario prerequisites:

• The user is watching content in the app – applicable to FFWD/RW-able adverts as well.

TP-02 Pause

Your content should pause when the user selects to pause content. This includes pausing while watching, fast-forwarding, or rewinding content.

Acceptance criteria

As a user, I want to be able to forward or rewind so that I can control my playback in the app consistently.

scenario : The user is watching content in the app – applicable to FFWD/RW-able adverts as well.

TP-03 Fast-forward

Your content should fast-forward when the user selects to fast-forward content and present a visual indication of timeline progress. This includes increasing speed while fast-forwarding (x2, x6, x12, and x30).

Acceptance criteria

As a user, I want to be able to forward or rewind so that I can control my playback in the app consistently.

scenario : The user is watching content in the app – applicable to FFWD or RW-able adverts as well.

TP-04 Rewind

Your content should rewind when the user selects to rewind content and present a visual indication of timeline progress. This includes increasing speed while rewinding (x2, x6, x12, and x30).

Acceptance criteria

As a user, I want to be able to forward or rewind so that I can control my playback in the app consistently.

scenario : The user is watching content in the app – applicable to FFWD or RW-able adverts as well.

TP-05 Scrubbing

When a user presses and holds the left or right button, a visual audio or video selector must slide across a visual timeline within the player UI of your app.

As an example, user can forward from position 00:00 to 03:00 in a piece of content.

Acceptance criteria

As a user, I want to be able to scrub forward or backwards so that I can control my playback.

Scenario prerequisites:

• The user is watching content in the app – applicable to FFWD or RW-able adverts as well.

Playback Requirements (PB)

See UI Examples for examples of app UI.

PB-01 Initiating Playback from the Show Center UI - Hero zone

Your app content should play and resume as expected from the content tile, fast-forwarding or rewinding content, or when content was previously paused.

Additional notes:

• Requires both metadata integration and consumption data integration.

Acceptance criteria

As a user, when I press select the watch call to action on a piece of content from the Show Page UI (hero zone), I want the to load that piece of content, so that I can start watching it.

PB-02 Initiating Playback from the Show Center UI - Available Now zone

Your app content should load and play the correct episode when the user presses 'Play' on a specific piece of content in the Show Center UI.

Additional notes:

• The app platform will not be able to include your app in the platform UI Show Center.

Acceptance criteria

As a user, when I browse down the platform UI Show Center to the “Available Now” zone and press “Play” on a specific piece of content, I want the app to load that specific piece of content, so that I can start watching it.

PB-03 Initiating Playback from a Merchandised Title (via Show Page)

When a user selects a piece of merchandised app content, then the platform UI should display the correct editorialized app content within the UI show page.

Additional notes:

• Merchandising is at platform discretion and requires app metadata integration.

Acceptance criteria

As a user, when I select a specific, editorialized piece of app content from the Sky UI, I want to access that particular piece of content within the , so that I can start watching the content I desired.

PB-04 Initiating playback from an app platform Show Page (no consumption data)

The CTA must say 'Watch' within the hero zone if the user has not yet watched any content from your app.

Scenario prerequisites:

• User has landed on the show page for an app which they have not engaged with and there is no resume point

Acceptance criteria

PB-05 Initiating Playback from an app platform Show Page (consumption data available)

The CTA must say 'Continue' within the hero zone if the user had previously started watching content from your app. The 'Continue' action must be based on the resume point of the content.

Acceptance criteria

Scenario prerequisites:

• User has landed on the show page for a which they do have a resume point and have started to engage with.

PB-06 Resuming playback from platform UI

Your app content should display the correct piece of content or episode in the app platform's Continue Watching rail or Show Page.

Additional notes:

• Resuming playback requires the app to have integrated both metadata and consumption data.

Acceptance criteria

As a user, when I surface a piece of content from within the app in the platform UI (either via a Continue Watching rail or from a Show Page), I want the platform UI to surface the current episode I’m watching or the next episode to play (UI Example: Continue -> Playback Intent).

PB-07 Initiating playback from the platform UI - play now/continue watching

Your app content should play the correct piece of content or episode from the app platform's Continue Watching or Play Now rail without additional user action when the user presses 'Play'.

Additional notes:

• Requires both metadata integration and consumption data integration.
• The app loading time is subject to the app Load Times requirements (OR01) . Where the content is subject to pre-roll advertising, idents, etc. the playing of these assets will fulfil this requirement.

Acceptance criteria

As a user, when I select “Play” on a piece of content from the “Play Now”/ “Continue Watching” rail I want the app to load and the content to start playing straightaway without any information screens and without the need for further button presses. (UI Example: Continue -> Playback Intent).

Ad break requirements (AB)

AB-01 Trickplay during advertisements

If a user initiates FFWD, RWD, scrub, or skip during an ad break, then your app must present a notification indicating which functions are unavailable during the ad break.

Additional notes:

• This is to avoid the Trickplay UI displaying at the start of every ad-break in normal viewing mode and impacting the viewing experience.

Acceptance criteria

AB-02 Visual timeline

When the user attempts to initiate trickplay, a visual timeline within the player's UI elements must be presented to indicate the progress for ads.

AB-03 Transitions

Black screens, error screens, or other visible transitions/ inconsistencies should not be presented at any point using trickplay between ads and content playback

Dismiss button requirements (DB)

On remotes that have a 'back button' instead of a 'dismiss button', the same requirements apply to 'back buttons'.

DB-01 App exit behavior

When a user is on your app's homepage and the dismiss button is pressed, then your app must exit and return the user back to the same point they launched your app from within the platform UI. Confirmation dialogues are not permitted for this action.

Acceptance criteria

As a user, I want the app to exit quickly so that I can get back to the platform UI.

Scenario prerequisites:

• A confirmation dialogue on app exit is not permitted.
• On exit, the current UI behavior will place the user back to the same point at which they launched the app
• If the hierarchical back is not the best solution, then historical back can be used on the basis that:
• Dismissing no more than 3 times will return back to the app platform's UI.
• On the dismiss journey, the app should exit via a show page and the in-app homepage.

DB-02 Dismiss button during playback

If on-screen UI is visible, the dismiss button first applies to going back to full-screen playback.

Acceptance criteria

As a user, I want the app to be intuitive when dismissing during playback.

DB-03 Ending content during playback

When a user is watching content, no on-screen UI is present, and the dismiss button is pressed, then your app must take the user to the in-app showpage for that show. Confirmation dialogues are not permitted for this action.

Additional notes:

• Some remotes have a back button instead of dismiss, the same requirement applies to the back button on these remotes.

Acceptance criteria

As a user, I want the app to stop playback quickly.

DB-04 Remote capability

A confirmation dialogue on app playback ending is not permitted. Your app should respond as expected when interacting with supported remotes (including touch dish and touch remotes).

Gaming requirements (GG)

To provide customers playing games a good experience, the following requirements must be met.

GG-01 Bluetooth pairing - settings

Previous ID: F10

Customers can pair a Bluetooth device.

Acceptance criteria

As a user, I want to be able to pair my Bluetooth controller through the Settings menu with ease, so my controller will navigate cloud gaming Cloud Gaming Apps.

GG-02 Cloud gaming app navigation - game controller

Previous ID: F13

Customers can use a Bluetooth game controller.

Acceptance criteria

As a user, I want to use my paired Bluetooth controller within the Gaming app, so that I can navigate the UI with ease

See button mappings for more information.

GG-03 Cloud saves

Previous ID: F15

Customers can save and resume progress within a game.

Acceptance criteria

As a user, I want my saves to be stored in the cloud, So that I can resume my game.

GG-04 Cloud gaming app responsiveness

Previous ID: NF2

Interactions by the customer with the Gaming app must not be delayed.

Acceptance criteria

As a user, I want the to respond quickly when I am using it so that I do not have to wait while navigating.

GG-05 Visual playback latency

Previous ID: NF4

The visual element of gaming content must not have lag.

Acceptance criteria

As a user, I want a visually responsive gaming experience when I am cloud gaming, so that I can immerse myself in the experience.

GG-06 Audio playback latency

Previous ID: NF5

The audio element of gaming content must not lag behind the visual element.

Acceptance criteria

As a user, I want an audibly responsive gaming experience when I am cloud gaming, So that the visual and audible experience are in sync

GG-07 Resuming games from EntOS UI

Previous ID: PB1

Customers can quickly resume playback directly from EntOS.

Acceptance criteria

As a user, when I play a game from within the Gaming app in EntOS UI (either via a Continue Playing rail or from a Game entity/destination Page), I want EntOS UI to surface the current game I’m playing (Continue -> Cloud game resume Intent).