Jupiter - Return search bar to left navigation in WHM
Completed
The search bar on the right side is actually not very intuitive and seems to actually interfere with tasks as it covers the main panel with a blue haze making everything unclickable if you are showing search results. We would like the ability to return it to the left side, We would also like the search to not block out clickable content when results are displayed. This would result in fewer clicks being required when multitasking on a computer.
This has arrived in v102.0.12. Please check it out and let us know what you think.
This has arrived in v102.0.12. Please check it out and let us know what you think.
We are currently evaluating ways to bring a filtering capability back to left navigation. Expect more specific updates about it as the dev team firms up their plans.
We are currently evaluating ways to bring a filtering capability back to left navigation. Expect more specific updates about it as the dev team firms up their plans.
Here's a work-in-progress screenshot from a development build. A few details and visual tweaks may change but the behavior and keyboard integration has been restored from how it worked in previous versions of WHM. One notable exception, though, is the keyboard shortcut to jump into it is now ctrl+/ (rather than just /).
The first iteration of the results-ranking is based on a simple direct-matching (which is how previous WHM navigations worked). In a followup, we intend on bringing the full power of the fuzzy-searching algorithm from the top search to this area as well. It will become more tolerant to typos, misspellings, and other "not exact match" queries once that happens.
Here's a work-in-progress screenshot from a development build. A few details and visual tweaks may change but the behavior and keyboard integration has been restored from how it worked in previous versions of WHM. One notable exception, though, is the keyboard shortcut to jump into it is now ctrl+/ (rather than just /).
The first iteration of the results-ranking is based on a simple direct-matching (which is how previous WHM navigations worked). In a followup, we intend on bringing the full power of the fuzzy-searching algorithm from the top search to this area as well. It will become more tolerant to typos, misspellings, and other "not exact match" queries once that happens.
This has arrived in v102.0.12. Please check it out and let us know what you think.
This has arrived in v102.0.12. Please check it out and let us know what you think.
For now, the interface will have two searches, one in the top right and the filter in the left.
We hope to retain the search in the top-right because it returns results ordered by relevance. You'll always get the best match to your query as your first result. We've also added your user accounts as potential search results there and we hope to bring more into the mix, making it a "jump menu" with time.
The search in the left navigation is probably better characterized as a filter because it simply refines the navigation tree to matching results. With v106, we're hoping to bring better matching to that filter by forgiving typos (fuzzy searching using the Bitap algorithm, read more here), adding more to the index entry for each link like feature descriptions and category names, and making it localization aware so that our global users can use it in their preferred language.
BUT, the big differentiating factor is that it's just a filter. Results will come back in the order specified in the navigation tree, not relevance. The first result is not likely to be the best result. It's been that way for a while and we want to provide something better.
For now, the interface will have two searches, one in the top right and the filter in the left.
We hope to retain the search in the top-right because it returns results ordered by relevance. You'll always get the best match to your query as your first result. We've also added your user accounts as potential search results there and we hope to bring more into the mix, making it a "jump menu" with time.
The search in the left navigation is probably better characterized as a filter because it simply refines the navigation tree to matching results. With v106, we're hoping to bring better matching to that filter by forgiving typos (fuzzy searching using the Bitap algorithm, read more here), adding more to the index entry for each link like feature descriptions and category names, and making it localization aware so that our global users can use it in their preferred language.
BUT, the big differentiating factor is that it's just a filter. Results will come back in the order specified in the navigation tree, not relevance. The first result is not likely to be the best result. It's been that way for a while and we want to provide something better.
Replies have been locked on this page!