The quality and power of Plone as a content management system is incredible. It’s got incredible usability, workflow, permissioning, document handling, search, extensibility, internationalization, accessibility — and more.  My colleagues at ONE/Northwest have launched over 40 Plone-powered sites for non-technical clients in the past year with a very small team of people.

However, for websites that revolve around “community” and “collaboration” (whatever those things mean, and believe me I’m often very cynical) I think that Plone’s community collaboration features could use some improvement.

The good news is that most of these features have pretty solid products that already get us 80% of the way there — they just need some focused and coordinated “polishing.” Here are some thoughts drawn from our experiences at ONE/Northwest, and some of my hopes for the future.

But before I dive in, I apologize in advance. These are all pretty raw thoughts, and there’s likely a lot of half-baked ideas and not-so-great conclusions in here. I thought it better to spit this out into the world to see what response it would attract than to spend too much time polishing it to a sheen.

Preface: What the hell is “community” anyway?

A fair enough question. And I’m not sure I’m really up to metaphysics as I write this on the bus ride home. In the context of Plone, I’m talking about features like:

• Blogging
• Aggregation of RSS feeds, with the aggregated items available as first-class content objects.
• Integration of “traditional” online community tools content such as mailing list archives, etc.
• Discussion Forums
• Tagging content
• Publishing content out to “social software” services such as upcoming.org, flickr.com, del.icio.us, commontimes.org, etc.
• Calendaring
  

Here’s my rundown of the tools landscape for each of these:

Blogging

Blogging is perhaps the building block of community collaboration software. Plone has a number of blogging products. Unfortunately, none of the are yet truly outstanding, and we have a bit of a problem of too many choices, all of them somewhat mediocre. Here’s my rundown, your thoughts welcome:

I consider the “essential” features for a solid blogging product as follows:

• Multi-blog, multi-author
• Rich-text entries that can include images
• Send and receive trackbacks (but resist trackback spam!)
• Allow admin to choose between registration required to comment, and reg. not required (but still not spam-magnet) — VisitorComments seems like a decent example.
• Generate standards-compliant feeds for the whole site, per topic and per author
  
• Send pings to a ping service (if any still don’t suck in six months)
• Sensible, ideally configurable archiving paths.
• Super bonus points for XML-RPC compatbility for blog desktop authoring tools.

Like many in the Plone community, I had high hopes for Quills.  This site is running it right now.  Things have picked up there lately, but it needs some more love in order to get all the way to excellent.

Knotes holds some promise, and seems very featureful, but as I tried it out in its sandbox, it still seems buggy and way too complex/quirky in its UI. Perhaps this could be cleaned up, I don’t know. Also has some pretty big dependencies, not sure how big a deal that is. One to watch, that’s for sure.

I’ve also been playing around a bit with EasyBlog, which seems to be moving rapidly right now. Has a pretty nice set of features, could still use some polishing around trackback usability, but seems promising.

RSS Content Aggregation

A key function of a “community” website is the aggregation of content that community members are creating “out there” — blogs, delicious links, photos on flickr, etc. RSS is the lingua franca that allows content from these tools to be syndicated between sites. 

The new Plone aggregator site planet.plone.org is running Planet, which is Python-based aggregation software.  That's fine, but it's lame to not do this natively in Plone.  (It's also lame that Planet expects one blog per author, and one author per blog.  But that's another story.)

There are three main Plone products that allow a Plone site to aggregate content: CMFSin, CMFContentPanels and CMFFeed. However, neither is entirely satisfactory. Here’s the scoop:

CMFSin

CMFSin is a “lightweight” RSS aggregation tool. Its core features include:

• simple feed aggregation
• the ability to aggregate mulitiple feeds into “channels”

However, its limitations are many:

• CMFSin currently configured via somewhat cryptic text files in the ZMI. This makes it tough for novice site managers, who would prefer to work through the Plone UI.

• CMFSin runs in the foreground, and can significantly slow down site performance during a refresh.

• Items CMFSin collects are not “first-class” content objects — they’re not added to the catalog, and they don’t persist in Plone after they expire from the feed.

• Users can’t “remix” CMFSin-aggregated feeds by selectively promoting or suppressing items.

• CMFSin only aggregates headlines and summaries, not full content bodies.

CMFContentPanels

CMFContentPanels is mainly designed to aggregate content from inside a Plone site, and it does a nice job of that.  It also includes some basic RSS aggregation features, that are fairly similar to CMFSin, in that aggregated RSS items are NOT transformed into first-class content objects.

In short, CMFSin and CMFContentPanels are suitable for “light duty” aggregation of ephemeral content like news headlines or delicious links, but not for sites that want to use RSS syndication as a core element of building a content library.

While not every website needs this more robust syndication, it is easy for me to imagine a generation of collaboration sites that bring together (and replicate) content from a network of partner websites via RSS.

CMFFeed

CMFFeed is a more ambitious product that picks up where CMFSin and CMFContentPanels leave off. It does good things like:

• Treating aggregated content as first-class content objects, opening the door for incoming feeds to be edited and remixed.
  
• Running in the background as a separate ZEO process, which avoids slowing page-loads to refresh feeds

While holding lots of promise as a power-aggregation tool, CMFFeed is not quite ready for prime time. It still lacks:

• A quick-and-easy install process – lots of mucking about in the ZMI still required.
• Through-the-web configuration — a must-have feature so that non-technical site admins can manage the aggregation process rather than Plone developers.
• Caching of feeds across multiple Plone instances on a single server. (A must have if you’re hosting lots of small sites on a single server which will want to draw on the same feeds — exactly that situation we face at ONE/Northwest.)

From my decidedly non-technical point of view, it seems like a relatively small bit of UI polishing plus server-wide caching could push CMFFeed over the hump to greatness.

Mailing List Archives

Email discussion lists are still amazingly powerful community collaboration tools. Even more so when they have good, searchable web archives – that can be seamlessly integrated into the community’s website. See where I’m headed?

While Plone has a few decent mailing list tool my feeling is that reimplementing email discussion list functionality in Plone is somethign of a waste of effort – there’s already lots of good discussion list software out there like Mailman, Sympa, etc. What Plone most needs, IMHO, is a relatively simple email list archiver. (Yeah, with external discussion list software, you’re giving up user integration, but I think that’s OK.)

PlonePostOffice appears to be very close to having this functionality. What it appears to be missing is:

• Through the web configuration for non-technical end-users
• Support for handling attachments (convert to File object within a folderish message object?)

The developer, Ivo, has indicated that he’s interested in doing some sponsored work on PPO. I’m hopeful that it can quickly become a great mail archiving tool for Plone. Let me know if you’re interested in talking about co-sponsoring some work on PPO.

It also appears that Mailboxer for Zope (written by Maik Jablonski) and its Plone wrapper PloneMailBoxer (kind of adopted by Robert Rottermann) can do this -- and more.  But it seems to suffer from a relatively complex install process and somewhat weak documentation.  (Thanks to Robert for the heads-up on these products.)

Discussion Forums

Plone doesn’t have a truly solid forum tool. CMFBoard appears to be dead. KNotes/KDiscussion is a promising contender, but is perhaps a bit too complex for its own good. Another promising contender is Ploneboard, which has a very strong pedigree as a project of Plone Solutions.

I’ve already been working with Marshall Mayer of LiveModern.com, who has one of the larger CMFBoard installs out there, on set of specifications for a next-generation forum product for Plone. Our current plan is to organize some community investment in Ploneboard.

To that end we did some initial brainstorming on the forum features that LiveModern (or any active forum community) would need, and after making contact with Limi and Tim Hicks at Plone Solutions, we refined and reined in our initial braindump and started fashioning PLIPs at the official Ploneboard page.

At this point, we are eager to expand the conversation to include anyone who is seeking a moderately-featureful forum product for Plone to figure how we can pool resources to bring it into existence. Take a look at the PLIPs, offer feedback, and let Marshall know if you’re interested in putting resources into the process.

Tagging

Tagging seems to be all the rage these days in the Web 2.0 crowd. While I’m often skeptical, I definitely have found the tagging system of del.icio.us to be hugely valuable. And Plone has the stub of a tagging feature in its Keywords, enhanced by PloneKeywordManager, but what it lacks is a polished user interface that scales to collections of a 30-60 tags (or more). I believe that implementing a tagging UI like that of del.icio.us would be a relatively easy “win” that would help Plone users “tag” content more effectively.

Creating a “tag cloud” as a way to visualize and browse the contents of a Plone site should also be a pretty easy win.

On a related note, it should be easy to get views and RSS feeds of tagged Pone content at the URL: http://plonesite/tags/nameoftag.

I definitely need to do more thinking about how tagging works on a collaborative website with many authors contributing content.

Update: It looks like the folks at DividedLine are perilously close to delivering exactly what I’m looking for. Yippee!  They've told me they're planning to package this up Real Soon Now.

Calendaring

Calendaring and the sharing of calendars is an important collaboration activity, and Plone has some good calendar products out there -- Calendaring and CalendarX come to mind.  It's even better news that in a couple of weeks there's gonna be a Calendaring Sprint to assess the landscape and plot a route forward.  Big props to Nate Aune for organizing.

Publishing content to community aggregation sites such as flickr, delicious, etc.

While Plone can pretty easily receive content from a community aggregation site that emits RSS — and would be even better with a power aggregator such as a turbocharged CMFFeed, it doesn’t have much support for publishing content to such services. That’s too bad. It would be really nice to be able to create content once in Plone and have it post itself to these online social spaces to reach an even broader audience.

OK, this is a less-than-half-baked idea. But I figured I’d throw it out there anyway to see if it sticks.

Update: apparently it has -- Nate Aune reports that the ATPhoto folks are working on publishing photos from Plone to Flickr, and that the upcoming Calendar Sprint may well start to address calendaring sync with Upcoming.org. 

Underlying Technologies

A shrewd reader will note that many of these functionalities share some core architectural elements: commenting & discussion, RSS syndication, importing content programmatically.

To me, this suggests that a smart approach for Plone is to factor out some of these underlying technologies into separate products (and thence into the core?) so that future collaboration & community products can use and re-use them.

Tim Hicks, who's been spending some time on Ploneboard and Quills (and more!) has made what looks like a promising start down this road with FatSyndication, which factors out a generic RSS syndication framework out from Quills. 

I can imagine a similar approach to improved discussions being factored out from Ploneboard (Tim's working on this too!).  Also for tagging.

Where do we go from here?

If you’ve made it this far, thanks for reading. You’re probably wondering what I’m planning to do about all of this. Well, that’s in part up to you. These are bigger issues that I (or ONE/Northwest) can tackle alone.

First of all, I think we need to get a good conversation going in the Plone community to refine these ideas, and more importantly to figure out who else is feeling this pain and what resources they can bring to the process of creating solutions.

So, I invite your comments — what parts of this are right, and which are wrong? What do you think are the most important community features that Plone needs to have? Are there promising products that I haven’t mentioned that need some energy? Have I unfairly judged anything? In short, I’ve taken a whack at naming the problem. Where should we go from here?