Spotify_Logo_RGB_Black.png
 

SPOTIFY SHOULD MAKE THIS

SHARED MUSIC INTERESTS

 
 

THE PROBLEM

People have such wildly different tastes in music; from person to person but also for any one given person. Apps such as Spotify allows users to curate and fine tune playlists but it can be challenging to find similarities across multiple people. Current solutions and workarounds to this problem include listening to something more generic such as the radio or pre-made playlists.

THE VISION

Develop an easy way for users to find and play music in the car that would make everyone happy. Increase satisfaction in what the music that gets listened to. Decrease the time it takes to find something to listen to.


DISCOVERY

 

The idea was originally meant to find overlapping taste in videos.

 

To better understand how other people find solutions to this problem we surveyed 30 people through Amazon Mechanical Turk. We started with a few screener questions to find people that would be potential users for this feature. This included collecting data in regards to age, gender, what the listen to in the car (we would have thrown out anyone that responded with "nothing"; we've kept data that responded with anything else), and if/how often there's someone else in the car with them.

In order to measure the efficacy of the proposal, we first established a baseline to serve as a benchmark for task completion time and level of satisfaction. (Note: For the sake of time and effort we've opted to ask users how long they think it takes rather than directly timing users.)

 

We asked users: "How long would you say it takes to find music everyone in the car agrees to listen to."

1 is very quick; 5 is very long.

We calculated the confidence interval with a 0.05 level of significance. We can be 95% confident that the population rating on this question is between 1.742 to 2.391. (TLDR: people felt picking music was relatively quick.)

We asked users: "How satisfied are you with the music that gets selected as a group in the car?"

1 is not at all satisfied; 5 is very satisfied.

We calculated the confidence interval with a 0.05 level of significance. We can be 95% confident that the population rating on this question is between 3.171 to 3.962. (TLDR: people generally pretty satisfied.)
 

We asked people how they decide what to listen to in the car with others -- there were a few re-occuring themes. Here are a few verbatim quotes.

“Based on time of day and mood.”
”I leave it up to them.”
”Take turns.”

HOW IT'LL (POSSIBLY) WORK

We'd first find songs that are exact matches for songs, artists, or albums. Next we’d expand the shared taste by looking into genre or similar songs. And finally we’d incorporate any additional information such as mood (a common dictator in terms of selecting what to listen to) by considering attributes such as time of day or weather.

 
 

DESIGN

We put together 2 different versions of what this feature would potentially look like. 

 
 

Version 1

This version features a banner across the top of the screen that informs users that they can play music that they, Tom, and Julie would potentially enjoy.

We asked users what they thought would happen when they pressed the play button. 34 out of 44 users were successful. We calculated the completion rate and concluded that the probability the observed proportion 0.77 comes from a population greater than 0.7 is 85.11%. 

We also asked users how confident they are on their answer on a scale of 1-5 (1 being not at all confident, 5 being extremely confident). We can be 90% confident that the range is from 4.029 - 4.471.

TLDR: We can be fairly certain that at least 70% of users would be able to successfully understand the banner and users are very confident in their understanding of this feature.

 
 
 

Version 2

This version features playlists (similar to what Spotify already has) that would be potentially enjoyed by the user, Tom, and Julie. 

We asked users what they thought would happen when they pressed "Shared Mix 1". 7 out of 10 users were successful. We calculated the completion rate and concluded that the probability the observed proportion 0.7 comes from a population greater than 0.7 is 48.38%.

We also asked users how confident they are on their answer on a scale of 1-5 (1 being not at all confident, 5 being extremely confident). We can be 90% confident that the range is from 3.716 - 4.484. 

TLDR: We aren't at all certain that at least 70% of users would be able to successfully understand "Shared Mix 1" but users are fairly confident in their understanding of the feature.

 

ENGINEERING

Disclaimer: I did not work on this section. Engineering work was conducted by an engineer.

The sample project demonstrates the intended functionality of discovering nearby friends and finding matching music to play. Utilizing the Spotify and geolocation API a user is able to login and see matches of their top artists with their friends.


how information gets populated

Information gets populated in the fields through multiple steps: (1) The user authenticates with the Spotify API to allow artist information to be fetched, (2) authenticated user calls the Spotify API to get account info such as user name and queries top artists for the account, (3) the geolocation API returns coordinates of where the user is located, (4) the backend server checks for other friend user data in memory that has geolocation coordinates within a specific threshold and (5) displays artists that both friends have to allow people to play music they both like.

  1. Authorization

Uses the Spotify authentication API and sets application scope/permissions.

var state = generateRandomString(16);
res.cookie(stateKey, state);

// your application requests authorization
var scope = 'user-top-read user-read-private user-read-email';
res.redirect('https://accounts.spotify.com/authorize?' +
    querystring.stringify({
    response_type: 'code',
    client_id: client_id,
    scope: scope,
    redirect_uri: redirect_uri,
    state: state
   }));

2. Spotify API

Uses the Spotify v1 API to get user information and top artists from https://api.spotify.com/v1/me and https://api.spotify.com/v1/me/top/artists.

$.ajax({
    url: 'https://api.spotify.com/v1/me',
    headers: {
        'Authorization': 'Bearer ' + access_token
    },
    success: function(response) {
    userObject.id = response.id;
    userProfilePlaceholder.innerHTML = userProfileTemplate(response);
}});

$.ajax({
    url: 'https://api.spotify.com/v1/me/top/artists',
    headers: {
        'Authorization': 'Bearer ' + access_token
    },
    success: function(response) {
        var d = response;
        var topArtists = [];
        for(i=0; i<d.items.length; i++){
        topArtists.push(d.items[i].name);
        }
        userObject.topArtists = topArtists;
        }
});

3. Geolocation API

Uses the built in geolocation API to get latitude and longitude.

navigator.geolocation.getCurrentPosition(function(position) {
    userObject.latitude = position.coords.latitude;
        userObject.longitude = position.coords.longitude;
});

4. Backend Server Check

Code assumes all demo user data is scoped as friends, searches through data given the distance threshold (i.e. users should be nearby) and returns matching top artists.

function getMatches(userId, lat, long){
    var matches = [];
    var topArtists = getTopArtists(userId);
    ...
    if(outsideDistanceThreshold(lat, long, userData[k])){      }
    else{
        if(userData[k].topArtists.includes(singleTopArtist)){
            var matchObj = { 'artist': singleTopArtist, 'friend': friendId};
            matches.push(matchObj);
        }
    }
return matches;
}

5. Display Match Results

Function tied to an event (i.e. on application load, navigation, etc) triggers the server to look for nearby friends and return matches.

function checkMatches(){
    var xhr = new XMLHttpRequest();
    xhr.onreadystatechange = function() {
        if (xhr.readyState == XMLHttpRequest.DONE) {
          data = xhr.responseText;
          var p = document.getElementById('content');
          p.innerHTML = data;
          p.style.display = "";
        }
    }
    var url = 'matches?id=' + userObject.id + '&lat=' + userObject.latitude + '&long=' + userObject.latitude;
    xhr.open('GET', url, true);
    xhr.send(null);
}

next steps

Next steps include figuring out a way of seamlessly detecting nearby users in a way that doesn't feel intrusive and continuing to iterate based on user feedback.

 

 

Examine other detection candidates:

Geolocation API’s

Pros: Easy to implement, devices with GPS or native hardware often give accurate results

Cons: Have to implement or prompt user for initial permissions to have code run


Server Side Detection

Pros: Easy to implement, streaming services require device to connect to service

Cons: IP geolocation data is often non specific or inaccurate to have fine grain results

Device to Device Sensing

Pros: Novel way to detect nearby devices using ultrasonic or radio broadcast (ie bluetooth) and pass information

Cons: Difficult to implement properly, channels are often noisy and no standardized API across devices requiring additional engineering effort

 

 

Redefine match results:

Currently matches are just top artist names but could be expanded to more complex, possibly better techniques. The top API currently returns popularity scores for each artists which could result in a more nuanced version of the current demo. In addition, there are other top objects available such as genre which would allow composite and more cohesive union of users tastes by factoring in more data to make a better decision.

 

 

Implement feature on server:

Implementing code on actual Spotify services are different but similar to the external API, figure out requirements and tests needed to replicate a production feature.