You are here: Home Articles Plone and its competition: choosing a CMS
Navigation
OpenID Log in

 

Plone and its competition: choosing a CMS

by Martin Aspeli last modified Jul 06, 2009 04:57 AM

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:

Seeing the wood for the trees

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.

What kind of CM do you need?

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.

Portals

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.

Architecture arguments

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.

Bake vs. fry 

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.

In-place vs. front-end/back-end

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.

Assets vs. content

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.

Folders and taxonomy

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.

Pages and fragments

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.

Managing code and content

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.

The contenders

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.

Usability is king

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.

Pay for what you get

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.

What Plone can learn

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.

Conclusion

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.

Document Actions

Great article :)

Posted by http://www.netsight.co.uk/people/matth at Jul 05, 2009 12:43 PM
Martin,
  A great article, and nice to see some comparative views of other systems. Only two points I'd note:

1) In-place vs. front-end/back-end.

Plone actually has the benefit of being able to actually be used in *either* of those ways. We've certainly deployed it with in-place editing for intranets and the likes, but also deployed it with separate front-end and back-end (via skin switching) when we wanted to heavily design the public view of a site without wanting to worry about fitting in the editing controls and the likes. This means we can make the call on which paradigm works best dependent on the project.

2) 'Alias' object.

We've tried this, and my god did it hurt. It is very difficult to do properly, mainly for much of the reasons you mentioned above. ie. what security does something take on? What happens from a UX point of view when you have 5 items in a menu and one is an alias that transparently takes the user elsewhere and dumps them is a different context? What happens when the user (as they inevitably will) wants the item to 'be exactly the same... but a bit different'? How do you edit the actual alias vs edit the source content? How do you deal with a user editing content not realizing there is an 'alias' to it displaying the content elsewhere in the site and that has now just changed as a result?

It is a very very hard problem to solve, and something that I think can't be sanely done without completely dropping the normal content hierarchy paradigm of Plone and switching to a completely taxonomy-node based approach. Problem with that is, the content hierarchy view really is so much easier and to understand and intuitive for users.

-Matt

Great article :)

Posted by Martin Aspeli at Jul 05, 2009 08:40 PM
2) 'Alias' object.

You're wrong. It *really* starts to hurt when you try to understand what to do when aliasing folders. :p

But I think there are solutions that can work. I'm experimenting with some options, but it's really hard.

The LinguaPlone model works

Posted by https://launchpad.net/~stefanholek at Jul 06, 2009 01:57 PM
Aliases *are* *hard*. The LinguaPlone model, on the other hand, is simple: "Full" content objects, linked by a relation, with the notion of a "canonical" object and its "translations" (or more general: its "copies"). Then sprinkle some event handlers on top to synchronize fields, workflow states, or what have you. Done.

It's a bit on the heavy side, granted, but compared to dealing with aliased folders, ... no contest ;-)

Stefan

Content Production systems vs Presentation Management Systems

Posted by http://openid-provider.appspot.com/pmonks at Jul 05, 2009 11:46 PM
Another way of comparing Web CMSes is to look at whether they primarily support the content production process or the presentation (rendering) process. See http://blogs.alfresco.com/[…]/ for a comparison of some WCMSes - I'd be keen to hear how you see Plone fitting into this (not knowing much about it myself).

Content Production systems vs Presentation Management Systems

Posted by Martin Aspeli at Jul 06, 2009 12:59 AM
Hi,

This is basically another twist on the "bake" vs. "fry" argument. Most "fry" systems have at least some presentation orientation, and most "bake" systems have a primary orientation towards production.

Plone supports both production and presentation. Some people choose to use it for production only, and stage content out to a separate delivery mechanism. The most common approach is to use Plone for both, however (normally with a caching proxy in front for performance reasons). All content is edited in-place, in the themed pages. When you don't have the rights to edit an object, you don't see the editing widgetry, of course.

Reading your article, I'm not sure I agree that content production and presentation are orthogonal, nor am I convinced you've represented Plone correctly. To say it has "weak" support for content models or "weak to no" support for content production is plainly wrong.

To draw an (imperfect) analogy, is Microsoft Word a "production" or a "presentation" technology? Most people will use it for both authoring documents and viewing others' documents, possibly then making changes as the document evolves. Most people do not need to convert the document to PDF before it is made available.

Another example, which I touch on in the article: what do you do when you want users on the front end to contribute content? If they are uploading videos, say, should they not be subject to the same type of content management rigour, classification, taxonomy and rigour as other content created in the CMS? Obviously, you don't want your visitors to see the full editing GUI (i.e. you tend to use custom forms), but once the content is in the system, it should be possible to manage it like any other content. Here, a strict separation between "production" and "presentation" can be unhelpful.

I think this is what you're getting at with Surf. I think it'd be good to have a number of standard components to e.g. store contributed content in the repository, generate sane urls, generate navigation, provide search, manage users and security, and so on. Plone deveopers rely on the CMS framework to provide these services, massively reducing the time to implement a front end (which becomes more of a theme-and-configure exercise than a development one).

I also worry about the usability of front-end/back-end separation. I have had more success with models where all editing is "in-place" rather than having a strict "application like" editing GUI and a separate, custom-built front end where content is published to. This type of model requires users to predict how their changes in the production environment impacts the live environment, usually via some maybe-not-perfect, separate preview feature. There are situations where this separation makes sense for other reasons, but it's a usability negative nonetheless.

Martin

Content Production systems vs Presentation Management Systems

Posted by http://openid-provider.appspot.com/pmonks at Jul 06, 2009 01:54 AM
The notion of production / authoring systems vs presentation / rendering systems is orthogonal to considerations of bake vs fry. Vignette VCM (to pick one example) is a production-only WCMS that doesn't support bake at all. The bake functionality in Alfresco WCM (to pick another example) is entirely optional, regardless of whether Alfresco components are used on the delivery environment or not. Interwoven Teamsite (to pick a third example) is as you describe - production only & bake only.

To pick up on one of your other points: except for small, technically skilled editorial teams I'm not a fan of the inline editing production model, as in any moderately large content contribution community (say more than a hundred or so contributors) you quickly find that the bulk of the subject matter experts are non-technical - they've spent their careers becoming experts in things other than web technologies and often don't know (or sometimes even care) where their content ends up on the site.

It's critical to provide these folks with an authoring and production toolset that they're comfortable (and ideally familiar) with - Word (for better or worse) being the lowest common denominator. The last thing you want is to be faced with an adoption / change management headache because you're trying to ram an unfamiliar toolset down these people's throats, particularly since they tend to be one of the more vocal and politically strong constituencies in most CMS implementations!

Content Production systems vs Presentation Management Systems

Posted by Martin Aspeli at Jul 06, 2009 03:58 AM
Hi Paul,

I see your point about production vs. presentation.

Still, if you have a "production only" CMS then you need some way to get the produced content out to the end consumer. I'd call that process "bake" if it didn't involve accessing the same content repository that the production system used for its content, i.e. content is pushed to a separate server where it is served statically or with some dynamic front end. Perhaps I'm not being precise enough in describing the various options in how the end result is actually achieved, though.

By the way, in my reading of the materials around Vignette, it seems it supports both "bake" (via decoupled delivery) and "fry" (via the portal server).

Regarding in-place editing, I think we just have very different experiences with what works and doesn't in practice. The reasons you state for preferring separate editing environments are quite similar to what I'd say in support of in-place editing.

Of course, it depends somewhat on how the in-place editing is configured, and what the users are interested in (i.e. are they just producing content that someone else will massage for the web and publish, or are they trying to make an update to the website directly). You certainly need to spend a good deal of time thinking about what people see, what options they have available and how they preview their updates.

But my biggest problem with completely separating production from delivery is that users need to "guess" how the content they are authoring will end up looking to site visitors. It may be that the users don't care, but in my experience, they normally care more about this than about anything else. If you have to publish to a separate staging server and/or use some kind of in-production-environment "preview", it's a symptom that something is wrong. :)

For the record, I think a lot of "big" systems do the in-place editing poorly. They often rely extensively on tiny icons, right-click menus and pop-up windows. It feels like something that's been tacked on, and you frequently have to go to a different view (the back-end) to do certain things. The line between front end and back-end can seem pretty arbitrary. I'd probably say that unless the system is in-place-only, and designed with that mentality in mind from the ground up, then "in-place-sometimes" editing can exhibit the types of problems you're describing.

A final note on editing in Microsoft Word: Few systems do this well, which probably has more to do with Word than with those systems. It's a bit of a holy grail in some scenarios, but it's also the extreme case of having to "guess" what the end result is going to look like. When you're editing a word document, you can't see the site structure around it. The context is lost. If you're just writing a standalone article, then that's fine, but websites are usually more cohesive than that, making explicit (hyperlink) and implicit (in the copy) references to contextual elements and pages.

Anyway, I'm sure we can agree on one thing: that there is no one-size-fits-all solution. Plone is great for some people and terrible for others. Ditto Alfresco. :-)

Martin

Content Production systems vs Presentation Management Systems

Posted by Martin Aspeli at Jul 06, 2009 04:35 AM
Hi Paul,

I added a bit of text above talking about production vs. delivery (what you call presentation management systems), and how it is different to "bake" vs. "fry". I do still feel those concepts are related and overlapping, though. For example, a "bake only" is by definition production oriented.

I'm also not sure it makes sense to talk about them as opposing choices. A presentation management system is of little use without a content production system, and vice-a-versa, so you need both (you may of course already have one in your enterprise).

In the table in your blog post, the "CPS" column contains systems that do production *only*, but the other column contains systems that do presentation, but don't need a separate production application. As mentioned, I also think you under-sell the examples in your PMS column, at least in the case of Plone, which certainly has good content production capabilities and good support for custom content models.

If you really wanted to talk about "PMS" only, then I think you should've talked about portal servers (which you mention) and web frameworks that run on feature-rich applications servers (which is basically the DIY version of a portal accessing a shared repository or baked files).

By the way, I tried to post some of this on your blog, but got a 404 upon submission of the comment.

Martin

Excellent run down

Posted by http://jeorgen.myopenid.com/ at Jul 06, 2009 06:52 AM
Excellent run-down Martin, and a good list of features to get into Plone.
Sponsor message

Researched website hosting companies for high traffic websites which need dedicated servers for smooth running but also covering virtual private server providers.

Plone Book
Professional Plone 4 Development

I am the author of a book called Professional Plone Development. You can read more about it here.

About this site

This Plone site is kindly hosted by: 

Six Feet Up