RunDMC
RunDMC copied to clipboard
Search suggestions should target most-likely results
I was given a suggested improvement to the docs search:
I’m searching for insert in the search box. It’ll be great if I can be taken to xdmp:document-insert() and have “Did you mean” for other inserts. Right now, it is not available.
Searching for "insert" takes you directly to the lnk:insert
page, which is less likely to be the intended target than xdmp:document-insert
. Likewise, searching for "delete" takes you to flexrep:delete
rather than the more likely xdmp:document-delete
.
I think we'd have to hard-code preferred targets for searches like these. Something to consider.
I am not crazy about this search suggestion because I don't really want to take on the maintenance burden of maintaining weights or whatever as we add functions to the product.
I also feel that this is attempting to scratch nearly the same itch as the TOC filter. The TOC filter won't cough up solely xdmp:document-insert
, of course, but I actually think what it does is better because that might not actually be what you're looking for. Instead, you get a small, scannable list of results from which to choose. Assuming you don't filter on something stupid like "s".
I think the TOC filter is under-utilized because:
- People don't really understand what it does.
- The stupid thing doesn't work right half the time, as you and I know, to our dismay.
- Hitting return in that text box flips you into full search because...reasons.
Another way to address this problem might be constraints. For example: func:insert
. It doesn't really address this request because it doesn't boost xdmp:document-insert
. It's more like an alternative to the filter-box-from-hell. Of course, Sam would remind me that users never discover constraints, plus we have no help or anything else that describes them, and no advanced search box to do an end run around the whole problem. So, I talked myself out of that idea. :)
@gfurbush and @jmckean17 Do you have any thoughts on this subject?
Should we change the "hitting return in the that text box" behavior?
Should we change the "hitting return in the that text box" behavior?
It certainly wouldn't hurt MY feelings. I've disliked that interaction from Day 1. After several years, I still forget and do it sometimes, which leads to head-desk action.
I'd like to get some input on all of the above from Jane and/or Gordon, though. Who am I to make executive decisions? etc. I gave them a nudge this morning to check this thread.
I don't have a strong opinion about this because I mainly avoid the TOC search, but it would be great if pressing return in the TOC search box did not send you to searching all of the documentation, just what you had filtered already. For instance if I'm in guides and I type 'security' in the TOC search, I expect to look at only guides, not everything. Am I understanding the issue correctly?
That's basically how it does work, Jane. If you type, say, "module" into the TOC filter and hit return, it'll do a full content search on "module", just as if you had typed it into the search box.
The way the search works is a little more complicated than that, though, so it's not always obvious that's what's going on: If you type a term into the search box that exactly matches the name of a function, the search takes you directly to the function page instead of to broader search results. So, if you hit return in the TOC filter, it might take you to the search results for your term, or it might take you to a specific function. I'm not personally crazy about this feature, either, but I think there are a lot of people who like it a lot.
This behavior is actually what gave rise to the original RFE in this thread. If you search (not filter) on "insert", it brings up the page for lnk:insert
because it is an exact match to your search term. However this is extremely unlikely to be what you were looking for. On the other hand, if your term was "document-insert", it'd pop up xdmp:document-insert
and the app looks like a hero.
All this makes me wonder: Why on earth don't we use search:suggest in the search box? If we really want to prioritize function apidoc over other things (which is what we do now), why not have suggestions scoped to the functions?
Maybe it'd be too slow. Maybe it's not possible to "wildcard out" the namespaces in generating suggestions. Maybe it's too hard to do a good jobs: If I type "xdmp" vs "insert", the suggestions should probably use a different algorithm. Etc. It might be worth wasting some brain cells on sketching out desirable behaviors in the future, though.