Project

General

Profile

Feature #827

Allow Groups to have sub-groups

Added by Matt Gold about 11 years ago. Updated about 7 years ago.

Status:
Deferred
Priority name:
Normal
Assignee:
Category name:
Groups (misc)
Target version:
-
Start date:
2011-06-16
Due date:
% Done:

0%

Estimated time:
15.00 h

Description

From Uservoice

"Add the option to create subgroups (a group within a group); could be useful for some larger groups"

My comment:

"Great idea. I bet that there are ways we can create a way for groups to be linked together in a way that would facilitate this (ie., Group X is part of Group Y). I'll subscribe you to the Redmine ticket where we will discuss this in further detail."

In other words, if it might be easier to link to groups and to display that connection on the page than to create some kind of "sub-group" interface that has combined forums or something.

But I'm curious about what you think might be the best way to implement this, Boone.

History

#1 Updated by Maura Smale about 11 years ago

Great, thanks for considering. Some more info: this is a LILAC-related request. We've just started a new working group that will include some, but not all, members of LILAC. This group will likely be heavy users of the forum and group docs, and it seems like it would be easier for the group to work in a dedicated space. We talked about creating another group entirely, but folks value the connection with the bigger LILAC membership.

Let me know if there's anything I can do to help think through or work on this. Thanks!

#2 Updated by Boone Gorges almost 11 years ago

  • Tracker changed from Bug to Feature

#3 Updated by Boone Gorges over 10 years ago

  • Status changed from Assigned to Reporter Feedback

What kind of interactions do you envision between the two groups? Shared membership? Shared activity streams? Or just a link from one group to the other that appears in the header (or something like that)?

#4 Updated by Maura Smale over 10 years ago

That's a good question. For the LILAC example I think it would be useful to have the subgroup include some LILAC members (but not all) for things like activity streams and notifications. But the larger group (LILAC) could just view subgroup content on the Commons if they wanted to, and subscribe to activity streams/notifications. And a link from one group to the other would be convenient, too.

#5 Updated by Boone Gorges over 10 years ago

  • Target version changed from 1.4 to Future release

Hm. So, from that description, it sounds like the only real connection between the groups would be a link in the header, right? Because, of course, simply defining parent/child relationships will not be able to differentiate which parent group members you want in the child group, with the result that you wouldn't want to have automatically shared membership.

I'm adding Chris to see if he has input, and moving out of the 1.4 milestone until we get a firmer sense of what's desired/desirable in this feature.

#6 Updated by Chris Stein over 10 years ago

I agree on putting this off for a bit until we can work it out. It sounds like on a t least the first incarnation it is a simple relationship on the technical side ( much like docs can be children of others) but on the ui side we
Need to answer questions like whether this is added to the group creation process, how to edit/add/delete relationships at a later time and how to show the relationship when you are in one of the parent or child groups. 

It would need some wireframes then too. I feel like there is a lot of other stuff going on right now and would like to push back focusing on this for a bit if that is OK. 

On first blush I think I would recommend not intermingling the activity streams for now. Users would just join the groups as normal and then view activity that way. 

I do see the utility in being able to see all of the activity in a related set of groups though (like it might be nice to see all of the CAT committee and subcommittee group activity in one place). However that may be better suited to the revamped mycommons page we have talked about. There people could make their own sets of groups kind of like the way you can group feeds in google reader. 

Either way that combined activity sounds like a phase 2 idea. 

#7 Updated by Matt Gold almost 10 years ago

  • Target version changed from Future release to 1.6
  • Severity set to High impact

Noting that we've just received another request for this functionality. Placing it in 1.6 so that we remember to return to it.

#8 Updated by Matt Gold about 9 years ago

Hi Boone --

Would BP Hierarchy - http://wordpress.org/plugins/bp-group-hierarchy/

and

BP Group Organizer - http://wordpress.org/plugins/bp-group-organizer/

allow us to achieve this functionality?

#9 Updated by Boone Gorges over 8 years ago

  • Category name changed from BuddyPress (misc) to Groups (misc)

#10 Updated by Boone Gorges over 8 years ago

  • Status changed from Reporter Feedback to Assigned
  • Estimated time set to 15.00 h

There are a lot of questions to think through regarding how this might work in practice. I am doubtful that we'll be able to work through them for the 1.6 release - too many UX considerations are likely to come into play.

However, I think that a reasonable first step is to install one of the plugins listed above in cdev, so that Chris and Matt can get a feel for how they work out of the box. It would be a helpful starting point for these conversations.

For the moment, I'll leave this ticket in the 1.6 milestone, until I get a chance to do this installation. At that point, I may bump it into 1.7, which is the release it's more likely to actually be a part of.

#11 Updated by Matt Gold over 8 years ago

Agree with your plan, Boone -- thanks.

I think, too, that this would be a good case for outreach -- we should write to the group for group admins and see how many people would be interested in this functionality, and if they are interested, how they would prefer that it would work.

But, first, it would be good to see how some of these plugins work on CDEV.

#12 Updated by Boone Gorges over 8 years ago

  • Status changed from Assigned to Testing Required

Added bp-group-hierarchy in https://github.com/castiron/cac/commit/e0d933fe51a163c68a87970639b223c9c2114807 and ready to test on cdev.

From what I can gather, here's what it does:
- Adds a step to group admin/creation that allows you to select a parent group
- Adds a tab to groups that lists their "member groups" (ie child groups)
- Changes group URLs so that they're nested within parents. Eg a group called 'child' will have the URL http://cdev.gc.cuny.edu/groups/parent/child/
- Offers a "Group Tree" directory view: http://cdev.gc.cuny.edu/groups/ (click Group Tree). Not sure how the sorting here works (it appears not to), but if you page through and find a group with children, you'll see that it can be expanded to show the relationships.

The plugin seems to have a good deal of stuff happening under the hood, so there may be more that could be done in terms of functionality, but hopefully this is a start. Play around and see if you think it brings the kind of value you're looking for.

#13 Updated by Matt Gold over 8 years ago

Excited to see some progress on this. We tested this.

A few thoughts:

1. Group Hierarchy should not be a discrete tab in the group creation process. Instead, we propose the following:

1. Convert the existing "Group Blog" tab in the group creation process to "Options"

2. On that options page, have the checkbox group blog element that collapses/expands on click

3. Add "Enable Subgroups" as a second option, and mirror the collapse/expand on click functionality that we have for group blogs

-- this way, there will be a single "Options" tab that will contain both "Group Blog" and "Create Sub-Group"

4. There needs to be clearer language around what is currently step 2 of the group hierarchy tab, where you set up the parent/child relationship. The following language is very unclear:

Member Groups:
Allow XXX to create Member Groups
Choices for XXX: Anybody / Nobody / only Group Members / only Group Admins

---> if this means that we are deciding who has PERMISSION to create subgroups, then a few thoughts:
-- we should "sub-groups" instead of "member groups" as a descriptor in this menu and in the sidebar menu
-- we need to add some explanatory text to this because it is very unclear

5. Finally, the process of creating a subgroup is unclear:
-- are all members of the parent group automatically added to the subgroup?
-- within an existing group that I have created, how do I assign it as a child of another group?

6. The "Group Tree" view of groups is unclear.

7. We found one bug:
-- we created one child group
-- then we created a second child group independently
-- now it appears that even when trying to create a regular group, it automatically creates it as a child group under the parent used previously

#14 Updated by Matt Gold over 8 years ago

  • Status changed from Testing Required to Assigned

#15 Updated by Matt Gold over 8 years ago

Also, my thought is that the issues here are serious enough and require extended UX discussion, so we should probably consider pushing this back to 1.7

#16 Updated by Boone Gorges over 8 years ago

  • Target version changed from 1.6 to 1.7

Also, my thought is that the issues here are serious enough and require extended UX discussion, so we should probably consider pushing this back to 1.7

I agree.

#17 Updated by Boone Gorges over 8 years ago

5. Finally, the process of creating a subgroup is unclear:
-- are all members of the parent group automatically added to the subgroup?

No. It's for this reason that I think that the setup as currently on cdev is kinda pointless. If you want this kind of membership cascading, please give specs.

#18 Updated by Matt Gold over 8 years ago

Thanks, Boone. I don't have specs so much as use cases. Here is one:

I'm teaching a digital praxis class this semester with ~16 students. We have a master group for the class, but since the students have split up into three project teams, it would be neat to have 3 subgroups for the class, one for each team.

Let's say that a member of one team wants to set up a subgroup. During the setup process, there should be a way to invite current group members to this subgroup.

This would necessitate an invitation screen in the group setup process. I suppose it could be done after group set up, but I think it would be more intuitive to have it be part of the subgroup creation process.

Does that make sense?

#19 Updated by Boone Gorges over 8 years ago

  • Assignee changed from Boone Gorges to Chris Stein

It makes sense, but I don't really have a good sense of how this workflow should be generalized and fit within our existing UI. I'm going to reassign to Chris for his thoughts.

#20 Updated by Boone Gorges almost 8 years ago

  • Target version changed from 1.7 to 1.8

#21 Updated by Boone Gorges about 7 years ago

  • Status changed from Assigned to Deferred
  • Target version deleted (1.8)

I feel like we're not really clear on what's desired here. As this is a major change to existing functionality, and doesn't seem to be in great demand, I'm going to close the ticket. If anyone wants to champion this concept by detailing workflows and UX, that person feel free to resurrect the ticket.

#22 Updated by Matt Gold about 7 years ago

I don't think we should defer this one, but I do think we might consider what "related groups" instead of "subgroups" might look like. Subgroups, as a concept, was a bit complicated, in that there were questions of shared data and feeds.

I'd like to propose something a bit simpler:

-- we create an interface that allows someone to create a "Related Group" from a current group. The main difference between this group creation interface and the normal one is that it would make it easy to invite members of the current group to the new one, perhaps through a checkbox format

-- somewhere in the interfaces of both groups, one sees a "related groups" tab or info panel, which provides direct links to those groups.

This might accomplish some of the original goals of the ticket without dealing with some other possible ways of conceiving of subgroups.

Thoughts?

p.s. Right now, one can do this manually by creating a new group and inviting people, and then, say listing the other related groups in the group description field or in a group doc. But the description field is tricky for private group, as the description itself is public. And I think that the "Related Groups" concept I've fleshed out about would be useful to groups.

Also available in: Atom PDF