Improved Quick Search

mflorea · February 3, 2022, 10:58am

Hi,

I just published a proposal on how we could improve the Quick Search feature. If you think there is something I missed and that there is something that can be done better please reply to this thread and I will try to take it into account in the proposal.

Thanks,
Marius

vmassol · February 4, 2022, 12:39pm

Thanks Marius for this design page and for working on this (I didn’t see this coming ;)). Great work.

I agree with all that you wrote.

Try to reorder the categories (search sources) dynamically based on the scores (e.g. if the Users results have a higher scope than the Pages results then show the Users category first)

Not 100% sure about this one since having a fixed order can avoid some bad UX too.

Unify / merge the Jump to Page feature with Quick Search. There’s no point in maintaining both when they do almost the same thing.

If it works well enough then sure. By well enough, I mean that the Jump To Page works with references so if we can still enter page references in the Quick Search and get the link to the referenced page as the first match then it’s fine.

tmortagne · February 4, 2022, 2:42pm

Looks good in general.

Make the list of search sources extensible by converting the XWiki.SearchSuggestSourceClass into a component (implement a WikiBaseObjectComponentBuilder)

Any idea how you will name this new component ? org.xwiki.search.solr.SearchSuggestSource ?

mflorea · February 7, 2022, 10:30am

I’m not sure either. I don’t even know if we can get the score in order to be able to order the categories, and even if we get a score, I’m not sure the values are absolute, i.e. I’m not sure we can compare the scores of search results from different queries (searches).

Yes, we need to make sure we don’t lose any functionality.

The new component must be generic (should go in the generic search API) so probably org.xwiki.search.SearchSuggestSource (there’s a property to specify the search engine hint).

tmortagne · February 7, 2022, 1:56pm

OK even better

Simpel · March 12, 2023, 12:05pm

Hi.

As mentioned in the design proposal we switched to “top hits” meaning the usage of Main.SolrSearchConfig in the suggestion. We translated this config to the query the suggestion is needing.

We now only provide 15 “top hits”

__INPUT__ __INPUT__* *__INPUT__ *__INPUT__*
fq=type:DOCUMENT
fq=-space_exact:XWiki*
qf=property.XWiki.TagClass.tags^15.0 spaces^15.0 title^10.0 name^10.0 doccontent^2.0 objcontent^0.4 filename^0.4 attcontent^0.4 doccontentraw^0.4 author_display^0.08 creator_display^0.08 comment^0.016 attauthor_display^0.016

and 3 “accounts”

__INPUT__ __INPUT__*
fq=type:DOCUMENT
fq=class:XWiki.XWikiUsers
qf=property.XWiki.XWikiUsers.last_name^10 property.XWiki.XWikiUsers.first_name^5 name^2.5 object.XWiki.XWikiUsers
fq=wiki:xwiki

That’s much more our users expect. If looking for attachements they will press enter anyway and use main search.
Regards, Simpel

lucaa · March 27, 2023, 4:02pm

Hello @mflorea,

Loading...

I am not really sure I understand this need. It needs to be clarified, not confused with “search string suggestions” and make sure that what we’re providing does not create any confusion about this.

What Google (mentioned in Loading...) does is to suggest search strings, not results, based on what other people have searched before. This is definitely not what the quicksearch of XWiki does nor what it can do, as XWiki is not storing people’s search queries.

If you launch a search on Google with “someth” as the search string, the results are for “someth” and Google suggests to update the search to “something” but does not search for “something”.

I guess for me Loading... would makes sense if presented as a “live results”, kind of thing: having results live as you type and the more you type the more the results get precise to match your typing, which is when prefix searching would make sense, as it would always assume that what the user has typed is the prefix of something longer.

Unify / merge the Jump to Page feature with Quick Search. There’s no point in maintaining both when they do almost the same thing.

I’m -1 on this, and, while we’re at it, we should rollback the jump to page feature to do raw page reference exact matching, on both the search itself and on showing results. The point of maintaining both is that one is a power user technical feature (jump to page) for when one knows exactly the reference of the page and wants to find the page by reference, while the other is a user oriented feature, full text search (the quick search).

Add links to view all the results for each category (search source)

While this may be a good idea, I think it’s important to also keep a way to access the search page for the typed string. If I understand correctly, fully submitting the search form would actually do that, so we’d basically have 2 ways of accessing the full results page:

submitting the search form
clicking on each individual “view more …” links.

I’m afraid the first method is very useful and needed but not that discoverable…

Make the UI consistent by using a Bootstrap dropdown to display the results

I think we may need to try also to see what happens with longer page names and longer paths, to choose the proper width of the dropdown (may need to be a bit wider).

Otherwise this looks good, thanks for the work!

mflorea · March 28, 2023, 11:16am

lucaa:

I am not really sure I understand this need. It needs to be clarified, not confused with “search string suggestions” and make sure that what we’re providing does not create any confusion about this.

What Google (mentioned in Loading…) does is to suggest search strings, not results, based on what other people have searched before. This is definitely not what the quicksearch of XWiki does nor what it can do, as XWiki is not storing people’s search queries.

If you launch a search on Google with “someth” as the search string, the results are for “someth” and Google suggests to update the search to “something” but does not search for “something”.

I guess for me Loading… would makes sense if presented as a “live results”, kind of thing: having results live as you type and the more you type the more the results get precise to match your typing, which is when prefix searching would make sense, as it would always assume that what the user has typed is the prefix of something longer.

For me the need is clear: support by default substring matching in the quick search. That is, when typing “xyz” show results that match both:

“xyz” as a word (analysed, e.g. extracting root word, etc.)
“xyz” as a substring, i.e. *xyz* (where * is a wildcard for any characters)

I don’t see anything in xwiki-platform/xwiki-platform-core/xwiki-platform-help/xwiki-platform-help-ui/src/main/resources/Help/Translations.xml at master · xwiki/xwiki-platform · GitHub (we have a tip for it displayed in the tips panel for all the users) nor in https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/KeyboardShortcuts#HNavigation to indicate that it’s only for power users. I don’t see why simple users can’t have the need to jump to a given page (without knowing the technical page reference).

As for what you use to search, I don’t see why the quick search couldn’t also match the reference. Putting aside the search input, both UIs serve more or less the same need, so I don’t think it makes sense to keep both when we can have a single UI that supports both type of searches.

No, the quick search results are not the same as the ones you get on the main search page. The main search page provides by default generic page results, while the quick search collects results from various specific sources (attachments, users, etc.). Hitting enter on the quick search opens the main search page. Currently there’s no easy way to open the main search page preconfigured to show the results from a specific source, i.e. to show attachments or users. You need to check how the quick search source is configured and manually try to reproduce that configuration on the main search page (apply the same filters, use the same weights, etc.). The idea is to hide this behind a link so that any user can access it quickly. Hitting enter on the quick search input would still work, and open the main search page with the default configuration. So there’s no feature duplication here.

Thanks for the feedback,
Marius

Wardenburg · March 28, 2023, 12:03pm

I love the idea to improve quick search! As a new xwiki user I’ve seen a lot of new users struggle with the current search bar functionality (they expect ‘google’ results) +1 !

I wrote in Changing (default) Solr tokenisation (EdgeNGramFilterFactory) - Help / Discuss - XWiki Forum about my own attempts to emulate this but lack the solr/xwiki experience to get it implemented. Currently I have a page/table with the possiblye search paramaters to educate users on the solr possibilities. (It’s in dutch but I’ll gladly share it if there’s interest)

Considerations/feedback:

Consider adding pageTags to the list of search sources provided by default. I think this would add a user friendly way to improve precision/recall of searches (especially when combined with a proximity search) - in general think the page tags are a solid adition to the ‘modern’ metadata approach to storing/finding pages- including it in the quick search will promote usage.
Perhaps adminpanel settings could include a max leviathan distance (or something along those lines) with which the quick searchs’ granularity can be steered.

question:

Will the new quick search functionality be integrated with the search panel also?

mflorea · March 28, 2023, 4:35pm

I don’t think so, at least that’s not part of my proposal. Do you really need the search panel if you have the quick search? Maybe to have a domain specific search (i.e. search the entries of a given application) but in that case it can’t behave like the quick search: it shows results from a single source.

Wardenburg · April 5, 2023, 7:26am

You’re entirely right, hadn’t consideredd just not using the search panel.

Thanks! Good luck with the solr!