[RFC] Search experience for new product spaces #31253
Comments
This came to my mind... Wouldn't make more sense to display results only regarding the product I'm currently looking at? I feel like preparing the search to display results across all MUI (company-wide) documentation is assuming that users are interested/actively "cross-using" the products - which could be something we wish and want - but maybe is lacking evidence?! Not sure. I guess I'd consider initially this scenario "product exclusion" first rather than the global search. |
|
Priority + badge for the package makes most sense to me too. I think it's risky to completely not display result data for other products. |
I agree that focusing search results on the product we're looking at makes sense. It creates a clear separation of products. However, not displaying other results could potentially prevent some of the users from finding out about our other products. We could hide additional results under a collapsed region (using a progressive disclosure pattern) with a header saying "Other MUI products", or something along these lines. |
|
It could work but I think I'd prioritize developer experience instead of trying to optimize for a bit of cross-selling. Given search is a heavy-used feature, it could become eventually annoying having to deal with results that are not really relevant if I'm a strict Base/Joy/one-product-only user. We could (and should) mention them when appropriate (or complementary) to a given component/problem in specific. |
|
I may have not made it clear, then - I'm for prioritizing the results that belong to the space we're in. So, someone on the Base space is searching for
and only when they decide to expand other results, they could see Material UI Button and Joy Button, etc. |
|
That could work! Might as well iterate on this and see how it feels. |
Yep, I think let's try the first step which is to display all related results and see how it feels (the result at the top will be the product space that the user is located at). |
ResultAccording to Algolia doc, the best candidate approach is to use Attempt 1: Without
|
| Joy | Base | Material |
|---|---|---|
 |
 |
 |
It is likely that the results contain only the product space search. I think it would be nice for material-ui and joy-ui to display base as well.
Attempt 3: Prepend base as extra optionalFilters
For example, if you are in /joy-ui/* the optionalFilters will be ['product:joy-ui', 'product:base']
| Joy | Material |
|---|---|
 |
 |
Note: if base has the same h1, there might be a wierd result like this which the results are grouped by docsearch library (not algolia):
I think all base components should prepend with
unstyled.
|
The best option for me is the 2nd one (thanks for showing us these though!). I'm not entirely sure we should display Base components on the search result, for either Material and Joy. The cmd+K search to me is all about speed, if folks want to dig deeper into the component build, we should for sure reference that they are built on top of Base and then link its respective Base API on that component page. I could be entirely wrong though... just my assumption! I guess I wouldn't be surprised at all if option 1 worked just as fine! We'd only need to tweak the UI a bit. |
For me, option 1 would not work. Imagine you are in
For sure, currently, we need 3 colors to separate between |
|
Oh, ok! Makes sense. So, between 2 and 3, I lean towards more to the second option. I'd want to wait more opinions here before dive deeper into the UI change it would need to happen 😅 |
|
@oliviertassinari what's your thought about this topic? |
|
@siriwatknp 👍 for option 2. Why? Because 1 would create too much noise (need to filter the list) and because 3 could create product confusion (the same component in two different products that behaves differently). |
Why?
We are about to have more than 1 space in the docs that can have similar headings. If we don't do anything, the search result will show a list of the same name (with different URL), for example:
By searching "Button", we might see
Goal
build a good-enough search experience for new spaces so that we can make them live as soon as possible
Requirement
Proposal
The first step I think is to rank the product space based on the user’s URL.
Product space ranking
Scenario 1: on homepage
When they search for “tutorial”, there is no ranking so the search result is ranked based on the object ID (default by algolia).
Scenario 2: inside a product space
If they are in material-ui space (
/material-ui/*), when they search anything the result of the material-ui space should be ranked first.Product space indicator
It is possible that the search result will show the same title like:
search for “Button”:
To make it obvious, there should be a product identifier (like a badge after the title)
Product exclusion
This one is optional if we found out it is needed. Basically for the case where developers are in material-ui space should not see the search result from another design system (joy-ui).
cc @mui/core @danilo-leal @samuelsycamore
The text was updated successfully, but these errors were encountered: