Extension talk:CirrusSearch/Query Construction/Use cases

Is there an industry perspective on an approach?

I haven't done any serious research and I'm having hard times finding example websites (other than major search engines) that provide search where results can have mixed content types.

Major search engines seem to all have adopted the tabbed search results approach to allow people dig into a particular category of results. Some have richer diversity in the main list of search results with different sections.

As for other search interfaces I've dug into (news sites, product search, library search) I could not find something that shares similar usecases (mixing different content types).

This certainly deserves further research but my impression is that UX should be adapted when different content types have to be part of a search system, I never encountered an search UI that mixes for example images and text results in the same list, it's either different sections or different tabs.

Google seems to use combined approach:

• It inserts sections of different-type content into search links list, such as images, videos, links to businesses, questions, etc. Some go on the bottom, some in the middle.
• It also has tabs like Shopping, News or Images
• It also has sidebars with some data and some related links

However, I am not sure whether what Google (as an example) does is what we want - Google has some concerns (like selling ads and search placements) that we do not, and frankly all that stuff on one search page feels a bit overwhelming and overwrought.

I know Adam is asking more about the backend, but one simplifying component to your and @DCausse (WMF)'s point, is that I don't think we should bother with multiple content types in basic search. I suspect most folks are probably searching for one content type at a time. I have never understood why we show pages, galleries, categories and files all together on commons, when the vast majority of people are primarily looking for a specific medium. It is hard for me to imagine the use case where someone says "I want a picture of a cat....or an audio of it...or a pdf or a category page. Some folks in the community might be disappointed that their curated galleries don't show up by default, and I could be wrong: I think an industry survey or some user testing could verify if users actually want mixed results. @RIsler (WMF) in case he has another interpretation.

How about for the search dispatching and routing part that's behind the UX, any insight on that?

Sorry for being late here and thanks a lot for your interest in this topic. The best I could do is guesstimate but would love someone with better expertise to weigh in. I suppose that detecting query intent plays an important role in choosing the layout of the search result page. Major search engines are probably OK to dispatch the query to many services (websearch, image/video search, question answering, location search, shopping...) including a service that is dedicated to selecting the best layout for this particular search.

It seems like "A dispatch service that select multiple best routes with tabbed search results" is the option that provides the greatest flexibility. I noticed that it only "may" break the following use cases. Would you please clarify why that is?

• As a client of the search API I want to list/count all pages that match my search query and I sometimes don't really care about the ideal search query builders
• As a client of the search API I want to be able to do everything that is done in Special:Search[1].

Also, I gather that while this says "tabbed" search results, this isn't necessarily suggesting that in fact such a UX change must happen, only that it would become possible, is that right?

I will clarify this point in the page but here is a short answer:

From a backend perspective the search system is accessed either from Special:Search using PHP internal apis or from MW API clients. Until now these internal APIs all provided a single list of results for the current wiki results.

Assuming we decide that mixing different content-types in the same set of results is something we no longer want to support we will break this usecase:

- As a client of the search API I want to list/count all pages that match my search query and I sometimes don't really care about the ideal search query builders

Secondly, assuming we provide a tabbed search interface through Special:Search we will have to provide new formats for the search API response and why we may break the second usecase you mention if we only focus on Special:Search and the internal PHP search APIs.

When I write "may" it should probably be read as: some specific efforts will have to be made to keep these usecases intact.

And I completely agree with your conclusion that says: tabbed search results might be a possible option that fits most of the usecases we would like to support (esp. when mixing different content-types) but it should not be mandatory.

I will try to rephrase this a bit more.

Thanks for your inputs!

I also like the tabbed search idea, with different namespaces in each tab

Do users really care about how many results are returned?

I'm sure some bots will just scan the number of total hits, it's why I think we still need to support (in the backend) a way to query everything even if it's not using the best components (provided by extensions).

fixed the content

> Currently not true, the go feature is not available through the API

I don't know if it's ever used (we could check ApiAction logs), but near_match is available via api using the `srwhat` parameter:

https://test.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=json&list=search&srsearch=test&srwhat=nearmatch

I completely srwhat=near_match, removed the note.

reformulated

As a user of the search UI I may find confusing to see mixed kind of metadata shown in the search results

I don't think this qualifies as "use case". Some users may be confused by some things but this is not something that is formulated as use case. The use case would be something like "as a search UI user, I want all my search results have the same metadata" - but then I'd question why one would want that. Maybe "as a search UI user, I want search results to be easily comprehensible and provide enough information about the results" - but it feels underspecified.

Agreed: changed to As a user of the search UI I want all metadata shown in the results to be clear and obvious on what they relate to.