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
Resting state:
Increase the width of the search box to 240px
Remove the scope indicator (This group and This project).
Rephrase the placeholder to: “Search or jump to…”
When the search bar becomes active:
Project
Group
Global
The width of the search box should increase to 320px for more comfortable typing.
The width of the suggestions dropdown should be 320px
The separator between the options for issues and MRs should be removed.
The headers that indicate the scope should be as follows:
Project: Name of the project (no change)
Group: Name of the group (no change)
Global: All GitLab
The style of these headers should match the 'Header title' style from the dropdown library spec previews.
Once the user starts typing:
[Examples for all the possible row types can be found here]
The max height of the suggestion dropdown should be 400px
There should be a fade effect layer at the bottom to indicate the dropdown is scrollable.
All substrings inside the dropdown which match the query should be bolded.
The first row should be automatically highlighted, so the user can just press Enter to search.
The first rows in the dropdown should allow the user to perform a search for the entered term:
Search rows for project scope:
Row 1: Magnifying glass + "KEYWORD" in this project
Row 2: Magnifying glass + "KEYWORD" in all GitLab
Search rows for group scope:
Row 1: Magnifying glass + "KEYWORD" in this group
Row 2: Magnifying glass + "KEYWORD" in all GitLab
Search row for global scope:
Row 1: Magnifying glass + "KEYWORD" in all GitLab
After that, navigation suggestions will be shown for projects, groups, pages inside the project/group, preferences pages and help pages that match the string entered.
Project and group rows will show their avatar on the left side.
The size of the avatar will be 16px x 16px
The margin between the avatar and the name will be 4px
If the project or group doesn't have an avatar, the generic one with its initial should be used.
The headers for each type of suggestion should also be updated to match the spec previews
The header for pages in the project or group should be renamed to:
@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.
@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 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.
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?
Maybe take a quick look at GitHub's new “Search or jump to…” field to see if we can learn something from that
For the text search, we might get away with just having 'keywords' in this project and 'keywords' in all GitLab since it's prefixed with the search icon (which is a known pattern). For a11y, we can have a visually hidden [Search] 'keywords' in this project.
Instead of Quick search… I think we can keep the current project/group name and, if in a global setting, just have All GitLab — WDYT?
I think you're the right person to follow this through. In any case, I'll be here assisting
I'd like for us to see if we can also use this issue to solve the fact that you cannot search for both project/group name and slug (see https://gitlab.com/gitlab-org/gitlab-ce/issues/36409#note_38084612). Or maybe you can and it's buggy today? It would be great if a developer looked into this.
@pedroms I agree. I made some changes to the design to make sure the Frontend at least highlights the matching string in the slug. I'll make an issue to improve the backend, since search does not seem to be taking slugs into account.
Maybe take a quick look at GitHub's new “Search or jump to…” field to see if we can learn something from that
I think they have some really interesting ideas, like the navigation suggestions they offer right off the bat and the ↵ badge to indicate navigation. This issue is an implementation deliverable, so let's address that in another issue, mauybe #28962 (moved)
For the text search, we might get away with just having 'keywords' in this project and 'keywords' in all GitLab since it's prefixed with the search icon (which is a known pattern). For a11y, we can have a visually hidden [Search] 'keywords' in this project.
Great suggestion, I changed this in the description.
Instead of Quick search… I think we can keep the current project/group name and, if in a global setting, just have All GitLab — WDYT?
This is also part of the design now
I never got back to this question you posted:
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.
My reasoning was that the longer string was actually too long to fit in the search box in its resting state, and Search or jump by itself didn't seem descriptive enough. Obviously GitHub is using it now, so I settled for Search or navigate…. We can definitely still use jump if we want to, though, what do you think?
I'd like for us to see if we can also use this issue to solve the fact that you cannot search for both project/group name and slug (see https://gitlab.com/gitlab-org/gitlab-ce/issues/36409#note_38084612). Or maybe you can and it's buggy today? It would be great if a developer looked into this.
@pedroms I agree. I made some changes to the design to make sure the Frontend at least highlights the matching string in the slug. I'll make an issue to improve the backend, since search does not seem to be taking slugs into account.
@cperessini I see that this issue is only for frontend, so that makes sense. Please do create the issue.
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.
My reasoning was that the longer string was actually too long to fit in the search box in its resting state, and Search or jump by itself didn't seem descriptive enough. Obviously GitHub is using it now, so I settled for Search or navigate…. We can definitely still use jump if we want to, though, what do you think?
@cperessini if we don't have a strong opinion for having Search or navigate, I would suggest we went for the same as GitHub's Search or jump to…, as it also works and has the added benefit of familiarity.
if we don't have a strong opinion for having Search or navigate, I would suggest we went for the same as GitHub's Search or jump to…, as it also works and has the added benefit of familiarity
The group and project names are great headers because they not only tell you that you are in a group or project context, but they also tell you which one
Nevertheless, we have a type of search results that returns pages inside the project or group. I thought the name of the project or group didn't work as well here, since it might feel like the name was a search result. That's why I kept the more generic In this project/group.
In order to keep these two types of headers consistent, I chose to use the generic one in the initial dropdown.
I didn't think that All GitLab by itself was descriptive enough to indicate that what was below was scoped to 'all GitLab'
I don't think these arguments are particuarly strong as I don't have any data, it was more my intuition. If you feel your proposal makes more sense, we can use that.
@cperessini I don't see a big issue with having “inconsistent” headers if showing the group and project names provides a better experience in the initial state. And then, in the results state, having "KEYWORD" in this project makes sense because of space constraints.
In terms of having In all GitLab or All GitLab in the initial state, the first one sounds odd to me, but that's it. So with this, I won't bug you anymore and I defer the final decision to you
Thanks for the feedback @pedroms. I reverted the group and project ones to use the actual names and changed the global one to All GitLab.
For the search results, I left it as In this project so it's static. I feel that "KEYWORD" in this project is more appropriate for returning results relating to content, not pages in the project. That's actually the same string we use for performing an actual search in the first row!
@dennis: we spoke about this one during our Admin Frontenders call, thanks for volunteering to have a look @timzallmann took a quick look and there may be some backend work required, so I've made https://gitlab.com/gitlab-org/gitlab-ce/issues/48920 just to make sure we've got that support in place.
I think we get most of what we need from /search/autocomplete, but we may need to add to this endpoint.
Hi @jeremy_, sorry for not getting back to you sooner! I took a look as well and thought otherwise. That said, I'm meeting with Tim later today so we can discuss it then and determine what's required for backend support, if required.
@jeremy_: I spoke with @timzallmann, backend support may be necessary since we need to retrieve the avatars, but I'll dig into it a little further and see if that support is truly needed!