QUOTE(Tenboro @ Nov 5 2022, 18:02)
A new code update has been pushed live:
New Feature: Seek/Jump Navigation
You can now do arbitrary jumps (number of days/weeks/months/years) backwards and forwards in search results, as well as arbitrary seeks to a specific date in the search results, by clicking the new Jump/Seek button in the navigation bar and entering a number or date in the box that appears.
Entering a number will make it jump backwards or forwards by the specified number of days, aligned to the start or end of each day. Adding w, m or y to the number will make it jump by that number of weeks, months or years instead. When jumping forwards (Jump >), the jump is based off the posted time of the oldest (bottom-most) gallery on the current page. When jumping backwards (< Jump), the jump is based off the posted time of the newest (topmost) gallery on the current page.
Entering a date with the YYYY-MM-DD will make it seek to that date in the search result (inclusive). Note that the semantics of < Seek and Seek > is somewhat different than < Next/Jump and Next/Jump > - specifically, which button you use determines whether it uses the date as the starting point or the ending point.
You can also use the YYYY-MM shorthand date. In this case, it will start from the first day in the month when going backwards and the last day in the month when going forward. (In other words, in either case it will include that entire month.)
If you only enter a number (not followed by d w m or y) and it is between 2007 and 2099, it will be interpreted as a year. In this case, it will seek to the last day the year when going forwards and the first day of the year when going forwards.
With the YYYY-MM-DD and YYYY-MM formats, the two first Ys can be left out - in other words, 22-11-05 will be interpreted as 2022-11-05.
Seeks and Jumps to galleries posted before October 2021 or so will be wonky until I run a script to make some fixes to the publish timestamps to match the behavior of newer galleries. This correction will happen shortly after the update is fully deployed.
Bugfixes
- Corrected an issue where galleries were no longer displayed under favorites if they are unavailable.
- Corrected an issue where, when using the /tag/ URLs (such as when clicking tags from the gallery page), it would keep adding additional quotes if you clicked the navigation links.
- Corrected some issues with uploader usernames with underscores and spaces. Note that for syntax and visual ambiguity reasons, underscores and spaces are now considered equivalent in uploader username searches.
- Corrected excluded categories still appearing on the Popular Pane. (They are still supposed to appear with file, gid and favorite searches.)
- Corrected an issue with dashes/hyphens in name searches where they weren't properly stripped for the index lookup.
-------
Since the thread has quieted down a little bit, and I'm sure there are people who are still unhappy about things even with this update, I'll also take some time to address some of the most common criticisms.
(Not having a page selector is worse than having a page selector / Not having an exact result count is worse than having an exact result count) and this update is therefore a step backwards UI-wise!
Well, no shit. They weren't removed because I thought it would be an improvement, but because with the increasing size of the index, it was getting more and more expensive processing-wise to provide these things, especially considering that the traffic has been significantly increasing as well.
I've seen some people make arguments along the line of "I don't mind waiting three seconds for a search result to appear". There are several problems with this argument:
- First of all, the problem isn't primarily that the user has to wait three seconds for a search result, but that a server is using most of its resources for those three seconds to build said search result - of which the user will probably only look at the first few pages at most.
- Secondly, if it's three seconds for a search today, it'll be six seconds in a couple of years - that is, if it doesn't fail outright due to memory limitations. At this point, the average server CPU load would be above 100% and the site would be effectively unusable.
The site does not have the budget for an additional full rack of high-end servers just to provide the existing functionality with the existing limits, so the options were:
1. Replace the old search engine that uses a naive approach of effectively building the full result for a query (which is necessary for full-range page navigation and exact-ish result counting) with a brand new search engine that is a lot more clever about doing stuff.
2. Put a bandaid on the old search engine by significantly curtailing the maximum size of the search result and/or the range of searchable content.
3. Remove functionalty that was expensive in the old search engine, such as hybrid title/tag searching and comment searching.
With the second option, you would have pages, but there might be a maximum 10 of them with 100 results per page. You'd have exact result counts, but it would be capped to 1000. Many sites use this approach, but if you think for a second that this would cause any less of a shitstorm if we changed to it, I have a bridge to sell you.
With the third option, you would only be able to search for titles or tags, but not both at the same time. Searching would just be all around hampered and unintuitive. See; shitstorm.
Alternatively, you might have a curtailment that only galleries posted in the last couple of years are searchable. Shitstorm.
Alternatively alternatively, those things but with donator-only unlocks and higher limits. Shitstorm.
I went with the first option, which involved three months of active development plus an additional month of testing + optimization, and is, in my opinion, by far the best tradeoff in terms of (server) performance and functionality.
Even if a lot of people disagree, this is a hill I'm willing to die on. And while you are allowed to both disagree and/or dislike change in general, if people keep accusing me of lying to my face about the current state of things and the reasoning for the changes, I'll just start handing out bans to preserve my sanity, so please stop doing that.
As for result counting, I'll put some more effort into providing estimates for various complex results, but this cannot happen until the update has been fully deployed and the old indexing code can be retired.
You should be communicating more about upcoming updates and giving script/tool writes a heads-up instead of just dropping them with no warning!
The new version of the site did undergo closed testing for weeks before it went live, and I can't think of any site that does full-blown public testing, so it would be easy to write this off as "you're asking too much".
But: fair enough. Even though these UI updates only show up every two or three years and would involve maintaining a separate test instance, this really would not take that much additional work.
While feedback from such a public test would be unlikely to fundamentally change the nature of the update, at least it might work out some issues that weren't raised in closed testing, and also provide tool/script writers with a heads-up for upcoming changes.
As such, whenever an future update with major UI changes is getting ready for launch, I'll make a public test version of it first.
又更新部分設定
對我來說
現在這樣的以日期或時間跳法比以前用頁數跳方便多了
中文討論區: 變態道的原罪 [禁無意義的水跟簽到], The Chinese discussion thread of declining quality.
Nov 5 2022, 07:17
