UX feature request: Like Button

[psilabs-dev]

Add an option to have a static category with the "Like" (or "Favorites") property, and express this property as a toggleable like icon on archive thumbnails. Users can assign any single category with this property, and of course assign any meaning to "liking" an archive.

In many social media platforms, this functionality is supported but is named differently; for example in Pixiv, it's called "Bookmark", in nhentai it's "Favorite", in Twitter/Facebook it's "Like". In LRR, User can change which category is their "Like" category.

The following are two examples of the like button on Pixiv and Twitter:

If a "Like" category is configured, the UI will add a "like" button on every archive thumbnail which toggles the archive's membership in the category. Additionally, when reading an Archive, the "like" button will also be present. The "like" button serves two purposes: 1) to quickly show whether or not the archive is in the "Like" category, 2) to conveniently toggle the archive's membership in said category.

Why have this feature?

Often I find that I want to quickly add images/archives in my server to my Favorites. The fastest way to do this is on a laptop, even then I need to right click, then add to categories, then select my Favorites category. In a situation where you have tens of thousands of archives, this can become very time consuming. It is also nice to easily notice archives that you've liked.

On a tablet like ipad/phone, it's much slower: there is no right click functionality that supports putting an archive to category easily, I have to go to the archive metadata page and add a category there.

While I can make frontend customizations to my LRR instances (e.g. add a button that automatically toggles my archive's membership for a specific category ID, I would like to look for more general ways to approach this.

One way to implement this

Add a hash key LRR_LIKE_CATEGORY_ID and point it to null or a static category ID. Implement corresponding CRUD APIs for this value.

When rendering archives in the welcome page or while reading an archive, check if each archive is a member of the category fetched by LRR_LIKE_CATEGORY_ID if exists, and display the appropriate icon button; otherwise, skip the button rendering stage.

And a (poorly) drawn example for LRR.

I would be interested in developing/testing this feature, but I want to check if this is something that we would want first.

[Difegue]

I have to mention that the right-click functionality normally still works on mobile - You should just need to long press.

As for the feature request... I don't think it's a bad idea, and it makes sense if we can tie it to a setting key so that users can specify which category they'd like to have on speed dial. I have a Favorites category myself so I'd certainly use the feature.

I don't think people would find out about it if we didn't create one default "Favorite" category for new installs though?
There's a bit of a fine line between having highly customizable stuff while still having a default experience that makes sense.

I also wonder how this would fit alongside/as a replacement for #417 ? Might be worth looking at that again.

[psilabs-dev]

So far on Safari on ios devices, the long press doesn't seem to bring up the custom context menu. I might just consider this a bug then and raise an issue separately

Creating "Favorites" by default is fine by me, I'm inclined towards it for new installs. Part of the issue was figuring out an implementation that is backwards compatible/doesn't impact existing user experience. If a server has some kind of "new install" flag, we can create a "Favorites" category and hook this feature onto it. Not sure if a "new install" state exists currently.

Seems with #417 they're also interested in using to add/remove from their favorites category, which I think adding a like button as described is suitable for that use case.

Extending this functionality to include other categories or showing the category on the thumbnail is a bit risky visually, since we are deciding on what information is important for users to see, "a wealth of information leads to a poverty of attention." Though this is just my very subjective opinion

[waz1500]

Thanks for tagging me @psilabs-dev!

I like the proposal, but I’ve always found a universal "like" system a bit limiting. For instance, not all the content I "like" or "favourite" holds the same value for me—some feel top-tier, while others are more mid-level but still worthy of a "like."

Since my collection already consists of content I like, having a tier system helps me organize it more effectively.

Would it be possible to support multiple "like" categories? While the heart icon works for a single category, if we introduce multiple "like" categories, could we also include a variety of icons? Having distinct icons that could be selected for each custom like category might make it easier to differentiate between them quickly.

One concern I have is ensuring clarity at a glance.
Currently, I rely on static and dynamic categories for organization, but there’s no way to visually represent these distinctions in table or thumbnail views. Adding this functionality could be really helpful!

That said, I don’t want to overcomplicate things unnecessarily. I always appreciate any enhancements to LRR and look forward to seeing how this concept develops.

[psilabs-dev]

Thanks for the feedback @waz1500 ! After the description, I think there is a bit of difference in requirements, so I'm hesitant to liken these two issues at the moment.

To give more detail, as a user, my hard conditions for a convenient and effective like button implementation are twofold:

1. Without clicking, see whether an archive is Favorited (on home page). This is satisfied by a toggleable like icon.
2. Toggle archive Favorite status in exactly one click/tap. No more than one click/tap to achieve this.

The third (3) softer requirement is that it doesn't overly cover the thumbnail, eg it's <20-30% of the thumbail space. I'd like to avoid placing text on top of the thumbnail. However, this is an aesthetic issue so I don't mind changing things on the fork.

It would be challenging to implement #417 that satisfies these conditions, at least imo. This isn't to say it can't be done but more discussion on the details of implementation and user requirements/expected behavior should probably be made, and perhaps a second pull request may be needed.

[Asinin3]

Wouldn't the ability to search for galleries you gave 5 stars be effectively the same as searching for favourited galleries.

[waz1500]

Not exactly. While both ratings (star) and the favourites (heart) icon indicate user preference, they serve different purposes.

Star ratings (1–5 stars) provide a more nuanced ranking system, allowing users to differentiate between "Adequate" (3 stars), "Great" (4 stars), and "Amazing" (5 stars). Searching by 5-star ratings would only show the highest-rated galleries.

Favourites, on the other hand, are a binary selection—either a gallery is favourited or it isn’t. A gallery rated 3 stars could still be marked as a favourite.

While there may be some overlap between 5-star galleries and favourites, they are not the same. A search for 5-star galleries would exclude anything rated lower, even if the user still considers them a favourite.

With the recent addition of the rating option in the WebUI context menu, the "favourites" feature will become useful in two ways.
For users who prefer granular control, it can also work alongside star ratings to distinguish between different levels of preference.
At the same time, for those who don't need that level of detail, it provides a simple, binary way to mark galleries as favourites.

This flexibility allows users to organize their collections in a way that best suits their needs.

[Difegue]

There's no "new install" flag per se, but I don't think it would hurt to just create this new category by default on new installs - If people don't want it they could just remove it. Otherwise, you could probably just check if the default password is still set, I think that'd work.

Imo, the need for multiple "like" tiers is somewhat satisfied by ratings instead now - And those can be leveraged in dynamic categories, although they're not one-click to set up like favorites would.
(Some people might argue favorites and ratings kinda duplicate one another, but I do think they're kind of complementary, ratings use tags/metadata while favs use the category system)

[psilabs-dev]

Yes, creating a new category by default will be the expected behavior for the implementation.

Looks like enough to get going. I think checking default password is good, though I'm wondering if restarting the server will cause multiple favorites categories to be created. We'll see how it goes; it wouldn't be difficult to add the new install flag post-implementation.