Group dashboard UI

changed milestone to %8.16

Thanks @dzaporozhets. I personally find combining the subgroups in the same list as the projects confusing. The two items look similar, but not quite the same, thus it is odd to have them in the same list. The groups tab option makes a lot more sense to me. The downside is that you have to click to switch tabs to see the subgroups. I'm not too concerned about that -- but let me know if you have concerns about it. Thoughts @pedroms @tauriedavis?

How will subgroups appear on https://gitlab.com/dashboard/groups?

added ~874211 label

The groups tab option makes a lot more sense to me. The downside is that you have to click to switch tabs to see the subgroups.

true. I am also wondering if we hide group in separate tab - should we show subgroup projects on group page

How will subgroups appear on https://gitlab.com/dashboard/groups?

@awhildy I would expect so. At least that behavior I am using now.

mentioned in merge request !8308 (merged)

I agree, I would use the tabs rather than putting groups and projects in the same list.

For the groups dashboard page, maybe we can indent the sub groups under the group they belong to?

@tauriedavis do you think it makes sense to show subgroups on dashboard/groups page? When I open File manager - it does not show me all nested directories inside directories right from start.

@dzaporozhets should this go into 8.17, or even 9.0?

added ~480950 and removed ~874211 labels

changed milestone to %9.0

assigned to @dzaporozhets

@dzaporozhets I do think it makes sense to show the nested groups on the dashboard page.

With the file view you can drill down to the information within a directory while still being on the same page. To drill down on a group in this view in the same way that the file manager works would not allow you to navigate to the primary group. This is because a directory with nested directories contains more information. But a group is not a directory that contains other groups, it is its own entity. Having both groups and nested groups on the groups dashboard allows you to navigate to both primary and nested groups from this view.

@smcgivern 9.0 is perfect

@tauriedavis I disagree with you. Lets say you are member of gitlab group (top-level) that has a lot of subgroups you are not interested in like marketing, sales, infrastructure etc. I don't see point of showing it unless you were added to subgroup explicitly as member.

Another example is Explore groups. It would be really annoying to explore company groups if you have all subgroups listed at same page. You would need to paginate a lot

I agree with you, @dzaporozhets. My thoughts were that the subgroups would only show up if you were a member of them. If there are other subgroups in a top-level group that you are not a part of, they should not appear on the your group dashboard page.

In this example, maybe Gitlab.org has five subgroups. I am only a member of two of them, so those two show up on my dashboard. We can also make them collapsable by default - this would help with the explore page as well which could have lots of subgroups since it is not tied to what you are a member of.

Thoughts?

In this example, maybe Gitlab.org has five subgroups. I am only a member of two of them, so those two show up on my dashboard.

We can also make them collapsable by default - this would help with the explore page as well which could have lots of subgroups since it is not tied to what you are a member of.

@tauriedavis I like it.

@tauriedavis I am still wondering how Group page (show) will look like with subgroups. We have tabs All projects, Shared projects. Adding tab Subgroup logically does not fit there.

@tauriedavis for example we can have 2 tabs: Projects and Subgroups. And Projects tab will contain filter All / Shared and search bar and new project button.

Either like this:

Or even better if we just remove separate "Shared Project" tab and keep it simple like

Shared project are present in All projects anyway

I am going to add filter for all/shared project in sorting dropdown so we can get rid of tabs:

Subgroups page looks like this now:

Is it ok?

It makes sense to combine Projects and Shared Projects since they are already there anyway. I have a couple thoughts:

It seems like subgroups should come before projects because they are at a higher level
Is there any reason to remove sort options on the subgroups tab?
I think it makes sense to show the full path for shared projects Group / Project. This is how it is on the shared projects tab currently.
Maybe we can add a tag to shared projects so it is even more obvious that these are shared. We already add a tag for archived projects.

mentioned in merge request !8786 (merged)

It seems like subgroups should come before projects because they are at a higher level

@tauriedavis when visit group page you expect to see projects by default. It would be weird when visiting group page /:group you have second tab (Project) highlighted.

Is there any reason to remove sort options on the subgroups tab?

Because its not implemented yet. We don't have sort option at dashboard/groups too.

I think it makes sense to show the full path for shared projects Group / Project. This is how it is on the shared projects tab currently.

I believe you either show full path for all projects or for none in one list. Otherwise you might confuse shared project with nested one.

Maybe we can add a tag to shared projects so it is even more obvious that these are shared. We already add a tag for archived projects.

good idea!

@awhildy and I were looking at the All projects tab and noticed that some of the projects on GitLab.org have full paths:

Do you know why these projects show the group @dzaporozhets ?

Just to add some quick thoughts on the discussion above:

I think we should show the full path for shared projects on the 'All projects' tab.
- It helps in the case when projects may have the same name. How else will you know which project to click on?
- The path helps differentiate between 'Shared' projects and the regular group projects.
Having the subgroups tab after the projects tab actually feels fine to me. I think it all depends on the focus of the page. For the group page, it is still primarily about the projects, so showing the most important element for the group first makes sense to me

Do you know why these projects show the group?

@tauriedavis I believe thats how shared projects are rendered in the list now

I think we should show the full path for shared projects on the 'All projects' tab.

@awhildy seems like its already the case. My concern is that now with subgroups you might confuse shared project with nested one. So shared label would be good to have.

added Deliverable label

After reading through your discussion, here are some notes (please apologize if it sounds too direct):

Individual group page

Tab order: Subgroups, Projects
Listed subgroup projects should be titled: Subgroup name / Project name
Listed shared projects should be titled: Group name / Subgroup name (if applicable) / Project name
Listed shared projects should have a label (in the same way as @tauriedavis hinted that we already do that for archived projects)
Listed subgroups should not have the parent group in their title (e.g. Group name / Subgroup name) in the same way that projects of a group don't have the group in their title. They should be simply titled: Subgroup name

Explore Groups (dashboard)

Listed groups should be titled as: Group name (X subgroups) [see example]

Your Groups (dashboard)

If you only have access to a subgroup and not to the corresponding parent group, list it as: Group name / Subgroup name as Role name
If you have access to a group and not to any of its subgroups, list it as: Group name as Role name [as it is today]
If you have access to a group and some of its subgroups, list it as: Group name as Role name (+X subgroups) [see example]
- In this case, the subgroups would appear under the parent group, without any collapsible control, as suggested by @tauriedavis

WDYT?

Thanks @pedroms, I've updated the description to be a SSOT.

A couple points I have regarding your notes:

Individual group page

Tab order: Subgroups, Projects

I dont disagree here, but I think we've decided on ordering them as Projects, Subgroups

Listed subgroup projects should be titled: Subgroup name / Project name

seems in conflict with

Listed subgroups should not have the parent group in their title (e.g. Group name / Subgroup name) in the same way that projects of a group don't have the group in their title. They should be simply titled: Subgroup name

The project will only display the project name, and not the subgroup associated with it. Right? The group page only shows projects created under that group, so the Group name is not necessary (I think).

Explore Groups/Your Groups

In slack we decided not to include the (+X groups) because it seemed confusing to potentially have a different number on Your Groups vs. the number you were a member off. We've also kept the collapsable component for both tabs so you can view all groups and subgroups.

Your Groups

In this case, the subgroups would appear under the parent group, without any collapsible control

Why would it not be collapsable?

changed milestone to %9.1

I dont disagree here, but I think we've decided on ordering them as Projects, Subgroups

@tauriedavis Yes, sorry! I meant the other way around

The group page only shows projects created under that group, so the Group name is not necessary (I think).

@tauriedavis Oh, I thought it would also show projects under its subgroups. Can you please confirm that?

Why would it not be collapsable?

If you are a member of a Group, are you also automatically a member of all of its Subgroups? If so, I agree that it should be collapsible. If not, I think we should treat Subgroups memberships in the same way as Groups memberships, so they have the same visibility and importance.

Oh, I thought it would also show projects under its subgroups.

Each group page will show the projects that are created under that group and the subgroups created under that group. To see the projects created under a subgroup, you would navigate to the subgroup page.

If you are a member of a Group, are you also automatically a member of all of its Subgroups? If so, I agree that it should be collapsible. If not, I think we should treat Subgroups memberships in the same way as Groups memberships, so they have the same visibility and importance.

I don't believe you are automatically added to all subgroups. I am double checking this. I think making this an option (add to all subgroups or not) for when you add a new member to a group could be a feature improvement in the future. I think adding the ability to be collapsable just allows for easier navigation and mimics how the explore groups tab will function.

but I think we've decided on ordering them as Projects, Subgroups

If you are a member of a Group, are you also automatically a member of all of its Subgroups?

no. Same like being member of group you are not automatically added as member of every project inside this group

removed assignee

Hey @dzaporozhets : Why did you change to 9.1 for this? Because of some of the newer design changes? We are shipping this in 9.0 right (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8786)? So we will have at least that version?

@victorwu - Some of these UI improvements aren't going to make it to 9.0, but the core UI necessary for nested groups will be there.

changed title from Show nested groups in UI to Nested groups UI improvements

@victorwu sorry I should have change the title. We do ship nested groups in 9.0 (btw checkout dev.gitlab.org to test the feature) but UI improvements discussed here are likely to go in 9.1

added frontend and removed ~19492 labels

@dzaporozhets I'll assign this to you, let me know if I shouldn't have :)

assigned to @dzaporozhets

@dzaporozhets @annabeldunstone is tagged to work on the FE here. Are you working on the UI or will she?

changed title from Nested groups UI improvements to Subgroups UI improvements

@jschatz1 no I don't work on UI. I would gladly pass it to @annabeldunstone

assigned to @annabeldunstone

I'm having trouble differentiating between parent/top-level groups and nested groups on the main groups page.

From @reprazent:

So I think we will need to load the groups differently in the controller

So we load the top groups first

Basically something like where(parent: nil)

@smcgivern is there someone on the backend team who could help me with this? I don't think it's a huge amount of work, but I'm not entirely sure

@annabeldunstone what order do you want the groups to end up being in?

@felipe_artur do you think you'd have time to help out Annabel here?

@smcgivern no specific order other than have the sub-groups underneath their parent group

@annabeldunstone sorry to keep coming back on this, but do you mean that within every subgroup (or the top level group), parents should be directly above their children? Or all parents should be at the top? Say I have this group structure:

A

B

C

D

E

F

G

H

I

J

K

L

M

N

O

What order should they be in? The order I've just given, but flattened? A, K, L first, then B, G, etc.? Something else?

@smcgivern no problem; thanks for checking! The order should be that every subgroup should be underneath its respective parent.

The issue description may provide more clarity. The structure will eventually look like this:

@tauriedavis can you confirm this?

@annabeldunstone right, but that only accounts for one level of nesting. Do we need the ordering the same otherwise? I think this might be hard, but it's Friday, so I could be wrong!

@smcgivern I'm not sure... is there any end to the subgroups you can create? I assume if you add a subgroup under Subgroup 01 from the screenshot, then that new group gets nested underneath Subgroup 01. And it just keeps going like that

This might be a lot bigger than a simple UI update.
cc @dzaporozhets

@annabeldunstone we can go 20 levels deep https://docs.gitlab.com/ce/user/group/subgroups/

@smcgivern I spoke to @tauriedavis about that. The design won't scale too well at first; this is more just a first iteration. Is there a significant amount of backend development to be done before this nesting is possible?

@annabeldunstone what order do we need for the groups in https://gitlab.com/gitlab-org/gitlab-ce/issues/25426#note_26122550? The answer to that affects how hard this will be

@smcgivern the same order posted here https://gitlab.com/gitlab-org/gitlab-ce/issues/25426#note_26142571. If there are 20 subgroups, then each subgroup needs to be nested underneath it's parent, like in your comment here https://gitlab.com/gitlab-org/gitlab-ce/issues/25426#note_26122550.

@smcgivern Yes.

@felipe_artur thanks, although I think this might be tricky - please take a look at https://gitlab.com/gitlab-org/gitlab-ce/issues/25426#note_26122550 and let @annabeldunstone know!

Awesome! Thanks @felipe_artur. I'll assign the issue to you for now

assigned to @felipe_artur

Working on some improvements so this scales better, I think we can utilize a similar UX as repo. Clicking on the row would navigate to the contents inside of the group. Clicking on the group name would navigate to the group. If there are no subgroups within a group, clicking the row would navigate to the group, just as clicking a file navigates to the file. When inside of a group, the first row allows the user to navigate back.

Thoughts @cperessini @dimitrieh @annabeldunstone ?

#19860 (moved)

@tauriedavis I think it'd be good if we could emulate the way native file browsers work, where you can choose to expand the tree in place or replace the view with a subfolder.

@dimitrieh and I worked on a way to achieve that for the file tree here https://gitlab.com/gitlab-org/gitlab-ce/issues/20962#note_14050626 What do you think about applying that here?

@cperessini : Really like that idea. There's plenty of places where that native-style navigation would be applicable. If the design team thinks that's a good direction to head in, this issue can be a great starter to implement that design before bringing it to other places.

Nice, I forgot about that mockup @cperessini. Do you think it would work with the group avatar images? In the description you can see how much space they take up currently, so the indent is pretty large.

@tauriedavis I don't think the pictures are a problem for indentation because they can overlap a little.

I created some mockups to test it out. I think it could be due to the repeating images and text, but it gets a little heavy and hard to parse. What do you think?

Yeah, it is a little heavy. The darkness of the lines/icons probably also contribute to that. The ones in your other mockup are a lighter color.

@tauriedavis you're right, I think I didn't grab the latest Sketch file from that other issue. We had also landed on a different structure for the lines

I used a darker color for the icons to match the ones on the right side of the page. It looks strange to have the lighter icons on the left, even if they work better for the tree

Yeah, I agree. The concept of this design is the same as shown in the description currently so I think we can just replace it with your new mockup Thanks @cperessini !

@victorwu I'm not confident that this is going to make it into 9.1

added ~874211 and removed ~480950 labels

@annabeldunstone : Sure.

@jschatz1 : Let's make this 9.2 Deliverable . Let me know if you disagree.

@tauriedavis @cperessini : Can we limit this to only the group dashboard page. Let's do one thing at a time. Let's work on the individual group page in a different issue. I suppose we can design/implement the group dashboard page first since that's more generic, and the design will carry over?

A few questions:

Everything should be collapsed to the highest parent group per the comments above right?
Per the description, why is the UI different depending whether you have permissions or not to access certain groups? That seems unnecessarily confusing to me. If we are using this native file browsing design as an analogy, a standard design is:

If you have permissions to view a file / folder name, you can see it.
If you don't have permissions to even know a file / folder exists, you cannot even see it, it's invisible to you.
If you have permissions to view a file / folder name, but you don't have access to see it's contents, the file / folder name is greyed out, and clicking on it does nothing. Can't we just have a similar design instead of what's described in the description. Yes, it's more clicking, but I would say more usable. Thoughts?

The subgroups to subdirectories analogy is clear. But in the icons above, we have fa-users and fa-folder and fa-folder-open. Is that weird that we have people and manilla folders as icons? Sorry not being helpful here with providing a good solution. But just pointing out the perceived weirdness. Not sure if we want to create our icons. Thoughts?

changed title from Subgroups UI improvements to Group dashboard UI

Can we limit this to only the group dashboard page.

Sure

Everything should be collapsed to the highest parent group per the comments above right?

Yep

why is the UI different depending whether you have permissions or not to access certain groups?

I'm confused. I don't think groups display if you dont have access to them. I don't believe the functionality of what displays on the group dashboard is changing from what it is today. Only the design of it being nested. Does that make sense @victorwu? I think those bullet points in the description are actually for what is currently in place, and this issue was reused for the ui updates. I've updated the description to separate the original points from the current task. Sorry this was confusing

Is that weird that we have people and manilla folders as icons?

I struggled with this as well. @hazelyang is great at coming up with icons, perhaps she has a suggestion on an improvement.

Thanks @tauriedavis for the clarification. Makes a lot more sense now. Let's implement exactly what you have in the mockup if we can't come up with better icons. It's a already a huge improvement.

We had some discussion about the icon for groups a few months ago https://gitlab.com/gitlab-org/gitlab-ce/issues/19997#note_14697278 It's a tough one

changed milestone to %9.2

/cc @mydigitalself

added ~480950 and removed ~874211 labels

removed assignee

Is that weird that we have people and manilla folders as icons?

@tauriedavis @cperessini @victorwu I only have the same idea in #19997 (closed): fa-folder --> fa-building

@hazelyang for inspiration, take a look at Phabricator's icons for types of projects here and here.

@tauriedavis what happens for groups that have no subgroups in the visual design treatment? Is there a big gap to the left where you currently have the folder and expand chevron?

@mydigitalself The icon would still be there so there wouldn't be a large gap. It would be the group icon, rather than the folder icon - like how you see the last children groups in the mockup above.

There is already Frontend code for this structure in Environments code we can reuse it.

@annabeldunstone I will do backend code for this issue. Ping me when you have details on what JSON data you need

@dzaporozhets looks like @alfredo1 is doing the frontend for this

Yeah, I'll work on this since it was assigned to me as deliverable @dzaporozhets I'll give you details when I start working on this.

mentioned in issue #30312 (closed)

mentioned in issue #30343 (moved)

assigned to @dzaporozhets

@alfredo1 I assign issue for you now since you do first step. Once you want me to do backend part - ping or assign to me

assigned to @alfredo1

mentioned in issue #30547 (moved)

@dzaporozhets I assume the data and layout should be handled in the frontend right (Using Vue/ajax)?

@tauriedavis @cperessini What happens if there's too many Level 1 Groups, there will be a pagination?

@dzaporozhets Here's the data I need, basically a nested array of group objects. sub_groups property is optional depending if the group has submodules or not. I'm just not considering pagination yet.

The endpoint path and the data it needs is up to you but probably I'll have to provide Parent Group Id when viewing subgroups tab in the groups page.

Group Dashboard

[
  {
    group: {
      name,
      url,
      avatar,
      description,
      edit_url,
      leave_url,
      visibility_level, // [private|internal|public]
    },
    stats: {
      number_of_projects,
      number_of_members,
    }
    user: {
      role, // Role in current group
      can_edit, // would be nice to have it as boolean so I can show the edit button
    }
    sub_groups: [
      {
        group: {
          // ...
        },
        stats: {
          // ...
        },
        user: {
          // ...
        },
        sub_groups: [
          // ... if it has sub modules
        ]
      }
    ]
  }
]

@tauriedavis Can you elaborate on this?

From the Individual group page

Listed shared projects should be tagged Shared

How the tag will look, is there a mockup for the Projects tab?

@alfredo1 are subgroups/project are expanded by default? I would expect only sending data for what user sees. So when I click expand button we make a new request to load subgroups/projects. Otherwise it might be a performance problem by loading all data as stated at https://gitlab.com/gitlab-org/gitlab-ce/issues/25426#note_28782014

@alfredo1

That line is referring to this:

The first project in this list is shared with the group, so there is a tag on the right that shows it was shared.

What happens if there's too many Level 1 Groups, there will be a pagination?

I think we can continue doing what we currently do.

@dzaporozhets That's a good idea, lets load subgroups in another AJAX request.

So there will be two ajax request:

To load all groups when page loads.
To load subgroups when clicking in a determined group.

I guess we can use the same endpoint?

@tauriedavis Thanks! So we will paginate groups since that's what we are doing right now.

@dzaporozhets I'm going to need pagination data. I think we already do AJAX pagination on the Pipelines feature. So I'm going to take a look how it works there and will comment with the data I need.

So there will be two ajax request:

@alfredo1 yes

I guess we can use the same endpoint?

yes

I'm going to need pagination data. I think we already do AJAX pagination on the Pipelines feature. So I'm going to take a look how it works there and will comment with the data I need.

@alfredo1 whats special about Pipelines pagination compared to existing projects/groups pagination?

@dzaporozhets hmm Nothing I guess. I just wanted to update the data I expected from the server response so I can post here.

@alfredo1 According to backend implementation:

We already have json endpoint https://gitlab.com/dashboard/groups.json - it used for AJAX search/filter group results and return html as json data.
We can change this json endpoint to return actual json array of groups data. But then we need to update AJAX search/filter accordingly
I will add extra parameter like parent_id so you can request subgroups on user click via request like https://gitlab.com/dashboard/groups.json?parent_id=12

@alfredo1 I think we should start WIP merge request where we can do some work. I will make one

Cool, sounds good to me

created branch 25426-group-dashboard-ui

mentioned in merge request !11098 (merged)

added subgroups label

@tauriedavis how does it look a group that doesn't have subgroups?

Right now I'm just hiding the caret icon. Is that ok?

We're currently having a separate discussion about icons https://gitlab.com/gitlab-org/gitlab-ce/issues/32416

What you have is good for this iteration.

Any new plans on this? Will this be shipped within a 9.2 patch release?

Group dashboard UI

Resources

Further UI Improvements

Original issue

Group Dashboard

Individual group page

Original Description

Designs

Child items ...

Activity

Admin message

Admin message

Group dashboard UI

Resources

Further UI Improvements

Original issue

Group Dashboard

Individual group page

Original Description

Activity