Simplify navigation

@dzaporozhets @JobV @hazelyang food for thought.

Added frontend ~19492 feature proposal labels

Thanks @gsmethells, love the work you put into your proposals

cc @tauriedavis @jschatz1

@JobV sure thing!

mentioned in issue #20721 (closed)

Adding my bits and pieces from my meta issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/20721

This is copied content

Sidebar discussion (yes I know, this is a hot topic).

Still I think the sidebar is at a place now where it doesn't do itself or GitLab justice. I have a lot of things to say for it, but also against it. In the end I think the current state is not good enough to justify its existence. It feels like a relic, or should be updated.

It includes profile specific + site wide navigation. However the profile has since been removed from it and has been placed in the upper right corner of the interface.

Let's break it down per navigation element:

Projects

One of the few elements that could belong here and the one I personally use the most.

Todo's

Same as notifications, has already a superior alternative in upper right corner

Activity

Activity over all "your" or "starred" projects. Although this is pretty oke to monitor projects it currently has insufficient filters and thus I wonder how much this is used. I talk about this elsewhere in this issue.

Groups

Could be displayed under profile settings in profile dropdown.

Milestones

Same as "Activity"

Issues

Instead of notifications it displays Site Wide "assigned" issues. This can easily be placed for example next to notifications

Merge requests

It displays Site Wide "assigned" MR's. This has a place next to the previous item.

Snippets

One of the few elements that could belong here.

Help

Could be displayed under profile settings in profile dropdown.

Profile Settings

Already available somewhere else (more logical place to booth)

It used to be a place where you could find/navigate to anything. Right now it's an inconsistent place to find "some" things. If it has too many elements, it becomes bloated and ineffective, but at the same time if there are not enough items in it, it is a highly inefficient usage of screen real estate (as it takes up a vertical screen portion). I calculated it wasting at least 7% of total screen real estate based on the following screencap portions:

Possible solutions:

Do away with it, get all navigation to somewhere else (omg no sidebar? )
Extend current navigation, so you don't need to load another page to get to the project you want for example. (that's where I use it the most for at the moment, "get to project X or Y")
Make it custom configurable for power users, to get the navigation in there, that they want
Display all your projects and snippets, with a quick inline search functionality

Of course if we would change this, it would again be a pretty big overhaul as things considered sidebar. How do we bring this change to the community etc in a good way? In my opinion change is necessary.

I used to desperately want the sidebar. Then when 8.9 came out, the sidebar pin was a bit flaky for me. I ended up giving in to its desired state of being hidden, more often than not. Then I realized how awesome that state was for code reviews -- my common case, day-to-day world -- and how much simpler the UI felt. At that point, I thought I'd put my thoughts down in this proposal.

I believe the biggest gain this simplification will garner is that users who are less tech-savvy, but are very business savvy, who deal with GitLab in their company as more like "something engineers need/use", will find it more friendly and adoptable if the UI treated "nouns" and "scope" in a more visibly consistent and simple manner.

Beyond that, they need dashboard to fulfill its name-sake in terms of business metrics, but that's a topic for another proposal. Or perhaps I just need to bite the bullet and buy EE for my guys.

mentioned in issue #13723 (moved)

mentioned in issue #21365 (closed)

@dzaporozhets would love to hear your thoughts here

@JobV @tauriedavis @hazelyang @dimitrieh @gsmethells this is again "lets change everything" proposal which has pros and cons. While people just started adopting new redesign I think its would be really really bad move to do another navigation redesign. I don't share @gsmethells concern that changes are necessary and strongly believe we can live happy with current (new) navigation for another 10-15 releases.

I would even put it under the rule like that: navigation redesign (not small improvements but general change of how things works) can be considered only 10 releases after last redesign.

@gsmethells I appreciate efforts you put in UI/UX suggesting. But this one is too big and too early.

@dzaporozhets how about in the long run then?

I believe that most people would desire a UI that strives to be intuitive regardless of granularity. The base level concept I'm after in the proposal, of course, is to unify the "scope picker" so that there is less of a jarring jump from the "group / project" granularity to the "dashboard" granularity. I think smoothing that out in the long run is very beneficial. I believe that interfaces benefit from not exposing the user to "modes". Like the "TV/Video" button on a TV remote. That's confused countless people over the ages. My suspicion is that many nouns in the design would benefit from being viewed at different granularities, hence users are likely to move between those layers in the course of their day. I'm sure you can all picture examples of that.

I certainly do not advocate timing. Whether it is too early is your call, not mine. All I'm hoping to help with here is to start a discussion that could lead to a long-term UI plan that removes the rough jump up from "group / project" to "dashboard".

@dzaporozhets thanks for your reasoning, it makes sense!

I think a different solution may solve this to some degree as well. In the following issue comment: https://gitlab.com/gitlab-org/gitlab-ce/issues/13723#note_14521834 there is an expansion on the sidebar being discussed. It doesn't do away with the current implementation, but instead enhances it. Simply said, what if we would make the sidebar context aware if needed/if the user chooses it to (everything is opt-in).

The sidebar is a unique element throughout the application that ascends hierarchy to some degree. We could use this ability to our advantage ;) and create an additional, but very real reason for the sidebar to exist beyond its current scope. (plz check the issue)

@gsmethells I don't want to step on redesign road right now as discussion without experiment (implementation) does not make me confident about it. I read your proposal and it makes sense to me but I am not sure if I would prefer it to current design. So I rather return to this issue in 3-6 month and see how I feel about it.

@dimitrieh thank you for pointing to the issue - I will respond there

@dzaporozhets okay, you got it. I'll hold tight for now.

@gsmethells thank you for understanding

mentioned in issue #22069 (closed)

Mentioned in issue #22889 (closed)

I see that "Help" has moved under the user avatar button in the top nav in 8.14-rc3.

@gsmethells Yep, thats correct!

@dzaporozhets @dimitrieh @tauriedavis could this be brought up again for some early 9.x release? I think that'd put it near 10 releases away from a previous re-design, but maybe I'm missing something.

@gsmethells we are going to remove sidebar in 9.0. See concept in https://gitlab.com/gitlab-org/gitlab-ce/issues/26200#note_21501269.

mentioned in issue #26200 (closed)

@dzaporozhets The main idea of the remainder of this issue is:

For any given context granularity (dashboard, group, project):
- there should be a nav bar (list of noun tabs) at the top of the page with all nouns of interest at that granularity:
  - and the page for a given noun aggregates all content for that noun at the current granularity

@gsmethells Can you provide a before and after of what you are describing in your comment above? I'm not sure I am quite following your proposal.

@tauriedavis I'll give some examples. Might be later today, though. Busy work day here.

No problem, thanks @gsmethells !

So to explain the idea, we need a set of nouns that might make sense at a given context (level of granularity). The contexts being either "dashboard", "group", or "project". I believe the full set of nouns that show up in the nav bar as tabs at either the "group" or "project" context is currently (but I'll skip those that might be changing soon):

Project
Activity
Repository
Pipelines
Issues
Merge Requests
Graphs (sees to be changing soon though)
Snippets
Milestones
Labels
Members
Contribution Analytics (may also be changing soon)
Wiki

There is no set of noun tabs at the dashboard level, but then there is if you think of the sidebar as just another expression of it. The "dashboard" is the odd man out here ... it doesn't look like the "group" page or the "project" page context levels. But for what benefit? Why not have a context picker that changes the content of the page and the noun tabs used to navigate things from that context level. So for example, the dashboard could be:

The nouns shown here are not exhaustive, of course. They can be any of them as long as they make sense in the "dashboard" context. Most would be project level things (nouns) that are worth seeing in aggregate. For instance, all Issues across all projects a user has access to would be in the "dashboard" context under the Issues noun tab. If the context switches to "group", then there would still be an Issues tab, but now the content only aggregates Issues for projects under that group.

The variations between the layouts for project, group, and dashboard would begin to vanish and the context picker in the top left-hand corner would drive the view of the "noun of interest" (those being Issues, Milestones, etc). The dashboard would be just like a group page writ large. The others would remain as they are basically.

They would be similar to now:

and

@tauriedavis so the motivation for the idea is that, right now, there is a jarring separation between the "dashboard" view and the "group" and "project' views. But it doesn't have to be that way. The variant can be removed in favor of simplicity by taking the "group" and "project" UI and applying it to the "dashboard" and providing a context picker where the bread crumb is shown in the upper-left-hand corner. The navigation becomes cleaner because the content for each granularity level is similar, it is only the aggregation that comes and goes.

Thanks for the level of detail you've put into this issue @gsmethells! I understand the concept now. I do worry that there could be confusion when applying the same UI to the dashboard as there is for groups/projects. They may not have to be separate, but to me they should be. I recognize that they have the same set of nouns but there is a distinction between something that belongs to the one (dashboard) and something that belongs to many (group/project). I don't see how the current separation is jarring.

I'm open to further feedback here, though. What are your thoughts @pedroms @dimitrieh @awhildy Thanks!

Thanks so much for the idea and details @gsmethells! Definitely interesting and some good things to think through!

This does feel like a more cohesive design system to me. It is nice to combine what would be 2 dropdowns (from https://gitlab.com/gitlab-org/gitlab-ce/issues/26200) to 1. And it feels like we are consolidating what you nicely called 'context switchers'.

I'm a little torn on the whole dashboard part of it. It is kind of nice to tie all the pages of the dashboard together (makes the dashboard feel like more of a connected experience). However, these pages don't really relate to each other as much as the project pages relate. You probably aren't going back and forth between them as much. It would also make the dashboard pages feel slightly farther away, as you have to go to the dashboard and then click on Merge Requests, instead of open dropdown, click on Merge Requests. Not sure if this is actually important though.

Given this, I'm a little hesitant about this concept. But open as well to keep exploring and thinking it through.

@tauriedavis @awhildy thanks for thinking through this with me. I hear that the current separation is something that is alright with both of you. I know that "jarring" is a subjective term, but I'm trying to get a general idea of "difference" across. The level of "whoa" is quite subjective to the user perspective, though.

I'm trying to get a feel for the benefits of the separation. Right now, when I train business folks on how to conceptualize what they are seeing the GitLab UI, I have to separate their understanding of "Issues" which is visible in the sidebar at the same time as "Issues" is visible across the tabs at the top on the same page. There is both a vertical and a horizontal list of options with very similar nouns which bewilders people. Beyond that, the dashboard is the only place where the "context picker" just "goes away" and the user feels abandoned regarding "where" they are now. They were in a project or group, but now they are not and it feels like limbo.

For example, there is confusion there when I say, "go to the Issues for the native app in the software team group". People honestly take many paths and not all of them are going from "Software Team" showing in the bread crumb "context switcher" with "Project" tab selected to simply clicking on "Issues" in the horizontal set of noun options. Some want to click on "Issues" in the sidebar instead. When they do, they freak out because now they don't know where they are. It just says "Issues" at the top. "Where is that?", they ask. And I say, "that's a different Issues than I meant. I meant the software team's native app's Issues." "How do I get there?" they ask. "Well, from here, you cannot get there directly. You need to click on Groups or Projects first". "But you said Issues?!" they lament. "We need to get to the right container/context first. We were there, but you went the wrong way. There was another Issues you could have clicked that was also showing along the top set of tabs." I point out. "What's the differece? And why can I not see where I am any more?" as they now feel frustrated.

I think for GitLab to be successful, it needs to be more "whoa proof" for those that are not technical, because we have stakeholders and they need to be involved, too, without feeling like GitLab is too complex to even bother with in the first place, which is where I am with several of them in my company right now. The intuitiveness could be enhanced. I hope you see what I see here. Perhaps you would implement it differently to get to the same end goal which is fine. I'm just trying to help point out my experiences because, to me, I see there is some bumpiness that could be smoothed out somehow.

At the very least, I'd love to see a bread crumb / "context switcher" that is omnipresent. Perhaps hiding away the sidebar under a drop down (as in #26200 (closed)) plus an omnipresent bread crumb would suffice?

Thats great feedback, thanks Greg! I can definitely see why there would be confusion.

I'd love to see some improvements to the bread crumb switcher. I currently do not use this dropdown at all because its always filled with projects that I don't personally contribute to often. In order to make it more omnipresent I would like to see the order of projects shown reflect what I have contributed too last. This way it is more useful for each individual user. I'm not even sure what order it is currently using.

@tauriedavis mostly the hiding of the bread crumb switcher at the dashboard level is the variant that gets confusing. If a dashboard is somewhere, then why does it not say so (in the bread crumb switcher)? Why hide that information, you know? Also, why hide the bread crumb switcher but only for dashboard? It's like once you arrived, you can never leave.

A tangential thought: why does the dashboard not look like a "dashboard"? Most other apps treat a "dashboard" as a "high level summary" / "executive view". Like this or that. Then the separation would feel more motivated to me.

Right now, the dashboard view is very similar in vain to the group view. Lots of duplication of lists of the same nouns and not looking all that different, hence this Issue which assumed originally that the intended direction GitLab wanted was to make the dashboard actually be a global view mimicking the group view (a series of granularities but the same nouns at each granularity). But if the dashboard offered a more dashboard-like view, then the purpose is more than just a global view of the data...

Anyway, tangential as I said, but hopefully it helps understand where my thought process started.

Have you had a chance to check out our smart dashboard issues? They may help with the feeling you're describing about the dashboard not looking like a dashboard. Would love to get your feedback on them:

Personal smart dashboard: https://gitlab.com/gitlab-org/gitlab-ce/issues/27111

Project smart dashboard: https://gitlab.com/gitlab-org/gitlab-ce/issues/27112

@tauriedavis yep, those speak to it.

I still like the idea of a omnipresent bread crumb switcher. That I think is the essence of this Issue's proposal.

mentioned in issue #27331 (moved)

Thanks @gsmethells for all the great feedback and explanation! I created https://gitlab.com/gitlab-org/gitlab-ce/issues/27331 just to have a scoped conversation on the bread crumb switcher (and linked back to the feedback you shared here).

@awhildy okay. I think if #26200 (closed) and #27331 (moved) got done, then this Issue could probably close (given how the dashboard seems like it'll be changing anyway from the looks of it).

closed

Simplify navigation

User Story

Elaboration

Proposal

Designs

Child items ...

Activity

Admin message

Admin message

Simplify navigation

User Story

Elaboration

Proposal

Activity