planet of the apes

Slouching Towards BuddyPress

planet of the apes

Creative Commons License photo credit: waferboard

I’m preparing to roll BuddyPress out on Blogs@Baruch later this month, and I’ve grown a little concerned about the implications of doing so. I thought I’d write up some of my concerns and see if the Internets has anything wise to say about them.

Our goal in using BuddyPress is to try to draw out and congeal an academic publishing network out of the various work that’s being done across the system. We hope to give students a platform to track their work over their careers at the College, to make connections with students with similar interests, and to cultivate a profile in a space they’re somewhat familiar with that we can support and that they can build as they desire. But I’m anxious about a few things.

First, we already have more than four thousand users on Blogs@Baruch, and the vast majority of those accounts were created for course-based blogging. I’m uneasy about turning on profile pages for users who never used the system for that purpose, without their knowledge. My current plan is to send an email out to all users when we turn on BP with instructions about granular control of profile pages. But, as far as I know, that control can only be so granular: with BuddyPress Profile Privacy you can set privacy on a field-by-field basis, but you can’t lock a whole profile page down. I’m hoping Jeff Sayre’s Privacy Component, which apparently is nearing a second beta, can help solve this problem. We’ll be registering incoming first year students for Freshman Seminar and instructing them on how to use the system beginning in August, and we’ll keep Profile pages set to “open” for new users from that point forward (we’ll be updating our woeful Terms of Service as well).  I think it might make sense though to lock-down already existing accounts and outreach to those users with details about BuddyPress’s purpose and instructions on how to manage their profile privacy. I’m uncertain about this, though, both the ethics and how I’d manage this technically.

Second, I’d like for the primary engine of Blogs@Baruch to continue to be course-based blogging. BuddyPress, however, elevates the social networking function to equivalence with the blogging functionality of a WP-MS installation. We’re not building ePortfolios like our friends at Macaulay and don’t have the resources to closely support the development of profiles on a system as big as ours. And I certainly want to avoid the creepy treehouse factor, which is an issue with incoming Freshman.  I just want students to use BuddyPress@Baruch to connect with each other around interests and academic work. So there are a few spots where I’d like to make some choices or changes that could nurture that understanding; for instance, I don’t think I’ll have a link to the members directory from the front page (but have it publicly accessible via internal links); I’ll hide the BuddyPress admin bar for logged out users; and, I’d like to hack BuddyPress so that upon log in, instead of landing at the front page of the home blog, users land at the Dashboard for their primary blog. Any other ideas?

Third, I have to revisit our registration process. In most classes, we use DDImportUsers to bulk register new users. Our most technologically capable faculty members can handle the intimidating two-step of a “self-registration” and the addition of Andre Malan’s “Add User to Blog” widget. Now, with BuddyPress functionality turned on, registration can become more complicated and require more information, which is fine for self-registering users but potentially problematic for those who are bulk-added. The bulk process also only creates new accounts, which I’ve been struggling with for some time; existing users need to be added to new sites individually, and to do so you need both a username and an email address (if I had my druthers, the DDImportUsers plugin would be able to check a list of newusernames|newemailaddress against the user_email field in the wp_users table and if a email address exists, add the user with that address to the individual site… and then to go on to register all the new users).

As the system grows, this is becoming a bigger problem since every semester a higher percentage of Baruch students have accounts on the system and find their way into new classes that use it. In an older version of WPMu you were able to add users to individual blogs simply with an email address, which was preferable because the cross-referencing is a pain. But that pain is balanced on the other side by the agita that would be caused if nervous first-time blogfessors are made to manage a multi-step registration process. In the past, I’ve taken the pain on in exchange for the benefit of drawing more users onto the system, and it’s been a good trade. I’m not sure yet how BuddyPress fits into this equation and how it will impact my overarching goal of easing the registration process, but wanted to get the issue out there. In the long term we’re looking at LDAP integration, but we’re not there yet. One solution is BP Group Blogs; but that creates additional steps in the registration process and we still want to make things as sleek and streamlined as possible.

These are my concerns for now, and I’m sure there’ll be more to come… any feedback, questions, and exchanges from out there in the wild are welcome and greatly appreciated.

5 thoughts on “Slouching Towards BuddyPress”

  1. Absolutely valid concerns! We are set up so that profiles are only viewable by logged in users, and the Member directory is also only open to logged in users. And we have ITFs talking to students about privacy/openness and what it means to control that.

    But for a BuddyPress install for newly-admitted students (hence minors–and hence folks we don’t yet have access to for discussion of privacy), I did make it so all of it is private–the whole network is closed with even the homepage blocked from anyone who is not logged in with an account. There aren’t any blogs there–it’s just a social network–and it’s been fairly heavily used and enjoyed.

    Free range/walled garden issues–you have to watch for them and talk of them!

  2. Hey Luke,

    I’m going to try and mumble through some of the things we’ve been doing at UBC:

    We are looking to roll BuddyPress out on by the end of the summer. We are looking at many of the same issues as you are and will probably be developing some plugins to help make some of the issues less difficult.

    Issue one: current members. We have over 3000 current members. The plan is to default their profiles to private and email them telling them how to change it. New users will be given the choice when signing up, with the default being private. I think this is a bit heavy handed and may kill the community, but privacy scares a lot of people these days (thanks Facebook!)

    Issue 2: We are leaving the admin bar as is. We are removing the members list from the home page as well (although have just had student feedback that they want the members page). As for after logging in, we haven’t finalized anything, but have had feedback from students that defaulting to an “activity page” (like Facebook) would be preferred.

    Issue 3: I’m not sure what our current system is for adding users. I know it works well, but we do not have the plugin listed on our WordPress page. We are also thinking of using the BP group blogs, but are still deciding how exactly we are going to handle things.

    That’s all I have for now. I’ll DM you the email of our project lead so that you can maybe get some more specific and official answers, as well as access to the custom code that we are writing (it will probably only go on in September).

  3. Thanks, Joe. How did you get set up so that profiles are only viewable by logged in users? Is that a plugin or a hack? I’m not seeing it in the basic settings. And, I’m glad I have you and the ITFs to compare notes with as this evolves…

  4. Well, this is weird. I can’t figure out how I did that! In fact, on my test server, which should be identical in every way, the member profiles ARE viewable by non-logged in users.

    I’ll keep checking. There must be some setting or some plugin that I’m not figuring. This might be a question for Boone!

  5. Ah ha! Found it.

    It’s an option in the theme I’m using, not buddypress itself. We’re using the buddypress fun theme (modified by using a child theme).

    That theme has this option in the theme options section of the dashboard
    “Do you want to enable privacy for all members profile
    * only logged in user can view members profile and members directory. ‘disable’ by default”

    If you set that to “enable” it blocks the member profiles for anyone not logged in.

    I feel pretty sure, from a quick look at the code, that you could take this option and add it to just about any buddypress compatible theme. Seems like something that will, eventually, be handled by a plugin or built into the core, too.

Comments are closed.