Teleogistic » collaboration

BuddyPress Docs

Boone Gorges — Wed, 02 Mar 2011 02:27:47 +0000

BuddyPress Docs is a powerful and flexible tool for collaborative editing in BuddyPress.

BuddyPress Docs features:

Full integration with BuddyPress Groups Docs can be activated on a per-group basis, creating a Docs tab. Doc access, by default, is inherited from group privacy settings. Doc authors, as well as group admins and mods, can override these default settings so that visibility, editing, and commenting of a given doc can be more restrictive.

Full integration with activity streams Whenever you create, edit, or comment on a Doc, an activity item will appear in all relevant activity streams. These activity items obey group privacy settings, so that edits in private groups are private, etc. New dropdows in sitewide activity filters allow you to view Docs activity selectively. Full activity integration means that the plugin can be coupled with a plugin like BuddyPress Group Activity Subscription for fine-grained activity notification.

Front-end, rich editing BuddyPress Docs has full rich-text editing, powered by WordPress’s own TinyMCE editor. Because it’s the WordPress editor, users will experience the power and ease of use they’ve come to know from the Dashboard. Because it’s on the front end, users don’t ever need to leave your BuddyPress environment to edit Docs.

Doc tags With full taxonomy support, BuddyPress Docs lets your users tag and organize their content however they’d like. Doc lists can be filtered by tag for easy navigation. You can see at a glance how many times a tag has been used in a given group (and, in an upcoming release, sitewide).

Easy sorting and search When viewing Doc lists, you can sort by a number of criteria, making it easy to find what you’re looking for. There’s also a search box, which is smart enough to limit searches to specific group contexts dynamically.

Comments Leave comments on docs just like you would on blog posts.

Protections against overwrites To make sure that users don’t overwrite each other’s work, BuddyPress Docs only allows a single user to edit a Doc at a given time. To make sure that others aren’t blocked from editing by those who leave leave Docs open and then forget about them (ahem), there is a timeout and autosave after 30 minutes of idle time.

Developer goodies Built by the person who has (probably!) built more BuddyPress plugins than anyone else in the world, BuddyPress Docs is designed with extensibility in mind. do_action() and apply_filters() is everywhere. Add-ons like taxonomy and hierarchy, and integration pieces like groups (and the upcoming profile integration), are totally modular. BuddyPress Docs uses WP’s internal APIs wherever possible: custom post types, custom taxonomies, and more. Templates have been abstracted out to make theme overrides easy. And – inline documentation EVERYWHERE! Feedback from developers is welcome: ongoing development lives at http://github.com/boonebgorges/buddypress-docs.

Lots more development is coming! User profile integration, BuddyPress Documents upload integration, and more!

NOTE The plugin is listed as requiring WordPress 3.1 and BuddyPress 1.3. While I have been developing against the BP 1.3 trunk, it should work fine with BP 1.2.8 as well. However, do NOT use the plugin with WP 3.0.x, as it will expose private group Docs.

Instructions

Upload the bp-group-reviews directory to your WP plugins folder and activate
Activate Docs on a per-group basis in the group admin section

Download the plugin here.

BuddyPress Docs has been downloaded 19,666 times. Are you using this plugin? Consider a donation.

Version history

1.0-beta – March 1, 2011: Initial release

New BuddyPress plugin: BuddyPress Group Email Subscription

Boone Gorges — Thu, 13 May 2010 03:37:19 +0000

Email Options on settings page

I’m quite happy to announce the release of a more-or-less stable (we hope!) version of BuddyPress Group Email Subscription, a BuddyPress plugin that allows for fine-grained, user-controllable email subscription to group content in BuddyPress.

This plugin is different from some of my others in that it was truly a group endeavor. The base of the plugin was written by David Cartwright, with a little bit of code from me. A nearly complete rewrite of the front-end and most of the guts of the plugin was undertaken by Deryk Wenaus. I wrote the daily and weekly digest functionality, along with some of the settings pages and various bugfixes throughout. The current codebase of the plugin is probably 60% Deryk, 30% me, and 10% David.

It was my first time working on a truly collaborative software development project like this, and it was a real pleasure working with both of these gentlemen. Thanks, guys.

Get BuddyPress Group Email Subscription here.

On the communal v. the individual student voice

Boone Gorges — Sun, 23 Aug 2009 17:35:42 +0000

On Thursday afternoon of this year’s Open Ed conference, a challenging contrast began to emerge between the approaches to student writing being espoused by the various speakers. First was Gardner Campbell and Jim Groom, who delivered a talk titled No Digital Facelifts: Thinking the Unthinkable About Open Educational Experiences. (This and other links go to Ustream recordings of the talks – they’re well worth your time, if you weren’t able to attend in person.) Gardner’s message echoed some of the familiar strains in Jim’s talk from the previous day, putting forth the idea that instead of herding students together into a single platform of our choosing, we should be giving them the tools and knowledge to be creators and curators of their own digital identity. (See this post at bavatuesdays for some of Jim’s thoughts on “a domain of one’s own”.) Gardner pushed this line of thinking a step further, suggesting that students literally become the sys admins of their own web space. Not only should students be able to move outside of the institutional platforms to develop their digital selves, the argument goes, but they should be free to choose and maintain whatever platform they’d like, without the different but perhaps equally cumbersome constraints of free/commercial platforms (like wordpress.com and others).

Gardner and Jim | cc licensed flickr photo shared by colecamp

Now, before I start talking about where the tension arose, I should point out that while there’s something very right about this idea of Gardner’s, there’s something arbitrary about it as well. He suggests that we conceptualize something like cPanel as a meta-framework for the construction of identity. But why stop there? If cPanel > wordpress.com because of cPanel’s additional freedom to maneuver, doesn’t it follow that it’d be better to give each student a virtual machine with a bare OS on it? Or maybe for them to build their own kernel from assembly code, which would truly provide the most software freedom? The obvious reason is that at some point the tradeoff is no longer worth it: what you gain in freedom by dropping down a level of abstraction is not worth the extra effort you’d need to master the medium. And I’d argue that as time goes by, and software both advances to higher levels of abstraction from the raw code and at the same time becomes more useful, the calculus of determining the ideal level of abstraction is constantly in flux. To echo a discussion from this year’s THATCamp: while it might be the case that most students would benefit from learning some HTML and some basic programming today, it’s likely that there will come a point at which it’ll no longer worth the trouble; this, in much the same way that you don’t need to know assembly code to qualify as a computer geek (in most circles?!). A GUI like cPanel might be the right meta-framework for most students today, but we should constantly be reassessing this conclusion.

OK, so back to Thursday afternoon’s tension. The session following Gardner and Jim’s was led by John Maxwell and was titled Thinkubator: Wiki as CMS/LMS. (Actually, sandwiched between the two was a fricking awesome demo by Grant Potter of some work he’s doing with virtual worlds – but I’ll gloss over it for the purposes of this post.) John has been doing amazing things with the wiki, related to his research, to organizations he’s been involved with, and – most germane here – to his courses. He conceptualizes the wiki as a place where students – especially graduate students – learn to work in the way that scholars work. (John, I’m going to fill in some points you left unsaid here, so please tell me if I’m borking.) While it’s of course true that individual scholars maintain their own voices and perspectives, there is also a voice that emerges from a community of scholars who are writing about the same things, publishing in the same journals, editing and reviewing each other’s work, teaching in the same departments, etc. In one of the best one-liners of the conference, John pointed out that students get practice in developing this kind of communal space in kindergarten and in graduate seminars – but not in between. Multi-authored wikis are, by their very nature, communal spaces. Thus, when students do their work on a wiki, they are learning the sociology of group work and of their discipline at the same time that they’re learning the subject matter of the course.

So here’s the tension (which John himself articulates very clearly in his own reflection on the talk). The Campbell/Groom angle is that students are better served by stewarding their own spaces: emphasis on the individual voice. The Maxwell angle is that students learn about how scholarship functions by authoring together in a space like a wiki: emphasis on the communal voice.

There is a sense in which the tension might be fundamental, going to the heart of what we want our students gain from our classes. If the point of education is to shape students’ individual agency – to make them sys admins of their own souls (?) – then it makes perfect sense to make them sys admins of their online selves. If the point of education is to develop the next generation of scholars (or, if we want to take the point further, the next generation of society members), then the wiki approach might be more sensible. Insofar as there is a real conflict here, it might run even deeper than the purpose of education, but to the purpose of knowledge production itself: is it more important to foster and encourage each individual’s idiosyncratic “truth” scheme or our collective movement toward Truth?

Distributed groups | cc licensed flickr photo shared by fdecomite

From a practical point of view, the tension is probably not so stark. A student with a developed voice and identity is more likely to be able to step back and envision his or her place in communal spaces; and someone who is comfortable participating in shared knowledge development will be better equipped to develop his or her own particular point of view. But the contrast with respect to educational technology policy remains. A wiki setup like Maxwell’s is homogeneous and centralized, while the Campbell/Groom arrangement is various and distributed. I wonder how much of this is a technological accident, though, and to what extent the phenomenal qualities of Maxwell’s method can be superimposed on the Campbell/Groom architecture. What I mean, very roughly, is that we might envision a new generation of software whose underlying infrastructure is essentially distributed and customizable – respecting the agency of individual student-sysadmins – while communal spaces, rich with the versioning and community feature of wikis, can emerge at the higher levels of abstraction. I’m not smart enough to envision what this might look like in detail, but in theory it might preserve some of the educational advantages of each approach.

What do you think? Is there really a tension between the two approaches? Does the underlying technological model you choose for classroom work rule out certain rhetorical models, or does it just make some a little harder to attain?

Hub-and-spoke blogging with lots of students