Unless there are somehow millions of musicians looking to get matched in a single city, the "swipe" UI is pointless and will just make the whole thing unusable. The search + filter pattern for online datasets was perfected many decades ago. Use it.
From the top of my head, I'm going to guess people want (1) personable and agreeable bandmates with (2) compatible music styles, (3) musical talent and skill, and (4) can play instruments or roles that a band is missing.
So the interface should support users in presenting and finding these traits. If I were to design it, I'd have:
- Auto-playing music sample gallery. This is the most important thing to present. The current design asks the user to dig into Youtube and Soundcloud links — which is very high-friction and would have the user jumping between this app and other apps every few seconds.
- One-minute self-introduction video. This helps the user grok the general 'vibe' of someone.
- Allow users to connect their Spotify or other music accounts. Then show users their shared music interests. This can provide another clue about having compatible musical personalities.
If I was looking to start a band today, I'd definitely give this kind of thing a try.
Dating app monetization creates a principal-agent problem: both subscriptions (for paid apps) and advertising/data-brokering (for free apps) are revenue streams that depend on people engaging with the app as much as possible — which people who actually manage to find solid romantic relationships won't do.
The only good dating app monetization model, would be a one-time-fee model. This would induce the correct incentives: as long as people are on the app, they continue to be a cost burden on the service with no further revenue — so, like people hogging a table at a restaurant, the service would be motivated to satisfy them and get them out the door!
But AFAIK, nobody has ever done this yet. (I think it's just because such a site would make so much less money than the traditional "milk your user base eternally" type of dating site. And people who build dating sites are usually in it for the money.)
There was also very little changes made to OkCupid core functionality between 2011 and 2016. Most monetized features predated the match.com acquisition, though I think the price increased at some point.
Even with millions of users, there's better ways to match people up than a simple swipe. It's to keep people at the mercy of an algorithm where spending money is the only way to get any sort of control over what you see.
It exists only for shady monetisation.
https://marvelpresentssalo.com/wp-content/uploads/2015/09/id...
where you can't conclude anything at all because a user didn't click on an item. (That and the scan-ignore-repeat UI paradigm that has kept RSS readers thoroughly out of the mainstream forever)
Even if you want to have a search-based UI it would still make sense to show you one match at a time and let you thumbs up and thumbs down and have the system remember your choices so you can come back next week and look at new items without the considerable cognitive burden of ignoring. But say “see something once, why see it again?” and people look at you like you’re a psycho killer. The whole advertising economy though is based fundamentally on spamming you with the same crap over and over and a ‘dislike’ button that works (negative sampling) would end it overnight, i guess there’s a reason why you can’t explain something to a person whose paycheck is based on not understanding it.
Treating recommendation as a classification problem has all sorts of flaws, mostly down to normalizing the user's indications into a larger model. People will be more passive sometimes and more engaged at other times. Sometimes they'll blindly accept and watch everything that comes along (or blindly swipe right on every match, etc); other times they'll be very choosey.
It's kind of the same problems that asking users for star ratings has — people interpret the meaning of "one star" or "three stars" or "five stars" differently; and there are selection biases on when people will bother to vote at all. (The Netflix Prize was a challenge for a reason!)
You can avoid all these temporal and selection biases, though, because content recommendation is actually ultimately a ranking problem: any recommendation algorithm ultimately wants to generate a subjective ranking of its universe of items, such that everything gets put in a sequence, with the thing the user would most like to see next, first.
And conveniently, we already have a mathematically-perfect way to do ranking: ELO. Or, in app UX terms: the classical HotOrNot design, where you're presented with exactly two options, and you have to pick one as being better than the other. And you get to see the each option several times, paired against different other options each time.
In user-engagement terms, a HotOrNot interface would be just as much of a "dark pattern" as a Tinder interface. But in recommendation-tuning terms, the backend of a HotOrNot-UX app could build you a subjective scoring function that's much more accurate, much sooner.
> you can't conclude anything at all because a user didn't click on an item
The real negative signal that sites like YouTube (and to a degree, TikTok) use, is landing on something though a more passive engagement action (e.g. auto-play next) and this inducing engagement in a previously-passively-consuming user to "get away" from this content.
A probability score for “will he like it?” works as a ranking score in my experience with some caveats which aren’t so much about the score as a score but that recommendation is really a sequential problem. That is, if I get different versions of the same news article that all score 0.9, it might be OK to show me one or two articles from that list. I believe people’s satisfaction with an article is greatly influenced by being spammed with too much of the same thing and that is not so influenced by ranking scores.
I’ll go so far as to say full text search should also be treated as a classification problem, in particularly you need a probability score if you want to make a service like “Google Alerts” where you tell people about new marching documents. Also if you are trying to combine several radically different searchers (like IBM Watson did back in the day) the probability score is essential.
Swipe UI is not the problem. Tinder is separately awful independently of its UI.