Define standards for when search has a minimum character limit

Where possible, we shouldn't have a minimum character limit on the query string when searching or filtering. As examples, in some languages a whole name can be a single character (誠), and short labels can make sense (UX).

However, there are API's in GitLab today that do not allow less than 3 characters as doing so would have large performance impacts and/or other reasons.

This issue is to define the standards for those instances.

Related issues/MRs

• Prevent search for when under 3 characters (gitlab-org/gitlab!101540 - merged)
• Namespace filter works only after 3 characters (gitlab-org/gitlab#327658 - closed)
• Allow searching of users using less than 3 chars (gitlab-org/gitlab!79927 - merged)

added pajamasdefine label

Hi @danmh,

Please make sure that both a workflow label and weight are added to your issue. This helps to categorize and locate issues in the future.

Thanks for your help!

This message was generated automatically. You're welcome to improve it.

added workflowready for design label

set weight to 3

mentioned in issue #1213

#1213 (comment 1150170695)

@dmoraBerlin : I'm not sure on that one. An example is the label UX. I'm not sure there would need to be standards defined on that, but rather code improvements? Unless we're sacrificing code improvements to force documentation on the limitations, which doesn't feel like good UX.

This is a really good point. Thank you for raising it!

This issue is for instances where code improvements are not possible in the short term. But I agree that we should keep making the case to shift the friction elsewhere.

#1213 (comment 1151215402)

@matejlatin : Maybe there's a difference between the two types of searches we have? "Search by click" and "Search by type". The first one is not a problem, if there are at least two characters in the input field, the user should be able to search. It's the second one that gets problematic. Maybe we can trigger searches only when there are at least 2 characters in it?

You're right, I think the patterns will change depending on which of the two types of searches we have.

From what I've seen tho, where the API doesn't support less than 3 characters (gitlab-org/gitlab!100433 (comment 1147636416)) we'd still need a way of communicating that to the user in both cases.

@danmh sometimes the character limit's purpose is limiting api calls. So a way around that would be to add a delay in the api call (search by typing) and rate limiting api calls (search by click)

we'd still need a way of communicating that to the user in both cases.

I guess we could show a message below the search field, similarly to an error message, but probably not in red. I think that could work for new searches we add to the product, but what about all the existing ones? If I understand you comment right, you're thinking we change the existing search by type search boxes and add a way to communicate this?

changed the description

mentioned in merge request gitlab-org/gitlab!101540 (merged)

mentioned in merge request gitlab-org/gitlab!112862 (closed)

added groupdesign system label

added devopsfoundations sectioncore platform labels

added Category:Design System label