Search result should take you to actual location of result in doc

[barbara-sfx]

Details

Search for the word extrapolation, then click on the "Plotting Metrics and Events in the Chart Builder" results link.

• Read the Docs project URL: product-docs
• Build URL (if applicable): docs.signalfx.com/en/latest/
• Read the Docs username (if applicable):

Expected Result

When I click on the result, I expect see the sentence/para containing the result (same sentence that was excerpted in the search results page). If there are multiple matches in a doc, that link is the first occurrence on the page.

Actual Result

I am placed at the top of the file and either have to scroll until I see the highlight, or search in the page for whatever I just searched for in the search box. In this case, I would have had to scroll through a large number of pages, (This is the longest doc in our doc set.)

[safwanrahman]

It can be a good improvement that is good for user experience. We will see if we can integrate it with search upgrade.

[ericholscher]

Do you have an example of somewhere that has implemented this? It seems like each entry in each document would need to be it's own search result, which would make the design of the search interface much more complex.

[ericholscher]

Just following up here. We've implemented something like this in the past, but the user experience around it was tricky. If you have ideas for how this would work in terms of the user experience, I'd love to get it working.

I think we could perhaps implement this in Javascript, and have the browser scroll to the first instance of the highlight param, but I think that could also be confusing and would need to be built into the theme instead of on our side.

[agjohnson]

I constantly hit this and wish we scrolled directly to the result as well. I was about to make an issue for multiple search results per page, which would be dependent on having a better solution for linking to individual results. I think both are really helpful features that we should be working on.

A great example of search is the webpack docs (the search hidden in the top nav):
https://webpack.js.org/concepts/

It looks to always link to the section that the result was found in. I feel like this might be better UX than linking only to to the found page (and only showing one result per page). What are folks thoughts on making the search results page use a section index, not a page index?

If we stick to the page index, I think we can do almost all of this without patching the sphinx search/etc JavaScript. A basic implementation would target the first highlight element, a more advanced version would target the Nth highlight element.

[ericholscher]

That looks like it's doing API objects based linking, which we can do with my work around #4767 and search. We could also start re-doing Section based indexing instead of pages. I think newer ES is able to handle this nicer where we could nest sections inside a page, and only return 3 "sections" for a page, but be able to link to them.

Of course, we'd only be able to link to places that we have the ability in HTML to link to, do sections or API object definitions, not specific text in the copy necessarily, unless we build it in JS.

[dojutsu-user]

Hi @barbara-sfx
We have now support for this and the code is already deployed to production a few days back.
You can find more info on our blog - https://blog.readthedocs.com/improved-search-and-search-as-you-type/
Thanks for your patience.
I am closing this issue.