Upvote vs like
Graphics/UI and #ux are one side of the project, UX that is combined with functionality and design is a slightly different story. Looking at the project from the beginning I was wondering about the sense of mixing upvotes and likes. Of course, I know that this from the functionality of federated applications, but also in them this function, especially combined with upvote, is not logical for me. It's just duplication of the same functionality and many users don't see the difference, and it causes unnecessary confusion.
In the case of a link aggregator such as /kbin, this is an additional problem, because the main principle of ranking results since digg and earlier is the upvote. Mixing this function and likes makes it unclear how content is sorted. Or at least, or rather, it is not obvious.
The problem is getting worse and worse. I am writing this because there are already entries with 70+ likes and only one upvote.
In the case of Twitter, expressing interest in a post is possible by liking or retweeting. In the case of #reddit, the user can raise or lower the rating, "reward" but in a limited way, share or save the entry. Although the functionality of these options mixes with each other in a way, it is not duplication of functionality.
In the case of Mastodon, Calckey, etc. We just have an upvote and a like. But after just a few minutes of using the site, you can see that users use these options randomly.
In my opinion, there are several solutions.
-
If someone likes content in an external, federated project on /kbin, it's only considered a boost. Because it's basically the same expression of approval. And the like as such disappears and can, for example, be replaced by saving the entry to "favorites" for later.
-
If someone likes content on an external service on /kbin, it is displayed as an upvote and a like.
-
If it is required to add other forms of expressing one's reluctance or approval, the standard reaction module can be used.
TBC
Add comment