- Spotify web player on mobile how to#
- Spotify web player on mobile install#
- Spotify web player on mobile code#
- Spotify web player on mobile tv#
- Spotify web player on mobile download#
The new Web Player is in line with the overall Spotify look and feel and is built on HTML5 standards. The simpler and faster web player outperformed the old web player in all key metrics. Once we felt comfortable, we released it to a small percentage of users side-by-side with the existing web player, and checked the performance amongst them closely. During the following months, we carried out extensive user testing and improved the prototype based on the gathered feedback. We built a Minimum Viable Product (MVP) in a few weeks using our new infrastructure based on Spotify’s Web API. After getting the results we decided on the bare minimum feature set that we would feel comfortable with releasing and that our users would enjoy. For some users we removed certain features and we measured their impact in user engagement. We decided not to repeat the mistakes of the past, so before deciding the feature set that the new web player should have, we ran A/B tests on the existing web player. The birth of a new Web Player The new web player It was very slow to iterate upon and experiment, especially when it came to making changes across multiple views like updating the visual style.The web player was built by multiple teams with over 40 developers but now would be maintained by a dedicated team of 5 developers.
Spotify web player on mobile code#
Giving every team an isolated environment to run their code also resulted in them choosing different client-side stacks to build their views. The web player was based on lots of libraries and frameworks that were quite outdated.The system to deliver the code for the views, that worked in isolation from each other, wasn’t used by the desktop application anymore and it was too complex for the web player use case.There were a few key points behind the decision to rewrite the new web player from scratch versus improving the existing one: Usually as a company we try to improve existing systems iteratively instead of completely replacing systems with new ones.
Spotify web player on mobile tv#
In parallel, we started working on a prototype following a similar architecture to the TV application.Īfter considering the two approaches, we decided on the latter. We researched the feasibility of upgrading the web player, rewriting view by view. It represented a good example of a light client being built by a single team leveraging existing libraries at Spotify. This application is a web-based Single Page Application, and uses the Spotify Web API that combines the access to lots micro services to create a unified interface to manipulate Spotify data. We found inspiration in the Spotify application for TV and video consoles. We wanted to go back to basics and support a set of core features (eg playback, library management, and search) and work our way from there. We realized that the architecture of isolated views was difficult to maintain and was preventing us from building a better product. In the summer of 2016 we decided to improve the web player.
Spotify web player on mobile how to#
With the rise of smartphones, we learned how to strive for removing clutter, properly A/B test features and understand better what was really needed to deliver a good user experience. Over the years, we got better at prioritizing a core set of features.
Spotify web player on mobile download#
The web player, on the other hand, had to download many resources every time the user navigated between views, which resulted in long load times, which impacted user experience. Having iframes for every feature and having that feature load their own JS and CSS might have worked well for the desktop application, which the user downloads bundled with all the resources that it needs. The architecture of the web player was ideal for consistency between platforms, and fit how the company was organized in feature teams. Thus, the team working on the Playlist view would implement a new feature, and make it available on the desktop application and the web player, without having to care about the underlying infrastructure. In addition, the code for the views was identical on both desktop and web player. The views were isolated from each other using iframes, and this allowed the teams to iterate on and release them without interfering with the rest of the application. The architecture of the web player followed the same approach as the desktop application.
Spotify web player on mobile install#
It made it possible for users to play music from Spotify as quickly as possible, without needing to download and install any application. Spotify’s web player was released in 2012 and complemented the experience on desktop devices. A web app within the desktop application showing a third party integration – from Felipe Ribeiro’s talk about Javascript Spotify at JSConf Iceland 2016
0 kommentar(er)
