Java CMS Roundup

I'm looking for a new CMS to replace my company site to replace Google Sites hosting that I currently use. I decided that it needs to be Java JDK1.6 compatible, use a Postgresql 9 database, and run on Tomcat 7. Smaller memory footprints are preferred, with a target maximum of 1gb ram for the cloud server hosted with Rackspace here in London.

I also wanted a good digital asset feature in the product so that I could make it more visual and introduce more style into the site. I looked into a number of possible products, all open source and all free to use.

dotCMS

At the time of writing dotCMS is previewing version 2. 

Pros

• It looks good. The demo of version 2 plays very well on their site.
• It's open source, free to use and licenced under GPL v2.
• Tomcat is supported, as is PostgreSQL.
• It has multi-tenent hosting, so several sites can be hosted completely separately on the same server.

Cons

• I tried and tried and tried to install this into a vanilla Tomcat 7 server without any success. I even tried to use Tomcat 6 and it still doesn't run. It turns out the only way of launching it is to use the bundled version of Tomcat.
• The image editor is only available with the Enterprise edition.

I gave up after spending far too long attempting to get this to work properly. Even with the stable v1.9 version running with the modified Tomcat it never successfully completely started.

Magnolia CMS

I've used Magnolia before. It's currently on version 4.5.

Pros

• It's open source, free to use and licenced under GPL v3.
• It all seems to make sense. Create a page, edit a page, publish a page. 
• The standard templating kit (STK) gives some nice components that work well.
• It uses an installer, but the WAR files can be used to redeploy it elsewhere.
• As standard, it's possible to create an intelligent, good looking site really quickly.

Cons

• The image editor was only available with the Enterprise edition with v4.4. Version 4.5 has this included in the community edition.
• I want to try something different, something I've not used before.
• Currently it relies too much on right-click actions, making it unusable on tablet devices.

Magnolia is a solid reliable CMS that I have no hesitation in recommending. In general it's a good product.

Jahia xCM

For some reason, Jahia isn't listed as a CMS on Wikipedia. I tried verson 6.6.0.

Pros

• Jahia Studio allows development through a web interface.
• It's got a great feature list and a very good demo.

Cons

• Jahia Studio is complex and hard to use. There is no obvious starting point.
• It's GPL v2; but not for commercial use.

The lack of affordable licensing for commercial use eliminates this as an option.

Weceem

Version 1.1.2 of Weceem is built on Java, Groovy, Grails, and Spring. It shows some promise, but it's ready to use.

Pros

• It's really lightweight.
• It's open source, and under the Apache 2 Licence.
• It appears to be highly extensible
• A little fiddly to set up initially, but fairly simple. Packaged as a WAR file but it needs an external configuration file to start up.
• The documentation is lovely and light. There's not much but it cuts to the chase.

Cons

• It's very rough around the edges.
• It has the worst demo of all the CMS I have looked at
• I'm not convinced that it deserves the v1.1 moniker - it feels more like a pre-release
• It has some questionable UI elements; most notably there are features which lead to pages that state that they haven't been implemented yet.
• Some of the documentation is already out of date.

I'm not convinced that this is mature enough for my taste. I would certainly struggle to recommend it except perhaps to developers who like to hack together solutions. Weceem is embeddable into other applications and this is where it's real value lies.

Hippo CMS

Hippo CMS community edition is version 7.7. Out of the box, this product offers the most.

Pros

• Open source, Apache 2 licence
• Includes all the major features I will need
• It's context aware, so I can create structured content and reuse it
• It appears to have great media handling with a good image editor
• Installation was simple; install two WAR files and some JAR files.

Cons

• I have to fill in a form to download. Why?
• As it's icon based it is less than intuitive to use
• The structuring of the content by context also adds a learning curve
• No obvious way of removing all demo content, nor does the demo yield many clues of how to create a new site

This is a very good product, but it might be too much for needs of a site with a single author.

OpenCMS

Despite being forced to register for a demo, I looked at version 8 of OpenCMS.

Pros

• It's FOSS.
• The menus pop up on left click, so it stands a chance of working on a tablet.

Cons

• I hate being asked for contact information just to demo a free product.
• It's designed to look like something from 1995. Bleugh.
• The demo is as bad as the admin screens, really ugly and tired.

I suspect that even if I could live with the ancient design of the admin screens I would struggle to make the output of the site look good.

Other choices

Flexive was rejected purely on the basis of horrific green icons all over the authoring and admin screen. It really is that bad.

RiotFamily was rejected as although it is beautiflly executed, it seems to have no navigation management, UI to create new pages, or image management features. It seems to be more of a page editor.

Alfresco & Nuxeo are document management or case management systems. Although they have the ability, it would be a strange choice to abuse them to create a website. 

Disclaimer

Although I am not affiliated with the product vendor, my daily work is with Adobe Day CQ5. Unfortunately there is no free licence available for this product making it unsuitable to power the website for my own company.

The parallels between video games and enterprise software

There are quite a few similarities between computer games and software designed for the enterprise. Ignoring gamification techniques where points, awards, and trophies are given for doing things, there's a lot of incidental likenesses between these two very different categories.

If it looks good it must be good

People will buy into something hyped enough even if it's duff. It it looks professional but is a bit odd or quirky, or even crashes frequently people will still want it. A slick front-end grabs attention and looks great in sales demos and makes a product stand out from the crowd. There's plenty of examples of good looking software that somehow didn't cut the mustard. The same is true of video games - folk want the shiniest graphics. I personally thought that Crysis was a mediocre game, but it did look great and sold well on that strength.

People will forgive quirks

Skyrim is a great example of a game that scored ridiculously highly in all the reviews and looks great but has tons of weirdness. The strangest thing I've seen was a mammoth that suddenly jerked 100m into the air then floated gracefully down to the ground. There's obviously bugs in the physics. There's also the 'dragons flying backwards' fiasco... it breaks the illusion of the game.

The same applies to more recent versions of Microsoft Office. The 'ribbon' Fluent User Interface is such a departure from the common Windows UI it's just odd to use and really hard to find functionality even now. It's been years since its introduction. Somehow the enterprise users tolerate this.

If it's not polished people won't buy

Games that don't quite look right or have strange design choices are not generally as popular as the more polished titles. In software, if there are no rounded corners, gradients, and attractive visual elements then it will be disregarded. The competition is so fierce and the selection is so broad that only the smartest, quickest, and boldest will survive.

The CMS market is quite indicative of this. There are hundreds of CMS systems, and literally dozens that are of a very high quality. Even narrowing it down using the development skills present in most in-house teams will yield more than a handful to choose from. The ones that seem rough in the demo & evaluation phase get dropped pretty quickly. This is multipled quite severely by the cost of implementing the solution.

A good title makes a difference

Names like Documentum, SharePoint, Office, SalesForce have an obvious link to their function. Tools that begin with a J are often Java based, which is a good thing if the customer is already using this technology. Titles that are short and easy to say on the phone work really well.

The same seems to apply to video games, but in a different way. Either it is easy to say, or it abbreviates or acronymns nicely. Examples include Call of Duty aka CoD. As with other software the title is often suggestive of what you have to do to use it - Battlefield 3 is obviously a shooter just as Photoshop is a photograph manipulation tool.

In both cases, sequels seem to do well whether its Windows 7 or Forza Motorsport 4.

People are willing to wait for a big name release

Gamers wait YEARS for the promise of certain titles. Duke Nukem Forever is a prime example of this, as is Elder Scrolls 5: Skyrim which was five years in the making. It's not unusual for entertainment titles to take this long.

Conversely, professional tools don't take this long. Very few companies could afford such a long development cycle, nor would it be prudent. This market moves much faster. Google+ took just over three montths to launch business pages and during this time it was critised heavily for not having a feature present on Facebook.

People will tolerate cross platform crappiness

Some games are great on consoles and poor on the PC such as Skyrim because of the console-based UI - it was still highly ranked by reviewers and in the charts. In other cases it's the other way around; strategy games are generally regarded as better on the PC because of the mouse and keyboard but people still play them with sub-par input methods.

Enterprise software generally has two parts, the server and the client. Poor quality clients in this regard would most definitely include Outlook Web Access if you try and use it in anything other than Internet Explorer - it was terrible in Firefox or Safari because it relied heavily on ActiveX controls. Lotus webmail was just as bad.

On the server side, a lot of technologies that work very well on Linux and Unix don't funciton quite so well under Windows but many will overlook this. The differences in the file system are the usual culprit.

People will even buy gear just to run it

Crysis had extremely high video graphics power to run it properly, as does Skyrim. There are many hardcore gamers who have no problem with spending serious money just to play a game. The same applies to consoles; you have to buy the hardware to play certain games when they appear on just one machine.

SharePoint is an example of this; you need to buy Windows Server to run it if you want it in-house. Most .net software also requires capital expenditure if you want to run it properly.

The other way of course is virtualisation in the form of cloud PaaS virtual machines. These too are the equivalent of hardware leasing but with much shorter lead times - don't be fooled by the marketing. You still have to spend to make them work.

Trophies are all the rage

Ok, I did say I was going to ignore this topic, but it's just too significant in the overall scheme of this article. Gamification is the art of making work tasks into games by adding artifical rewards in order to encourage and create a competitive spirit. Plenty of in depth articles have been written about this phenomenon elsewhere on the internet. Workification is adding dull tasks into otherwise exciting games for minor rewards which can help with the main objective of the game.

Both are fairly commonplace at the moment. It seems that application designers want their tools to appeal to younger audiences who have grown up with video games, and that game developers wish their product to be accessible by more mature markets who have been ground down by the menial repetitive tasks they have to perform in their daily duty. Seriously though, I have no idea why they put a pie-making minigame into Fable 3 just to earn a few shekels.

There's only a handful of genres

Think about it: just as games can be bunched together into genres like racing, shooting, platform, puzzle so can enterprise tools. Broadly speaking, there's CMS, ECM, office packages, email, server software, backup, anti-virus, security tools. I'm not going to try and define what these categories are here (maybe another time) but there is definitely a limited number of types of enterprise software.

There's usually something bolted on that is an afterthought and doesn't quite fit

Mini-games, driving sections, and character customisations are the usual culprits in the gaming world. The enterprise market has much the same, with features that nobody really uses but are needed to tick boxes. Examples of this would include complex workflow designers, half-baked integration with analytics, and social networking & collaboration features that are half measures. Gamification done wrong is just as bad.

Something unique comes along every few years

Once every few years an innovation pops up which becomes a bandwagon that all and sundry leap upon. Titles like Grand Theft Auto really changed the landscape with the blend of violence, humour, and open game world. Business tools like LinkedIn are continuing to change HR roles. Twitter has mutated marketing, sales, and customer service by giving the consumer a voice. Facebook has hooked marketing directly into peoples daily lives. None of these were predicted, nor without hindsight were they predictable.

Both force people to do things a certain way

Although the trend is for more freedom of action, there are many activities that must be done in the prescribed manner. Just as puzzles in many games must be solved by collecting the item and taking it to location X then inserting it into slot Y to open door Z, jobs must be done by opening an application, clicking on a set of buttons in a certain order, then clicking save / done / ok to complete the task. Workflows add 'multiplayer' to the mix, making the task dependent on the actions of another 'player' and enforcing more rules. Compare this to Portal 2 which has a dual player co-operative online mode where you have to work with the other person to get the job done.

What next?

There is much that is the similar, and much that differs. The key is to try to spot the trend; what aspect of gaming will creep into the workplace next? What will migrate from the enterprise into the entertainment market?

CQ5 best practices for component development

Following on from my advice for best practices for developing with Adobe Day CQ5, here are some suggestions centred around component development - you should tailor these to fit your needs. They should help if you are unsure where to start. There's lots of technical documentation on the product itself and the core open source frameworks; elements of these are useful for developers, but there's scant information on methodologies or strategies you can apply when starting out. Some of this may also apply to other systems albeit with different no-go areas and so on.

Avoid copying components

Firstly, avoid modifying anything under /libs. Also avoid copying anything from /libs to /apps. There are a few reasons for this:

1. If you upgrade you will hate yourself for doing this. Your boss and co-workers may hate you too.
2. Changing /libs implies that you are either not going to version control it, or that you are going to. Either way leads to madness, unless you like code to go missing and have servers which behave differently or if you want to add half of the core product to subversion. 

Copies to /apps should be VERY limited for a few significant reasons:

1. when you upgrade, you need to upgrade this code too if you want it to work or at the very minimum have the new features. 
2. there's no way of quickly identifying these 'overlays'.
3. if you overlay something that is key, things go sour very quickly post-upgrade.
4. having two components with the same name in the same group breaks design mode in CQ5.4 - for me at least

Override the bare minimum

All components for paragraph systems should have a 'sling:superResourceType ' of 'foundation/components/parbase'. Development of derived components should be done using 'sling:superResourceType' where possible. An example might be creating a paragraph system that behaves differently. Say you want to make one where component display is inverted, so that new components are inserted at the top - this is a parsys with a 'sling:superResourceType' of 'foundation/components/parsys' and a customised script. There's no need to copy the whole component.

Component Organisation

A recommended structure for component definition is

 /apps/<site-id>/components/page/<component>
/apps/<site-id>/components/content/<component>
/apps/<site-id>/src
/apps/<site-id>/install 
/apps/<site-id>/widgets
/apps/<site-id>/nodetypes
/apps/<site-id>/templates/<template>

Of course, all of these are optional. Page rendering components explicitly defined in the templates are split from paragraph and non-whole-page components such as navigational bars. This is purely for the benefit of developers; it means it's possible to see at a glance if the component is used to render a whole page or if it might appear as part of a page - a useful distinction. It has another benefit, for example it allows a 'sitemap' paragraph component which lists in HTML format to exist as well as a machine-readable sitemap.xml page type for SEO - two very different things with the same name.

Composition of Page Types 

A process of decomposition into sub-scripts is applied to the page rendering code to create a solid foundation which will allow extension of the basic type into more specifc page components:

/apps/<site-id>/components/page/base
/apps/<site-id>/components/page/base/base.jsp
/apps/<site-id>/components/page/base/head.jsp
/apps/<site-id>/components/page/base/body.jsp
/apps/<site-id>/components/page/base/header.jsp
/apps/<site-id>/components/page/base/content.jsp
/apps/<site-id>/components/page/base/footer.jsp

The base component extends the foundation page, with a 'sling:superResourceType ' of 'foundation/components/page'. 'base.jsp' basically sets the page doctype, outputs the <html> tags and includes head and body. Subsequenty, body.jsp includes header.jsp, content.jsp, and footer.jsp.

Extensible Page Components

This is the minimum for a base component which is extensible. We can easily make this better by adding other override-able scripts, such as adding an analytics.jsp or a meta.jsp. From this start point we can create a new component with a 'sling:superResourceType ' of '<site-id>/components/page/base', and the only thing we need to create is content.jsp

/apps/<site-id>/components/page/twocolumn/content.jsp
/apps/<site-id>/components/page/twocolumn/left.jsp
/apps/<site-id>/components/page/twocolumn/right.jsp

This obviously a two column layout. In order to separate content from code we should create a new component with a 'sling:superResourceType ' of '<site-id>/components/page/twocolumn', which now needs no scripts at all. It will derive all configuration and code from the super type, leaving us free to change the super type if we want a different representation (so long as the paragraph systems have the same names). We can also override the two column layout if we so chose, by creating a script which does something then including the overridden script. For example, we could create a  /apps/<site-id>/components/page/contentpage/right.jsp script which displays a title component then includes the  /apps/<site-id>/components/page/twocolumn/right.jsp  script. This gives a great level of flexibility.

Content has a type

Remember that when content is being created, the component path is 'stamped' into the content so that Sling knows what script to use to render it. Always plan components so that an appropriate resource type is associated with the content. In our page example, it is much better that it is a 'content page' than a 'two column page' or even a 'base page' as the intent is that is it content. The fact that it displays in two columns is incidental, especially if in six months time a third column is added. It's much more future proof to use a layer of inheritance, but only if it doesn't add unnecessary complexity.

Favour composition over inheritance

Components is CQ5 should also favour composition over inheritance. If you want a list-image component for example, don't take a list component, copy it, and hack it to have an image. A reasonable approach is to create a new component and add the necessary components to it. When you upgrade CQ to a new version, you'll have no changes to make - it'll automatically use the new version. If you did it by creating a new component by forking code, you could find it difficult to get it working if there have been major changes to the original component.

I hope this guide has been useful. It's based on real world development practices and is the basis of any recommendation I would give at this time. 

Magnolia CMS

I’m developing a website using Magnolia CMS and I’m mighty impressed so far. Firstly, it’s been very easy to get it up and running in the tiny memory constraints that I have imposed upon it; it needs to work on a 512mb virtual machine because I don’t want to pay more for my hosting, and it's a good challenge to try and get a stock product with modern feature to work reliably in a confined space. Secondly it needs full user access rights, and it’s been very simple to configure and test. Finally the stock templates are actually useful and I’ve needed to do the bare minimum of customisation so far.

It's for a personal site, so I’m sure there would be other challenges if I had specific functionality that was needed and a design constraints but as it uses a template system it looks like this is part of it’s internal design to allow massive customisation of the output. It seems to run quickly even though it has virtually no heap space to use, and is stable. Some of the included features are fantastic, such as the ability to do polling import of RSS feeds which will allow me to pull in this blog for example. It also can aggregate the RSS to merge and filter which is very powerful.

The Digital Asset Management features are good too, I can upload an image, tag it, and attribute it with the Creative Commons information for the source so that I can add the links back to the creator. There are neat image gallery tools too which list whole folders of images and display thumbnails with big versions shown using a ‘lightbox’ style when they are clicked on.

My only gripe so far is that when a page is given an image it’s used in different ways; by the page itself, in search results, in teasers, and in carousels. Unfortunately it sometimes scales the image without regard to the aspect ratio thus squashing it. There is an add-on available to do image manipulation but it’s only for the Enterprise Edition and they don’t publish the price of that licence. It’s the only EE feature that I would like so it’s highly unlikely to be worth it. Thankfully it does have the option to override the image in these components which means I have to manually create a new image using a desktop application but that’s not too tricky. It would have been nice to have some basic crop and scale image tools built in, especially as Magnolia is a Java application so there are lots of free open source libraries which can provide some very advanced functionality. 

A link to the new site will follow when it’s launched… soon.

Update on Friday 18 November 2011 at 22:28 by Antony

Boris Kraft (@bkraft) of Magnolia has advised me that as of version 4.5 the community edition will have the imaging component. Huzzah! Thanks Boris!

NuxeoWorld

Last week I went to Paris to find out more about Nuxeo, an enterprise content management system. It seemed like a very polished product developed by a highly professional company and I was impressed by its capabilities. It’s very much geared towards Case Management and Document Management as it centres itself on workflow and processing of content items in a structured manner, with item state as a core tenet of the system.

I liked the idea of the Nuxeo Studio, a web based facility that allows changes to be made then deployed to live servers but also facilitates support of the live systems and distribution of the development effort. It also enables automatic upgrading which is a nice idea. They are also embracing the cloud with their Nuxeo Platform platform-as-a-service offering which is an intriguing proposition.

It’s a very different platform offering to the WCM systems I have implemented before, and I think this is a great niche to watch to see how it evolves. It’s a complementing system which is more about items which have lifespans and transitions between states as opposed to the web content created by CMS implementations I have done using Adobe Day CQ5, Umbraco, or Magnolia CMS.

I met some interesting people there, and I had a great evening out. I look forward to meeting you all again soon, and to the next Nuxeo event.

[photos to follow]