Suggestion: Add search option on all blog categories

[amareshsm]

What problem do you want to solve?

Currently, the search function is only available for the "everything" category (https://eslint.org/blog/). This means that searching within other categories, such as Announcements or API changes, is not possible. To search for content from these other categories, you must return to the "everything" category each time.

What do you think is the correct solution?

Add the search option in other categories also.

Participation

• I am willing to submit a pull request for this change.

Additional comments

No response

[nzakas]

Two concerns:

1. I'm not sure that it would make sense to only search within specific categories.
2. I'm not sure it would be obvious to people that the search box only searches within a specific category.

I think it's a good idea to add the searchbox everywhere, just not sure about the behavior.

[amareshsm]

Two concerns:

1. I'm not sure that it would make sense to only search within specific categories.
2. I'm not sure it would be obvious to people that the search box only searches within a specific category.

I think it's a good idea to add the searchbox everywhere, just not sure about the behavior.

Yes, it's a good idea to display search results from a specific category. Can we add a prefix in the search input, like in:category, similar to GitHub's PR search box?

The only issue I see with this approach is that we don't have enough space in the input field to display both the search text and the prefix text. To address this, we could open the search options in full-screen mode when the search input is clicked, which would solve the space problem. Additionally, we can enhance the way we display the search results.

If this works, we can also implement it on the docs site to display the results more effectively.

[nzakas]

@amareshsm the search is done through Algolia, and so we'd need to use whatever options they have. We'd also need to make sure the crawl is updated to tag information correctly.

Overall, I'm just not convinced that it makes sense to search within a specific category. What use case are you thinking of?

We decided against using their widget because we didn't like having a full-screen overlay for search.

[amareshsm]

@amareshsm the search is done through Algolia, and so we'd need to use whatever options they have. We'd also need to make sure the crawl is updated to tag information correctly.

Overall, I'm just not convinced that it makes sense to search within a specific category. What use case are you thinking of?

We decided against using their widget because we didn't like having a full-screen overlay for search.

The use case I’m thinking of is to allow users to quickly narrow down search results to a specific context, improving their ability to find relevant information. For example, if a user is looking for documentation, tutorials, or specific topics within our platform, being able to search within a specific category can significantly reduce the time and effort needed to locate the desired content. This can enhance user experience by providing more precise and relevant search results.

However, given the constraints with the search input field and our decision not to use a full-screen overlay, we can proceed by adding the search box with its current behavior to every other page for now.

[nzakas]

However, given the constraints with the search input field and our decision not to use a full-screen overlay, we can proceed by adding the search box with its current behavior to every other page for now.

Sounds good. 👍