Friends and Groups for BuddyPress 1.3
John James JacobyKeymaster
Andy and I kicked around an idea for BuddyPress 1.3, and it’s time to get some developer feedback. It has to do with 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.
Join the discussion here and feel free to reply to this forum topic with non-developer opinions on the idea if you’re not comfortable contributing on a developer type level.
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.
Remember these are all just ideas and specific to the behind the scenes code. As far as the user interface is concerned there would be no overlap.
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.
John James JacobyKeymaster
@erich73, this idea actually helps your issue along, as it would allow you to rename “friends” to be anything you want it to be. In theory, your users could group people together that they’ve gone on dates with, if not for any other reason but grouping them together for their own sake. In some cases the term “friends” isn’t accurate, and all that friends are is a group of users that have a specific scope of access.
This idea could even be used to group people together that you don’t want to access your profile. Or you could group people together that you work with, family, etc… Or you could use groups in the same old traditional manner to create little micro communities within a website.
Again, this is all just theory and talk at this point. The point of this topic (and the trac) is to open up the idea for community discussion to get opinions and ideas before I/we decide to pull the trigger(s) and make it so.
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
I am personally not a fan of taking it this direction (with a few caveats depending on where it goes)
@Peter – 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. Not sure it would be wise to try and break the momentum 300mm users already understand. Now, expanding on the idea is another thing altogether.
We should start with what a “friend” means/should mean in the BP environment. There is overlap of the concept with Groups, but a major distinction, too that keeps me from supporting this shift you describe. If we expand the friend concept in its current manifestation, I think we’ll be better off.
Yes, @jjj friends are just groups of users. But that doesn’t make them Groups. Groups are organizations around a topic/idea. I think if you try to include an aggregation of users into that model, you will blur the lines as to confuse everyone. Since I don’t want being a friend of me being the same as being a member of the “Mike Pratt” group, you will force developers to have to change everything to make it look like the old process, or do it yourself. Is there really that much gained by you in the process? I mean, so much of the group functionality may not be necessary in a personal group.
Re the “it’s like Twitter following” it’s not either/or there. “friending” requires acceptance on the befriended’s part. Following does not. Admittedly, it would be great for BP to allow for a following kind of capability so I can keep tabs on those whose activity I care about but aren’t really “friends” with.
What is the filtering issue you speak of? On 1.2 I can look at activity of My friends or My groups and it works great. 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. I’d even do it on buddypress.org and list @jjj @andy @jeffsayre etc into a group to follow what the sage’s all have to say. In this new concept, I will have to create a group for them? but they will already be in my “friends” group?
One thing to consider – the new Update functionality, in effect, already gives each user his own forum. A threaded conversation can already happen there and it’s centered on that user. If you are truing to make it a private one, then revamp the message system to allow me to send a private internal BP message to a group of friends (need that part too) and have it be a private threaded conversation/message. It’s dangerous to allow me to make it like you suggested
“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 gives the ability for someone to interact more personally with someone to whom they never initiated contact. Perhaps just adding a friend “type” ie “follow” would be very useful. It is the type that doesn’t require acceptance on the followee and the followee’s activities are visible according to their own set terms.
In summary, I think we keep Groups as topically focused “clubs” or “associations” that have members, content and activities and then each person has relationships with other users on the site. Some are “friends”, some they just “follow” with added functionality like grouping (pardon the use of the word), mass messaging (based on permissioning), etc
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.
Thank you Mike Pratt for doing all my typing for me. +1
totally agree with you.
“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.).
I made a mock-up of how I picture this “friend” page.. Actually a better name for it would be “My Network” or simply “Home”
The screenshot can be viewed here: http://www.bp-tricks.com/wp-content/uploads/my_friendsv1.jpg
The design is my own, but the functionality could be used for the new BP theme as well:
Left: The activity stream as we all know it from the upcoming BP 1.2. Added the options to filter activity based on “Friend Categories”. This works with a vertical dropdown menu so if a user has many friend categories you won’t run out of horizontal space. It would be cool if the same could be done with Groups. So you can not only show activity from all groups but also from specific groups. This would make the activity stream even better imo! In the example I added a custom filter which could be added by a Twitter plugin. It allows the user to filter the Tweets from their friends!
The right side is filled with boxes which display useful information for the user. It shows:
– Quick Links: Links to pages which might get used a lot. Users can add their own links to pages they visit often.
– Friend Categories: Show the 5 most recent friends from every category
– Groups: The groups a member is part of and an options to show all their groups
– Custom boxes: these are boxes that are added by the users or by plugins. See it as widgets but then for an individual user. In my example I’ve made two widgets:
A quick tweet widget: Allows a user to send a tweet to twitter easily
An RSS widget: The user fills in one (or more) RSS feeds which get displayed in the widget.
Personally I think this would be a great step forward for BuddyPress profiles. If there would be a “Profile API” similar to the current group API, which allows developers to easily integrate widgets or activity stream filters for their plugins, it would be really great! Some other examples could be:
Quick Photo uploads (quickly add photos to your album from your “Home”)
Submit link (BP-Links widget to quickly submit a link)
It would be even better if users could also drag and drop the widgets to their liking. I’m interested in what others think of my mock-up, and the way I think the Stream/Friend Categories should be handled.
Also I would like to add that I agree with Mike about what Groups should be and Friends should be… Well said Mike
Hoeveel Nederlanders zijn er in de Buddypress community…?
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.
the suggestion of JJJ is great, but why not make “Groups” of people which you have “friended” already ?
So first “friend” with people, then put them in your different Friend-Groups like “family”, “customer”, “employee”, “girlfriends” (which might be set to be a hidden Group), etc.
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.
@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?
@Bowe Nice 1st attempt. t has many elements Andy is trying to capture in 1.2 default theme. I appreciate everyone’ kinds words. My objective is to try and force myself to view this from the perspective of he user. I have a userbase that has a few quirky characteristics: ages 17-90, usually very bright but many find this whole area unintuitive. lastly, they all want to engage with each other. So…every element on the site has to promote that re-connection and engagement…intuitively. 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.
Back to our issue: in a nod to @jjj’s original point, we have a set of groups (graduating class groups) in which users are auto joined upon sign up (having been required to input class year) Now, this is a group that everyone already is “friends” with. There is merit to some sort of auto-friending action which is being proxied by joining the group. Most users on the site seek out their year group and friend them. Maybe we should keep it that way (let’s you keep your distance from the jerks in your class) but we could also do more in making the process easier.
As we start from scratch and redesign the sight with the new parent/chile & 1.2 functionality we will focus on the following questions: What’s going on in the things I care about? e.g groups and friends and What is going on in the site that I might care about? Focus on too much of the former and users miss out on a lot. Too much of the latter and it doesn’t feel like a personal experience of connection and engagement.
The last thing we need o NOT lose sight of: As we connect, sync and add inter-operability to all of our components, how we present all this activity to the user will make or break the success of the site. Actions and activity need to be where the user expects them to be. Not cause we just threw it in there. It can’t appear out of place or cobbled together. Many a site has blown off this aspect and wondered why the user behaviors on their site are erratic. Example (minor but critical) On testbp.org a user made a post onto a topic in the BP testers group. That topic has 3 pages of replies. When you click View Thread you are taken to the topic’s 1st page. There are pros and cons to this. Pro: you get to start from the beginning and go thru all replies Con: you have to start from the beginning and goes thru all replies….or make your way to the end . Now you can reply from the bottom of the 1st page but you will actually never see the reply whose View Thread link you clicked on, so the user is often mis-oriented. I know I digress, but my users have written me to emphasize that it was often the person who made the reply that prompted them to click View Thread and then they never see that reply again.
The point is, it’s the user and his relationship to other users (friend or not) that often drives behavior and expectations. That’s why adding avatars to all activity completely changes a feel of a site and makes it seem personal.
@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.
a bit more food for thought… http://daggle.com/facebooks-microsoft-moment-1556
@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.
I guess the “Group-settings” (public, private, hidden) would give an additional level of Privacy-Options for “Friends” if we go with the idea of Andy and JJJ.
So I can set a certain “Group of Friends” to be hidden from all my other friends.
That would be a very needed feature !
For example you are running a website for a niche-company-directory:
so the user will have friends at his suppliers and at his customers. But I am sure he does not want his customers to know who his suppliers are and vice-versa. This would be also the case at other niche-websites, like dating-websites, etc.
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!
@peter certainly not offensive. seemed out of place. no worries
@erich73 the friend group setting could easily be done in the context of merely “grouping” your friends. No need to make them part of a “friend” group. ok, i will stop duping that word. I will call it a friend list!
@bowe I think the functionality is there to filter in the way you suggest. Of course, you are talking something different when you discuss allowing people to create their own Home pages.
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.
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 ?
Keep It Simple & Stupid
I would like the twitter list style with two communication.. maybe create special friend/group hidden from other people/friends..
… 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?
- The topic ‘Friends and Groups for BuddyPress 1.3’ is closed to new replies.