Choosing a platform for the telecentre.org network
Read my blog post about this project and document.
Download this document (“Choosing a platform for the telecentre.org network”) as a PDF.
Telecentre.org has outlined plans for a distributed network of telecentre network sites around the world, which will include a site for telecentre.org itself. Mark Surman engaged me to help specify the platform requirements for creating a distributed network of sites that will share and exchange content.
This document outlines the process we followed for choosing a telecentre.org web platform; the platform we ultimately selected was Drupal. For the specific requirements and overall web strategy that guided this process please see the separate telecentre.org online strategy (PDF) document. The overall vision is of a network of sites that will likely run on a variety of platforms, including a growing number of sites that run on our Drupal-based “support net in a box”.
RSS offers the obvious means of sharing and aggregating information across the sites in this network. Because telecentre end users are often accessing the Internet with low-bandwidth or intermittent connectivity, and RSS-based strategy also offers options for getting content easily and storing it locally for later reading. By tagging (assigning keywords to) as much of the sites’ content as possible, it will be easy to organize content across sites and even across multiple languages. The implementation of RSS and tagging was thus central to our review of software options.
Our search for the optimal web platform for the telecentre.org support-network-in-a-box (SNIAB) focused on options that might combine content management features (like the ability to easily create and edit web pages, register users, and automatically create navigation structures) with community and collaboration features (like RSS, blogging and wikis). We initially expected to choose a separate (though compatible) platform for the event-in-a-box (EIAB), with some overlapping functionality. As our vision for both SNIAB and EIAB grew more nuanced and concrete, we concluded that there would be significant advantages to selecting the same platform for both purposes. The primary advantage would be the ease of incorporating event-driven content into the flow of content among telecentre network sites; a secondary consideration was that it would be easier for telecentre partners to become familiar with a single tool, rather than two.
We gathered preliminary candidates by reviewing the tools used to create sites with community features, reading online discussions of CMS tools for the non-profit sector, and soliciting suggestions from colleagues. We wanted to find a tool that wasn’t just a CMS with a bunch of blog-like features attached to it; we wanted a tool that was fundamentally suited to a distributed network in which content would be continuously exchanged among sites. We also wanted to ensure that sites that were not built on the core platform would still be able to access content from the sites that were; we recognized that RSS was the only standard that could serve this purpose.
The goal of establishing a distributed network that circulated content via RSS led us to three core questions that served as a filter on our potential platform:
1. Has this platform been used to rapidly deploy a large number of interlinked sites from a basic template?
2. How widely does the platform integrate RSS into its structure – both in terms of creating outbound RSS feeds and in enabling easy, flexible aggregation of inbound RSS feeds?
3. Does this platform support blogs or wikis, which are the most common tools for online community and collaboration?
These three questions provided a litmus test for whether a platform had “community DNA”, and allowed us to quickly narrow a long list of possibilities. Some of the initial options that were set aside due to lack of community functionality included:
Ekton: no blogging
Kintera: minimal RSS orientation
MCMS: no blogging
Red Dot: blogging not core
Sharepoint: no blogging
SiteRefresh: RSS feeds are not core to software
We took a closer look at seven options:
APC ActionApps: The distributed network model is central to the design of ActionApps, which lets users share “slices” of content with other ActionApps sites. The limitation of the slice model is that it is a content distribution scheme that is specific to ActionApps, so any telecentre network sites running on other systems would not be able to participate in the content-sharing scheme. While there is some RSS support it is not the primary mechanism for content-sharing, and both blogging and wiki functionality are still under development. We were also concerned that the small developer community for ActionApps did not promise significant growth on the platform.
Mambo: The user and administrative interface for Mambo was one of the best-designed options on our shortlist. We were also interested to note the emergence of Soapbox, a Mambo toolset geared towards the nonprofit community. The Soapbox toolset is however limited (at this point) to integration with the Democracy in Action CRM, and to single sign-on among sites. The information architecture of Mambo itself proved incompatible with the telecentre.org project, since it is structured around categorization (rather than tagging), which in practice imposes such limitations as precluding multiple categorization of inbound RSS feeds. Since much of the telecentre.org network’s content will need to be distributed to multiple categories (e.g. a story on a Bolivian wifi project needs to be tagged “wifi” and “Latin America”), the categorization structure was a deal-breaker.
Plone: As a CMS based on the Zope platform, Plone offers much greater programming extensibility than other CMS options we considered. The flip side of this virtue is that Plone’s relative advantages are much less compelling for a project that (like telecentre.org) specifically wants to limit its custom programming commitments. Ultimately our biggest concern was that Plone’s RSS aggregation capacity was not part of its standard install; while adding an aggregation module is a trivial technical challenge, the lack of native aggregation support spoke to the platform’s orientation towards single-site content management rather than distributed community.
SocialText: We used SocialText as a platform for circulating our requirements, which gave us an opportunity to try out the software in action. SocialText was appealing primarily as an EIAB option, and once we decided to focus on choosing a single platform for both EIAB and SNIAB, SocialText made little sense. In particular we found that its pricing model – based on per-user or per-day pricing – made little sense for our purposes, and reflected the fact that it is really a collaboration platform rather than a content platform.
Userland Manila: As a CMS that began as a blogging platform, Manila seemed like a promising option for a community-oriented web platform. However it lacked many key features we required, including wiki support and flexible, native RSS support. While it would be possible to extend Userland with scripts that allowed (for example) aggregation of different RSS feeds to different areas of a site, the extent of custom-scripting needed to effect the kinds of RSS control we’d like indicated that Userland was oriented to single-site CSS rather than distributed network community.
TIG (Taking it Global): Taking It Global is an NGO that runs both its own TIG community on a homegrown platform, and offers that platform to other users (such as the Digital Divide Network). The platform is specifically oriented toward supporting multiple sub-sites, but its model for supporting multiple sites is based on storing all sites on a single server (and in a single database) rather than as a truly distributed network; this would make it difficult to integrate non-TIG sites into a TIG-based telecentre.org network. While we were confident in TIG’s ability to quickly and efficiently deliver additional programming as needed, the relatively long list of features that would require custom programming for our purposes (site-wide tagging support, separate aggregation pages, wikis) again suggested that the TIG platform was not fundamentally oriented towards an RSS-based distributed network.
Drupal: With a fast-growing user base in the non-profit sector, Drupal’s strong online community focus made it an appealing prospect. Nonetheless we were concerned about documentation and interface issues and its wiki support. Our wiki concerns were resolved by a demonstration of a Drupal site with installed wiki-like features that fully met our needs. Documentation remains a concern but appears to be a priority for both Bryght and CivicSpace, two major players in the Drupal community. Likewise an improved administrative interface is high on the development agenda at CivicSpace, and may be partly manageable in the shorter run by implementing a custom theme for administrators.
Most importantly, Drupal was alone among all CMS options in its compatibility with a distributed network approach. The platform is essentially built for exactly this kind of approach: it supports ubiquitous outbound RSS feeds, complex aggregation of inbound feeds, per-feed or per-item non-exclusive tagging, and native support for blogging. Compared to the other options, which are virtually all CMS platforms that have developed distributed community features, Drupal is innately oriented towards community networking and distributed content creation. The following outlines how we anticipate using particular features of the Drupal platform to support core elements of the telecentre.org web strategy.
Questions? Please contact:
Alexandra Samuel
alex (at) alexandrasamuel (dot) com
August 2, 2005
{ 3 trackbacks }
{ 12 comments… read them below or add one }
Yes, Drupal’s community orientation is definitely fantastic. It was the natural choice when GhanaThink.org wanted to deploy a more community-oriented website. In our implementation for them, we deployed 5 Drupal sites for each of their administrative divisions. All 5 sites share some information (like user login/profile) but are also independently managed. Telecentre.org has definitely made a great choice!
Nice writeup.
Our team has been working on Civicspace since February. It has come a LONG way and has some really exciting stuff coming up “very soon” such as the CivicCRM integration (contact management).
A caveat, tho: this is definitely bleeding edge stuff, and I would suggest that if you’re not ready to roll up your sleeves (codewise) you’ll have a rough time.
The communities (DRUPAL and Civicspace) are very supportive and informative; and, as mentioned above, the rate of progress in many directions (including, thankfully, documentation) is very rapid.
My $.02. Keep up the good work on the comparisons and keep checking on CS/Drupal in the next month in particular.
Charlie in TX
Ms. Samuel has elegantly stated many positive aspects of Drupal.Org that I would never have imagined. She could add to the list that Drupal writes its code compliant to Cascading Style Sheets (CSS) instead of using HTML Tables to format the text like many other Content Management Systems.
It is really sad that people think that Plone is lack of RSS support. Plone has RSS support by default! It is not enabled by default.
Login to ZMI. Enable syndication on your Plone site. Select portal_syndication -> Properties tab -> Enable syndication
Login to Plone. Go to the folder which contains documents you want to syndicate. Select Syndication tab -> Enable Syndication
You can also create RSS feed by any search result.
Question. Where is TrackBack Ping URL here?
ZOPLONE vs DRUPAL summary (first approach)
ZOPE+PLONE
· 2 PRODUCTS: web-application ZOPE and the CMF Plone
Plone is based in the Content Management Framework (CMF) which in turn is based on the Zope Web Application Server (WAS).
The CMF on top of this defines object types and processes for content management.
Plone builds on this to deliver a complete Content Management System.
· Python is the more appropriate choice of programming language to meet these goals in a Zope and Plone combination providing an almost unparalleled development platform.
Python is fast enough on the execution side and blisteringly fast on the development side.
It is object oriented from the ground up instead of having had objects tacked on late in the game and remarkably intuitive.
You’ll find the percentage of correct first guesses is higher in Python than anything else you try.
·Zope stands for “Z Object Publishing Environment” and that sounds like a lot of buzzwords like many acronyms, but it turns out that’s exactly what it does. You write Python objects.
Then, Zope makes them available on the web. Available to humans. Or software. Or whatever. Zope itself is a web server (though it is frequently run behind Apache), an object database (which holds most everything in a Zope installation and is something I miss about every non-Zope system), and an application server that executes the objects you’ve written.
· Plone is more oriented toward sites with lots of static content. with fewer releases and the releases more polished. The templates which exist for Plone are more attractive than the themes that currently exist for Drupal.
· Plone already does blogs, forums, stories, images, wiki, and more.
· Plone/CMF is built around multi-users with roles-based permissions (which can apply at several levels of granularity, from cross-site server level down to individual object level) and workflows. ppropriate model for all community sites – particularly where you NOT want a model of all content is available as soon as it’s written – IF NOT for many communities. The endusers are restricted by default because they can’t figure out how to get into the CMF, and because you have this object oriented inheritance based scheme for giving people access to editing various objects.
OKOK
· There are a lot of products on top of Zope, not only CMS/CMF, but for example ERP systems, that offers an incredible amount of functionality out-of-the-box that you just won’t find anywhere else. Features like: end-to-end i18n; localisation; placeless content; pluggable, configurable workflow; messaging; granular security (in way more depth than Drupal);
· Plone would be a strategic core system for complex requirements like an intranet for insurance companies or financial institutions.
· Zope/Plone is fantastic for large-scale projects, as you can do amazing things with it in a very short period of time.
MODULARITY
I’d like to bring some of the power and flexibility of Plone’s content management functions to Drupal,
Plone’s modularity strikes me as more powerful and flexible than Drupal’s.
· Zope is quite a mature company with quite a few proprietary ‘industrial strength’ products.
OKKO
· PERMISSIONS
Available but complex inheritance based permission schemes
KO
· Plone can similarly be stripped-down considerably, however, due to the approach of presenting everything by default, there’s actually more work involved in making a simple site.
· Plone does have “customisation policies” that allow you to choose from a number of default setups for a site, however, this extraordinarily powerful feature has never been properly utilised.
· Finding cheap and reliable Zope hosting is very difficult
· Zope can easily be configured to talk through Apache and the permissions logic is extremely granular but
· The core problem I have with the zope/plone/cmf pile is its open source-ness.
· The Zope framework is still free, but I wonder ‘how long’ and ‘will there be a development fork?’.
· Plone’s exterior seems usable, but to do very basic things you have to get into the Zope CMF which is not intuitive at all.
Plone CMF is quite confusing.
· Very difficult to enter in the code, If you don’t know about Python and the massive number of files just scare. Also having troubles in common setting tasks designing the rights permissions with plone.
· Plone is very RAM-hungry, a common gripe about Java appservers.
– DRUPAL –
· ONE PRODUCT the CMS Content Mangement System or Knowledge Management System (KMS),
· PHP
I think Drupal could be improved by taking choice pieces of Zope/Plone to heart.
replyDrupal attract by his simple and clear internal structure, which requre minimum time for learning to use and administer it. Drupal and more attractive for realization of complex workflowDrupal – mostly supports communities and hobbyst projects. While I don’t think I’m fully qualified to answer your question I can explain why I chose Drupal over the others.
* PHP/MySQL/{Apache,IIS} LAMP STANDARD
* Installation — Installation is fairly simple and a very small learning curve to get going.
* Interpreted, not compiled — meaning the module I write here will work on (virtually) any other machine that can run the other modules.
· Drupal is not by any stretch of the imagination an application
server. It’s a collection of PHP scripts connected to a database.
· The main requirement of Drupal is to provide an easy and intuitive way to allow some users to update web pages. ‘Here’s your login bob, please add a document here, I’ll review it, then publish it.’
OKOK
· Drupal has a very small learning curve relative to Zope and Plone,
Youth & Fresh adaptable to the new situation as the broadband communications conditions.
· Drupal is still in the early stages, ‘cleaner’ and quicker.
· Drupal has a more modern system for organizing the site. While Plone basically is built around the old catalog/document metaphor.
· Drupal offers the possibility to use categories to structure the site and its navigation.
· the functionality of the submission queue.
· Using MySQL also allows you to nicely hand-hack tables ‘n stuff incase things break.
- Small by comparision.
What it does (community plumbing) it does very well and important when you want to adapt it to other systems, it has clean code and well-documented programming interfaces – something I rarely see in the PHP world.
· Add its flexible templating and caching and it is very well capable of driving even large community sites or just the interactive parts of more traditional websites.
· Drupal is the best foundation for even large public community websites.
· Drupal works pretty well for smallish community sites that require minimal expenditure of effort in setup, and a defined set of core features.
· Permissions schemes with multiples roles for user
· Drupal’s configuration, layout, content editing, and style to be far more comfortable than Plone’s.
· Reworking and building a website time
· Drupal tends to move quickly and the development is less centralized.
· Drupal is easier once you understand it
· Drupal is more oriented toward community sites and blogs, where Plone is more oriented toward sites with lots of static content.
· Drupal is much more geared toward the same kind of audience that drove Movable Type to popularity; individuals and small groups of people who are more interested in communicating with the outside world quickly and easily. That’s one of the things I like about Drupal: users can do a great deal with minimal training.
Drupal’s modularity as one of its big strengths.
It intially comes configured as a small, easily manageable package. If all you want to do is maintain one blog, Drupal can do that without blinking. But as your needs grow and you require more functionality,
Drupal can easily grow with you.
· Drupal’s modules get more refined and polished, if it’s conceivable that Drupal eventually might compete on even footing with Plone
Drupal is a bit easier for the initial setup of the site.
Drupal is more permissive, a bit harder to lock down.
Drupal permissions are not inherited.
Drupal can assign more than one role per user by selecting a simple checkbox, ideal for many sites. The reason this works so well, is that sites implemented with several admins, each performing a different task, and not allowed to directly work on another department’s tasks.
Ideal DRUPAL site is for a fairly large media company, with branches country-wide.
· Drupal is confortable with the very little code threre is to drive this CMS.
· The real issue is the size of the developer community. Drupal has functionality I need, and it has it now.
· Drupal offers incredible functionality that I can access on very low cost hosts, and that’s what won this time for me.
· Drupal’s approach to a lot of the process of adding content is more streamlined, and that works well for users.
· Drupal’s is simpler and quicker to use.
· Drupal is extremely well suited to smaller, personal sites, whilst Plone is designed ground-up for enterprise applications.
· Drupal could conceivably work its way into this space with official support for Postgres, Ingres, DB2, MSSql, and Oracle.
· Drupal offers genuine simplicity out of the box.
· Lots of companies out there just want a CMS that will allow them to negate the need to pay a design company bucks to update static pages.
· Drupal can be just as ‘enterprise’ as the competition.
KO
· Drupal is not as easily able to handle the big stuff.
· Drupal still has some core things to fix (such as taxonomy_access and getting it working with some better features) that could make it very painful for a medium or large scale company to deal with.
· DRUPAL documentation is of a lower quality than Plone
· DRUPAL needs a template, making Drupal look like Plone
en Ferran
Very insightful. Thanks Alexandra for a matured article.
I do agree on the template part, of someone has a plone-like template for Drupal to share, please drop me a line.
Plone-template for Drupal.
http://www.zanattadesign.com/try/drupal/
Thanks to alexandra and ferran for giving me so much vital info! I still have so much to learn .. CAN’T WAIT!
Nice article.
IMHO, Drupal has best balansed feature and time required to learn.
Thanks for the detailed reviews. Any chance of an update as to whether Drupal was implemented?