<!-- Content Here -->

Jeff Potts explains the difference between Alfresco's DM and AVM Repositories

Jeff Potts has written an excellent article explaining the functional differences between Alfresco's two different repositories (the original DM and the WCM). The enclosed chart is a useful cheat sheet that belongs on any Alfresco developers cubicle. Nice work Jeff!

For those of you who are new to Alfresco, the WCM repository (or AVM: Advanced Versioning Model) was introduced to the platform when Alfresco added web content management. The AVM is designed for managing structured XML content and does very cool things like snapshots and contributor "sandboxes." But the AVM is slower than the original DM repository and has less powerful metadata capabilities. Typically, web content will be managed as XML in the AVM and then pushed over to a cluster of DM repositories to power a dynamic website.

The Drupal Divide

Recently there has been a lot of chatter about friction between the designers and developers within the Drupal community (see posts by Earl Miles and Greg Harvey). The Drupal community is huge and dynamic and is bound to have various skirmishes as members with different backgrounds and needs try to get what they want out of the platform. But I didn't really expect that the divide would be along the lines of developers and designers. I thought it would be between high-end adopters (like media companies) and low-end adopters (like individuals, small companies, and non-profits that make up the bulk of the Drupal community). Or it could have been between people who see Drupal as a business application and those who see it as a development framework.

The Drupal community is keenly aware of the importance of usability and has done a lot of work to identify issues. With the upcoming version 7 release (code freeze any day now), Drupal upped their usability efforts by bringing in some high profile designers to participate. The transition from being developer-dominated to having a more even balance between design and development is important for the Drupal platform as a business application. Mark Boulton and Leisa Reichelt conducted a very open process to incorporate peoples design ideas and feedback. Now that I think of it, this rift between new ideas and the old Drupal guard was pretty inevitable. This kind of transition is not easy. Both sides need to adapt. I don't think there will ever be total harmony between pure developers and pure designers but I do think the project can achieve a healthy level of tension that improves the software.

Drupal Panels Tutorial

Readers of the Drupal for Publishers know that Drupal lacks a native system for associating different page layouts for different sections or pages on a site. Sub-layouts are typically implemented with conditional logic in the template code (page.tpl.php). The Drupal Panels module puts this control in the administrative interface and is becoming widely used within the Drupal community. To learn more, check out GotDrupal's excellent video tutorial on Drupal Panels. As you can see from the video, the Panels user interface is quite powerful but is also very complicated because you have to create these rules to determine under what conditions a layout should display. You still probably want a developer or well trained administrator to do the work on a staging environment and then migrate the configurations to the production environment.

Art of Community Now Available

Jono Bacon's new book The Art of Community: Building the New Age of Participation (Theory in Practice)

is now available. I first heard about this book in January and I have tracked the progress and discussion on and off since then. As you would expect from a book about community, the development of The Art of Community was a very open process. I must say that I was a little underwhelmed by the activity around the book given the interest in the topic. Number 1 on the list of top 10 commenters had 29 comments. Number 10 had 7. Maybe most of the discussion happened over Twitter where Jono has over 2,400 followers.

I have no doubt that the book will sell well. Doesn't everyone want to start a community? I just ordered my copy and will post a review here when I get through it. The incumbent for my favorite book in this category is The Success of Open Source

by Steven Weber. Clay Shirky's Here Comes Everybody: The Power of Organizing Without Organizations

is also quite good. Both of these books effectively describe the community phenomenon. What may set The Art of Community apart is a set of instructions for creating your own successful community (Jono draws from his experience with Ubuntu and KDE). But if the techniques work so well, why hasn't the community around the book thrived? Did Jono (who also works as community manager for Ubuntu and is a musician) not have adequate time to write the book implement his techniques?

What the Customer Really Needed

This great cartoon showing how a product is understood and described by different stakeholders is definitely going in my toolbox for explaining project disfunction. My explanation will be that you can't start to achieve a common understanding of something until get visual. If everyone got together and drew a picture of the solution and then regularly checked in as it was incrementally built, the potential for miscommunication would be nearly zero. Proofs of concept, prototypes, and pilots are useful for communicating more complex functionality — Much better than a lengthy detailed written specification.

Eric Barroca Debunking Commercial Open Source Myths

Nuxeo CEO Éric Barroca has an excellent post that breaks down the hype and decodes the marketing speak around commercial open source software. He doesn't name names but he does call out some of the claims and language of some commercial open source vendors. The general message is this: software vendors should focus on making great products and be clear and direct about what they are selling. There is nothing wrong with selling proprietary software or charging license fees — just be clear about it. Don't call a license fee something else to give the appearance that the software is free. Éric also gives a lot of credit to commercial software vendors that contribute to open source (like Atlassian, Day, and IBM) without making a big deal about it.

The J. Boye Short List

Today J. Boye posted a shortlist of vendors that "you should always consider" when selecting a web CMS. While many will take issue about what products were included or excluded from the list, what surprises me the most is that they published such a list at all. Here is why:

• J. Boye is very closely partnered with CMS Watch, which covers 42 products in its Web Content Management Report. Putting out this list would seem to undercut CMS Watch's flagship product.

• The CMS Watch messaging has always been that there is no "magic quadrant" in CMS and I would tend to agree. J. Boye is the first reputable buy-side analyst to come out with one. The title "Web CMS Shortlist 2009" suggests that they will come out with one every year.

• J. Boye does a lot of CMS selection consulting. This list implies that their selection services will start from these 10 products. I think that undermines the value of their consulting services.

I am sure that the J. Boye website will get a lot of traffic from this post and there will be a lot of angry comments from the vendors and open source projects excluded from the list. Hey, all publicity is good publicity, right? It is very interesting to see what J. Boye considers to be "go to" products and what is a global footprint. But this list will not influence what products I consider during the CMS selections that I facilitate.

Hippo CMS 7's New Content Type Editor

Arjé Cahn posted a short video demonstrating the Hippo CMS 7's new content type editor. The process is all GUI driven and looks very slick. It is difficult to know whether this is as flexible as the old Hippo CMS 6 system of editing layout and xsd files but it certainly appears easier. It is also nice to see that Hippo CMS 7 maintains the ability to control the layout of the entry form. Most CMS products only let you control the widgets used, their order, and, in some cases, what tab they appear on. Hippo gives the developer control over the layout of the whole form.

Dimensions of Success (or Ways to Fail)

While most of my consulting work is in product selection, I think the most interesting and rewarding type of project is evaluating the results of a CMS implementation. The typical scenario is that a client feels like their CMS project didn't yield the expected results and engages Content Here to identify what went wrong and what adjustments should be made. Without this type of analysis, it is typical for a buyer to grumble and suffer with the solution for the next three or four years until they have the money to replace it; then the cycle repeats itself because nothing was learned from the experience.

When evaluating a CMS implementation, I typically look at three dimensions: expectations, product, and project.

1. Expectation rationality. Too many projects are doomed from the start because the expectations were set too high. It is often useful to have a third party assess whether the project was oversold or if it under-delivered.

2. Platform suitability. Choosing the wrong CMS product also puts the project in jeopardy. The platform should support your requirements, feel intuitive to your users, be maintainable by your team, and be supported by a well run company that can be a compatible partner.

3. Project execution. The project to implement the solution should be appropriately scoped and phased to achieve short term results quickly and work toward long term goals. You need to select a competent integration partner (internal or external) that you can trust and collaborate with to make good decisions. Your users need to be well supported with training and coaching.

Failure in any of these areas makes a buyer miserable but some are more correctable than others. Choosing the wrong product is the hardest mistake to undo. Migrations are always hard. Even if you can get the data over, all the work to customize and configure the wrong solution is non-transferable. However, it may be possible to minimize the impact through customizations and work-arounds. Generally, these systems are flexible enough to achieve some level of comfort even if it is not ideal.

Irrational expectations is the easiest problem to correct. For example, if it was unreasonable to expect that everyone in the organization (without training) would autonomously contribute their own content, maybe you need to keep that web coordinator role. Maybe some of the benefits will not be immediately realized after the first release of the solution. It is fairly typical to do a few subsequent maintenance releases to expose new functionality or correct bad design assumptions. Ideally, this should be a living solution that is constantly evolving and improving. You are not going to get everything right the first time.

Even though no implementations are perfect, some projects go better than others. Inexperience is the biggest culprit. You want to work with an integration team that is familiar with the technology (on most platforms, it usually takes 2 to 3 substantial projects to establish best practices and patterns). You also want to work with a team that has done similar scale projects, understands your industry, and can speak your language. It is easy to misinterpret requirements and make bad design assumptions if you don't have a suitable context. Sometimes a rocky implementation with a new vendor is part of a natural learning process and things will improve. Other times, it is a sign that two organizations are incompatible as partners.

If your organization feels disillusioned by a recent CMS implementation, the good news is that most problems can be fixed without having to start over. All that is needed is a solid understanding of what went wrong and a roadmap of corrections. Over time, the solution will probably be able to achieve all of the reasonable expectations that you had for it. Let me know if you need help evaluating your CMS implementation. Content Here can put you on a path to improving it.

Magnolia Conference 2009

Magnolia is hosting its first big user conference this September 10th and 11th in Basel Switzerland. I was going through the program and it looks great. There are two tracks: one for business users and the other for developers. The developer track has a session where David Nüscheler will talk about the new JCR Specification (283). There will also be two people from Texas State University to talk about their work with Magnolia. If you are using or considering Magnolia CMS and can talk someone into sending you to Basel, definitely try to go (register here). You can even get a 30% discount off of the €200 standard price if you use the code "mconf09gottlieb".