Feature Request

Currently, when multiple Knowledge Base (KB) articles contain similar content, the search results do not always display the most relevant or preferred articles at the top. This can lead to difficulty in finding the most accurate or frequently referenced content. We request the ability to manually or dynamically control the order in which articles appear in search results.

Customer is looking for hybrid search for Eddy AI to pick the exact content search results.

The customer prefers the search bar to be displayed inline, similar to its appearance in KB Site 1.0, rather than as a full-screen overlay. Currently, in Site 2.0, the search bar appears as a pop-up at the top of the site. The customer is requesting the previous design from Site 1.0.

Currently when articles with attachments are searched for, the keywords in the attachment get highlighed, ideally we would like for users to be directed to the attachment itself rather than the article and then asking the user to do another click to open the attachment.

After running a search, it should be possible to open a result article in a new tab. The way it works now, when you open a result you lose the rest of the search results

When search finds the keyword(s) in an accordion, the accordion should be open by default when user goes to that article.

The more I use the search engine, the more frustrated I am with it. It pays no attention to quotes, so when I search for "user site" it returns every article that has the word "user" and the word "site" in it. Some of the results only have one term or the other! That's unacceptable.

There certain keywords we use that we'd like to relate to other possible keywords that customers may use. This can then surface the best articles matching those synonyms/keywords along with other search criteria. I think we can accomplish this by maintaining a synonym database that can be used as part of the search logic. For example, "Create Article" -- using "add" as a synonym keyword for "Create" so searching "Add Article" ranks "Create Article" as possibly the same. Today, we can make this work by using tags but it's not the right application for it.

Could you make the terms from the Glossary appear in the search results? Often people search for the meaning of abbreviations using the search bar so it would be useful if the term from the Glossary appeared in the search results.

I note that there is a lack of breadcrumbs displayed in the search results displayed by KB Site 2.0, and only the parent category name is displayed. This means that there is an absence of full navigational context for each article in the search results. For content in my company's information architecture, all parts of the breadcrumb are important and provide valuable information about the context of the search result. In our case, the first navigation level is product name, second level is product version, third level and lower are documentation structure. Without all this context displayed in the search results (directly displayed, rather than hidden in a tooltip), our users will be unable to understand at a glance what each search result is about. An additional factor is that multiple articles in different parts of the knowledgebase might each have a parent category that has the same name as another category in the knowledgebase. For example, there will be an Installation Guide category in the Product A part of the navigation, and also an Installation Guide category in the Product B part of the navigation, so that the user has a consistent experience when navigating the knowledgebase. In the current KB Site 2.0 search results implementation, the user would be unable to see which product’s installation guide a particular article in the search result was part of. Please could you consider how to offer customers like us an alternative search result context layout, this perhaps could be an option in Settings because I understand that the current layout in KB Site 2.0 search results will suit some customers fine. As a suggestion, perhaps in an alternative search result layout, 1.) the current category name could instead be the full breadcrumbs and occupy the whole width of the search results window, 2.) the site and language indicators could move to a new line underneath the breadcrumbs, 3.) the site and language indicators could be hidable (because, for example, in my company's case this information is not useful to the reader), 4.) the breadcrumbs line could be configured to wrap if necessary rather than truncate (although, because the current category name text is small, maybe this wouldn’t be necessary), and 5.) the breadcrumb text colour could be configurable.