Tag Archives: collaboration

Introducing Participad: Realtime collaboration for WordPress

Today I’m releasing the first public beta of a new WordPress plugin: Participad. Participad integrates an Etherpad Lite install into your WordPress installation, enabling realtime collaboration on the WordPress Dashboard or the front end of your WP site. If you’d like to download Participad, learn more about its features, or play with a demo site, check out participad.org. In the rest of this post, I’ll give some of the technical background about Participad, and some explanation of why it was built.

Participad was developed as part of some work I’m doing for thatcamp.org. If you’ve even been to a THATCamp unconference, you know that the first thing that generally happens in a session is that someone starts a Google Doc for collaborative notes, and tweets the link to the #thatcamp Twitter stream. In one sense, this is great – it’s very much in the spirit of THATCamp to have shared, crowdsourced, online notes for each session. But Google Docs, for all its coolness, is not the ideal tool for the job. For one thing, Google Docs are tied to a user’s account, making it very difficult to assemble a persistent, searchable archive of all THATCamp notes. There’s also the concern of storing user-generated THATCamp content on Google, which is alternatively benificent and malevolent, depending on the swings of the market.

Etherpad provides an ideal solution to the Google Docs conundrum. It’s a free software project that can be locally hosted, giving organizations and admins full control over the software and the data within. Etherpad has recently been rewritten as Etherpad Lite, an implementation in Node.js that is far more lightweight and easy to install than the original Etherpad, and, notably, has a rich REST API for integration with external software. This is what makes Participad possible: Participad uses iframes to display the Etherpad interface inside of WordPress, and then uses the EPL API to sync content between Etherpad Lite pads and the associated WordPress posts.

Participad is shipping today with three “modules”, each of which is a separate implementation of Etherpad Lite in your WP installation:

  • Notepads are the solution to the THATCamp/Google Docs problem described above. Notepads are a WordPress custom post type that can be created and edited from the front end of the blog by any logged-in user. Participad comes with a widget and a shortcode for displaying the Create A Notepad interface. And Participad redirects the Edit link seen on the front end of WP blog posts, so that it leads to a front-end editing interface. Content is synced back to the WP database every two minutes, or whenever a user clicks away from the Edit interface. In the spirit of THATCamp, Notepads can be “linked” to WordPress posts and pages, and a Participad widget can be placed in a sidebar that will display a list of a post’s Notepads. And because Notepads are just a species of WordPress posts, you can access lists of Notepads via an archive page.
  • Frontend is the Participad module that allows you to enable front-end, Etherpad editing for *any* WordPress content type. Turn it on, and the Edit link for any post will lead to an Etherpad interface, embedded in your theme where your static content would normally appear. Participad has a permissions schema that works with your WordPress installation, ensuring that only the users with the proper rights to edit a given piece of content through WP are able to edit that content through Participad as well.
  • Dashboard enables Etherpad editing throughout the Dashboard of your WP installation. All Edit screens – posts, pages, and other posts types – will have their WP editors (the Visual and HTML tabs) swapped out with a Participad tab. Autosave works just like it does in WP, and content is synced back to the WordPress database when you click Publish or Update.

I have a feeling that these three modules will cover most of the potential uses of Etherpad in WP, but if you have an unusual need, Participad is designed to be extensible. Build your own module by extending the Participad_Module class, in your own WordPress plugin.

Full instructions on setting up Participad can be found at http://participad.org/faqs/. Please note that Participad requires a separate Etherpad Lite installation, and for the moment, that installation must be accesible on the same domain as your WP install.

If you’d like to follow development, contribute fixes or improvements, or suggest future features, please visit Participad’s development home at github.com/boonebgorges/participad.

BuddyPress Docs


Flattr this

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

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

Download the plugin here.

BuddyPress Docs has been downloaded 26,474 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

Email Options on settings page

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

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).

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?

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?