Uploaded image for project: 'ListenBrainz'
  1. ListenBrainz
  2. LB-400

Data collection enhancement with a client identifier

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Normal Normal
    • None
    • API, web pages
    • None

      Summary

      • API: Allow clients to include client identifier data in submissions
      • Web pages: Display client identifier next to listens in user's profile / now playing submissions

      Background

      In the pre-2014 Last.fm, this was a feature I enjoyed having. The representation of this data benefits both the individual user and rewards the ecosystem with feedback on ListenBrainz client usage.

      For the individual user, they have better insight to what application or platform was used to submit a listen. For debugging, this is obviously useful in case there are unknown listens in the profile and their origin is unclear. For data, to me, it's also super interesting because the client I used could correspond to something like a different time period of my life, depending on what I was using.

      For client developers, it allows for ListenBrainz to offer a statistic on popular clients and link out to them. This provides positive feedback to a developer to know their client is being used and also helps new users find supported clients to choose from.

      Details

      I figured there are two components, as described in the Summary. We need to allow for clients to tag a listen with a client identifier string when sending data to the ListenBrainz server. It might also help to publicize a change like this in the blog. Once the data is available, building in a way to display it along with a listen in someone's user profile would be helpful.

      In designing this, it might be good to keep an option open to display an icon alongside a name, in case clients could submit a thumbnail to appear next to their identifier in the user profile.

      Also, this should be a toggleable option for the user to make public or private. I think a default of private is better. Obviously the data is still there and could be accessible in the API, so it should be clearly communicated that the metadata does not disappear and could be discovered in the API – it only hides it on their public-facing user profile.

      Outcome

      More interesting data to understand along with listens and also more feedback to client developers that people are using their client!

            alastairp Alastair Porter
            jflory Justin W. Flory
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved:

                Version Package