ProSiebenSat.1

The brief

Be the central service provider for the group's HbbTV applications — and do it in a way that does not multiply by seven every time a channel asks for something.

The constraint

Seven distinct channel brands, each with its own look, its own editorial team and its own schedule, sharing one platform and one release train. The failure mode here is the opposite of a multi-runtime project: not four codebases drifting apart, but one codebase slowly acquiring seven exceptions.

Below is what we actually built on it. Each of these is a different problem, and on a television none of them is the problem it would be in a browser.

A catalogue you navigate with five keys

A web catalogue can lean on a search box and a mouse. An HbbTV catalogue has neither. Everything a viewer will ever find has to be reachable through up, down, left, right and OK — so the browse structure is not a fallback for search, it is the product. Rows, depth and ordering are editorial decisions with a navigation cost attached, and every extra level is one more press between a viewer and a programme.

The second problem is memory. A grid of thirty posters is thirty decoded bitmaps, and a television from 2016 will not hold them. Tiles are loaded as they approach the viewport and released as they leave it, which means the scroll position, the focus model and the image lifecycle are one mechanism rather than three — get that wrong and the set stutters exactly when the viewer moves fastest.

Then continue-watching, which sounds trivial and is not: playback position has to survive an app that can be killed at any moment by a channel change, and storage on a terminal is small, shared and occasionally wiped by the device.

Making a playlist feel like a channel

A themed channel is a curated sequence of on-demand items presented as though it were linear television. The editorial part is a playlist. The engineering part is that television viewers have thirty years of expectations about what a channel does, and a visible gap between two items breaks every one of them.

So the next item is prepared while the current one is still playing, within a memory budget that does not allow two decoders to be comfortable at once, and the handover happens without a black frame. The app also has to answer “what is on now” and “what is next” for a schedule that exists only inside the playlist — which is an EPG problem wearing different clothes.

A week of schedule, on a device with no room for it

An EPG is a two-dimensional grid — channels down, time across — navigated with a four-way pad. That is a solved interaction on a desktop and an unsolved one on a remote, because the viewer's mental model is “later” and “another channel”, not “right” and “down”.

Underneath it is a data problem. A week of programme data across several channels is more than a terminal will hold, so the grid is windowed: fetched in time slices around where the viewer is looking, discarded behind them, and prefetched in the direction they are moving. Now-and-next has to stay correct without polling the backend every few seconds, which means the client has to reason about time rather than ask about it.

Every entry arrives in the same ninety seconds

A competition attached to a live format has a traffic profile unlike anything else on the web: nothing, nothing, nothing, then the host says the sentence and the entries all arrive at once. The interesting engineering is not the form; it is that the load is a spike whose timing is known in advance and whose magnitude is not.

On the client side the design constraint is text entry. Typing an email address with a remote control is genuinely unpleasant, so every field that can be removed is removed, and the ones that remain are chosen to be enterable with a number pad where possible.

And there is a legal surface most web forms do not have: participation terms, age checks and data protection, on a device the whole household shares.

Animated Switch-In — an ad format that must not damage the ad

Switch-In is the format that makes an HbbTV application pay for itself. During a commercial, an animated element appears over the broadcast picture and invites the viewer to press a key and enter the advertiser's application.

The whole difficulty is in the word “over”. The spot is still running underneath, it was paid for at broadcast rates, and nothing may cover it, delay it or stutter it. The overlay has to be signalled, loaded and animating inside the break, and it has to animate smoothly on a GPU that is a decade behind the phone in the viewer's hand.

Beneath that sits the part advertisers actually buy: impressions and interactions counted in a way that survives an audit, because this is inventory that is sold.

Landing pages that ship to a broadcast schedule

Campaign screens for a running show — The Voice of Germany, Germany's Next Topmodel — are the one kind of television application with a deadline nobody can move. The air date is the air date. Content changes with each episode, and the traffic arrives in the minutes after an on-air mention.

That turns a design question into an operational one: the editorial team has to be able to change the screen between episodes without a release, which is the whole argument for a headless CMS sitting behind the app rather than a build pipeline.

One platform, seven brands

A Drupal headless content management framework with React frontends for ProSieben, Sat.1, Kabel Eins, Puls 4 and ATV, among others. VAST advertising inside the HbbTV player. Automated daily ingest of formats and clips from the pre-production systems, so nobody retypes a schedule. And an editorial playlist builder, so the schedule is made by the people who know the schedule.

The brand differences live in configuration and design tokens, not in forks. That is the only reason seven brands can share one release train.