Discovery: Watch v2

Outcome

Every Discovery streaming service went on to run on v2 of the shared platform, with playback as I documented it in Watch v2. I wrote the white-label spec with the platform’s tech team and its PO, then supported the discovery+, Quest and Eurosport teams through implementation and UI delivery on their services.

Context

Discovery ran discovery+, Eurosport, Quest and its other streaming services on one shared white-label platform. Their content and business models differed. Some had live channels and live events streamed outside a channel as well as VOD, some were ad funded and others sold subscriptions, and parental controls and broadcast guidance rules varied by market.

Playback was being rebuilt for v2 of the platform while its tech specs were still changing. The goal was one set of playback journeys and player states for the iOS and Android apps, on phones and tablets in both orientations, that every service could configure and the platform’s developers could build against.

Writing playback journeys beside the platform’s tech specs

The platform’s playback capabilities were still changing when I started on Watch v2. I worked embedded in the platform’s tech team, with its PO, and documented each journey in Axure beside the tech spec it depended on, revising the journeys as the capabilities changed.

Several features depended on data in the stream: skip intro and the next up cue on markers in the stream metadata, the scrub preview on trick play images, and ad breaks on insertion cues. In the spec each of these journeys applied only where the stream carried the data it needed. The spec published in March 2020 ran to 39 pages: 16 local playback journeys, the player and the full-screen player in five blocks of states, the states of each sub-component, and casting.

01Playback journeys

Letting each service choose how playback opens

The platform had to support services that opened playback in different ways. For each content type, VOD, live and live catch-up, I wrote three journeys: no forced full screen, full screen forced on playback, and full screen forced in landscape. Each runs from the tile in browse through loading, playback start and the controls fading out to the end of playback, where users can close, watch again or load the next episode.

Toggling full screen took six journeys, by device orientation and by whether the service forced full screen on playback and landscape on full screen. On a landscape device with full screen forced, the player showed no toggle. The platform had to support every journey, and each service picked its behaviour through configuration.

Supporting live, catch-up and scrubbing

Live content reached the player in two ways, on a channel or as a stream outside one, and either could be live or on now. I gave each its own block of player states, including the states for a viewer who had skipped back. Users who chose watch from start on a live event could skip to live at any point, and if the live stream had ended by then they went to the end of playback.

On VOD the scrub bar showed a preview pane with trick play images from the stream, to help users find a point in the episode. Live streams carried no previews, so scrubbing live showed a timestamp, in a format each product chose: the time behind live, the local time at the playhead, or the time elapsed from the start.

Handling ads, guidance labels and parental PINs

Ads were inserted dynamically into VOD, live and catch-up. Users needed to know how many ads were in a break and how long until playback resumed, so each ad showed its place in the break and a countdown, with a skip button where the ad allowed one. A user who scrubbed past an ad cue on VOD had to watch the skipped ads before playback resumed, and a second tap on an ad opened its link in the browser. Ads on live catch-up were marked on the page as still needing requirements.

Guidance labels were a legal requirement in some markets and a product choice in others, with visual rules that changed by region. I referenced Denmark’s NICAM ratings and the BBC’s guidance labels, and mapped two journeys meant to cover most cases or to serve as the base for a custom one: full-screen guidance before playback, or a label on the video once the controls fade, held for the legally required time. Content above a profile’s parental control rating asked for the PIN before playback, with a state for a wrong PIN.

Keeping viewers watching at the end of an episode

Some services wanted to offer the next video before the current one ended. For serial content I specified a next up card that autoplays the next episode, with autoplay on or off and a large and a small size, triggered by a cue in the stream metadata or a set time before the end. Where nothing was queued after the current video, a recommended next card offered related VOD. Users could cancel autoplay and still reach the next episode from the end of playback.

Where the stream metadata marked the intro, a skip intro button appeared and faded out after it. I flagged the end of playback in a minimised player as needing exploration and testing.

02Player

Breaking the player into components and states

The same controls had to work in all three ways into playback, on phones and tablets in both orientations. I specified the player as an organism of components, each with its own page of states: the top bar for closing, casting and minimising, the quick controls for play, pause and 15-second skips, the scrub bar, volume, the metadata box and the next cards. On-video controls showed on load, faded out and toggled on tap. Volume, audio and subtitles, full screen and the metadata sat below the video and stayed visible, with volume behind an icon on small screens.

The player’s states came in five blocks: VOD, a live channel, a live stream, dynamic ads, and no video. The full-screen player used the same five with on-video controls only. Audio and subtitle choices were saved to the profile and followed the user across sessions and devices, and volume was saved to the device. A product could rely on hardware volume alone and drop the on-screen control.

Covering every state where a video cannot play

A tap on a tile could lead to a video the user was not allowed, or not yet able, to watch. I specified eight no video states for the player and the full-screen player, each on large tablets, on tablets and phones in landscape, and on phones: loading, needs an account (L1), needs a subscription (L2), region locked, a generic error, VOD coming soon, live soon, and live ended with a way to catch up. I carried the user levels of Auth v2 into the player through the two unentitled states, each with a call to action, join to watch or get a pass, into sign-up or purchase.

03Casting

Casting to the TV with Chromecast and AirPlay

The player had to hand playback to a TV through Chromecast and AirPlay, each with its own platform rules. For Chromecast I wrote two sender journeys, one where casting was off when playback started and one where it was already on and the stream went straight to the receiver. Each sender step named the receiver state it caused, from loading to paused, seeking and idle. The receiver states covered touch receivers too, which toggled controls on tap and hid them during playback and seeking.

The Chromecast journeys followed Google’s Cast UX guidelines and the platform’s native Chromecast APIs. For AirPlay I used Apple’s native components and guidelines, and the top bar showed which cast options were available or active.

Sources

• Watch v2 spec ↗Axure, March 2020Get password →