Sounds Web Next: a “persistent player” prototype for BBC Sounds
In order to listen to any audio content on the BBC Sounds website, you need to be on the so called “play” (or “playback”) page.
If you navigate away from it you’ll interrupt the stream.
The interruption happens because every time you click a link, a new page is requested to the server, meaning there is no way to preserve the streaming on the device across requests, because the browser is performing a full page re-load.
During last BBC Hack Week 2020 edition, myself, Garth Connell and David Todd have been busy hacking a prototype of Sounds as a Single Page App, introducing a persistent player that remains in page and keeps streaming audio while browsing around. You may be familiar with this concept if you use other apps like Spotify, Deezer, Apple Music, Soundcloud, etc. From a product point of view, this is a profound transformation that welcome our audience desire to keep listening without interruptions.
The hack week was an opportunity to build such a proof of concept for Sounds and for us an opportunity to learn and play with new technologies.
Hack week and innovation a the BBC
The Innovation Week or Hack Week at the BBC is a hackathon that runs once a year in December for an entire week, during which everyone is encouraged to participate. Well 5 days to be precise.
The 2021 edition just ended and I’ve worked on the prototype again from a different perspective this time, but I’ll leave the details perhaps for another blog post.
The event starts with a pitching session a week early where people present their ideas with the intent of attracting members to join the crew. You don’t have to have your own project necessarily, you can simply listen and join the hack that entice you the most.
Monday to Thursday busy hacking and having fun with other people, not necessarily from your same team. On Thursday it’s time to wrap up your hack and submit your video presentation before the cutoff time. To be honest, even hours after the deadline you’ll still get a chance to upload your work if you beg hard enough, but don’t tell anyone I wrote that. It just means that you’ll make the organisers pull an all-nighter to edit the final video collection for the day after. But it will be worth it.
Friday is finally demo time, where the hard work of the previous days is showcased in a few-minutes video and the best of people’s craft and cinematic skills comes to life. Believe me when I tell you that I’ve seen presentations that deserved an award regardless of what the hack was about. Various filmmaking techniques are used such as stop motion, acting, sounds effect, storytelling, the works. Simply stunning. Once the premiere comes to an end, it’s time to announce the winners for each category while comments of appreciation and virtual claps flow by — cause needless to say the whole event runs online.
The main goal is to have fun, learn something new, possibly working on stuff outside your comfort zone or area of proficiency, meet new colleagues, create something interesting, possibly cool enough to be used in production.
Sounds Web Next demo
Why Sounds Web Next? Because the hack is about prototyping the next generation of Sounds on the web, plus it’s built with Next.js which makes the name even more fitting.
Ok, enough presentations. Before deep diving within any further details or the nitty gritty of the technical implementation, I’d like to show you the video that participated at the 2020 edition of the BBC Hack Week.
The prototype
The proof of concept has been built in React using Next.js, a React framework that improves the development experience by providing out of the box all the much needed features that most developers desire, such as: fast-refresh, “transpilation”, bundling, TypeScript integration, etc. Moreover, it optimises the production artifacts with very low effort.
It sounds all great and amazing, but usually when it comes to adopt a framework that does the world for you, means that you have to compromise on something, remaining with little to no control over customisation. Not with Next so far, which is the reason why we decided to adopt it with our Sounds Web Next prototype.
The alternative was to build everything from scratch, which it has been done to a certain extent by the way. As a “builder” I’ll admit, making everything from scratch is thrilling. You get hands on with every aspect of the app, business logic along with configs and production pipeline. You learn a lot by touching on every aspects: Webpack, Babel, the whole family. The drawback of doing so is the added complexity of having to maintain, patch and upgrade all these moving parts. Needless to say, implementing all this features isn’t “zero config” as advertised. As a production engineer, you have to abstract and automate the repeatable tasks to a certain degree so that the focus and the effort can shift towards the app you are trying to build.
Just to be clear, there is no morale or bias towards adopting one or another approach in what I just wrote in the previous paragraph. Things can be different for you. It is always a case-by-case situation and a matter of balancing out the options based on your resources and requirements. Also, this is not an endorsement of Next.js. Draw your conclusions and follow me to the next section.
Implementation
At the time of building the app, Next.js was on version 10 and React on version 17. This version of Next came just about at the right time, main killer features for us: the Image component with built-in lazy loading mechanism and support for the core Web Vitals. The prototype has been later upgraded respectively to version 11 and currently 12, bringing in the new Script component, conformance, Webpack 5 et all.
Main objective of the prototype, integrate our Standard Media Player (SMP) with Next.js and React, and make it play whatever audio content we click in the app — whether live or on-demand — without interruption. SMP has been treated as a third-party library and included in page using the Script component. The way the SMP works is by adding elements on the DOM at runtime, and we had to wrap this in a functional React component that uses side effects to do so.
The whole state orchestration has been managed using the usual suspect: Redux. It’s stable and mature and we already use it in production, which made us build the prototype quicker as there was zero learning curve. With Redux we stored and managed the ID and metadata of the selected audio content and its playing status, so that we could update the different UI components and load the content in the SMP playlist.
We initially focused on the live radio streams and the seamless switching across stations. We managed to do so with client-side routing using the Link component which is the key ingredient for single-page apps and to enable the persistent player. While the impression given to the user is a page change, what it really happens is a client-side re-rendering of the UI within the same HTML page requested the very first time. Later in the week we had enough time to add on-demand content too.
Any UX treatment has been kept to the minimum, even using random icons that were on-hand at the moment (and that is visible in the demo) but we managed to integrate the UI components from our existing Sounds library used in production, place them in page and populate them with real data coming from our very own RMS backend API.
The final result, a web application that behave like an app and allow you to play BBC content without interrupting the audio stream. Hope you enjoyed what you’ve seen and read so far. If you are interested in working with us on projects like BBC Sounds, keep an eye on https://careers.bbc.co.uk.
Thanks for reading.
