Navigation to Milestones and Iterations impossible without internal issue tracker

added UX devopscreate frontend groupeditor [DEPRECATED] navigation sectiondev labels

changed the description

@ericschurter @mle @gweaver @cdybenko @hollyreynolds @uhlexsis Any concerns with this suggestion?

This would be a good move for Milestones to move up. This is supported by this first click test https://dovetailapp.com/projects/0530978d-761a-4f04-8e90-43ff25b388a8/insights/present that would suggest "Project information" (previously Project overview) was the second best location.

In recent left sidebar navigation tests we asked participants Where can you view your team’s progress against the project’s milestones? using an accordion pattern #323874 (closed) and tabs https://gitlab.com/gitlab-org/ux-research/-/issues/1384. In the accordion approach 10/10 participants went "Project information > Milestones" and in the tabs 6/10 participants went "Project information > Milestones"

@mvanremmerden this feels like the opposite direction that I was personally hoping we would go in terms of simplifying the navigation, but I'm not going to make a fuss if this is the direction we end up heading 😄

My $.02:

We are merging Group and Project behind the scenes so the navigation in each would theoretically be identical.
We haven't decided if we are going to eventually call them the same thing or not, so we would have Group Information > Milestones, Subgroup Information > Milestones, Project Information > Milestones. This is subtle but the variable name adds a bit of cognitive overhead IMHO.
In Group, we have Epics > List, Boards, Roadmap and Issues > List, Boards, Milestones, Iteration. In Project, we have Issues > List, Boards, Service Desk, Milestones, Iteration. This has always been a bit confusing to me.
I almost want to consolidate things together like [insert top-level nav name] > Issues, Epics, Roadmap, Boards, Milestones, Iterations, Service Desk, Labels OR make each of those top-level nav items. In either case, we should have the option in Settings (or better in a dedicated settings area under this new proposed top-level nav) to enable/disable each feature independently. If each is a top-level nav item, we could also make Members a top-level nav item and then rename Project Information to Activity in order to completely remove a barrier to more easily navigating around a group/project.
Eventually Epic, Issues, Requirement, and Test Case will all be a type of Work Item (&6033) and we intend to introduce "saved views" (#14512 (closed)) which will more or less be a saved query/filter + view type (Board, List, Grid View, and so on) so I'm not sure how to best handle that from a navigation perspective either, but it could further simplify the nav down to Views, Milestones, Iterations, Labels.
If we do go this route, we will need to update Milestone (and eventually Iteration) to remove any Issue related UI elements if issues are disabled in Settings.

I had an interesting talk with a user yesterday who lamented how confusing and overwhelming our navigation is for non-engineering personas. It may be worth checking out -- https://gitlab.slack.com/archives/CHHGVPJHY/p1629405969045800.

@mvanremmerden I have no specific concerns about this move as an MVC but @gweaver brings up a great point. The more time that passes, the closer we get to seeing the outcomes of the Group/Project consolidation effort. We'll likely have to take a fresh look at the categorization with this lens and be prepared to propose another significant update to the navigation.

The good news is that with the refactored sidebar, making these changes is approximately 1,000,000 times easier than it used to be. 🎉

@mvanremmerden I think this makes sense for now though I do agree with Gabe that as we merge groups and projects as well as introduce work items, the navigation will need to be revisited. @tauriedavis I wonder if our conversation about the placement of Requirements in the nav is appropriate to touch on here? It didn't feel entirely right to put it under Issues, though eventually issues and epics will be associated with work items so I could see them all merging in that way in the future.

cc @gweaver

I don't have specific concerns with this either @mvanremmerden . I think I might sort it by type, something like:

Activity
Members
Labels
Milestones
Iterations

^ In the future, perhaps all timeboxes could be within one item as well so they don't need to be listed independently.

💡 Some other potentially wacky ideas:

Add Milestones under the Merge Request nav item as well. The duplication could potentially be strange, but it could be an interesting small experiment and MVC.
Perhaps moving it within Analytics or something similar, since reporting is a large job here.

@hollyreynolds, Since our 1-1 chat, @mvanremmerden beat me to opening an issue regarding Requirements 🚀 Check out #338884 (closed) 🙇

@aqualls I think this might be a fun one for the docs?

@mvanremmerden Let me check that I'm understanding the issue correctly:

Current state: if a project doesn't use GitLab issues, users cannot navigate to Milestones or Iterations
- Docs action: check to see if this is acknowledged anywhere. Based on https://docs.gitlab.com/ee/user/project/milestones/ and https://docs.gitlab.com/ee/user/group/iterations/ it doesn't look like it.
Future state: still being decided.

The two docs pages are both devopsplan groupproject management, so you'd want to involve @msedlakjakubowski to do the updates. I don't know the Project Management docs at all. Marcin will know if other pages that need updates as well.

Amy got the correct pages, and I don't think this is mentioned anywhere.

I was thinking where in the docs should we say that you need to have enabled the issue tracker to be able to use these, but it's not true - we're talking about getting to these features. Alternatively, the docs troubleshooting section could straight up say "Go to https://gitlab.example.com/<group>/<project>/-/milestones" 🤔

@aqualls WDYT?