-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
General requirements for search boxes #835
Comments
@filippomc @D-GopalKrishna @SimaoBolota-MetaCell @sanjayankur31 please let me know if any of the above is not in line with how you believe(d) the searching/filtering should work, and we can discuss. |
@pgleeson the current implementation of the search is much simpler (LIKE match on title and tag match) and is as what you suggest would be ideal but requires a more sophisticated implementation of indexes as the more we include, the less the search is filtering out, so it's necessary to implement a relevance based sorting, so rely on a full-text-search engine. This is especially true the moment that we include the summary. Also including the username could lead to complications performance wise as usernames sit in another database. How much do we want to push |
Yes I will address that here - #828 (comment) thanks! @pgleeson |
@filippomc It seems the repositories search does search over the summary text too, here 'recognize' in the text is matched for the search term 'ecog'... |
Yes true, although not sure it makes sense now with a lot repositories without full-text search and relevance sorting |
Can't see any reason to remove it unless it impacts performance. All the more reason to be able to refine the search with AND linked tab searches. |
It does not impact performances, it's more about having a relevant sorting as matches in titles and tags should bump higher than matches in long text. This becomes more evident with lots of content and using generic words |
I am intensely relaxed about someone searching for a term and getting lots of relevant, correct matches... |
Closing as this is generally how it's implemented now. |
As there are a few related open issues related to search in repos and workspaces, I'm just outling here the general principles that the search boxes should aim for.
The golden rule is that since the search box is the only things that's visible to the user (the tab filter needs to be clicked to show it), typing something in here should search over the maximum number of fields to find something for the user (independent of capitalisation).
So for workspaces, all of the text shown (title, summary, tabs, even username if possible) should be searched over:
Similarly for repositories.
The tab filter should be considered an advanced setting for refining search results, by specifying an exact string for the required tab, though this can be case insensitive. Typing something in the search box shouldn't add anything in the tab filter.
Generally, behaviour of the search box/tab filter should be the same for both repository and workspace pages, either thumbnail or list views.
The text was updated successfully, but these errors were encountered: