[docs-infra] Add capacity to filter the search scope

[oliviernt]

Summary

Often when I search for something on the MUI docs through the Algolia search (Strg + K), I'm presented irrelevant search results for the Toolpad components first.

It'd be great to have the ability to exclude products from search.

Examples

Example of the results when searching for "DatePicker"

Motivation

No response

Search keywords: search toolpad

[danilo-leal]

Hey @oliviernt, thanks for opening the issue! I'm not immediately opposed to your suggestion, but I think there's some bug with the Algolia search ranking that's not suggesting the most relevant page, which, in this case, should be the Date Picker component docs from MUI X instead of Toolpad. @mui/docs-infra, any ideas here?

[alexfauquette]

For some pages, there are filters. For example searchin when you are in a picker docs pages, search query will get the attribute optionalFilters: ["productId:x-date-pickers"]

Some url such as mui.com don't have those filters, because from it we can not now if user is looking for the core, X, or toolpad docs

But we could look for lowering the importances of toopads API pages, because if they put one page per components, they will always appear first

[oliviernt]

Hey @alexfauquette @danilo-leal, thank you both for your fast response time.

Lowering the importance of toolpad would indeed, solve my current issue but it could possibly deteriorate the experience for other users.

My idea was that selecting which products I'm interested in would make a nice feature in itself. It would reduce the search scope, allow for people intereseted in toolpad (or any other product) to select that and make it flexible in the long run as you guys are providing more and more products...

[danilo-leal]

Yeah, I agree that having the option to tailor the search results ranking to your preference would be great! We'd still need a ranking from our side, though, because if you're a new visitor accessing the website for the first time, you wouldn't have a preference just yet. So, considering this specific example, Toolpad's Date Picker docs page shouldn't be the first resource that pops up if you're looking for that.

[oliviertassinari]

Regression fixed, https://mui.com/ is back to the baseline:

---

Details. When I do the search of @oliviernt's query "date picker" in the Agolia's UI, it tells me that pageRank is the tie-breaker:

https://dashboard.algolia.com/apps/TZGZ85B9TB/explorer/browse/material-ui?query=DatePicker&page=2&searchMode=search

Which doesn't make sense to me. Turns out, it's a regression I introduced on a bug I fixed. This change solved the problem:

        // % from https://docs.google.com/spreadsheets/d/1x9uTSMlu4xug2SfHrvr5amZ2HokYBoQaSozHmRRdVqw/edit#gid=907743010
        const baselinePopulartyProductId = {
          material-ui: 83,
-         "mui-x": 12,
+         x: 12,
          system: 4,
          "base-ui": 2,
          "joy-ui": 2,
          toolpad: 1,
        };

https://crawler.algolia.com/admin/crawlers/739c29c8-99ea-4945-bd27-17a1df391902/configuration/edit?testUrl=https%3A%2F%2Fmui.com%2Fx%2Freact-date-pickers%2Fdate-picker%2F&useLogin=true

It needed to match with:

material-ui/docs/src/modules/utils/getProductInfoFromUrl.ts

Lines 3 to 15 in 6da671c

	export type MuiProductId =
	| 'null'
	| 'base-ui'
	| 'material-ui'
	| 'joy-ui'
	| 'system'
	| 'docs-infra'
	| 'docs'
	| 'x-data-grid'
	| 'x-date-pickers'
	| 'x-charts';
	type MuiProductCategoryId = 'null' | 'core' | 'x';

---

Now, I don't think we should close this issue until the larger discussion goes to completion. It's point 3. of #16502. What we could explore:

1. On the homepage, maybe we should have a clear toggle in the search to select a product, e.g. https://nextjs.org/

AWS

MUX https://docs.mux.com/?q=al

2. Should it even be possible to have non Material UI results show in between Material UI ones?

It feels like it only makes sense for when you are on https://mui.com/, but anytime you go to a product, it should only show that product results. We could make this change:

      customRanking: [
        "desc(weight.pageRank)",
        "desc(weight.level)",
        "asc(weight.position)",
        "desc(weight.popularity)",
      ],
      ranking: [
+      "filters",
       "words",
-      "filters",
        "typo",
        "attribute",
        "proximity",
        "exact",
        "custom",
      ],

but it's kind of strange. Or, we could also make two different searches one with the filter set, and one without, so we would only show one type of results at the time. Or we could just hide all non-product related results, forcing developers to go to each doc. This might be best.

[oliviernt]

Thank you for the fix! 🚀

My personal 2 cents on both points:

1. for me the ideal solution would be to have a persisted multiple choice select of the product docs I'm searching in.
   As we're working with Material UI, I'm normally nor interested in the BaseUI, JoyUI or Toolpad docs. I do know they exist and I know how to access them if I need to...

2. I think it's nice to have results related to the seach in there as sometimes it might just be the one piece of advice one missed.

[flaviendelangle]

It needed to match with:

Looks like we are missing x-tree-view by the way

[danilo-leal]

Given there was a quick fix for the original/more immediate problem, I went ahead and rephrased the issue's title so it reflects the "filter the search scope" feature mentioned above that we'll want to explore at some point to potentially solve the issue more holistically!

[oliviertassinari]

Looks like we are missing x-tree-view by the way

@flaviendelangle On view-source:https://next.mui.com/x/react-tree-view/ I see:

<meta name="mui:productId" content="x-tree-view"/><meta name="mui:productCategoryId" content="x"/>

We are good.

[flaviendelangle]

But shouldn't we have x-tree-view in material-ui/docs/src/modules/utils/getProductInfoFromUrl.ts ?