The original address: engineering.atspotify.com/2021/04/07/…

Original author:

Release date: April 7, 2021

Over the past few years, we have been working to modernize the Spotify client by creating a single desktop UI for desktop applications and web players.

We couldn’t build everything we wanted for our users with the old Settings, so we decided to do something about it.

In the beginning, there were two clients

At the end of 2018, our team is the owner of the recently established Web Player and Spotify desktop client. The desktop is our rich, full-featured experience, while the Web player is a lighter, simpler experience.

Because the Web player was implemented with the modern React application architecture, we were able to get new engineers to add to the web player code. But these engineers have trouble using desktop clients, which use a very diverse set of networking technologies (thank you, Conway’s Law). Because we had to implement many features twice, at different levels of complexity, while handling context switches, we didn’t roll out new features as quickly as we wanted.

In addition, there are accessibility issues among our customers that need to be addressed. We found that making our web player accessible would be a difficult but achievable challenge. Making desktop applications accessible, by contrast, is almost impossible.

We had many discussions about how to solve these problems. The team decided that blending the client into a single code base and user experience was the best approach. We looked at several approaches and did technology peak testing of many ideas — component sharing, feature sharing — always trying to find the right balance between solving our technical debt problem and continuing to improve our user experience.

We knew we were in the middle of a long-term project, so our biggest priority was to reduce delivery risk and avoid locking ourselves in a big bang rewrite. We settled on a bold solution: focus on iterating over the existing Web player code base until we reached a desktop-level feature set. Since our web player is continuously deployed, we can ship and test every change we make to achieve our end goal with real users.

Of course, there are risks. The desktop version has far more users than the online version, and Spotify’s desktop client is home to most of Spotify’s “power users.” We know we will have a lot of work to do to bring our web player up to the exacting standards of these power users.

Now, in early 2021, we have created a maintainable code base for two of our customers with the high standards of accessibility and speed of development we want.

Let’s talk in more detail about how we turn ideas into reality.

One user interface, multiple containers

The Spotify desktop client is a native Application for Windows and Mac that uses Chromium Embedded Framework (CEF) to display a web-based user interface. This is still true today, but on previous versions of the desktop, each “page” in the client ran as a separate “application” in its own IFrame. This architecture is designed to promote autonomy, allowing multiple teams — and potential partners — to own the development and maintenance of functionality. Eventually, however, one team became responsible for the user interface of the entire application.

Previous desktop client architecture (simplified). Each page in the application will be sandboxed in an IFrame and built differently. The UI will access the back end through the local container.

Previous versions of the desktop client had many advantages, including Spotify’s initial “killer app”, where listeners could start playing with a click. It also has a comprehensive set of features that we know Spotify listeners value. But, at the same time, this architecture has created serious friction for developers.

However, the web player code base is considered a more solid foundation. It allows us to develop new features quickly. It was developed with the Web in mind, which means it is small, performs well, and runs in a variety of browsers. The client is delivered continuously, allowing changes to reach the user almost immediately. So we decided to use Web Player as the starting point for a single user experience shared between web player and desktop. One of the main challenges we encountered was that this approach required us to deliver and run the Web Player user interface with the desktop container.

The Web player is also closely linked to our web servers, and all data and authentication depend on them. The web player uses a player system that is not compatible with the desktop. Authentication works differently – we need to support our network OAuth login on the web player and our local login on the desktop. The Desktop also needs features that its users expect, such as downloads and offline playback, that Web Player does not support.

This concept of running the same user interface on two similar but different infrastructures underpins the architecture we develop. To keep the user interface unpredictable, we built a TypeScript platform API that abstracts different data sources and different play stacks and provides useful information to the user interface about what functions are available. We’ve also rewritten the entire client in TypeScript along the way, because we’re rebuilding the experience bit by bit.

While some work was done outside of our team to make certain types of data available over the web, we focused on decoupling the Web player not only from the web server, but also from any hard-coded dependencies to run in a normal browser.

The final architecture looks like a layer of platform APIS that exposes the underlying Spotify ecosystem to customers, with a React based user interface and platform apis exposed via React Hooks. As a result, the new user interface can run on the network as well as in our desktop container and never know, or care, whether the data comes from our C++ stack or our network infrastructure.

New architecture for web player (left) and desktop (right) clients. The UI is built as a React application that goes to the back end via our GraphQL and Web API services and, in some cases, through native desktop apis due to its improved performance and capabilities.

With this architecture, the speed of the team began to increase rapidly. We added downloads, offline mode, local files, lyrics, “playing” queues, and advanced features such as sorting and filtering of playlists and albums. In just over a year, the new shared user interface includes all the features of the original desktop client and is actually more advanced in some ways, including features previously only seen on mobile clients.

Contrast between old and new: The web player’s user interface has come a long way since the project began.

Solve organizational challenges

From the moment we decided on our product strategy for the new desktop client, we set out to solve the engineering challenge — but also the organizational challenge: How could we actually achieve this goal in a reasonable amount of time, without giving up the day-to-day “business as usual” work that needed to continue?

We also have to address a huge information gap. What features from existing desktop applications must be implemented in the new application? What should a new customer look like? Almost immediately, the design and product insight team began investigating how our users were using our software, so we could develop a roadmap to be able to ship it.

At the same time, we created a small “virtual team” of engineers from several teams to start initial engineering experiments and answer some basic questions. Is the desired solution possible? How much work does it actually take? The virtual team’s first task was to get the Web player to run inside the desktop container, as it does now. They will address playback and authentication issues, explore how the user interface is tied to the container, and develop an engineering blueprint for the rest of the project. The team enlisted the help of other teams within Spotify to create a single user interface that could work across multiple platforms with different functions — TV, for example. As a result of previous efforts to merge customers, the fact that the two codebase are co-located in the same singleton is key to facilitating this task.

Three months later, the team’s work came to a successful conclusion. We have established our roadmap and priorities, and we have a clear idea of what we want to do in the year ahead. It takes everyone in our broader team to pull out all the stops and do constant testing and analysis to make sure we’re on the right path.

In fact, this project was made possible because our engineering, design, and product management teams were committed to envisioning a product that engineers could iterate on quickly and that fully supported Spotify’s vision. We had to iterate longer than we would have liked before shipping to users, but the speed with which the team was able to implement these features in the new shared user interface gave everyone confidence that we were moving in the right direction.

Evaluate success

When we started this project, we had four main goals: to make our code reusable, unify our user experience and visual design, increase speed for faster delivery, and do it all while meeting the needs of desktop and Web player users. How are we doing on these metrics as the project results come in?

1. Reuse

Reusing the same code across multiple clients (that is, the Web player and desktop) allows us to write code once and reap the benefits in multiple places. When we need to implement a design change, it is more efficient to make the change in one place and propagate it to all receiving endpoints. We hope to expand our reuse and share our platform apis with more customers in the future.

2. The unity

User experience and visual design is an important and time-consuming area of application improvement. Therefore, having a set of components that serve multiple customers ensures that we can implement the design more thoroughly, thus improving the user experience.

Crucially, we’ve been able to achieve a degree of unification with the rest of the Spotify ecosystem, moving our customers over to Spotify’s shared design language. The result is a more consistent experience as users switch between mobile and desktop, as well as a more modern, immersive, convenient and user-oriented experience for everyone.

Speed of 3.

An important rationale for this project was that a modern code base with a single, easy-to-understand architecture would speed us up as engineers. While we need more time to finally demonstrate long-term success, the team has accomplished a significant amount of functionality since the project began, which is a positive indicator. Speed, however, is just a result — a result of a well-directed engineer working with a healthy code base. We measure code health in terms of test coverage, maintainability, readability, and ease of removal. The architecture we’ve chosen has unexpected benefits in making UI coding easier and easier for developers to understand, so we expect this platform to be a solid foundation for us for years to come.

4. Satisfaction. Meet the needs of desktop and web player users

The new experience was developed with Spotify users in mind — both existing desktop power users, as well as new users from mobile apps or the completely unfamiliar Spotify ecosystem. Since the beginning, we have been evaluating and testing our progress at every step to ensure that we are delivering an experience that meets the needs of our users. Extensive user research and ongoing testing over the past year have given us an idea of the direction we should take. We’ve made the experience more accessible than ever before, so everyone can enjoy using the app.

We are closely monitoring the feedback we receive and constantly shaping the application to meet the needs of our users. The new architecture allows us to move faster, and users can expect the client to evolve faster than ever before.

What does all this mean to you as a user?

As a music listener using the Spotify desktop client or web player, we want this to feel like a brand new experience, but all the features you use and love are still there. You’ll notice some new features that you may have already seen on Spotify on mobile, also for the first time.

Over time, you’ll start to notice brand new features popping up more often, making your music and podcasting experience even better. The launch of the new desktop is not the end for us. This is just a new beginning, because this app is Spotify’s starting point.

Is this what you want? Join us!

Want to join our team and build Spotify’s future? Please go to our job board and see if anything appeals to you. We just announced our “Work anytime, Anywhere” policy, which allows employees to choose to work full-time from home, full-time in the office, or a combination of both.

Hats off to all those who contributed to this project, especially Felix Bruce, Peter Johansen, Alberto Nunies-Acosta, Guido Cathers, Trigway Gilfasen, Craig Spence, Lucas Lencinas and Emma Bostian.

Translation via www.DeepL.com/Translator (free version)