I'm currently working on a social music-based application that, among other things, allows users to recommend music to their friends. In trying to pare down the system to be as simple and straightforward as possible, I got into thinking about whether or not a formal friend request/accept/ignore system is really required.

Normally with this approach, if the user wanted to recommend music to someone, (assuming they are not already friends with that person), they would have to search for the user, then send them a friend request, and then wait for that user to accept the request before being able to recommend anything, a la Facebook.

However, does this add an unnecessary level of complexity? For something like Facebook that deals with a lot of personal data, it makes sense that not anyone can see it. But for something like this- I was considering instead letting a user recommend music to any other user of the system (the way it's setup pretty well prevents mass spam recommendations), and then if the receiving user does not know that person or want to receive anything from them, give them the option to block future incoming messages.

I'm basically concerned that, because the app's usefulness relies entirely on a user having friends on the system, that getting rid of having to send/accept friend requests might encourage faster/more adoption, since it's one less step in the path to being able to interact with other users in the system.

So basically the gist of the question (or maybe poll) is- for an application like this, is the formal friends model really necessary? Obviously there's not a concrete answer, but I'd appreciate any opinions for or against it.



The problem with allowing recommendations from anyone before you've established a formal link between the people is that it could be seen as spamming, even if you have processes in place to try to prevent this.

One solution would to have an "opt in" during the sign up process:

Allow recommendations from other users who aren't my "friends".

Another option could be to give these recommendations a lower "weight" so that they don't have the same priority as recommendations from connections.

  • I think you and Jeremy hit on a similar idea, and yeah I really like that. That would allow a user to send a recommendation without having to wait for a friend request to be accepted, but also allow users a way to ignore random/spam recommendations. Awesome suggestion! (now how to mark two correct answers...)
    – blabus
    Aug 10 '11 at 22:35

I think if your placed these recommendations into a separate "stream" from recommendations from people I have a connection to, this could be useful. I would be interested in more details regarding your statement "the way it's setup pretty well prevents mass spam recommendations" - My impression is that this is a rather difficult feat to accomplish with a high degree of success.

  • Hmm, that is interesting. The app (it's an iPhone app BTW) is setup as a 'stream' list of recommendations to you, so I suppose I could simply add an option to push 'connected' recommendations to the top, or even not even display 'non-connected' recommendations at all. And I was thinking it'd be relatively difficult to spam users due to the fact that the only interface to the service is the iPhone app. So sure, an actual user could spam people, but they'd have to manually send recommendation after recommendation. So I was meaning spam-proof more against automated systems.
    – blabus
    Aug 10 '11 at 22:32

Take a look at Songkick, Last.fm and Spotify and see how they do things:

  • All three sites/apps employ approval-based friend systems.
  • Songkick sends you an email and puts it in your wall. You can turn off email notifications.
  • Last.fm is almost entirely based around music recommendations, so while you can disable communication, most users probably don't mind being alerted of recommendations.
  • However, Last.fm does allow users to write on each other's pages even if they're not friends. This is a way for people who don't know each other to approach each other (outside of many other ways to do so) casually and perhaps build a relationship from there.
  • Spotify allows you to send music to a user's inbox; although they aren't alerted of it outside the app, a tempting notification icon on their inbox reminds them that there's something waiting for them whenever they load the app.

My advice would be to follow in their footsteps as they're clearly successful services. However, never do anything without user research ;-). Perhaps your service is light-weight enough that people won't mind?

Remember that Songkick is based around events, Last.fm is about music discovery, and Spotify is about listening to anything you want. So each service makes decisions based on goals stemming from those contexts. Make sure your decisions are equally tuned to your service.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.