Deprecate Friends component and replace with Personal Group type

[johnjamesjacoby]

Since "friends" are just a group of users, the thought is you could ditch the "friends" component all together in lieu of letting users create their own personal groups, where they pick who's in them rather than people just joining them.

People could request membership the same as they do now, except with this method "friends" reaps the benefits of everything the groups API can do. This would solve the group activity feed/list/filter issue also, since my private groups of friends would just show up as another group to view and post to.

It would solve Jeff Sayre's user relationship issue too, because then he could create 10 private groups and call them what he wants and put people in them however he wants.

Our fear is that this might over complicate the groups component, so making the UI easy to understand is critical if we go this route. It also blurs the lines as to what "groups" actually represent.

What I notice on testbp.org is that when people join the site, they immediately do three things. Check out the activity wall, join groups, and add friends. This would simplify the group/friend process and make it a one shot deal.

Other open source software works similarly. phpBB uses groups in a way that works on both an Access Control level, and a friends/foes/ignored users type of level.

If we introduced a "system" group type, you could basically have site-wide moderators, site-wide contributors, etc... Groups of users that have their own forums, activities, members, and scopes.

My theory for how this works is a lot like Twitter's lists, only they work in both directions. Not only is it a group of people that I know, the people I've added to that group now can talk back and forth to one another because I've added them as a "friend." It's a way for my circle of friends to talk using me as the center.

In the group creation process, I just imagine seeing an extra option for a "personal" group type, and maybe a "system" type if we expand it that far.

These groups act like hidden groups, except people can request to be in them, as well as the group admin being able to add anyone to the group they wanted.

DB migration wouldn't be too hard. Just make new groups called "friends" for each user, and add the user_id's that everyone already has as friends.

URI's would need to be mapped away from /groups to /members/john/groups/group_name instead.

The "friends" component then could be replaced with something similar to the "follow/followers" model of Twitter. Something a little lighter and less meaningful than a group or a friend.

Thoughts?

[mikepratt]

JJJ - I have many thoughts. I hope some of them help! I think this is an idea that NEEDS to be discussed on the forums and not in TRAC. Trac isn't a great tool for this and I don't subscribe to Andy's idea that if the conversation gets to dev'y then it scares folks. If that's the case, then all we need to do is have Dev group on buddypress.org.

Look for my long forthcoming comment on the forum thread.

Mike

[johnjamesjacoby]

The reason I refer people to the trac is for developers to monitor the conversation and be able to document, patch, and branch it, and add it as a specific enhancement or feature in our development cycle.

The forums are mostly for supporting the software itself and showcasing extensions of it. Development of the core is better in the trac because we can open, close, and more closely relate the dev talk to dev code, patches, revisions, and changesets.

Also people pay closer attention to the forums and sometimes things are taken out of context or too seriously as being fact instead of theory. Trac tends to be taken more as theoretical dev discussion that doesn't get anyone too excited. :D

[DJPaul]

I agree with most of the points in these posts - http://buddypress.org/forums/topic/friends-and-groups-for-buddypress-13#post-32115 and http://buddypress.org/forums/topic/friends-and-groups-for-buddypress-13#post-32157. I'm not sold on this idea as it stands.

Specific points:
MrMaz; "Friends [or other types of relationship] are one-to-one mappings. Groups are one-to-many."
Mike Partt; "...friends are just groups of users. But that doesn't make them Groups."

Also:
"…could be replaced with something similar to the "follow/followers" model of Twitter"; moving relationship mapping into the Groups component is not the only way to achieve this and so shouldn't be held up as a reason for such a change.

"...reaps the benefits of everything the groups API can do"; this is extremely wooly and vague. I need specific examples -- in the way that the Friends/Friends? workflow is currently -- to discuss this.

Mapping friend URLs to something like /members/john/groups/friends/ looks horrible. Read the URL backwards, it doesn't make sense for this context; that URL to me is saying "list of friends in all groups that John is a member of" rather than "this is John's friends."

Mike Pratt comments on the forum thread, "the friend group setting [for SWA & Personal Activity filters] could easily be done in the context of merely "grouping" your friends. No need to make them part of a "friend" group." I think this is exactly right. Think Site Wide Tags.

[erich73]

Talking about "grouping" of friends into different Group-folders, like e.g. "family, work colleague, customers, suppliers, etc." - this brings me to the following feature which would be required:

---

I am building a website with 5000 different Groups, like a company-directory.
So giving each company its own "Group".
How to categorize a big list of Groups into different categories ?
Like I want to sort this big list of Groups by industry-specific areas.

---

http://buddypress.org/forums/topic/how-to-categorize-groups

[windhamdavid]

jjj, I'm sold. This is very insightful point. (from the vantage of a behavioral psychologist) It makes 'friends' more powerful and oblique at the same time. Friends will consolidate perfectly in the groups api while opening up the more dynamic (not "less meaningful') 'follow/follower' model.