"Graph" and "Charts" are too close in name and therefore confusing

Every time I am looking for the colorful "Charts" for detailed project stats, my brain wants to trick me to click into "Graph" since that makes me think of what I actually get in the "Charts" menu.

I do also feel like the "Repository" menu is too long and crowded by now, and I feel like "Charts" is a bit misplaced there in general. I cannot really specify why exactly, it's just a bit of a gut feeling - it might be related to it being the only entry that isn't really giving super specific information about project organization, but rather much more vague overall charts and stats that feel like they are on a much more indirect subjective level than the other entries.

I therefore propose that "Charts" is reconsidered both in name and place in the menu. Maybe a completely separate "Insights" (which also sets itself much better apart from "Graphs" as a word) menu like GitHub has it would be an idea?

GitHub also has much more graphs than GitLab: some of them are actually really useful and IMHO sorely lacking from gitlab, e.g. the contribution graph here: https://github.com/tethercode/stdlib/graphs/contributors which gives you a much better idea of how active the project is right now than the pure commits-per-weekday stats stuff gitlab has. Therefore, this maybe also would be a possibility to expand the available Charts into multiple pages with more interesting stuff and catch up on this front a bit.

Interesting, I did just notice the contributors graph is in GitLab's "Contributors" tab and I never noticed for some reason. Maybe it would also be a good idea to consolidate some of that stuff in a statistics/charts menu?

@TonasJ Thanks for the feedback. I seem to remember mention of changing the wording for the same reasons.

/cc @sarrahvesselov

added UX ~395718 labels

For what it's worth, I thought about this some more:

I think why I didn't find those graphs is because "Contributors" makes me expect a plain list of contributors sorted by activity or contribution amount, not the huge colorful pie graphs I was looking for. I would move those to "Charts" and create an additional simple list for the "Contributors" tab which maybe has a link to the relevant chart, but otherwise is a separate page.

This would also help reinforce a better separation of all the colorful stats fanciness being in "Charts", and all the basic hard data being under "Repository" outside of Charts. (which is also what GitHub maintains, which is I think the reason why I find it less confusing in that regard)

I think a little bit of UX research may help here @sarahod.

added UX research label

I agree @sarrahvesselov, I will look into this. Thanks for the feedback @TonasJ

assigned to @sarahod

mentioned in issue ux-research#35 (closed)

marked this issue as related to ux-research#35 (closed)

marked this issue as related to ux-research#43 (closed)

Research Update

I have now concluded a card sort of our contextual navigation. The results were very similar to @TonasJ's comments. Users would like a Statistics category to be added to the sidebar navigation. At a project level, the Statistics category would include Charts, Graph and Contributors.

During the card sort, users could access a brief description of the content if they were unsure of what it was from just its name alone. Therefore, we weren't able to identify whether other users have confused Graph and Charts as part of this study. However, we have another research study lined up which will answer this question (ux-research#43 (closed)).

Additionally, "Charts" can be understood as Kubernetes Helm Charts in the CI/CD section where Kubernetes is a first-class citizen, and GitLab is inevitably going to have a built-in Helm repo sooner or later. (Helm is becoming the main way of deploying apps in Kubernetes) CC @markpundsack

removed UX research label

unassigned @sarahod

added auto updated awaiting feedback labels

Still seems like a valid issue

added UX research navigation labels and removed auto updated awaiting feedback labels

Research Update pt 2: This question was investigated as part of ux-research#43 (closed):

Do users confuse the content of Graph and Charts? Users had a higher propensity to confuse the content of Graph and Charts when the items were placed within the same category of Statistics. The success rate for Graph was much higher when located within Repository (Existing) showing that, for now, it should continue to reside there. We identified in recommendation 3 that Charts could potentially work well in a Statistics category and by keeping Graph within Repository, user confusion is lowered, strengthening the positioning of Charts within Statistics.

@markglenfletcher We intend to take steps toward addressing this via https://gitlab.com/gitlab-org/gitlab-ce/issues/43432. I'd say this issue can be closed out, but I'm fine with keeping it open for further discussion too.

@katokpara This research that is totally out of context. Charts have a special meaning in Kubernetes world, and it's a redistributable package of YAMLs for Kubernetes. Having a link called "Charts" within "Kubernetes" menu is a terrible idea. It's like arguing that a word "Bridge" with a meaning of an actual bridge over a river is totally okay to use within "Network" tab, where bridge means a specific type of network interface. Just ask any CI/CD person for opinion to confirm. CC @markpundsack @jlenny @ayufan

removed UX research label

@Nowaker This research was conducted to address the original question in the issue description, regarding the "Charts" that appears in the Repository menu.

However, it'd be good to know if the changes to the left sidenav address your concerns (Kubernetes now exists under the Operations menu).

CI/CD	Operations

added [deprecated] Accepting merge requests label

added devopsmanage groupoptimize labels

removed [deprecated] Accepting merge requests label

mentioned in merge request gitlab-org/quality/triage-ops!268 (closed)

added analytics label and removed navigation label

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue