GitLab Navigation UX, 21 Sep 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Navigation Update: 2021-09-21

Description

- [Issue] Move "Requirements" into "Issues" in the left sidebar: https://gitlab.com/gitlab-org/gitlab/-/issues/338884#note_677535017
- [MR] Move Requirements under Issue top level nav item: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/70748
- [MR] feat(navigation): Add initial guidance for in-app messaging: https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2549?view=inline

- [Issue] Explore merging Deployments, Infrasructure and Package & Registry items in the left sidebar: https://gitlab.com/gitlab-org/gitlab/-/issues/339506#note_666290546
- [Issue] Make runners within groups visible and a first class citizen: https://gitlab.com/gitlab-org/gitlab/-/issues/19819#note_677492459
- [Issue] Improve consistency of Runners location in the Nav in Admin view: https://gitlab.com/gitlab-org/gitlab/-/issues/340859

A

Hi everyone- this is tori davis. I am the product design manager for the foundations group, I'm going to start creating uh some regular video updates regarding what's going on with navigation, and this is the first one. So let's go ahead and dive right in um first, it's been long awaited that we move requirements out from being a top level menu item to living under issues.

A

In order to start getting this rolling, I reached out to russell from our technical writing team to ensure that we would have some coverage for any of the docs changes that may need to occur with this update, and then I also paired with one of our backend engineers, lucas charles, to get this merge request, started to move the nav item, so this should make it into 14.4, and thank you lucas for sitting down and pairing with me to make this happen. I really appreciate it.

A

um One aspect of navigation that came up when discussing these changes is the type of communication rollout, that's required. We don't currently have any guidance on in-app messaging for navigation changes, so I went ahead and opened this merge request with a proposal to arrive at this proposal. I looked at our click data across particular features and then divided that number by the unique active users to come to a percentage of clicks per active user per month.

A

So from that, I was able to draft this proposal, which is that, if a feature has less than 0.025 percent of clicks per active user per month, then no in-app message is required to make that change and requirements is an example of something that falls within that category.

A

If a feature has between 0.026 and 0.99 percent, then we would show a toast or a broadcast message informing the user of the change. After we've already made the change in the product.

A

If a feature has 0.1 or greater of clicks per active user per month, then we would show an alert in the product for one milestone, informing the user of the upcoming change and then, lastly, for major navigation overhauls.

A

We should provide a temporary opt-in method for at least two milestones, which gives us, as a company time, to communicate the changes as well as allows users to preview what's upcoming, and all of these are methods that we've used in the past. This guidance just adds some data to help determine what the best method is, depending on the particular feature, that's being used so using this data, and these numbers is just a first draft.

A

If we determine that there is something better to measure or maybe tweaking these percentages would be useful, then we can do that at any time.

A

Lastly, there is a note here at the bottom of this merge request that notes that documentation should always be updated and all changes should be included on our release posts and that we can also make use of feature flags or rolling out changes slowly to users over time as a method of just getting more feedback early before releasing it to everyone.

A

So if you have any feedback on this proposal, I will link the merge request in the video description. So you can add a comment there or reach out to me. Really anywhere and be happy to to discuss it.

A

Next, we have an issue that includes a proposal to combine deployments, infrastructure and package and registry.

A

We did some research in the past to arrive at where we currently are so before we make this change to reconsolidate. We want to do an additional study and make sure that we are heading in the right direction.

A

Anna from our research team is taking this effort on and I'll have some more updates here in the coming weeks. Right now, it says backlog here, but we'll either create a research issue to continue that work for 14, 4 or I'll update this milestone. A little later today,.

A

Lastly, we have this issue where the runner group is looking at moving runners out of settings and into the cacd top level nav items, so it would live here.

A

There are a few reasons that the team believes that this is the right place for runners to live. One it makes runners available in a read-only form, so non-maintainers would be able to view the runners uh within a particular project and then that would allow them to identify different resources that are available to them.

A

Moving. This section would also provide more flexibility in terms of improving the runners page, so we could add functionality such as search or filters, and then, additionally, through some of the research that has been ran, we found that the current location and settings is not where users expect the content to live.

A

So this change does not add a top level menu item for projects. It would just live under the cic cd menu here, um but caicd is not a top level menu item for groups, and so this would mean adding a cic top level menu item for groups and then runners would live under it.

A

I believe that this is okay for a few reasons. First is just that the data supports moving runners out of settings and placing it under ci cd, since that's where users expect to find that content.

A

Also, the number of top level nav items within groups is far lower than what we have in projects and having ci cd in both places, just promotes consistency and it'll just enable users to know where to look at each level that gitlab has so. This also means that we're looking at where runners lives in the admin area.

A

Currently, this is under overview, so you can see here in the admin area we have runners under overview. um The there's already consistent inconsistency with where it lives in projects, so we're just going to continue correcting the inconsistency iteratively, and we have an open issue here to look at changing where it lives in the admin area.

A

So that's it for this week's updates I'll link. All these related issues and merge requests in the youtube description, if you have any feedback or thoughts, feel free to ping me, and thank you for watching until next time.