Skip to:
Content
Pages
Categories
Search
Top
Bottom

Friends and Groups for BuddyPress 1.3


  • John James Jacoby
    Keymaster

    @johnjamesjacoby

    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.

Viewing 21 replies - 51 through 71 (of 71 total)

  • @mercime
    Keymaster

    @mercime

    With BuddyPress being used now by/for different interest groups from colleges to niche organizations to purely social networking, etc. there is no doubt that there would be different opinions regarding importance of the friends component vis-a-vis groups component.

    I’m surprised in the first place that the friends component could even be considered for deprecation since that’s a popular feature. How about a switch to enable or disable the friends component? In one install, e.g. for a professional organization, they don’t need “friends” and prefer “groups.” In another install, for a social club, they’d like “friends” and “groups.”

    It would be great if we see categorization of friends (as Bowe mentioned above) as it makes a lot of sense and extend it so that you could send a message only to Friends-Family or send a message only to Friends-CollegeBuds.

    However, should the friends component be deprecated, I would request devs to expand Groups component with a user function to have the ability to privately categorize the people within a Group he/she belongs. e.g. Group-Hiking-Friends, Group-Hiking-Pros, Group-Hiking-CollegeBuds, Group-Hiking-NeedsMoreTraining.


    designodyssey
    Participant

    @designodyssey

    I’m very late to this party, but since I’ll be developing when 1.3 comes out, here’s my two pennies.

    I believe the modularity and CMS capabilities of WP/BP should be expanded. I think we need the ability to create different “content types,” “user types”. Groups could essentially be a user type. Users are a user type. Tournaments, Classrooms, Camping Trips could all be user types. Differentiation is based on functionality and capabilities. I’d like to see a single API work with user types as I hope WP is moving toward for content types.

    Let me decide what a friend can do just as a group. Because “groups” can have multiple distinct members, they require a bit more thought, but other than that it should be the same.

    BTW, I would never want users to have their own individual forum, but someone else might and that’s the point.


    stwc
    Participant

    @stwc

    20,000-foot thought here, but possibly germane.

    I’ve been thinking as I’ve gotten from ankles- to knees- to nipples-deep in Buddypress is that there may be a little fuzziness conceptually (or perhaps it’s just my own lack of understanding and need to hammer things down, mentally) around some stuff at the highest level as BP has evolved.

    What I mean is something like this: forums and groups seem commingled in a way that is pretty darned counterintuitive, I think, for most users accustomed to traditional forums structure or to social networky ways of doing things. This is not entirely to the bad — I’m not suggesting that — but I think it confuses people who are not ‘techy’. This initial confuzzlement means a lot of people give up without trying to figure out the Buddypress Way, which is a Bad Thing. For my part, as someone who’s highly technical and been working on and off in designing user experience stuff for decades, even me, if a site doesn’t present its ‘expected’ interaction mode after a few seconds, I’ll probably give up and go elsewhere. Little things like a lack of an easily found search box will have me closing a site tab, my patience level is so low — I think that ordinary users tend to be a little lost in the groups/forums melange of Buddypress, sensible as it may seem to those of us who are building the sites, and just give up and go back their Facespaces and Mybooks.

    Part of the issue I’m describing badly probably comes from the bolt-on and eventually plugged-in nature of BBpress as part of Buddypress, but I also think it might have been a bit of a result of not starting from top down, boring old use-casey thinking. I could be wrong there, of course, it could just be me, and no offense to Andy or anyone else meant by saying it. It just seems a little… wrong to me, a bit, thinking as a user.

    So, finally, about this latest idea and thread: there seems to me, as part of the shift in 1.3, to be a changing conceptual focus. That is, we are directing the focus of users from other individuals, other users on the site (as ‘objects’), to the activity of those individuals, as the engine of interaction, if you will. ‘Following’ activity and so on. Now there’s nothing wrong with that, and I actually feel it’s a very good idea, because engaging users and keeping them actively using a site and interacting with others is what it’s all about, and Facebook, like it or love it, understands that perfectly.

    But there are downstream consequences of activity (actions) being the focus of site use as opposed to, for lack of a better word, objects (people, groups).

    I’d just like to hold up a hand and say that considering what those consequences might be is a wise thing, I think, if only to avoid a kind of frankenstein’s monster situation, with different conceptual drivers for user engagement ruling over different parts of the app, and further stirring up cognitive dissonance in already-possibly-bewildered users.

    OK, that’s enough words now. ;-)


    Mike Pratt
    Participant

    @mikepratt

    @stwc I think you make an eloquent, objective point. While I think there’s some merit in it, I respectfully disagree. Yes, people are used to (in many respects) to the old b-board way of doing forums, so from that perspective, BP will be a tad foreign. Looking at it another way though – that old method shoe-horned users into combing though a giant list of things looking for what they were interested. As a tech dude myself, I can tell you I never “browse” forums because they are just not browsable. You have to search for what you want and then pour over unrelated threads. It’s too much work.

    BP Groups is a new way of looking at things, for sure. BUt it allows you to “group” content, of which forums are merely a part, in a way that makes sense for people that want to associate with that content.

    The model breaks down in some use cases but I have something like a 90 “love this new way” hit rate on the concept. Only a few have stated they want the old way (and BP’s forum listing solves that problem for them.

    my .02

    I am also of the opinion that if you design something with a supremely intuitive interface that just “works” in a very logical manner, it doesn’t matter how much you change the model (assuming it’s a step forward)


    MrMaz
    Participant

    @mrmaz

    @mike

    I agree with both you and stwc. I think you are both correct. It all comes down to the audience and who you are developing the site for. In my limited experience of exposing BP to uninitiated and/or Average Joe type users, the 1.1 branch’s default theme is not very “dummy proof,” and at times downright confusing. It will be interesting to see how the 1.2 default theme does in the real world.

    Modeling real world social interactions which are very organic and three dimensional in a software application which is by nature “flat” is not easy, and probably impossible to get perfect. This is why I am always advocating a flexible API type of approach, over a rigid feature set type of approach. Developers need the freedom to tune the app to their audience, because no two sites will have the same requirements. I am not talking just about the interface, I am also talking about how the app behaves and responds to differing requirements.


    Mike Pratt
    Participant

    @mikepratt

    @Mrmaz well spoken


    abcde666
    Participant

    @erich73

    @stwc

    I agree with you on the Group-Forums being a bit confusing, for techies and even more so for non-techies.

    Any suggestions / ideas of how to improve this ?


    peterverkooijen
    Participant

    @peterverkooijen

    … forums and groups seem commingled in a way that is pretty darned counterintuitive

    My solution is to just ignore/remove forums and focus on communication between members via (micro)blogging and threaded comments.

    It’s cool to have the option of BBpress integration if you want it, but I don’t understand why it is becoming a default core component of BP. I hope BP steps back from that brink…


    Bowe
    Participant

    @bowromir

    @Peter a lot of social networks could benefit from a forum for a more centralized discussion, especially larger sites.. Forums should not be the main focus but certainly not forgotten or “dropped”. Especially since it works pretty well and intuitive after you’ve grasped the concept of the group/forum connection.

    We all have to remember that BuddyPress sites can use any or all of the components; what is right for one site is wrong for another (and vice-versa).


    John James Jacoby
    Keymaster

    @johnjamesjacoby

    Saying that friends would be “deprecated” maybe was a bad idea. :)

    The friends component is basically done, and doesn’t need much more development, because it’s a means to an end, and a dead one in my opinion. You add someone as a friend, they accept, now you’re friends. But that doesn’t actually mean you’re really friends, nor does it make BuddyPress function differently when viewing other users. Not to say you can’t build custom functions around the “if we’re friends do this, if not do this” way of doing things, but that involves template switches and chopping up code for 1 specific type of relationship with no depth or scope or ability to reuse or repurpose.

    It will come to a point where we either build out the friends component with an API that lets “friends” tag each other, categorize each other, and plugin to it (like groups already has, think “friends calendar” functionality,) or we use what’s already here, eliminate duplicate code and functionality, and add a few extra brain cells to the groups component.

    The best way to explain why I think this is a good idea (from all perspectives) is that it gives the group component more or less flexibility, by giving it a range that it can reach based on what the site admin allows, and what the user allows, from within an API that already exists.

    Real world example: Go to testbp.org and create a group. A group about what? Well, BuddyPress obviously, since that’s what the website is about. What if I don’t want the people in that group to talk to each other, but I just want to group users together that I’ve met in real life? Or at WordCamps? I can’t… They’re not my friends, they’re not colleagues or really even acquaintances, but I met them and want to stay connected somehow. I make a group called “Met at WordCamp”, I check the “User Group” option, I don’t create a forum because they don’t need to talk to each other through me, I add the people I met, and I made a group of people. Now, if I want to talk to all of them at once, I use the activity stream and since they’re all in that group, they get it on their feed and they can all reply to that stream item.

    It’s a way to isolate people you already know, and put them in a box for later. BuddyPress already does a wonderful job of making sure you have access to all sorts of information, from people, blogs, groups, and friends. What about when I want to start narrowing down all that information and isolating it into what I think I want to see, and who I want to talk to? That’s what this would/could/should do.

    And if your site needs the friends functionality exactly the way it is, it would still be available in exactly the same way it is now, with the same database structure and code and filters and everything else. Only you would need to install it as a separate BuddyPress “add in” like what will happen with the wire component for 1.2.

    Maz, I get that “friends” is a very simple 1 to 1 relationship that makes data management easy, but it’s also severely limited in the functionality that it provides. If we grow out the friends component, it would only be to include more group like functionality anyway, right?

    At the end of the day my feelings won’t be hurt if the idea gets voted down, so keep pouring on the feedback and brainstorming. It’s been a really great discussion so far and I’m pumped that everyone’s this interested and passionate about the idea. :D


    MrMaz
    Participant

    @mrmaz

    @jjj

    Just a little clarification, not meaning to nitpick. In my post I said that friendship is a one to many relationship, since each person can have one or more friends, but yes, each relationship in and of itself is a one to one mapping.

    I think I have a pretty good idea of what you want to accomplish, but I still think you need to re-think how to get there.

    Based on everything you have said, what is needed is to make friendship more abstract so that it can be extended. For instance so there can be more than one type of friendship. You could even have layers of friendship types without making things complicated as far as data storage goes. Once you have some abstraction then powerful filtering becomes possible.

    And instead of using groups to accomplish the grouping of friends so that you can use the group component’s features, it would make a lot more sense to refactor those features out of the group component so they can be re-used elsewhere. So if there is a particular feature of groups that you want to use for something else, ask yourself how to move that functionality vertically into the core API instead of merging components horizontally to share features.

    In case all of that is unclear, basically what I am trying to say is instead of moving functionality around, break it up into smaller generic bits that can be re-used. You get rid of lots of code duplication and increase the depth of the API, while not losing any features.

    TLDR version: Introduce types of groups. e.g. “User group” type – it has no forum, no “Home” page, just members listing and activity stream. This group added to Activity Stream filters where relevant.

    Would have to filter out custom group type “User group” out of the /groups/directory page & member profile group page.

    These custom group types could be set so they are publicly visible/private to those members involved/or hidden (visible to the creator only). As per current Group privacy settings.

    Could add e.g. “Friends”, “Colleagues” and “Fans” as default, empty groups for each user on user registration. Obviously revise theme to make the “Friends” page (“Connections”, maybe) look like the Friends page rather than a regular Group.

    Different users might create “User group” types with the same name but with different meaning (“Fans” could be interpreted several ways for example). This is no problem as such categorisation is defined — and belongs to — the user who does it. Might need some semantic group kind/type identifier in the code to allow FOAF/SIOC RDF profiles to be able to assigned to these “User groups”.


    abcde666
    Participant

    @erich73

    hmm…I am not a FaceBook user, but it seems 300 million people are.

    How are “all of the above mentioned” things being done at FaceBook ?

    Do we need to re-invent the wheel ?


    peterverkooijen
    Participant

    @peterverkooijen

    Last post from me on this thread, just for the record and to summarize, I support John James Jacoby’s vision 100%.

    Restructering friending around groups and microblogging/activity stream is a next step in where social web is going. Groups would become extremely useful for all kinds of use cases. It would really set Buddypress apart.

    Buddypress can’t be all things to all people imho. Development should focus on a conceptually coherent core, with APIs that make it easy to plug in other more linear functionality, like classic friending and forums.

    Do we need to re-invent the wheel ?

    Buddypress shouldn’t just copy Facebook – apart from perhaps the registration process… ;-) BP has the opportunity to do things different, better, move things forward.


    Mike Pratt
    Participant

    @mikepratt

    @jjj You confuse Group with “grouping of friends” I get your point but you wouldn’t create a group on TestBP.org just to group your friends. That’s not what a group even means. It is an aggregation around a concept or a topic that people self associate/ask to be a part of or are invited to associate with. It’s like a little contextual club within the site. What you are speaking of in your example is a grouping of friends which the BP Api should allow for and hopefully will. The you’ll be able to filter by friends or groupings of friends. That becomes personal. On the group side, you can join Groups and then say “keep me up on all that happens in said Group” or better yet, show me activity in Group X by my friends only.

    Friending someone does have meaning. it means you care about that person’s activity. At this point people who try to shoehorn the traditional definition of “friend” into the social media-sphere will end up pulling their hair out. It was a co-opted term from the start. We have to live with that.

    All said, John, I am your friends wether we click a button or not :-)


    Bowe
    Participant

    @bowromir

    Thanks for further explaining yourself JJJ, and I like the general concept behind a lot.. But the idea that speaks to me the most is making BuddyPress in general more flexible and not “hook” into the group API but make a new one based on that which can not only be used for groups but also for users (and thus friends options).

    The idea to make a general API which can be hooked in by the Core components and 3rd Party plugins seems to me the best solution. If you take the group API for example and use it’s functions for individual users:

    – Add extra signup pages/fields

    – Add new pages

    – Add new navigational items etc

    All these things are possible with the Group API but take lots of work with a regular profile. Like MrMaz said you could break these functions into smaller parts which can be called upon and extended upon for Groups, Users, Friends and the Activity stream.

    The amount of possibilities for new plugins would be endless :D Once again I’m no programmer and this is coming from as a site admin/BP enthousiast/”Copy and Paste and pray to god I don’t get a white screen of death” kinda guy..

    edit: I would also like to say that Mike perfectly summorized my exact ideas of what a group should be and what a group of friends means. Well spoken. I’m getting a Deja Vu here lol :D


    stwc
    Participant

    @stwc

    I’m pretty much good with all of this.

    Back to what Mike was saying in response to my woolgathering: I do tend to think that there is a good intersection between traditional forum/thread/comment structure and the kind of social-networky way of (not) organizing things, and that Buddypress is heading in that direction, particularly with the new activity/threadedness stuff.

    But traditional forum-like structure, to some degree, is still what most un- or semi-sophisticated users who haven’t grown up with social networking kind of expect, I think. That doesn’t in any way mean that it’s the best way of doing things, though, as you say.

    The optimum path, as you suggest, I think is to continue to rethink things a bit (as Andy and everyone else who’s contributed to Buddypress has been doing) so that we can leverage the best of both worlds — the structured, heirarchical, predictable (if hard to search) architecture of the traditional forum along with the interconnected, non-heirarchical, loose-coupled, folksonomical, social, person- and activity-focussed interconnected peopleweb New Way.

    Hit that point just right in terms of architecture and UI design, and we’re not just reinventing Facebook or PHPBB or mashing them up, we’re doing something that’s made of awesome and sauce.


    stwc
    Participant

    @stwc

    Let me concretize what I’m getting at a bit — I just had a sudden thought.

    Taking what is probably the largest active Buddypress install — this one right here — as a test case, I just realized that I don’t really use any of the Buddypress social-networky stuff here (realizing it’s an oldish version of Buddypress and a unique case in some ways), other than the occasional personal message functionality. I don’t look at Groups or anything else, much: every time I visit, I head straight here, to the forum, which isn’t really all that featureful when it comes to forum implementations, but still does the job admirably.

    I’m not sure if the way I use this site reflects the way that most people do, but that’s my experience. Sure, I’m an old fart, and am more interested in finding and sharing useful information than I am in just hanging out and socializing, to some extent, and that’s the major part of why this install of Buddypress exists, but hopefully you see my point.

    I have a feeling that traditional, threaded forum structure might be an important centerpiece, as it is here, for many sites that will use Buddypress, if, of course, not all of them.

    Nothing we’re talking about — and I admit this is getting a little off-topic, but it’s germane, I think — is going to destroy that. I’m just raising it as a consideration in moving forward.

    Maximum flexibility, as Bowe and JJJ and others talk about above, is probably always the best thing to aim for.

    I guess this topic dropped off the radar, but I hope it comes back up again, because I personally think this is a great direction to go, and I see many advantages to having the friends feature built on top of the groups feature.

    I haven’t had time to read most of the previous 70 posts on this topic. One thing I do want to respond to was what MrMaz said early on about friends being a one to one relationship and groups being a one to many. I think friendships are one to one, but in practice they are almost always queried as one to many. You don’t usually query to get one friend, you query to get all of a user’s friends at once.


    Donald McIntyre
    Participant

    @donmcint

    Friends should be able to be called other names like: contacts if its a business networking site like I did with mine, partners if it is a closed partership intranet for a lawfirm or accounting fir, students, collegues, etc. there should be an option wher you put something or frieds is default. Groups is groups, but the additional functionality to add is very poor, group wiki does not assing a default wiki theme, group blog does not assign a default blog theme, etc Admins sgould be able to choose the default theme for these addons…

Viewing 21 replies - 51 through 71 (of 71 total)
  • The topic ‘Friends and Groups for BuddyPress 1.3’ is closed to new replies.
Skip to toolbar