Difegue / LANraragi

Web application for archival and reading of manga/doujinshi. Lightweight and Docker-ready for NAS/servers.
https://lrr.tvc-16.science
MIT License
2.18k stars 153 forks source link

Sort galleries randomly #642

Closed thebrokenfacade closed 2 years ago

thebrokenfacade commented 2 years ago

Please describe your suggestion, and the problem it'd solve. My collection has exceeded 50,000 items in over 500 pages in lanraragi. It would be nice to have the ability to sort the galleries randomly both when a search filter has been applied, and on the landing page before a search is applied.

This would help prevent people with large collections from seeing the same few doujin all the time. It could also help rediscover old forgotten favorites, or discover new ones.

Hopefully this is easy to implement.

Difegue commented 2 years ago

The carousel on top of the index page does this already: It presents random archives from the current search filter, or the entire DB if there's no search.

I don't plan on adding random sorting to search results themselves as I think it'd make no sense from a UX perspective.

thebrokenfacade commented 2 years ago

My intent with this message is not to be argumentative or combative, but the better explain why I thought adding a random sort may be beneficial specifically from a UX standpoint and not just for my use case with a large collection. Who knows, perhaps it will change your mind. Either way, thank you for your time and for developing this app. It is awesome.

As an example, let us consider how many motions (scrolling, clicking, etc.) it takes to user to look at the thumbnails of about 100 archives. We will assume the user wants randomly selected archives, otherwise they would not use the carousel in the first place. I will use the number of motions determined in the third and fifth paragraphs for my calculations.

The carousel displays a maximum of 15 archives each time it is refreshed. To view 100 archives the carousel would need to be refreshed 6 times. On a 1440p monitor, it takes 7 clicks of the 'next' button in the carousel to view those 15 archives. If the mouse wheel is used instead of the button, it takes 2-3 scrolls to see all 15 archives. On that final scroll immediately after the 15th archive is displayed, continuing to scroll moves the entire page down. That means if you lose track of how close you are to that 15th archive and scroll an extra time, or that 15th archive is displayed mid-scroll and you do not immediately stop scrolling, instead of scrolling the carousel horizontally, suddenly you are scrolling the entire page vertically. At that point you have to scroll back up to the top of the page to see the carousel again.

At best, it takes 20 movements to view 105 archives with the carousel. 14 scrolls to view all the archives and 6 clicks on the 'refresh selection' button. That is assuming you never over-scroll as described in the third paragraph. Any over-scrolling just adds extra movements to the ideal count above. Also, the page suddenly moving vertically when the user over-scrolls is jarring; not great for UX. If the 'next' button is used in the carousel it would take 55 movements to view 105 archives. 49 clicks of the 'next' button to view all the archives and 6 clicks on the 'refresh selection' button. Neither of these cases consider moving the mouse to click on the 'refresh selection' button which would add another movement on the first page.

If a random sort could be applied to the main thumbnail container, 100 archives could be looked at on a single page. On a 1440p monitor, it takes 3-4 scrolls to get to the bottom of a page. Once the bottom of the page is reached, continuing to scroll does not have some unexpected behavior: it just stops scrolling. Thus it only takes at most 4 movements to view 100 archive thumbnails and there is no possibility of the page behaving unexpectedly using a random sort in the main thumbnail container.

That means that using the carousel is at best 5x (20/4=5) less efficient than having a random sort option for the main page in terms of the motions or actions required to view about 100 thumbnails. At worst it is 18x (55/3=18.33) less efficient in terms of the motions required to view about 100 thumbnails.

I am not a UX designer, or even a coder, so perhaps there is some other reason not to implement a random sorting feature that I am not considering. But to me, at least a 5x improvement in efficiency for the user seems compelling.

Difegue commented 2 years ago

Thanks for the detailed insight! I certainly appreciate it. Likewise, I hope you didn't take my original comment as aggressive, I did write it in a hurry so it might've been a bit too dry. 😅

As far as your calculations go, they're certainly correct from an efficiency standpoint! However:

That's the kind of stuff I mean by UX, as it's not only about raw efficiency but also trying to have an interface that's usable at first glance by the layman without drowning them in poweruser options right off the gate. (*cough hydrus*) It's obviously not perfect in its current state either, since there's always a balancing act between the desired state of things and how much javascript I have to throw into the beast to get there. 🥲

But I'm not a professional designer either (and even if I was that wouldn't magically make me immune to criticism), so I'm always open to hear suggestions from others! Since this issue now has a lot of words™️ in it I'll convert it to a GH discussion, so that others can see it and chime on the idea if they want to. 👍