Clarify the usefulness of the search bar

Description

With #35269 (closed) we're removing the “project switcher” from the breadcrumbs to avoid duplicating existing functionality. The current search bar already searches projects, groups, project pages, settings, and help pages — it's an incredibly powerful and useful tool, yet it's too subtle and unnoticed for any kind of user. We need to make this functionality clearer and accessible to everyone. This will be a step in the direction of making the search bar become more of an omnibox, Spotlight, or Alfred.

Proposal

There are two changes that will dramatically improve the search bar:

• Rephrasing the search bar placeholder to: “Search or navigate GitLab”
• Removing the scope token and indicating the search scope with options inside of the dropdown
• Global option: Search GitLab for 'git'
• Group-scoped option: Search this group for 'git'
• Project-scoped option: Search this project for 'git'

Normal	Focused	Active/open

If the user is not in the context of a group or a project, there is only a global-scoped suggestion in the dropdown:

Other minor changes in this proposal:

• Slightly expand the search bar on focus to allow for more comfortable typing
• Search suggestions should always be at the top, above navigation suggestions
• Change the active state style for the search bar so it has a white background
• Copy changes to the menu that default options in the search dropdown:
• Global: Quick search
• Group: Quick search this group
• Project: Quick search this project
• Remove the separator between Issues I've created and Merge Requests assigned to me
• Style project suggestion rows to match #35010 (closed)

Links / references

• Related: #35010 (closed)

mentioned in issue #35010 (closed)

mentioned in commit gitlab-design@321f3914

mentioned in issue #35269 (closed)

@cperessini @mydigitalself please take a look at this as a way to compensate for the removal of the project switcher — it's being removed in %10.0 and we haven't decided upon a solution yet :yikes:

@cperessini feel free to take the lead on this issue while I'm away

@pedroms I think this is a good idea. We will need to tweak the dropdown so you can change the scope of your search, but what you proposed is most of the way there. Something like what you made for your navigation concepts would be great.

I'll take this on while you are away and add a proposal here.

removed assignee

assigned to @cperessini

@pedroms @cperessini i was under the impression the switcher was being included in https://gitlab.com/gitlab-org/gitlab-ce/issues/35010?

@mydigitalself we don't want to duplicate the search bar functionality. Since the global search bar already does everything the other one does and more, we'll just keep the global one.

The dropdown from #35010 (closed) will have a switcher, but it will show you a list of your recently accessed projects instead of every project you participate in like the current switcher does.

@cperessini

Since the global search bar already does everything the other one does and more

Not really...

cc @pedroms

@mydigitalself you have to use the project name, not its slug

@cperessini in the switcher gitlab-ce works just fine...

I understand where you are coming from, but to me, the Projects link/dropdown seems to be a natural place for switching to projects and I'm not convinced it should be removed from https://gitlab.com/gitlab-org/gitlab-ce/issues/35010

On one hand you're trying to de-duplicate functionality and have one consistent place to do something, on the other you're shoe-horning multiple pieces of functionality into another place, and seemingly the functionality is somewhat different.

I'd like to get this resolved ASAP please - if you wanted to discuss it, happy to jump on a call.

changed the description

the Projects link/dropdown seems to be a natural place for switching to projects

@mydigitalself I agree that the dropdown is a natural place for switching projects. That's the main motivation for #35010 (closed), and I think that what makes the most sense and will help users most is to show them a static list of their recently accessed projects.

I don't think we need a dynamic list with a search bar in the dropdown if the list we offer matches the users's needs 90% of the time.

on the other you're shoe-horning multiple pieces of functionality into another place, and seemingly the functionality is somewhat different.

I don't see it this way because the functionality is already there in the search bar. Like @pedroms mentioned in the original description, the goal is to move the search bar in the direction of tools like Spotlight or Alfred, and I actually think it's a great deal of the way there already.

You can currently use the search bar for jumping to projects and groups, but it also gives you options for navigating inside a project, jumping to your settings or going to specific help pages

The search bar should be the go-to UI for switching to a specific part of the app, so I think that with this issue we are not trying to make up for functionality that we lost in #35010 (closed), but rather we are trying to bring attention to something that's very powerful and already part of the app.

In-project navigation	Settings and help

---

I wanted to put these thoughts down on the issue, but we can definitely talk about it today.

I updated the description with a little more detail in case we move forward with this proposal.

I don't think we need a dynamic list with a search bar in the dropdown if the list we offer matches the users's needs 90% of the time.

I think that's the problem, it's somewhat nondeterministic if the dropdown will suit your need or not and then you have to go to another place when it doesn't and that leaves you with two places to go to switch projects, which imho is frustrating.

@mydigitalself The current search doesn't take into account project slugs/handles like the project switcher does, but I don't think that's a good argument for keeping the project switcher. However, I do agree that it can be frustrating having to go to two places to switch projects if you don't find what you're looking for in the project switcher. I had thought about this and, initially, it made more sense to de-duplicate the search functionality and keep everything in the search bar.

@cperessini thanks for taking over and updating the SSOT a couple of questions:

• what's your reasoning for changing the placeholder from Search or jump to a project, group or page to Search or navigate GitLab? I find it a bit “vague”… but I'd like to hear your thoughts.
• why does it have a section title “Quick search this project” for issues and merge requests?

marked this issue as related to #37514

Created #37514 to solve the inconsistency of searching project slugs/handles.