1 Comment

Why Hippo CMS?

In the Spring of 2011, Software Systems Development and Research (SSDR) and the Web Advisory Committee (WAC) were in the process of implementing a new Content Management System (CMS) to run the Libraries’ Website. Babak Hamidzadeh, newly-hired Associate Dean for Digital Systems and Stewardship (DSS), and I discussed the difficulty of supporting our then-diverse technology stack and possible alternatives.  At the same time, WAC was expressing dissatisfaction with the CMS in progress, a proprietary ASP.NET based application, which had been chosen somewhat unilaterally.  So we decided along with WAC to scrap that CMS and begin a joint selection and review process for a new CMS.

The selection process began in June with the creation of a requirements matrix containing author, editor, and technical requirements and desiderata.  After a process of seeding the matrix with CMS candidates we began with a documentation review, followed by installation and  testing of a subset of candidates, a gradual narrowing of the field, and finally selection of the chosen CMS, Hippo CMS, in October 2011.

We maintain several Drupal-based sites and there is wide Drupal adoption in the library community.  It has features which would have made it a good choice but was not selected.  Here are some of the reasons why we selected Hippo CMS.

Commercial Open Source: Hippo CMS is provided by Hippo B.V. as Commercial Open Source.  They maintain the code under a dual license: the community edition is released under the Apache 2.0 license which is great because we can trial and then run in production the fully functional application without committing any financial resources.  On the other hand an enterprise edition is available which provides add-on functionality and additional support services when we need them.  We originally brought the application into production using the community edition.  Once we established that Hippo CMS was working well for us, both for the developers and users, and that it had become a mission critical application we decided to pay for an enterprise edition support contract to help grow our Hippo based services into the future.

Java Enterprise: In thinking about a standard technology stack we realized that we already support Java Enterprise-based software like Fedora Commons and DSpace and in the future Kuali OLE.  Since we needed to build a development team with Java experience anyway we strongly desired to leverage our investment in Java training and hiring.  Hippo is implemented as standard Java Web Applications utilizing Apache Wicket for the CMS and the Spring Framework for the Hippo Site Toolkit (HST).  Apache Maven is utilized for dependency management, building  and for running the local server environment. These mean we can leverage our existing development and support environment with Java, Eclipse, Tomcat, etc.

Folder Based Hierarchy:  Hippo CMS content is stored as documents within a folder heirarchy, with author and editor permissions being configurable and able to apply to a folder and all child folders and content.  This was a firm user requirement for the CMS and the primary factor which knocked Drupal out of contention.  We have some experience implementing this model in our staff intranet using the Node Hierarchy  Drupal module.  However it has been kludgy and difficult to support so we decided that a CMS which natively supported this model would be best. The folder model  for content maintenance empowers (and reduces stress) for our users by providing an environment familiar to them from their desktop experience.

Multi-site, Multi-channel, Multi-lingual: Hippo CMS provides a highly configurable and scalable architecture.  All content is stored as documents (not pages) and the HST mapping system allows that content to be routed and transformed to various domains, websites, published modes (published v preview), and languages.  We use this mechanism to deliver the same content to standard desktop websites and mobile specific websites.  The out-of-the-box support for multi-lingual distribution was important as our Gordon W. Prange Collection website had previously existed in a custom JSP based webapp which was difficult to support and difficult for users to maintain.  Now they can easily maintain the English and Japanese versions of the site.

Development Lifecycle: Our preferred development platform is the developer’s workstation, standardized for us on Mac OS X, and then promote to Test, Assurance, and Production servers running RHEL with Apache Tomcat and Apache http server. The Java Entreprise features mentioned above make this an easy fit for us.  In addition Hippo provides a nice content bootstrap mechanism whereby repository content (documents, assets, and configuration) can be serialized to XML files.  These bootstrap files are used to both rebuild a repository from scratch, done frequently in development, and update an existing repository, as when promoted to server environments.  This also means that content and configuration changes can be included under version control instead of being trapped in the database and requiring manual recreation in each environment through an administrative interface.

Of course any technology has trade-offs and areas which are not as good a fit.  First is that Hippo CMS is not a trivial application and requires a lot of overhead to learn.  Unlike Drupal, Hippo implementation requires a software developer and cannot be accomplished with a less technical staff.  Second is that Hippo CMS is not as widely known and used as other CMSs and therefore we don’t have a very good chance of hiring a developer with previous Hippo experience, so everyone we hire will require the full course of training and lead time before they can begin contributing significantly.  In the same vein, Hippo utilizes the Apache Jackrabbit JCR implementation for its repository, rather than a standard relational database, which means we have a much smaller ecosystem of tools and support available and therefore increased overhead in learning and using the repository.

Despite these drawbacks we did select Hippo CMS.  Work on the new website began immediately in October 2011 and resulted in a soft release of the new home page, Library News blog, and Library Hours in May 2012.  From May until November  we ran the old and new sites in parallel, migrating content, and ending in the complete shutdown of the old site.  Since then we have realized the promise of Hippo CMS by providing a platform for diverse library staff to comfortably create and maintain content and by bringing online new features, such as:

Look for additional features coming in 2014.

About these ads

About Ben Wallberg

Ben Wallberg is the Manager, Software Systems Development and Research at the University of Maryland Libraries. http://lib.umd.edu/dss/software

One comment on “Why Hippo CMS?

  1. I left out some information about hiring developers. Over the years I have rarely seen software developer applicants that come from the Library community, even when posting to the code4lib (http://code4lib.org/) jobs site. The Library community is rich with Drupal/PHP and Python/Django experience but we don’t get those applicants. Instead, the vast majority of applicants are from the Washington, D.C. metropolitan area non-Library community, which is rich with Java developers. So we adapt our supported technologies to match the developers we are able to hire.

Discuss!

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 1,753 other followers

%d bloggers like this: