Navigation - Add dropdowns to global links in top bar

Resources

FE @kushalpandya | UX @cperessini

In order to provide quicker access to projects we add a dropdown to the Projects link in the top bar. The dropdown will open on click, following the behavior of the + button and personal dropdowns in the top bar.

The dropdown will contain direct links to the different subsections of the Projects dashboard (Your Projects, Starred Projects and Explore projects).

On the right-hand side of the dropdown we will show a list of frequently accessed projects and a search box to navigate to other projects not present in the list.

The list of frequently accessed projects will be stored in localStorage. Every time the user visits a project, the Frontend evaluates how frequently that project is visited and adds it to the list if appropriate.

• The dropdown will show up to 4 of the most frequently accessed projects
• The list will have a static header, Frequently visited
• If there are no frequent projects to show, an empty state message is shown: Projects you visit often will appear here
• The height of the dropdown is always the same, which gives us available space to show search results
• The avatar for each project should be shown next to its name
• The project's parent group (or groups) is shown in a second line in the same style as the breadcrumbs
• The dropdown should follow the style used in https://gitlab.com/gitlab-org/gitlab-ce/issues/28921#note_36011920

Empty state	1 project	2 projects	3 projects	4 projects

Search box behavior:

• When the dropdown is opened, the keyboard focus is automatically put on the search box
• When the user starts typing, the frequent projects list is replaced with a blank background. We can add a spinner if we expect results won't be instant
• The results are shown right below the search bar
• If there are no matching results, an error string is shown: No projects matched your query
• The current project switcher only searches projects you participate in. In this iteration we should the same behavior

Spinner	Results	No results

For mobile we make the dropdown full-width to account for long project names. We show the list of projects below the navigation links.

Searching on mobile inside the dropdown wouldn't be comfortable, so the search box is hidden.

Since vertical space will be more limited, the list should show only 3 projects instead of 4 on mobile.

Empty state	Frequent projects

For logged-out users we don't show the dropdown at all because:

• If users are visiting GitLab without an account they probably are occasional visitors who won't have frequently visited projects. If they do, they probably always access those projects directly
• The search box only searches projects you participate in, so it would always return empty results
• The only link on the left side would be Explore projects, so we'd be requiring two clicks where you currently only need one

cc @mydigitalself for scheduling

removed assignee

changed milestone to %Next 2-3 months

mentioned in issue #35121 (closed)

@cperessini will this mean an extra click to get to your list of projects, or is the drop-down a separate click-target?

mentioned in issue #34917 (closed)

changed milestone to %10.0

added frontend label

added Deliverable label

assigned to @cperessini

changed the description

Updated the description with designs.

I left out a Group switcher in this issue because I don't think we have a Backend for that yet. @mydigitalself can we find out if this can be added for groups too?

We can add a dropdown with just options for Your groups, Explore groups and New group, but that doesn't add much value and it puts the current behavior one click further away.

changed the description

Talked with @mydigitalself and we'll add the dropdown to Projects for now. We'll consider adding it to Groups in the future.

Can we create a new issue to keep track of adding the dropdown to groups?

mentioned in issue #36234

Created https://gitlab.com/gitlab-org/gitlab-ce/issues/36234 for the Groups dropdown

Just my 2 cents:

• As a user I would not expect the button "New project" in the projects dropdown. There is the + button for creating new projects and groups in the navbar already.
• The dropdown ui is a little bit confusing- having a dropdown which links to different section of the projects dashboard does not brings any benefit.
• I would suggest to build a quick way to show last accessed, starred projects and allow the user to quickly search these lists directly in the dropdown. This would add value!

One suggestion how this could look like:

• Last accessed would show the last 5-10 projects the user accessed last time
• Starred projects will show the 5-10 starred projects. User get a "more" link to load all starred projects in the dropdown.
• All projects will show the 5-10 projects where the user has access to. Ordering is influenced by last activity in the project.
• The search would trigger a search in all projects of the user and will show a match to the search term of the user.

What do you think?

assigned to @kushalpandya

As a user I would not expect the button "New project" in the projects dropdown. There is the + button for creating new projects and groups in the navbar already.

I agree here. It seems redundant to the plus button and feels as though we are mixing actions here.

I would suggest to build a quick way to show last accessed, starred projects and allow the user to quickly search these lists directly in the dropdown.

This is an interesting proposal, thoughts @cperessini?

The addition of the search is reminiscent of the current chevron dropdown. We have talked about removing/relocating this. This is a good potential candidate but perhaps in the next iteration is better.

mentioned in issue #36409

When I was experimenting with this dropdown, I had a design similar to what @jens.goldhammer is suggesting:

However, after many iterations, I realized I was just duplicating existing functionality by having the search in there. The current search bar already searches projects, groups, project pages, settings, and help pages — it's an incredibly powerful, yet subtle, search. For that reason, I don't see a need to duplicate that functionality in the same area, with the same purpose. I've created #36409 to clarify the usefulness of the search bar and make sure it replaces the “project switcher” and more.

However, I do agree that having a “recently visited” list is useful, especially if you're not dealing with that many projects. This is what I ended up with in one of my previous explorations:

@cperessini WDYT? We can also adopt a column design as you proposed, I don't have a strong opinion about it.

mentioned in commit gitlab-design@1f6f48ff

mentioned in issue #35269 (closed)

mentioned in issue #36351

marked this issue as related to #36351

mentioned in issue #30343 (moved)

@pedroms @cperessini Are we done finalizing UX here? if so, please add UX ready label and mention me in a comment so I'll start on implementing this.

@kushalpandya sorry about that, I meant to reply to the conversation going on and it slipped past me. We'll finalize the details and I'll ping you.

As a user I would not expect the button "New project" in the projects dropdown. There is the + button for creating new projects and groups in the navbar already.

@jens.goldhammer @sarrahvesselov The + button is not very popular among our users, so I wanted to bring that option to a place they would be more likely to use. However, duplication like this is not good, so I think it's better to remove it.

I would suggest to build a quick way to show last accessed, starred projects and allow the user to quickly search these lists directly in the dropdown.

@jens.goldhammer @sarrahvesselov @pedroms That was the original purpose of adding this dropdown, but in order to simplify the implementation I proposed we move the project switcher here without any changes to its behavior.

@pedroms's idea to have a static list here and use the global search bar as a generic project switcher is good. However, I think generating that static list of recently accessed projects will require some backend work, so I'm not sure we can do that in this iteration. Maybe @kushalpandya knows if there already is an API for recent projects that we can use right now.

I worry a little that implementing my proposal as a MVP right now and removing the search box next month may confuse users.

I worry a little that implementing my proposal as a MVP right now and removing the search box next month may confuse users.

Agreed. Adding it in later is less confusing than adding it and removing it later. I would much rather implement the static list proposed by @pedroms.

@cperessini @sarrahvesselov so do we agree with the following?

• Don't include a “New project” item or search bar in the dropdown
• List 3 or 5 most recently visited projects
• Look into https://gitlab.com/gitlab-org/gitlab-ce/issues/36409 as another way to compensate for the removal of the project switcher

Look into https://gitlab.com/gitlab-org/gitlab-ce/issues/36409 as another way to compensate for the removal of the project switcher

I assume this means "Don't include search bar in dropdown" @pedroms?

I agree on the other two points.

@sarrahvesselov Yes, that's it, sorry I wasn't clear (I've edited my comment).

@pedroms your three points sound good to me. We just need to find out if it's possible to show a list of recent projects in the dropdown or if our only option for replacement right now is moving the project switcher here.

@kushalpandya do you know if this is possible to do this without backend work?

@pedroms Can you elaborate on 5 most recently visited projects? I mean do we show 5 most recent projects visited by currently logged in user? if so, then what happens if user isn't logged in and just exploring public projects?

@cperessini I believe getting list of projects is doable via v4 APIs, but it largely depends on what type of projects we're looking to pull via API, take a look here to understand what our APIs already support while pulling list of projects. https://gitlab.com/help/api/projects.md#list-projects

I think closest we have already supported as of now is getting list of projects with last_activity_at parameter, and that we already use in dropdown showed via Project breadcrumb.

Spoke with @kushalpandya and we are going to be storing a list recent projects in localStorage instead of making requests to the API.

Mockups will be added to the issue description today.

changed the description

changed the description

mentioned in issue #32794 (closed)

changed the description

After a talk with @mydigitalself and @kushalpandya we decided that showing frequently visited projects makes more sense than recently visited ones. This has two big advantages:

• The list won't get wiped out if you visit a few projects from the Explore section, for example
• The list will usually be in more or less the same order, instead of changing every time you visit a different project

We will also be keeping the search box in the dropdown. As @mydigitalself pointed out in https://gitlab.com/gitlab-org/gitlab-ce/issues/36409#note_38291766, once users come to this dropdown to switch projects, they should be able to complete that action from there. Making them go to a different place to complete what they started will be frustrating and unintuitive.

@mydigitalself @cperessini One thing that came to me regarding Frequently visited projects section is that should we build that list only for logged-in user or Guest users as well?

For either of the scenarios, I'll be taking current session (or logged in user) into account while building list of frequent projects into localStorage as that would help us in preventing projects from different login sessions or users to show up for different people.

especially when a project is private and we don't want people with no access to even view name and descriptions of such projects as that could potentially be a privacy issue.

Wdyt?

@kushalpandya I think it would be nice if it was also built out for unauthenticated users, sure.

Is this UX Ready @cperessini?

@kushalpandya Great thinking on separating this by user and not just by browser. We can consider unauthenticated sessions like a user.

---

It is @sarrahvesselov. Changing the labels now.

added UX ready and removed UX labels

mentioned in merge request !13866 (merged)

changed the description

When switching projects, is it possible to stay in the same sub-section of the project rather than be redirected to the project home @kushalpandya?

For instance, I am in issue boards and I realize I should be looking at CE not EE. When I switch to EE, it would be great if I could remain within the Issue boards rather than be redirected and have to navigate back to where I started.

This was brought up on the navigation feedback issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/32794#note_36831185

@sarrahvesselov It is not entirely impossible to have that feature and would certainly be nice to have but here are some caveats if I implement that.

• While switching between current projects, I always need to be aware of current page location, which involves parsing current page URL before switching between projects.
• This can work for top level pages like Issues, Merge Requests which are always guaranteed to be available for any project user wishes to switch but this guarantee of page availability depends a lot on individual projects settings.

• What if user is viewing an Issue and switches to different project (unaware of the switching behavior) and expects to land on to project homepage?
• What if user has enabled third-party integration like JIRA for issue tracking for the project to be switched to? we won't have necessary details for JIRA url.
• What about users who do not have access to certain top-level pages like Project settings, Environments, etc?

• This obviously won't work for any URL that is perma-link to something specific to a certain project (link to Issue, MR or comment within Issue or MR, search filters, labels).

Not only covering above cases would lead to complex implementation, I wonder how we'd communicate this kind of switching to users who intend to switch to project homepage rather than page within.

Nothing like a hard dose of reality on a Monday morning @kushalpandya

What if user is viewing an Issue and switches to different project (unaware of the switching behavior) and expects to land on to project homepage?

I don't have hard data to back this up but I do have anecdotal evidence from users who have complained that this is the switching behavior they expect and that they are jarred by our current behavior.

Not only covering above cases would lead to complex implementation

It sounds like there are too many gotchas for this to be worthwhile. There simply is not enough gain to warrant this level of complexity at the moment. I appreciate the thoughtful discussion on this, it will help me explain why we cannot do this at this time.

@sarrahvesselov I'd suggest that we have separate issue with list of enhancements we'd wish to see in Projects dropdown after it goes live with 10.0 instead of pushing everything in first revision. As we have lot of room in the dropdown to do neat tricks.

instead of pushing everything in first revision.

Not pushing for it all @kushalpandya, I just wanted to know if it was viable or not so we can make a separate issue.

It sounds like there are too many gotchas for this to be worthwhile. There simply is not enough gain to warrant this level of complexity at the moment. I appreciate the thoughtful discussion on this, it will help me explain why we cannot do this at this time.

Complexity for changing switching behavior in the topnav sounds daunting indeed, but adding a swift project switcher on issue list/board views is maybe a more feasible solution? See suggestion at gitlab-org/gitlab-ce#36351

Complexity for changing switching behavior in the topnav sounds daunting indeed, but adding a swift project switcher on issue list/board views is maybe a more feasible solution? See suggestion at gitlab-org/gitlab-ce#36351

Can you create a new issue for this @rmoreas? You can mark it as related to this issue and we can keep discussing the possibilities there

mentioned in merge request !13919 (merged)

closed via merge request !13919 (merged)

mentioned in commit dacb6338

@mydigitalself MR for this feature is ready for review, for your reference, here's the summary of how we determine frequently accessed projects. https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13866#how-do-we-determine-list-of-frequently-accessed-projects

/cc @sarrahvesselov

reopened

Would it make sense to open this dropdown via global short-cut? I've currently assigned Ctrl+` to open dropdown and then Esc to close it.

cc/@cperessini for UX Review

@kushalpandya cmd+k perhaps? What's the precedent for Ctrl+`

@mydigitalself cmd+k triggers Chrome's search input. I'm open for any combination as long as it is easy to use and remember.

@kushalpandya odd, not for me, that's cmd+f on OSX

@mydigitalself Ctrl+f triggers Find in page, while Ctrl+k triggers Search Google option within URL bar.

mentioned in issue #37215 (closed)

mentioned in merge request !14010 (merged)

mentioned in issue #18955 (moved)

From this Chrome help article:

Action	Shortcut
Jump to the address bar	Ctrl + l or Alt + d or F6
Search from anywhere on the page	Ctrl + k or Ctrl + e

It seems Ctrl+K and Ctrl+L are both taken in windows

We could use a combination of keys. We have gp for going to the projects list. We could have something like op for opening the projects dropdown.

closed via merge request !13866 (merged)

mentioned in commit 6e4949db

mentioned in commit d0f5b3c2

@cperessini

If there are no matching results, an error string is shown: No projects matched your query

This text is too “machine-like”, maybe something along the lines: “Sorry, no projects matched your search”. Additionally, consider including a link or button that directs to the “New project” page.

The current project switcher only searches projects you participate in. In this iteration we should the same behavior

The proposed placeholder is not clear about this scope as it says “Search projects”. As a user, I might think it will search all projects in the instance.

Oops, I just noticed that the issue was closed yesterday after posting my previous comment.

Just my two cents regarding the shortcut: n is currently used to open the main navigation dropdown, so maybe n + p to open this dropdown?

mentioned in issue #37513 (closed)

@pedroms thanks for pointing that out! I created an issue to address those concerns: #37513 (closed). I'm gonna try and submit a MR myself