[X] My Assistant

Nice idea to use what's already available by default, but input type=range or input type=progress is insufficient imo, considering what was originally described. The "currently displayed" range information will be lost with this.

Without the range information, it's hard to digest / not very useful. E.g.:

[=====||==============]: I am 25% deep into the search result.

How many more times do you have to click next to view all the results? You can extrapolate this by counting the total result number and the fact that each page contains fixed number of results (50 or 100), or by hitting next/prev a few times to get some sense of it, but it also means that the visual indicator failed its purpose / is not doing a good enough job.

[=====[=====]=========]: I am 25% deep into the results, and I can hit next about twice and I would have seen everything. In pagination parlance: I am at page 2 out of 4.

I think anything that helps my brain to understand where i am inside the search is better than nothing

Just some text (25%), that changes when i click "next" would be enough for me


If i have a progress bar like this it's even better, just for graphical representation, less thinking, more fapping

[=====||==============]:25%


This is even better, because the graphical representation will tell you how big is each page in one glance
[=====[=====]=========]:25%


This said, even the last solution can be implemented with the native range slider, just make the thumb bigger with css and add step="25" to the input property, so the slider will make you slide 25 steps at time

What people currently seem to find most lacking in the new search engine compared to what they had with "page-based pagination" is a way to see how deep they are into a result, as well as a more visual way to jump deep into a result. So if we can do this without pages (and we can, it'll just take some work), then there shouldn't be a single advantage left for "page-based pagination" outside of "we always used page-based navigation and that's the way we likes it".

Yes! These advantages are exactly the traits of the page-based navigation UX I felt was missing yet couldn't pinpoint when using the new system. I'm impressed by how accurate and precise your analysis of the feedback is, and feel extremely optimistic knowing that you plan to implement those advantages into the new system.

Thank you for the hard work on the site!

A recurring complaint people have had is that they don't want to leave hentai bookmarks on their computer because other people might find them.

It would be possible to add a Bookmarks drop-down menu at the top of the page so people can save their progress in searches in their EH account instead of in their browser. It could be called My Searches to distinguish it from Favorites.

A recurring complaint people have had is that they don't want to leave hentai bookmarks on their computer because other people might find them.

It would be possible to add a Bookmarks drop-down menu at the top of the page so people can save their progress in searches in their EH account instead of in their browser. It could be called My Searches to distinguish it from Favorites.

I don't know how many people would bother, but I don't really think it's worth the dev time to reinvent bookmarks when things like [portableapps.com] PortableApps exists. Stick it on an encrypted filesystem container using VeraCrypt or similar, and no one is going to see your bookmarks.

can you display the aproximate number of results when searching through favorites?

One thing I always wondered was: How the hell did he manage to do unbounded, accurate pagination with *that* many pages, while still retaining performance -- damn he must know something I don't, some magic sublinear algorithm or something...

Well I'm kinda relieved how that turned out.

Anyway, I've seen some sites do fake pages - where it internally just works using an ID, but in the URLs for the "next" and "previous" page, they just add a totally fake page number. What you did with the new jump feature is obviously way better.

This post has been edited by muggwnqt: Nov 8 2022, 23:13

A recurring complaint people have had is that they don't want to leave hentai bookmarks on their computer because other people might find them.

bunch of normies... just put them bookmarks on a .txt file on system32 or something

What, everyone doesn't have a flash drive Linux OS Brave browser that they use to-

No! People just want to click things and get what they want the way they want it.

When you've gone to all the mental toil of learning how to raise, butcher and cook the coding cow it can be easy to look at those who haven't as being lazy, but in truth, they're the normal ones.

Asking everyone to adopt some power user adaptation or risk exposing their specific perversions to anyone who might be waking past is a bigger ask than it might seem at first. Because no one wants to have the, "So this is what you're into" talk with the spouse, or roommate, or... boss.

What, everyone doesn't have a flash drive Linux OS Brave browser that they use to-

No! People just want to click things and get what they want the way they want it.

When you've gone to all the mental toil of learning how to raise, butcher and cook the coding cow it can be easy to look at those who haven't as being lazy, but in truth, they're the normal ones.

Asking everyone to adopt some power user adaptation or risk exposing their specific perversions to anyone who might be waking past is a bigger ask than it might seem at first. Because no one wants to have the, "So this is what you're into" talk with the spouse, or roommate, or... boss.

Just write down a date then and resume from then. Not sure why you'd choose to die on the hill to defend people who care about their privacy but also don't care about it.

This post has been edited by Cipher-kun: Nov 9 2022, 02:13

Asking everyone to adopt some power user adaptation or risk exposing their specific perversions to anyone who might be waking past is a bigger ask than it might seem at first. Because no one wants to have the, "So this is what you're into" talk with the spouse, or roommate, or... boss.

Odds are, many of the people who can't figure out a solution to the "private bookmarks" problem, are not going to be savvy enough to deal with encrypted Veracrypt partitions. I assume favorites are already mostly aimed at that kind of thing.

Having "favorite searches" would be nifty, I guess, for some people? I don't see much point to adding them myself. Either my searches are broad/simple enough that a few memorable tags work... or they're an attempt to locate one damn gallery for 8 years ago by continually adding more and more tags until I find it. The former seems like overkill for a feature, and the latter is better served by just favoriting/note-ing it once I find it. Maybe other people have much more specific and discerning tastes.

More generally though - on the topic of "so this is what you're into" talk - there's only so much a site can do to protect users from their own carelessness. This is not a new problem; I remember making sure to delete history and whatnot after browsing sites decades ago (and yes I had "the talk" with my parents after I forgot one time). Or putting URLs I liked in some text file hidden ten folders deep - next to a small cache of favorite downloaded images, because doing anything over 56k was painful and if I found good stuff I never wanted to download it a second time.

Maybe that's a dismissive mindset? I dunno. Learning to hide your porn is kind of a rite of passage. And besides, when the user leaves this site and browses other ones, those ones aren't going to bend over backwards to protect them from their own carelessness either.

At the end of the day, you're responsible for your own secrets, and who you want to hide them from. (And to be blunt, if someone's boss finds them browsing porn on company time, then they kind of deserve it. The other ones I can at least sympathize with.)

Just a quick bug(?) I noticed, but tags that are set to "hidden" are not shown below thumbnails anymore, when tags are being ignored in the search.

For example if I search for something and notice that 5 results are removed from the search due to filters, I could then tick the checkbox for "Disable default filters for: Tags" and quickly identify which galleries were previously hidden thanks to the little boxes below the gallery thumbnails.

Just write down a date then and resume from then. Not sure why you'd choose to die on the hill to defend people who care about their privacy but also don't care about it.

Because the vast majority of people fall in the grey area between, "Leave open porn pages up all the time" and "Make a Bond villain ninja stealth kit for your prepper go bag", and that's who I'm thinking about. If you tool for only edge cases, you'll soon find you have only edge cases.

Now that this thread has calmed down a bit, I wanted to bump up my suggestion again, to see if it's something worth trying. May not be, but it feels like a good middle-ground solution to appease all sides.
Link to earlier in thread.

--
If I'm understanding how the system works now, the first page displays results from the most recent GID and it continually cycles through the next sequential GIDs until there is enough tag matches to fill a page, then the next page continues from where the previous left off to repeat this action.

And the entire switch to this system was done to prevent strain on the servers from the whole-index-searching process the old system used, right?

You also mentioned considering limiting the number of total results to like 1000 as an alternative to this setup. Would it be feasible to add a pseudo-pagination just by returning more results (1000 or whatever) and splitting them into, for example, 25 page increments, where, upon reaching the end of those pages, search for the next 1000 results and display the next 25 pages? With that it shouldn't really matter if there are new uploads in between searches, when the new "page 1" is set to the next sequence of GIDs. [Or refreshed when a new search is performed.]

If this fits technically speaking, it feels like a good compromise. Your system isn't being overwhelmed with unnecessary search caching, the average visitor is happy to have some form of pages back, and the people that like to deep dive into the archives have a way of doing so with more reliability than the current setup.

Oh. Question. When a gallery is updated (say by adding new images or whatever), does its GID change? Or stay the same?

Say I'm 30k results deep in a search, and my URL has "&prev=12345678" on it. That's its anchor to my results location, basically. If I refresh I always stay in that same spot, no matter if new galleries are added, or old ones retagged, or whatever. This is good.

Then someone updates 12345678. Adds a few pages or whatever. When a gallery is updated it jumps to the front of the results again - I've seen that before. So if I refresh my page, am I now looking at the front again (ie 12345678 got its date moved and since my URL was anchored on it that moved too)? Or am I still 30k results deep (ie 12345678 still points to its old location and the updated gallery has a new GID)?

My assumption is that I'll still be 30k results deep in there. Otherwise that would kind of be jarring and weird behavior. But I can't test that unless I know of a gallery that's going to be updated, so...

I'm not sure if this has been brought up already but I noticed that when trying to search between X and Y number of pages, the minimum range it can search has been upped to 21 pages. I don't know why this has happened as previously I could go as low as I wanted and it'd still show me results. Hopefully this is just a temporary thing and the range is expanded upon, otherwise I'm not sure why this change has occurred.

Oh. Question. When a gallery is updated (say by adding new images or whatever), does its GID change? Or stay the same?

Updated galleries get a new GID. Galleries cannot be updated after a year has passed.

search engine not really work. results number really really low. i know alots of matariel avaible but search cant search..

I'm not sure if this has been brought up already but I noticed that when trying to search between X and Y number of pages, the minimum range it can search has been upped to 21 pages. I don't know why this has happened as previously I could go as low as I wanted and it'd still show me results. Hopefully this is just a temporary thing and the range is expanded upon, otherwise I'm not sure why this change has occurred.

Read through all of first post in this thread, changes are documented there :

CODE

- Excessively narrow page range filters (min > 1000, max < 10, min/max > 0.8, min-max < 20) are no longer allowed.

search engine not really work. results number really really low. i know alots of matariel avaible but search cant search..

Likewise ...

CODE

This update is a complete rewrite of the gallery search engine, meaning that the usage and behavior of searches has changed in a number of more or less significant ways.

etc. etc.

Say I'm 30k results deep in a search, and my URL has "&prev=12345678" on it. That's its anchor to my results location, basically. If I refresh I always stay in that same spot, no matter if new galleries are added, or old ones retagged, or whatever. This is good.

Then someone updates 12345678. Adds a few pages or whatever. When a gallery is updated it jumps to the front of the results again - I've seen that before. So if I refresh my page, am I now looking at the front again (ie 12345678 got its date moved and since my URL was anchored on it that moved too)? Or am I still 30k results deep (ie 12345678 still points to its old location and the updated gallery has a new GID)?

My assumption is that I'll still be 30k results deep in there. Otherwise that would kind of be jarring and weird behavior. But I can't test that unless I know of a gallery that's going to be updated, so...

You'll still be 30k results deep.

If the gallery with GID 1234 is updated and you are on the page with &next=1234, the result page will be exactly the same if you refresh it, since the number in the URL is the first/last gallery to *not* be included in the result, and it does not necessarily have to exist.

If the gallery with GID 1234 is updated and you are on a page that *contains* this gallery (say &next=1235), the result page will also be exactly the same, except that this gallery will be gone, since it got bumped up to the start of the results (with a new GID).

So if the new GID is superior in every way and page base navigation is a barbarian's way of travel. When will this entire forum remove pagination and replace with FID?

I'm looking forward to the world where the gallery and the book get rid of pages.

User encrypted bookmark... this tells all you need how far out of touched the hardcore dev is when it comes to computers.