Yes but @pod s main complaint is that neither search nor bookmarks offer a “take me to last read position” option, which I can understand.
That is especially weird for a bookmarked topic… I am a bit more mixed whether search should allow this however if we only offer it on search hits to the first post in the topic I think that would be OK too?
I think @mcwumbly talked in the past about a special shortcut I support adding.
TU take me to the first post I did not read in this topic
The advantage of adding this shortcut is that it can fix up the situation in a maze of conditions on forums that carry lots of giant topics you feel very passionate about. It works in both directions.
I also think maybe we should add “Star Trek op” for only searching post #1 this is also mega powerful cause it expands the search set for a restricted subset forum (E.G. the Star Trek topic can drop off in Q23 and sometimes you want to revive it 6 month later )
Yes but a clickable or tappable link in the search results (for first post only) and in bookmarks (for first post only) is far more discoverable UX.
Yeah I agree this needs some UX solution, we can’t just ninja solve this. maybe when we get to redoing our topic progress panel we can add a tiny marker that shows up in timeline that highlights first unread in a topic. In fact maybe we should just repurpose our current go back button.
The thread is a rewatch thread with a weekly period. So it bursts every week. Though I lagged behind for many weeks due to IRL stuff meaning I couldn’t watch.
Either way: I used the search simply because I knew I wanted to go to that thread. “Let’s go the QT3 and read the star trek thread”. I usually browse QT3 using the latest/unread page. But on this occasion I specifically wanted to read that thread, so why waste time?. And in general I’m conditioned to just type what I need into a search box and it finds it, be it google, Window’s 10 start menu, Voidtool’s Everything, iOS’s Spotlight, IntelliJ’s Search Everywhere, Whole Tomato’s “go to object”, etc etc etc.
So I go to Discourse, press the search box, type in “Star Trek”, it instantly finds it and presents it as the first option, so I click the name of the thread I want and am met with the utter disappointment of finding myself 200 posts on from where I left off, deep into spoiler territory, never to find my way back.
(Had I used latest/unread I would have to double ctrl+f to get my browsers search up and hope that Discourse’s inifini-scroll had ‘paged in’ the thread’s name. Ironically, had I done that and clicked the thread name I would end up at my last read position, as the latest/unread list takes you to the last read marker)
I deal with so many search-bar syntaxes on irregular bases that I’m never going to remember how to type that stuff in, which means I’m going to have to faff with the advanced search’s GUI. But, for me, that’s longer than manually adjusting the URL to take me to safe territory.
That’ll take me to the LATEST POST, which is definitely not what I want 
I want to avoid that at all costs. I want my read marker! It’s why it’s there.
In this case, it is actually is set as “Watching”. (Though that’s caused trouble in the past with 60 year old SPOILERS popping up on my desktop.) In this specific “incident” however:
a) I forgot it was set as watching
b) it was waaaaaay down in my notification list. On the phone UI it’s below the cutoff. I’d been delibertly ignoring it for a month as I hadn’t watched a new episode in awhile.
c) I knew what I wanted, so why would I bother with all of these clicks on different UI parts anyway? Usually I can just type words in and end up where I want, lickety-spit.
I’m reading every post! In order, from my current read position up right up until the last post in the thread that talks about last episode I watched. Once I get up to there I avoid the thread until I’ve had time to watch the next episode, and can therefore “catch up” and read the next batch it. I used to be surfing on the very latest posts in the thread, but due to the stall I’m now a few episodes behind.
I think what you are running into here is an oddball scenario that you’ve created for yourself.
Wanting to go to a specific thread in the fastest way possible is an oddball scenario? Or is my desire to keep the sanctity of my read-marker the oddball part?
Q: If you know you want to go to a specific thread, e.g. to post a new news story about how crap certain processor manufacturers are, do you manually trawl through big lists of threads via the unread/latest/new screens looking for the thread? Or perhaps scroll down your notifications, hoping it was set to watched? Or do you do the natural thing and bring down the rapid search box and type in “stuff” to go to the “stuff” thread? If your read marker is at the bottom of the relevant thread, then this works fine. But if it’s in the middle, then it’s destroyed. Sometimes that’s fine, but other times it’s not!
It’s like going into a shop with the aim of buying a certain object. You could slalom every isle and stare at every product until you find it. Or you could try and navigate to the right “section”, assuming the shop is sign-posted correctly, and then scour that section. Or you could just walk up to the nearest shelf stacker and say “hey, where’s the stuff kept?” and be instantly teleported to your destination.
I’ll have to look into the bookmarking stuff. I’ve never used it. (and, by Sam’s other post, I see no-one else does either!)
Personally, I think this should be the default action for a search result. How many people are searching for a specific post in the quick search list, rather than for a specific thread? I feel like searching for a specific post is what the advanced screen is for, or even the in-thead search option, once you go to the thread.
You guys have metrics for everything, do you have metrics on how often people’s read markers are obliterated by accessing threads via search results? Or perhaps metrics on how often people have to frantically scroll back up trying to manually find their previous read marker?
Barring the UX change, this is exactly the kind of voodoo I was after in my first post, really. I note that you said topic here rather than post.
Something touched upon above but not explicitly stated: I feel it’s also slightly inconsistent UI.
Usually you click the name of a topic and you go to your read marker.
But in the search window you click the name of the topic and you go to a specific post, irrespective of your read marker.
I guess it makes a sense in the context, given that the post’s contents are spilled out into the search window. But it means I can’t keep the normal behaviour when inspecting search results. Perhaps dividing the search result’s “click target” into the topic-title and the post-body might be an easy way to keep both behaviours?
How about we allow it in 2 conditions
If the result is for post #1
If the result is for a post in the topic that is higher than last unread
Big question though is how we would render this extra link
I kind of like this concept:
And doing it unconditionally if you have unread.
Finally 10 replies in, the info I kept asking for 
Yes that is how search is supposed to work, and that is how everyone in the world — except you apparently — expects it to work
Probably ok but I worry about performance for that 2nd case. “Is it the first post” is a trivial operation.
What’s being asked for here is still a little bit of an oddball use case IMO, I do not want perf to suffer for the 99% of people that will never run into or care about this.
This is a completely trivial operation, especially when compared to search.
For example: on the home page we are filling this info for topics it takes 3ms for 30 topics.
SELECT "topic_users".* FROM "topic_users" WHERE "topic_users"."topic_id" IN (109224, 109967, 109964, 104441, 109941, 109957, 109911, 87848, 89916, 108029, 61966, 48839, 109928, 109955, 77467, 65602, 86343, 109328, 109897, 109922, 26173, 109613, 67574, 59847, 109949, 109784, 109079, 108240, 109937, 109404) AND "topic_users"."user_id" = 1;
In the context of search that takes 100s of milliseconds this is trivial.
Regarding it being a hugely uncommon feature, I think it highly depends on the user.
Me and you are not unread hoarders, so this would barely show up for us. Other users who cultivates 1600 may find it extra handy (we have quite a few on meta including a team member). Cause if you search and get a visual tip right away that both you read the topic AND have unread it is super powerful. Plus you can quickly get to the last position you had in the topic, which is super useful. This feature encourages reading, and reading is fundamental.
@awesomerobot how would you recommend rendering this visual tip? (both in full page and mini search)
I don’t think that’s really the issue. This is a kind of unusual and highly specific use case, to wit
So you can’t read the latest posts in the topic because you’re afraid of spoilers, but you also can’t entirely ignore the topic either … because you plan to go back in (weeks? months? years?) and watch more of the show.
This is why I feel bookmarks is a better solution in this specific case. Bookmark the topic about “Star Trek” and then come back to it when you’ve gotten around to watching the latest {x} episodes.
In fact, I feel most comments @pod made about searching here are a complete red herring, unless the topic has a pathological title that makes it impossible to search for. And if that’s the case… fix the title. This is why trust level 3 abilities exist in Discourse.
Since you asked, @pod, I would …
Search for “qualcomm hole” which, I’ll grant you, brings me to a weird place in the topic (post #506, from Jan 2nd 2019).
Solution – add a
fpquery shortcut so I can quickly specify I only want to match this in the first post. That way I could search forqualcomm hole fpand run zero risk of messing up my read position, and the vertical timeline would show a “back” button where my read position was as soon as I enter. That way it’s a one click / one tap operation to get either to the end or to my read position, just after entering the topic.
Immediately use the vertical timeline to jump to last read (if I arrived higher up in the topic) or jump to last post (if below my read position) and then scroll up or down as necessary to catch up. Yes, I definitely would have preferred to end up on the first post or my last read position, but since I am not exactly avoiding spoilers here, as long as I’m somewhere reasonable in the topic, it doesn’t matter a whole lot.
If the topic is “hot” then I would typically arrive there via my reply / mention / quote notifications, or seeing it bumped on the homepage. But I now understand why that’s not the case since you finally added important context.
The critical information @pod finally added – he is trying with all his might to avoid spoilers for movies or TV shows he is watching intermittently, over a period of weeks or months (even years?) after the fact – finally helped me understand the concern here. The topic is probably cold, nobody is replying, and even if they were replying to bump the topic, you physically cannot go there for fear of seeing a spoiler. 
I agree the above option is good to have, especially in bookmarks.
Note that none of the solutions involve changing or “fixing” search in any way…
I think if we are pushing for bookmarks as a solution here, then star trek b seems like another reasonable search amendment.
Another one which is interesting would be in:unread which could be shortcutted to u (we don’t have either now)
The most critical new search shortcut we need at the moment is fp (or op as a synonym maybe) that means “first post” or “original post”. Most of what @pod is complaining about here can be summarized as
I only ever want to arrive at the first post no matter what I searched for.
There’s already a search term for this but it is kinda contorted
in:first
I do think it is completely legit to say “I only want to search for topics right now, thanks, not any replies to topics.”
This is now done per:
https://github.com/discourse/discourse/commit/0a357299b7e1f14de6dc070cae64d2163779de9b
star trek t will do an in:title search.
star trek f will do a in:first post search.
The commit also cleaned up a bit of a mess we had with our advanced search clauses where we were regexes were not bound properly … so in:first_banana for example used to work just like in:first which is very strange.
Join us on the dark side!
I don’t see how the context is relevant! My unread markers are important to me in every thread, not just the Star Trek thread :’( Why would I want my place in the post-stream to vanish? It’s annoying to lose my place in every thread. But it’s especially annoying in a thread with spoilers.
I’d disagree! The only reason the first post was useful is because it was part of the workaround for the “search destroys me read-marker” issue. I’d summarize it as:
I’m really searching for topics, rather than posts, and I’d like to arrive in a topic at my read marker
Thanks. 
When QT3 updates with this I’ll give them both a go.
Still doesn’t really make sense; the purpose of search is to arrive at the exact location of the specific thing you searched for. If I search for “finely tuned albacore”, I expect to end up on the post containing those precise words (or as close as possible), not at the first post in the topic. Claiming otherwise is … frankly, insane?
I totally understand your desire to specify a topic-only (or even title-only) search, but that has already been possible for quite some time, we added in:title and in:first over a year ago, as I recall.
↑ ↑ that’s why the context is relevant. Not every topic has spoilers. You have inflicted topics with land mines upon yourself, and since you’re well behind others in viewing the media (not a judgment, I’ve done the same thing) you have to tightly control your read position to avoid spoilers. Of course 99.9% of that is solved by using the existing search clauses to lock your search to the first post – because you aren’t searching for posts, you’re searching for a topic.
Technically you didn’t need to search for these topics at all. Since you are returning to them over and over, you could have trivially bookmarked these topics rather than searching for them repeatedly, but as you correctly noted, bookmarks don’t offer any ability to jump to your current read position. So at worst it’d be a two step process: visit the bookmark, then use the back button on the vertical timeline to jump to your current read position.
I agree that giving you the ability to jump to your current read position from a topic bookmark, and possibly from some search results, is a nice power user function.
Just a comment that our users are not figuring this out either. Every now and then we get questions on why the search takes the user into a (seemingly) random position. Clearly the use case is to find a topic that currently is not listed high on the index page, in order to continue the discussion.
But good that I found this post. Now I can at least explain the behaviour.
We recently tuned this behavior.
Current behavior is to take you to the post with “the most relevance”, this is very hard to explain to end users.
We are probably going to revert this so we simply take you unconditionally to the first hit in the topic.
I am fairly certain that our userbase would appreciate an option to land on the latest post, but our community culture is very different than for exp. Meta.
There are many options:
My pref for a default is: First post with a "search match"
Giving this as a option to forum admins would be hellish, I would need multiple paragraphs to explain all of this. Nobody would touch this setting.
This makes sense to me.
Nice to have (if not already available, I don’t remember) would for the search to be “remembered” and to have next/previous buttons/keys to find other matches within the topic once opened.
