BuddyPress.org

when this is helpful to you in order to solve some issue as you described in the related TRAC, then this is fine. Also it will give additional options for the user, as he will have better Admin-rights to manage his Friends and have his own Forum (you really want to have each user having his own forum – probably a great idea….).

However, it should be a clear differentiation between “generic Groups” and “Friends”.

Lets say I am running a Dating-network on which I do have generic Groups like “Dining”, “Travelling”, “Hobbies”, etc. , then it would not be nice if Friends-Groups would get mixed-up with generic-Groups.

I’d like this shift. I’ve always found web friending a bit silly. I’m trying to use Buddypress for semi-professional communities. Groups is where the action should be and where Buddypress could really set itself apart from the Facebook wannabees.

After some thought I kinda like the idea of giving friends a central place to talk just like a regular group. Here are my thoughts:

I think it could work very well and some group-like functions should be added to the My Friends/My Network idea proposed here.

but I also think the “My Friends” should be more limited then a regular group and would serve a different purpose then a regular group. A regular groups allows for more in-depth user interaction which is also viewable for the general audience of your community, while the My Friends section should be a quick way to interact with all your friends and to filter new stuff based on your friend types (familiy, work, regular friends). It does not need to have a discussion forum, I think it’s main focus should be a “friends” activity stream + extension possibilities trough a Friend API (based on a group API)

The way I see it the “My Friends” page should be an overview of all your friends activity and let you filter content just like the activity stream. I am working on a screenshot to visualize my vision . Hope to have it finished today!

I really like the idea to filter your friends by category, and for instance show only the activity of my family members. I also like the idea extending “My Friends” by showing Tweets from my friends etcetera.

think that this is important because Groups are meant to

Maybe this is a little off topic, but it’s about something mike mentioned. I think the development goes with 1.2 already in the right directions. I like almost everything about it. But some things are really missing. For example the mass-messaging in a group. I think it was a crucial option for the groups (and right now it is the backbone of our groups!!!) and now it’s gone… (is there any thought of bringing a funvtion like that back?)

I many points I agree totally with mike.

@Mike

totally agree with you.

especially:

“What BP needs, I think, is expanded friend functionality. Ie friend grouping a la facebook style so I can filter my ever growing list of friends into like groupings e.g. Family, etc.”

being able to do mass-mailing based on different “Groups of Friends” (different mail for Family, company, best friends, etc.).

Also I would like to add that I agree with Mike about what Groups should be and Friends should be… Well said Mike

I think a lot of what Mike says is quite sensible, but my impression, reading what JJJ posted above and at the trac ticket, is that there would be next to no change in the way that the friend relationship works from the user point of view. Viewing a list of my friends, for instance, would be the same as it currently is. The difference is behind the scenes: the friend list is really the member list of a special kind of group (where ‘special’ entails private, stripped down, etc). While it might technically be true that, for instance, Mike’s friends would be a member of the “Mike Pratt” group, that’s not how it would be represented on the front-end of BP.

From a developer’s point of view I very much like the idea of merging components where possible, both to streamline the core BP code and to make extension easier to do.

A small thought about how it’d have to work. Currently if A requests membership in a private group, an entry is written to bp_groups_members = 0. When the group admin B approves membership, it changes to 1. If the current symmetrical model of friendship maps onto group membership, the second step – admin approval by B of A’s friendship request – will have to write another entry to bp_groups_members, this one making B a confirmed member of A’s friend group.

Just speaking strictly from a software design standpoint, calling someone’s friends a group does not make sense.

A friendship is a direct relationship between two people. It is a one to many relationship which is handled by using a lookup table that points back to the user table. It is just about the fastest possible relationship that you can have in RDBMS because both keys point back to the users table and the optimization of that query is killer if you have the right indexing. The only faster one would be a self join, for instance Bob is Jane’s spouse, which requires no lookup table.

A group however, is a one to many relationship, which is handled with a lookup table that acts as a bridge to a third table that holds the groups data. This is much different when it comes to querying. If friends are just Bob’s private group, it is going to make querying for relationships between two people very convoluted in many situations, especially where a fourth, fifth table or more is involved. There will be round tripping for data and/or nasty DISTINCT queries in many cases where it would not otherwise be necessary.

@Boone I understand, but think about how much you just described to merely add some meta information to a user’s friends. I’m not convinced it reduces and simplifies.

@Peter Why would you ask that question in this thread? I’m sure Bowe can tell you how many are in the Dutch BP community in a less non-sequitor thread, no?

His screenshot was full of Dutch and said Brajesh is in the Netherlands as well. Just thought it was surprising/funny. Apologies for any offense.

Yes, Facebook burned “friending” into the lexicon and made a mess of things as far as that definition goes. But it’s here and it’s what we have to work with. … We should start with what a “friend” means/should mean in the BP environment.

Just because Facebook has it doesn’t mean Buddypress has to have it. Imho Buddypress should concentrate on profiles, (micro)blogging and groups. I’m certainly not in favor of turning levels of friending into Buddypress’ center piece as Bowe’s screenshot basically proposes.

@ Mike:

As an example, a place to tweet from my site won’t turn many on. Not because they aren’t on Twitter, but they don’t come to the site to do it, don’t usually want to tweet about what they are doing on the site and the added convenience of tweeting from within the site isn’t worth the real estate. Still – it’s a great idea for other sites.”

This is exactly what makes these kind of decisions so hard to make for the development team. Basically there are so many different needs for different usergroups, that decisions about core functionality are always very hard to make. I apreciate the amount of interaction between us (end users) and the developers (core + plugin developer) on the forum and the trac, and I do think we’ll get there in the end. Since I am not a programmer I can’t say what is technically the best way to do something, but I do know a thing or two about social networking and online communities in general.

The thing which makes BuddyPress really stand out is, is that it actually crosses a bridge between blogging/publishing of content and micro-blogging/meaningles social networking. There has always been a clash between those two types of users and some usersgroups are way more focused on quality (and somewhat lenghy!) content then others. Your example about real estates agents looking for totally different ways to interact then a typical social networks user is spot on. You do not need twitter integration on your site, and you do not want to have those functions overcomplicating your site. My users on the other hand are EXTREMELY mixed on so many levels. The only thing they have in common is the fact that they all have the same disease. This makes creating my network a really big challenge and it means that there are many factors I need to think about. Many of my users are used to blogging and discussions forums, and a younger generation is used to facebook and twitter. Currently the more traditional users have more then enough to do on my site with the amazing Blog + Group functionality. These components can be tweaked to my liking by WordPress (user blogs) and the Group API.

Since the introduction of the Group API you have seen that there are plugins coming out which let us (the site owners) decide what we want to add to our social network. Plugin developers can easily hook into the Group API and add functionality to it, which might be specifically written for a specific usergroup. We’ve seen Groupblogs, External Blogs but also Twitter integration plugins, and it made the Group component by far the most powerful and promising BP component as of yet.

The mock-up I’ve made is basically saying that this kind of functionality should also be extended to regular profiles, so we get much more flexibility to create the social network we see fit. This does not only mean adding new functions but also disabling unneeded ones.

If the Friends functionality was extensible trough the Profile API it would mean that it could be customized into something that would fit different needs for different sites. Maybe some sites would like to allow individual users to add Twitter Widgets to their profile page, and allow groups of Friends to discuss on a seperate forum. I could imagine that a “family oriented” community could greatly benefit from such a feature, but your real estate community would not! With a Profile API it would mean that it could be added as a plugin on top of the basic friend functionality which everyone could use as a base to work from.

So basically I’m saying that it might be smart to work on making all the components as flexible and easy to extend as the Groups component, then it won’t take long before before there are so many options available to do thing they way you want, we will all be happy! There are more and more people discovering BuddyPress as a “general” Social Network solution instead of a “social network for bloggers” and there are even a lot of users who want to get rid of the blogging functionality and make it a normal social network. If WPMU and WP merge there will be even more need for individual/profile related functionality and a good API is the first step to achieve this!

@Bowe,

well said.

I guess what we do NOT need is “twittering” and “tweets” with 140 letters.

But what we do need is a feature to “FOLLOW” somebody we are interested in, like “follow” somebody because we like the way he is writing his Blog or we do like someones opinion on something. Following somebody does not relate to the “quality and somewhat lenghy” content of that specific person.

In fact we could “FOLLOW” a “Person” as well as a “Group” – and after a while get to the point to invite this person for a “Friendship” or decide to “Join” a specific Group.

Hm well……

reading what I have just wrote myself – not really sure whether we really do need a “FOLLOW”-feature after all. Because if you like somebody, you can directly request a “Friendship” without following him for a year

So at the end: do we really need all this TWITTER-FOLLOWING-stuff ?

Probably just having something like “subscribe to this Forum-Thread” or “subscribe to this Blog” and receive an e-mail when there are any updates would be what we REALLY need ?

KISS

Keep It Simple & Stupid

Original question:

… deprecating the friends component entirely, and using the groups API to mimic the behavior of “friending” people, which is basically just grouping people together anyhow

Removing the friends component would be great from a KISS perspective. Could you do Twitter-style following with the groups API?