Concorder. The Sonos Queue Manager
I’m going to start this post with an assumption: everybody likes music. I assume this, because I don’t think I’ve ever met anyone who didn’t like music. And, if someone likes music, it’s also fair to assume that they think they have the best musical taste — and yes, I’m including myself in this.
At ELSE, we all like music and therefore, every single one of us has the best musical taste. We have a Sonos system and every now and again, you get the odd argument about the music that is playing. I mean, no one ever got hurt or anything (or at least we don’t talk about that anymore), but to me, seeing and hearing people complain about the music that was playing was… a little bit annoying.
So, I came up with an idea. What if we could have a system that could democratise the Sonos queue at the studio? A system that knew who was present and added songs to the queue based on each of those persons’ preferences. A system that would balance said queue, so that everyone would have an approximately equal number of songs they liked on it.
Using ELSE’s R&D time allocation, I set off to create such system. This is the story of Concorder.
Developing the idea
At the beginning of 2018, I needed to come up with an idea to use my R&D time — at ELSE we got a full R&D day every two weeks as part of our 4-day week initiative. I wanted to do something that was hacky. Something that would allow me to do a bit of coding as well as design and perhaps, even have some kind of physical hardware component to it. The idea of Concorder was perfect. It would allow me to do all of these things, and it would significantly reduce ELSE’s hospital bills (just kidding — no one ever got hurt… seriously).
What would such a system look like though? I knew I would need a controller: a brain to connect the different parts of the system and make sure they talked nicely to each other. The controller would need to engage with the Sonos system in our studio and be able to manage its queue, reading from it, adding and removing songs, etc. The controller would also need to know who was in the studio and what were those people’s musical preferences.
The song pool
I decided that the best way to determine people’s preferences was to have an individual pool of songs for each user. That pool would be curated by each person and they would be able to add their favourite songs to it. The controller would then pick songs from these individual pools to add to the queue, based on how many people were present, and how long was available until the ‘end of the day’.
The web interface
In order for each user to be able to manage their pool, a web interface would be needed. On the web interface, users would be able to, not only add and remove songs to their pool, but also see which of their songs were up next in the queue.
These operations would be done via the Spotify Web API, which allows users to login with their Spotify account and have access to their playlists and library.
Knock, knock. Who’s there?
A few different options existed for determining who’s in the studio, ranging from the use of bluetooth beacons, to facial recognition. In the end, and in the spirit of proving a concept, I decided to simply add an on/off switch to the web interface, which would allow users to declare their presence manually.
The controller
To build the controller I decided to use PHP. I’ve used PHP a number of times for different projects and I knew that with all the available support out there, I would be able to find libraries that would allow me to put this thing together.
A.P. Why?
To get this working, I would need to use two APIs: Spotify’s Web API and the Sonos API. Luckily for me, I found two great PHP libraries for dealing with them: Craig Duncan’s Sonos library and Jonathan Wilsson’s PHP wrapper for Spotify’s API. By using these, I was able to easily access the data I needed, without having to worry about parsing API responses, thus significantly cutting down the amount of code I had to write.
Defining the user experience
Once I had decided on all of the above things, I set off to put it together. The first step was to decide what the user experience would be like. For this, I enlisted Greg Cavanagh, Senior Experience Architect at ELSE and a generally nice guy. Talking to Greg was extremely helpful as, up until this point, I’d been working in isolation. Having someone to bounce ideas with was extremely valuable.
Having decided on what the experience would be like, it was time to create the back-end. The first step was creating the web interface, including the pool and all the methods to allow users to manage it. This also meant integrating the Spotify Web API.
Determining the algorithm for adding and removing songs from the pool was the next step. As a reminder, the goal was that at anytime, all online users would have an equal number of songs in the Sonos queue. This wasn’t too complicated but it took a bit of trial and error.
The final step was being able to interact with Sonos, and add the algorithmically generated set of songs to the queue.
At this point, I had a functioning system. I was able to log into it with my Spotify account, add/remove songs to my personal pool, set myself as ‘online’ and watch my songs being added to the queue. But, it was all black text on white background. It was time to make it look pretty!
Branding & UI
The first thing I needed was a name. I asked around for suggestions and amongst all the good ones I got, Greg (again?!) suggested ‘Concord’. Concord is defined as a state of agreement or harmony between two or more people, but also as a simultaneous occurrence of two or more musical tones that produces an impression of agreeableness or resolution on a listener. “That’s it!”, I thought; “perfect!”. It just needed to be a bit more product-y. And so, Concord, became Concorder.
I proceeded to do a quick branding exercise, creating a simple logo and went straight into designing the UI for the web interface.
Building the UI
Next task: take the designs and turn it into HTML/CSS/JavaScript pages. Easy. Done. Next!
Front + Back = 🤯
Now it was time to put everything together. This required a bit of tweaking of the back-end, due to the slightly chaotic nature of my coding process. But, I got there in the end.
All that was left to do now (well, apart from fixing countless bugs), was to add it to the production environment, fix another million bug that weren’t there in my local development environment and get people to use it.
Conclusion
On-and-off, it was about a year of work. In total, 320 hours (that’s 40 days or 8 weeks), 5,335 lines of code and lots of fun.
By the time I moved from ELSE to Capital One, Concorder had been in use at the ELSE studio for a few months and although a bit buggy sometimes, it worked pretty well. Some people were actually using it daily and I was very happy with the final result.
No doubt, there were improvements to be made and many potential new features to be added but for now, this is the story.
