Plone and its competition: choosing a CMS
Finding out about Plone's competition
Recently, I've had a chance to evaluate a whole slew of web content management systems. This has been quite eye-opening. I'll try to recount a few of the themes and experiences here, and draw some conclusions about how Plone stacks up. This is by no means intended to be a full-blown product evaluation, and is quite Plone-oriented given the usual readership of this blog.
In this post, I'll talk about:
- The CMS market
- Different types of content management needs
- The difference between a CMS and a portal
- The importance (or not) of system architecture
- The two most common models of content delivery
- In-place editing vs. back end administration
- Assets and images
- Folders and taxonomy
- Managing pages vs. managing content fragments
- Managing code and content
- Some of the important contenders
- What Plone can learn from them
The content management market is huge. The list of vendors and products is quite frighteningly long, even if you decide to stick with the tried and tested options, and getting a good enough understanding of each system to make an informed decision can be daunting.
Google helps, but the signal-to-noise ratio is pretty poor. The vendors' marketing materials decidedly do not help. Even figuring out which is the latest version can be a struggle, let alone what the licensing costs or hardware requirements are. The "call me back" button is normally quite prominent, but don't expect a call back as soon as they promise, and be prepared to speak to salespeople.
You can also buy reports from analysts like Forrester and Gartner. Personally, I find those two a bit superficial at times, but there are more specialist report writers, notably CMSWatch, that do a pretty good job of dissecting the market. I'm also a big fan of Seth Gottlieb's Content Here, although there haven't been too many reports lately. I know when he evaluated Plone for his previous employer, he did a good job. So do CMSWatch (and we do have a chance to review and correct mistakes, which is good), on balance. As always, you do need to take these types of reports with a grain of salt, though, and look for the broad themes, rather than take every word as gospel.
These reports all cost money - sometimes quite a lot of money - but they should save you enough time to make that worth your while, especially if you're paying someone by the day to come up with a recommendation.
CMSWatch do have one "freebie" that I rather like: the Vendor Subway Map. This shows the various vendors (as opposed to products!) on a map that illustrates the types of features they have in their product arsenal. For example, Plone sits on the intersection of the "Web content management", "Social software & collaboration" and "Enterprise portal" lines, which is probably about right. This type of key can help you get a good feel for what vendors to look into, although it is of course a bit gimmicky.
Beyond that, it's important to realise that most products these day support the basic features. Thus, non-functionals such as cost (both licensing and likely implementation costs), fit with your existing IT architecture, and usability/end-user experience become a lot more important. I'll touch on some of those later.
My advice would be to focus on getting a list of requirements for your end solution, prioritise those, and only then start to extract actual system features that you need. Sometimes, that means getting a vendor in to run a demo, although these days it's easier to do that kind of thing over the internet. I'm a hands-on kind of person, though, so getting a demo version to play with makes me a lot more comfortable. Vendor demos have a tendency to gloss over the warts and steer the conversation towards a product's strengths.
The word "CMS" - Content Management System - is quite overloaded. Plone is really a Web CMS, which is often what people are referring to when they use "CMS" unqualified. Even here, the boundaries are quite blurred. Is Wordpress a CMS? Is PHPNuke?
And then there are are all the other types of content. The word Enterprise Content Management often refers to all-in-one type solutions that focus mainly on managing documents, records, archiving, and so on. Sometimes, "content" is taken to include XML resources that are consumed by systems. And many systems emphasise wiki-like editing and social collaboration, sometimes at the expense of the rigour you'll find in more traditional content management solutions.
Within web content management, vendors sometimes focus mainly on content production, giving you an application to let authors contribute content, manage templates, and participate in workflow. Sometimes, this means you are left to build the content presentation layer yourself, either through a portal server, or with a custom application. Other vendors include a dedicated presentation server. Some systems, like Plone, accommodate both in a single server (although you will often want a caching proxy to offload some of the presentation work). See also the differences between the "bake" and "fry" approaches, below.
Thus, it's important to decide what kind of content management you're talking about before you begin any kind of evaluation. It's also important to decide whether you're looking for a single vendor to provide all your content management needs, or if you're after "best of breed" systems. It sometimes seems like the vendors that are particularly strong in document and records management, are less strong in web content management, and vice-a-versa.
We also seem to be seeing a shift away from tight integration towards federation of services on heterogeneous platforms. On paper, it may look attractive to get all your systems form one vendor (and companies like EMC|Documentum, IBM and Open Text have a dizzying number of products under their large product umbrellas), in the hope that they will integrate well. In practice, they frequently don't (especially if that product portfolio was built by acquisition, as is often the case), and some of the solutions are downright poor, tacked on to fill a gap rather than built with the same dedication as the "core" product. I shan't mention names.
The "federated" view of IT is more realistic as an option these days, due to improved portal technologies, better support for standards, and more use of higher level "glue" languages (like Python or Ruby or PHP) that allow for integration projects that are measured in months rather than years.
In the Python/Zope/Plone world, we also have a very exciting technology: Deliverance. This is a transforms-based solution to theming arbitrary web sites, with support for weaving together multiple back ends into a cohesive application. plone.org, for example, "deliverates" Plone and Trac, the popular issue tracker and wiki. Coupled with single sign on (perhaps via a simple cookie-and-HTTP-BASIC based approach like mod_auth_tkt), LDAP or ActiveDirectory backed authentication, and shared access to document repositories and databases, it is possible to evolve a federated architecture that presents a unified user experience without having to jump into bed with a single vendor or try to build everything all at once.
This approach to integration is also quite interesting because it side-steps the need for a traditional "portal" server. Plone is sometimes used as a portal, with "micro applications" like issue trackers, wikis, blogs and so on exposed in Plone via special content objects, custom portlets or forms. In the Java world, there are more formal standards (notably JSR168 and it's successor JSR186) that in theory allows a "portlet" to be built once and deployed onto different portal containers. Here, a portlet is just an application that makes use of certain services (like page rendering and authentication) provided by the portal container. The portal container may have some UI for deploying applications, logging users in and out, and managing the "window state" of portlets, e.g. whether they are "maximised" or if you are viewing multiple portlets side-by-side. It is otherwise fairly passive.
Some content management systems use portal servers for the delivery of content, and some allow the editing environment to be accessed via a portlet if you already have one.
That said, it's probably best to think of a corporate portal (as opposed to a portal server, which can sometimes just be an implementation detail in a bespoke content delivery solution) as business process oriented: it allows you to deploy important applications through a single interface. Conversely, a content-managed website or intranet is information oriented: it allows you to present information resources in a way that makes them easy to find and ingest.
The implication is that these two types of systems require different user interfaces. A portal is often personalised by or for an individual user. An intranet or public website should largely present a stable, well-thought-out information architecture, and will almost certainly have a richer, more bespoke, less application-like user experience. This in turn has implications for how you evaluate systems on their "integration" ability, and whether you look for solutions from vendors with rich portal offerings or not.
Many companies have policies about what kind of software they will support. This is especially true if they have in-house developers who intend to customise and integrate their products. The typical choices are Java (J2EE) and Microsoft .NET, although in some cases it also includes vendor preferences (e.g. IBM, Oracle, Microsoft).
In recent years, we've seen a shift away from this one-platform-to-rule-them-all mentality. There is often better value for money to be had by shopping around, support and development is often outsourced to specialist vendors, and systems are more standards compliant and integration-friendly than they once were.
Furthermore, some of the "platform" arguments are red herrings. If you hire a Java developer that's spent his life learning the ins and outs of WebSphere, he is not necessarily going to be able to run with an Oracle product any more quickly than he'd be able to pick up, say, Plone, even if he didn't know Python. Some of the Java frameworks, in particular, are very deep and have steep learning curves (the problem is somewhat less acute on .NET). Web programming skills are fairly transferrable, and a good developer should be able to pick up new languages and frameworks relatively easily. Of course, this is very much an "it depends" kind of argument, but it's probably not a good idea to shut the doors to a particular platform just because it's not "Java" or ".NET".
The same is true for support. Your IT support staff need to be able to feed and water the servers your CMS runs on, but they're hardly going to dig into the content database or recompile the CMS code. It's important that you pick a solution that is supportable, but this normally involves either training your in-house staff or (more commonly) having a separate agreement with a specialist vendor. Most modern systems are so complex that you can't just expect your IT staff to be able to support them without at last some investment in training.
It's also important to realise that many of the more established commercial offerings have a lot of legacy code. Open Text/RedDot, for example, is a mix of Microsoft COM (which they're hoping to migrate away from) and .NET on the back end, with a Java based delivery front end. Intervowen TeamSite is based in part on Perl, with a good mix of other technologies used in various parts. Of course, this has everything to do with the age of these systems and what was available at the time. But just because a system is "Microsoft" or "Java" (or both!), that doesn't mean it's going to be architecturally clean and tidily fit into your enterprise architecture.
Beyond the system platform, it's important to understand the fundamental architecture principles behind a given CMS and how it eventually makes content available to end consumers. In web content management, there are two prevalent approaches. CMSWatch calls them "bake" and "fry".
A "bake" system is predicated on a standalone "management" application wherein content authors collaborate on and edit content, before it is pushed out to a "delivery" server. The management application is typically web based, but it doesn't have to be. The simplest "bake" system is a shared drive, Dreamweaver, and FTP to a static web server.
Many of the older CMS systems have a "bake" mentality. They normally include some kind of "preview" functionality in the management interface, but they also have things that are "delivery-side" only. This model is good in the sense that the performance characteristics for a public website is probably quite different to that of a content management application. You can get much better performance out of a bunch of static files and lightweight scripts than you can out of an application with a rich editing GUI, workflow, security and so on.
However, the "bake" approach adds complexity in that you need multiple servers, sometimes with different licencing. Managing the staging and publication process can be cumbersome, and sometimes the preview in the CMS is not a completely true representation of the content on the front end. Furthermore, modern websites often allow end users to create content, e.g. through forums, blogs and so on. These types of "micro applications" need to be built into the front end, usually without access to the services provided by the CMS. In other words, the content created through the front end cannot be "content managed" in the same way as the web content can.
The alternative, then - the "fry" approach - is to serve content from the same application that is used to edit the content. This means there is only one application to worry about and all content is created equal. However, this approach may require more careful performance optimisation (for example via a caching proxy), and you sometimes you end up having to customise the management application in order to change your end users' experience, for better or for worse.
There are obvious parallels between the "bake" vs. "fry" approaches and the "production" vs. "delivery" approaches. For example, "bake-only" system is by definition also "production-only", but it is possible to have "production-only" systems that allow you to build "fry"-type front ends that access the underlying content repository.
Plone, Ektron CMS400.NET and Sharepoint are "fry" systems. Intervowen, Open Text Web Solutions (RedDot) and Alfresco WCM (largely) are examples of "bake" systems.
Another important distinction is whether the system primarily allows in-place editing, where content is modified in-situ on the styled web pages, or uses a dedicated "back-end" editing GUI based on forms filling and/or a rich text editor, usually with some form of preview.
The in-place approach is probably more user friendly (and was once revolutionary), but it does mean that you need to accommodate the editing UI in the "designed" pages. Sometimes, this can constrain the design and make templating more complex. This in turn can thwart the usability advantage of in-place editing. Many systems (like Open Text/RedDot or Ektron CMS400.NET) make liberal use of somewhat cryptic (but unobtrusive) symbols and right-click menus. Plone is probably harder to skin than it would otherwise be, because of the need to accommodate a fair amount of in-place editing widgetry.
Plone takes an almost completely in-place approach to editing. The closest thing to a "back end" is the ZMI, but this is really just an integrator/administrator console that is not meant to be used in day-to-day operations.
Almost all systems on the market today feature some degree of in-place editing, but often defer to a dedicated back end for "power users" who need access to additional metadata or features. This can lead to some confusion, as users may need to learn two different UIs.
The front-end/back-end approach has a more general problem: The content structure is represented in two places, and users will need to adjust their mental models of the site's content to accommodate both.
For example, in Open Text/RedDot and Ektron, you may see a list of blog posts on a page, with a pop-up menu available giving the option to (among other things) add a new post. That post may not appear in the list until it is approved. So once you've added the blog post, you need to look for it in a workflow queue (typically a separate view in the back end, via some sort of dashboard). If it's not there, you need to find out where in the content database it was added, perhaps via a search or a browse of a content tree that represents the site's taxonomy. Understanding what actually happened to your content requires either a fair amount of functional training, or a pretty good understanding of how web publishing works.
In Plone, there is a structured hierarchy of content. We talk of web pages, files, images - even micro application containers like blogs or issue trackers - as content items that live side-by-side in the content tree. This "mixed" mode of content mirrors how files are managed on the desktop, and allows a great deal of freedom in terms of how information is organised. It does, however, require more discipline to set up a system where there is a centralised asset repository of controlled resources, which is an important use case in some organisations.
Many of the higher end systems store all files and images in a separate "asset library". Some vendors sell this as a separate, stand-alone application that integrates with the CMS. The asset library often includes features such as version control, image manipulation, detailed search, and so on. If it is a standalone product, it can often be used by other systems as well, for example to manage versioned documents.
When using a CMS that puts all non-HTML content in a separate repository, the metaphor changes slightly. Anything that shows up on the website is a "web page" (which is of course true, in the strict HTML sense). It may use a template that allows download or preview of some asset. Other content, like a dedicated blog or a forum or a web form, is inserted either with special templates or macros with placeholders, or just linked into the navigation structure using a separate "navigation manager" and served using a separate script.
In Plone, each of these things is either a container or standalone content item, with a particular template that renders it however it should be rendered, and may include forms and other interactive features.
In my experience, it's easier to build up site structure and navigation using Plone's approach of an integrated content hierarchy. However, it is sometimes too easy to put content in the wrong place, unless the system has been configured carefully.
Related to this is the issue of taxonomy. This is an area where Plone is comparatively weak. The site structure of a Plone is the content hierarchy. Some solutions exist to put one piece of content in multiple places, but none are particularly elegant (unless you count simple redirects).
Of course, this is not an easy problem to solve. How do you deal with differences in access rights when access rights can be granted right down to the content item? How can you have separate approvals for an item's appearance in one area from its appearance in another?
In some other systems, such as Ektron CMS400.NET, pages are created "in the database" and then linked to site sections using a "taxonomy editor" - really, just a tree control where you tick the boxes of the sections where you want the content to appear. Sometimes, content can have a natural home, but be additionally published to other sections. In more advanced systems, such as Open Text/RedDot, it is possible to let different templates apply in different sections (usually automatically), so that the item looks quite different in different areas of the site.
Whether this is an important requirement or not depends largely on your use cases. It is often more user friendly to use search-based listings (what we call Collections in Plone) and redirects (the Link type) to steer people towards a content item's canonical location, not at least because this means it will have the intended context around it. On the other hand, if you are rapidly launching "micro-sites" for new initiatives and want to multi-publish content to multiple sites with radically different look-and-feel, then a more taxonomy-based approach is likely to suit you better.
Related to this is the question of whether the CMS is primarily dealing in pages or page-like objects (as is Plone), or whether the content is more granular than that. Some systems, like FatWire, excel at managing smaller content items that are re-purposed in multiple places, with pages being composed of multiple fragments. I suspect such systems are more work to set up and possibly require more training, but will be very powerful in certain use cases.
Zope was originally an application server wherein power users could build their own applications by editing templates and scripts through the web. Over the past several years, the Zope and Plone communities have done a lot of work to move development out onto the filesystem. It is quite interesting that many high end content management systems still want to manage all templates in the CMS itself. Examples include Open Text/RedDot and Umbraco. Code is either inline in these templates, or deployed onto the underlying application server separately.
There are some advantages to this approach. For example, Open Text/RedDot has a custom in-browser editor for its template language (it is normally also possible to launch a separate editor form within the CMS, much like Zope's ExternalEditor does), and can deploy templates in the same way as content when pushing a new update to the delivery server. This alleviates the integrator from having to understand how to manage the "software" part of the web site.
On the other hand, it's sometimes difficult to apply good software development principles, like version control and automated testing, to an opaque data store.
The underlying assumption with this type of model that templates are created by designers or developers (often the latter), but that the system is an application to be configured rather than a platform to build upon. New content types and forms are built through a web GUI or via XML files. New functionality can be deployed as add-in modules, although the gap between the skills required to create new content types (which is relatively easy) and those required to perform this type of programming (which requires relatively more knowledge and understanding of the platform) is probably wider than it is for Plone.
Below is a list of systems I think are worth looking at and learning from. I won't claim to be an expert in any of these, but at least I've been able to do some research on each.
- Open Text Web Solutions is the new name for RedDot. Although less expensive than the traditional heavyweights Intervowen and Vignette (which Open Text is buying), it still carries fairly hefty licence fees. This is the "bake" system that pioneered in-place editing, and the UI has some nice elements, although it can be confusing with the use of a large number of small icons and pop-up windows. The system has powerful templating and asset management, and is very capable in terms of multi-publishing.
- Ektron CMS400.NET is a pure .NET system, probably aimed at a similar market to Plone. It uses a "fry" model and has a number of modules for things like wikis and group workspaces. You can get a 15 day demo, which is nice for testing. The UI functional, but clunky in parts and can be inconsistent across modules. It's also a little too easy to end up in a pop-up windows of the back-end application when you thought you were editing something in-place. Templating and extension development uses standard .NET features, lowering the learning curve for developers with experience of that platform.
- Microsoft Office SharePoint Server has a fairly familiar, "Office-like" UI and a lot of features out of the box. I find it confusing to work with, though, because of the way it nests "sites" and a certain lack of focus. Even you personal homepage is your own "site", with its own navigation. Sharepoint is probably more applicable as a document management and collaboration tool than as a web content management system, and the web content management features are pretty basic.
- Alfresco WCM is a "bake" system (although you can have front-end applications that access the Alfresco repository) with some interesting features for sandboxing and collaboration. It's probably more interesting if you're after a way to manage web application files than if you're looking for UI components and services for web page delivery or end-user content contribution. Architecturally, it's interesting if you're a Java shop, and it benefits from being quite young in the sense that there isn't a whole lot of legacy in the architecture.
- Umbraco is an open source .NET-based CMS. Like Alfresco, it still appears to be tightly controlled by a single (and in the case of Umbraco, tiny) company, and you have to pay for certain things up front (like the instructional videos, which seems a bizarre thing to charge for). Looks interesting from an architecture point of view, although it's relatively young and very basic in some parts (workflow in particular). It separates front end from back end, and assumes you will be managing code and templates via the back end GUI. If I were a .NET developer looking for a framework to build a custom CMS application on top of, I would probably take a look at Umbraco.
- Morello is interesting in that it has a fat client Windows application as its primary GUI, although it now also has an AJAXy web client that mimics this. Some good integration with the Windows desktop and what looks like a pretty good UI for contributors.
I've looked at a lot more systems, but those - in addition to Plone, of course - are the only ones that really interested me. And in large part, that has to do with the UI. Even Open Text/RedDot, which says in every "datasheet" that Gartner calls its usability "legendary", is confusing to use at times, and many of the other systems - especially the older ones - are downright shocking.
To me, this is probably the biggest differentiator. If usability is poor, uptake is going to be poor. Your editors and administrators are going to hate the system. In 2009, the world expects software - web applications included - to be usable and intuitive. It's no longer enough to think you can "fix it in training". The most enlightening evaluation I've been able to do is just to install the system and click around it. If I can't figure it out easily, it's not good enough. End of story.
The other interesting observation is that price is not necessarily related to quality. Some of the "enterprise" tier systems have enterprise price tags, but they don't necessarily offer features or usability that warrants such a high price. Sometimes the intangibles do - support, ability to integrate with existing, entrenched systems, indemnity - but there seems to be a sweet spot at the middle of the market where usability is better, the implementation cost (licensing + consultancy/development) is acceptable, and the feature set is more than good enough.
All in all, this evaluation exercise has confirmed my belief that Plone can hold its head high in the web content management world. It's obviously not a perfect system, nor is it going to be the best choice for everyone. But it is built on a solid architecture, it's got a mental model that works and end-user usability is better than in a lot of systems. People often complain about the learning curve and the complexity of the stack, and there's a lot of truth in that, but it's not necessarily much worse than many of the other products that you could compare it to (and serious work is underway to try to simplify things). I also believe that the "it's not Java/.NET" argument is becoming less important in today's world, although it can still be a hinderance in some situations.
That said, there is still a lot that Plone can learn from the other systems on the market. I'll try to summarise some of those below.
- Formalise and document support for the "bake" model. Not by default, but as a deployment option. This probably means something like Content Mirror or transmogrifier being used to export content on a scheduled or ad-hoc basis, and example applications used to theme and deliver such content, perhaps via Deliverance and some simple back-end web application.
- Provide a file representation of all content. We already have this to a certain extent via WebDAV, but it's not perfect and not well maintained. It should be possible to browse the site via WebDav and upload content easily. This also makes migration and export/import easier.
- Bring back the External Editor. Editing content in Word, for example, is an important use case. Morello has an interesting take on this, where an exported file becomes a protected Word document with editable fields acting as a form. When you re-upload (or save-to-server) the document, it is parsed and the data is extracted.
- Better integration with Microsoft Office and the desktop. For example, it should be possible to edit web pages in a Word document, using styles to highlight headings and sections. Embedded images should be supported and extracted on upload. Upload and workflow should be available from within the desktop application using dedicated menus or toolbars.
- Allow content to be dragged from the desktop and dropped into the CMS. Many CMSs do this, although they sometimes do it badly. Open Text/RedDot has a nice model whereby you can drop an image onto an editable field, and it pops up a dialog asking you for any mandatory metadata, and then inserts the image into the page. The file goes into the asset library.
- Expose all standard operations (like creating, editing and accessing content, changing workflow states, security, and so on) as RESTful web services. This makes integration with other systems much easier, and helps alleviate some concerns about committing to a system not based on a more common platform. Ideally, we should be using existing standards here where they make sense.
- Provide better support for group workspaces. A group workspace can just a folder with a suitable "front page" for showing group members (holders of local roles) and their content. The workspace would be a natural location for the working copy when content is checked out using Iterate, for example, and would more easily support use cases where content is produced by one set of people, but given a home in the IA and published by another. There are already decent add-on products for this, and it may not need to be in the core, but a slightly more robust and accepted solution would be welcome.
- Expand the dashboard. Plone's dashboard is just a set of portlets, and is a bit clunky. It really should be the first thing users see when they log in, configured by the administrator to highlight important information. That should include workflow events that pertain to the current user, including messages from reviewers (e.g. if content was rejected) in a personal "inbox".
- Support content notification. Users should be able to "star" content they care about and get notifications on updates to that content, either in-Plone (via the aforementioned "inbox" of messages) or by email, depending on personal preferences. Such "stars" can also be used as content metadata, e.g. content with many "stars" can be seen to be more popular.
- Improve support for taxonomy and content re-use. At the very least, it should be possible to place a given content item in more than one place (via some kind of "alias" object, probably), and apply different security, workflow states and view templates to the two different instances. The placement of such aliases should optionally be controllable from the edit screen of the item itself, i.e. you can decide where the item is to be displayed when you're adding or later editing the item.
- Improve multi-site support. Many organisations need to be able to publish a content item to multiple "micro-sites", and manage multiple such sites through a single interface and security model. There is some work going on in collective.lineage to enable this.
- Support through-the-web content types and templates. Most of the successful CMS systems allow administrators and power users to create content types for forms-based content through a web GUI, create simple templates in the browser, and associate a content type with a template. Dexterity includes support for through-the-web content type creation, although the UI needs some work. Through-the-web templates already exist, of course, but it would be better to bring basic templating for custom content types into Plone, rather than rely on the ZMI. We also need to ensure that we have good way to move those files to the filesystem for serious development.
- Improve page composition. This is what the Deco system is all about. We need to deliver on this, and make it easier to design custom layouts (ideally without the need to learn HTML) and make them available on a per-type or a per-item basis.
These were my experiences and my suggestions for what Plone may focus on. A lot of other great ideas have been posted to the newly created (and very successful) Plone UserVoice forum. I may make a few new entries there myself.
I'd be very interested to hear from others, both about systems out there that do something well, where Plone has something to learn, and about situations where Plone has an edge over the competition.