Tl;dr; We tried to solve a problem related to interpreted TV-shows with a purely technical perspective and ended up causing modelling debt and confusing ourselves and our users in the process. We had to delete the solution, collaborate with UX and redo the entire feature.

The problem at hand

NRK is producing content with Norwegian sign language (tegnspråktolk) and audio description (synstolk). These are versions of the original with their own mediafiles, to be more specific we will call them accessibility versions. They differ only in the videotrack (the sign language interpreter) and audio-track for audio descriptions (a narrator that explains what is going on in the visuals). The original is called the “MASTER” version, sign language is TOLK (“tegnspråktolk”) and later SYNS (“synstolk”) was added as a version for audio-description.

What’s On master data is used for streaming at NRK TV and for traditional broadcast. The master data for all our programs – both for streaming and traditional broadcast – is in What’s On , and it is imported to NRK TVs system to be published online.

A simplified model of how the content is stored in What’s On. What’s On is our scheduling, planning and content lifecycle software for both linear broadcast such as NRK1, NRK 2, NRK Super and our streaming service NRK TV.

	Product ID	(Accessibility) Version
Original	MUHU21005520	MASTER
Audio description	MUHU21005520	SYNS
Sign language	MUHU21005520	TOLK

In the beginning NRK TV ignored the versions, so the users could not play the accessibility versions. This table illustrates NRK TV’s model of the data.

	NRK TV ID
Original	MUHU21005520
Audio description	Not available
Sign language	Not available

At some point it was decided that the interpreted content should be made available in NRK TV. This was before I joined so I can not really tell the story. To me it is all legends and tales, but in my mind something along these lines happened: Someone wanted the content published. Some other person did not want to spend too much effort on this feature. Then, a third person figured out a clever hack! If they appended the version to the ID in the backend-systems for NRK TV then the program would – from NRK TVs perspective – be seen as yet another stand-alone program. No changes to the apps were necessary, and a lot of work saved.

The hack – import to NRK TV but create new programs of the accessibility versions by concatenating the PRODUCT ID and VERSION to a new ID. Modelling wise this is shoehorning a new concept (accessibility versions) into an existing model.

	NRK TV ID
Original	MUHU21005520
Audio description	MUHU21005520SYNS
Sign language	MUHU21005520TOLK

Now, only one issue remained – if it was a separate program, how could it be presented to the user? Hacks open up the door for more hacks: we can use the categories. Let us say in addition to movies, drama, humor and entertainment we could have a “sign language interpreted”-category, and a “audio descriptive category” – then the discoverability issue was also addressed.

Shows episodes scattered all around with no connection to the series they belong to. — Episodes with accessability versions lost connections to their series and was presented as stand-alone programs in an accessability category.

This is what happened, and this is what stayed in production for many years. Notice that series, such as Heimebane, are presented with episodes as standalone programs. Now, close your eyes and imagine browsing this with a screen reader. It is possible – but it is really cumbersome. And as more content is added, the experience further degrades.

The broken solution to the episode-issue

This solution had numerous issues. The main issue was that the programs now had no relations to their original series. Only the MASTER versions were episodes in the series. The accessibility versions of the episodes were presented as stand-alone programs in their category, and the users had to navigate to the correct episode among a sea of content. Sadly and ironically the problem grew worse over time, as we added more sign interpreted content. A few scattered episodes without a unifying series was bad enough, but a variety of episodes from a variety of missing series became a nightmare of navigation

The feature that was requested was for these series to have a connection to their original series. This was talked about as “sign language series”.

It did seem – at the time – as making a separate series for these was a fairly straightforward solution to the problem. Of course the interpreted episodes deserve their own series!

An attempt had been made – or at least a discussion of an attempt – at solving this issue of series in the legacy API. Alas, the SQL queries had grown complex – to the point where no developer dared to take on modifying the queries to work with SYNS and TOLK as series and episodes.

However, we had just introduced a new set of services that made these changes easier for us. This allowed us to transform the interpreted programs to look like they belonged to a new series, with API contracts that looked similar to the old ones. Our eagerness to demonstrate the power of this new system over the legacy one probably helped lure us a into choosing this solution. Trapped by our own vanity, we argued that we could fix the issue with no need for anything else but a few weeks of backend-development. No need for front-end developers or concept designers. The API developers would single-handedly save the day! We could simply append __SYNS__ and __TOLK__ to series-IDs, following the same pattern as had been done for the episodes, and voilà.

As said, as done. A few weeks – or more honestly, likely a couple of months – later, we could turn it on in production.

Crumbling under its own weight

Now, this new version had even more problems than the old one. In other contexts, this concept did not work properly. For search, it made really little sense and it was hard to make it work properly. A user would get different search results for the different versions. They already had for episodes, but the new series would not show up in the search properly. Also, for logged in users we got some problems. The personalization services struggled to understand how to handle these new series. And the recommendation systems struggled too. It turned out, the issues were leaking into all other contexts. We could only turn this feature on for non-logged in users, and even for those the issues of search and recommendation still existed. And while the rest of the organization made efforts to make more people log in, this feature made them log out again. The solution was clearly not very impressive. It was technically sound – it demonstrated the power of the new components we had built over the complex SQL queries of the legacy system – but it was functionally broken. How could something we built so elegantly fail so miserably in practice?

Re-visiting the issue from another perspective

We started over, this time with help from UX. We had some work done on a conceptual level on how this would work for users. This perspective turned out completely different visualizations of the problem at hand.

Initial sketches of a different perspective on the problem

When I got my brain around the issue from another perspective, I saw quite clearly why our solution was wrong. We had tried to address it in the catalogue domain, to present the series with a new ID – as something separate in our content catalogue from the main series. Our excuse for this modelling blunder was that the interpreted episodes already had a separate ID and was a separate entity. Therefore, making series and seasons a separate entity was simply building on that solution.

Once we realized the modeling blunder, and that only in the player should there be a different entity, a different manifest to play the content – the conceptual perspectives and the technical perspectives aligned.

By moving the solution from the series (green circle) to the playback domain («blue circle») the solution made a lot more sense.

Fixing it – Import to NRK TV to the same program, but let the player context have different versions the user can choose between in the player.

	In NRK TV except player	In NRK TV’s player
Original	MUHU21005520	MUHU21005520
Audio description	MUHU21005520	MUHU21005520SYNS
Sign language	MUHU21005520	MUHU21005520TOLK

The front page only knows of one series for Skam

The seriespage knows that in the playback domain, there are different versions. The player can navigate between these versions.

What did we learn?

Solving a problem with only one perspective – and only one proposed solution – is risky business. Challenging your views by opening up to other perspectives will shed light on your models’ strengths and weaknesses. A dangerous trap to walk into is when the discussions of the problem become very technical – using a language that alienates the people who have a different perspective.

On architecture, sixth post: Technically correct