CUNY Academic Commons

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!

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.

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. 

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?

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.

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

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

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.

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?

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.