Bertrand Delacretaz was interviewed at the OpenWorld Forum in Paris about the Apache Software Foundation. It is an ASF primer - apparently the ASF and its ways of working are relatively unknown in France.

Won't somebody please think of the children authors?
(almost Helen Lovejoy)

Have you seen the component for multi-variate testing (MVT, aka A/B testing) in the upcoming CQ5.3 release? I saw it demoed by David at Ignite and was completely blown away: CMS users (authors) can simply drag a couple of alternative banners onto the component right from within their regular editing interface (the CMS will then show the different versions to different users and count the click-through rates so that eventually the best performing banner is determined).

The MVT feature reminded me of two other CQ5 features: personalisation and analytics. All three are truly and seamlessly integrated into the user interface of the authors and they all provide less functionality than full-blown standalone solutions. To give you a concrete example: for each page the editors see right in the site admin (i.e. in their daily user interface) how many views each page got in the last 30 days. Clearly, this is no match for the kinds of reports you get on, say, Google Analytics, not even the same ballpark. Yet, I still think the authors get something that is valuable for them: they see it right away what is of interest to their audience.

(there is screencast available that demonstrates personalisation features from an author's perspective, registration needed)

When I compare this author-centric evaluation of functionality with my usual point of view as a system architect the business value of a feature for an author might be determined by:

• ease of use rather than feature richness and
• seamless integration into the UI

This is probably true for most systems that have non-technical users, but I believe the effect is amplified in CMSs because many CMS users use the system only once in a while rather than regularly.

Of course, this author-centric view on features should not necessarily dictate the underlaying systems architecture especially when you look at a complete content management solution encompassing analytics, personalization etc. The architecture might still be full-stack or best-of-breed and I do not want to postulate one being better than the other. However, I believe that one way of knowing that you got the author's user experience right is when you cannot see the system architecture reflected in the UI anymore. Or to put it the other way round: the UI should not enable you to guess which box which feature is running on.(*)

Thanks to Lars for providing discussions and ideas on this post.

(*) This idea is adjacent to a pet subject of mine: the user interface for basic content management (CRUD stuff) should not enable you to guess the underlying content/data schema. Sadly, up to today not few CMSs UIs resemble ERP-style data entry masks.

Ignite in Zurich was a blast. Lots of good presentations (which I will hopefully be able to share later) and excellent discussions on content management. My favourite quote was from Newsweek's Meshach Jackson. Their editors on the CMS selection process:

If you don't select CQ we're all quitting.

I also enjoyed what David Nuescheler had to say about separation of content and layout. The standard CMS architecture thinking goes like this
a) we need to separate content and layout
b) therefore, the user interface for the authors cannot look anything like the rendered pages and we will make it look like a database entry mask

David demonstrated that a) simply does not lead to b). Or in his own words:

Separating content and layout does not mean you have to confuse the authors

To get a taste of the event: The conference hashtag was #dayignite and here are some Ignite pictures on Flickr:

So, in case you missed Ignite Zurich there is still Ignite Chicago coming up...

Justin Cormack has written a noteable blog post titled "RESTful daydream #4" (pun intended?) about RESTful content repositories. I disagree with some of what Justin writes about JCR and Sling. However, I completely share his vision about REST's role in content management and I am with him regarding the overall theme of his post.

Essentially, Justin asks for a "web content repository":

The odd thing is that a web content repository alone surely lends itself to a simple REST architecture. Content is after all lots of small resources with relations. [...] It takes content, relates it to other content, and serves it back, with authentication and versioning. Everything else is in other system layers, transforming it and so on. Not simple, but well defined; lower level than JCR + Sling say.

Apache Sling provides a RESTful interface onto content, but being a web application framework it provides much more, especially scripting. So I can understand well why Justin dismisses Sling as being too powerful. However, I believe that Jackrabbit's native http layer is pretty much on the mark (Justin also dismisses it in the comments as being not RESTful. I do not know why.). As far as I know the Jackrabbit http remoting layer is quite work-in-progress so one might argue about the details regarding its RESTfulness, but overall it fits what I understand to be a RESTful web content repository.

There is one aspect regarding a web content repository I would like to add to the discussion: I think it is crucial that the representations of resources and be consumed by browsers. HTML forms for writing and presenting resources in JSON should be part of the equation. Adding models or semantics on top of that will might do more harm than good.

Do we need a formal standard for web content repositories? From my perspective: not yet. At the moment we still need to learn more, i.e. more repository implementations and users that have built a CMS on top of a web content repository.

Apache Sling keeps on growing up. Today's step: Felix Meschberger announced a users mailing list (before there was only one mailing list for developers and users). The new list is also available in the Discussion Groups section of dev.day.com.

If you use Sling please consider adding your project to the Sling users wiki page.

eXo's Peter Nedonosko discusses on his blog why JCR is good for content management. I could not agree more with his conclusion: it is useful for cms developers.

JCR standard is useful for CMS [...]