ICT-KM of the CGIAR

Collaborate, Create, Communicate

Selecting a CMS: how not to get distracted in a potential religious war

Recently, choosing a content management systems (CMS) has become a hot topic among the CGIAR digerati.

Discussions on Sharepoint vs Drupal, Drupal vs WordPress, custom-built solutions vs Joomla are blossoming in online spaces, like flower buds in the warm springtime sun.

We at ICT-KM are frequently asked what CMS we prefer or would recommend. But are we sure we are starting on the right foot or are we getting distracted in a potential religious war?

Drums of war?

As in many decentralised organisations, each CGIAR Center has made its own  Web technology choices over the years. But things are changing recently: there is an emerging trend toward consolidating experiences and coming together on key principles of openness, availability, accessibility and applicability of research and knowledge outputs. Social media have done the rest, by bringing more and more CGIAR teams to the social Web, thus creating a basis of shared experiences. Perhaps, this emerging trend toward stronger coherence is one of the first beneficial effects of the CGIAR reform.

With the CGIAR Research Programs gearing up to start, the multiple facets of online communications – from branding to messages, from social media policies to data repositories – are taking central stage. And this is bringing about plans for new Web sites, revamped Web sites, redesigned Web sites and all the shades in between. And what pops up first? Content management systems!

I have recently been invited to participate in a discussion on the pros and cons of a well-known commercial (e.g. not open source) CMS. I had to decline the invitation. I have direct experience with custom-built applications and mainly WordPress. My hands-on experience with other popular CMSes is superficial. So, sorry, I’m not taking part in a discussion on tools without the proper context on what is needed. The risk of turning a discussion on CMSes into a religious war is always around the corner.

As an information architect, I have been working on content management for almost a decade now and do have some firm methodological standpoints on CMS selection and CM at large. They do not cover the full range of technical, architectural and functional areas a CMS could support, but they have been standing the test of time and technology ( and with the proper shades of grey, they are broadly shared by the ICT-KM team…).

An agnostic approach

When we talk about CMSes, are we running the risk of making choices on beliefs instead of facts? Here are a few points, based on hands-on experience, that have proven their value regardless of specific CM technologies.

#1: go through a learning process

As I commented on Michael’s post on our recent experience with CMS selection, there is no 10-easy-steps-to-CMS. But if you like lists, here is a 6-step learning process for you:
1. clarify your needs;
2. don’t look at features only;
3. don’t believe the hype;
4. get your hands dirty with the solution before making a decision;
5. make provisions for the financial and technical human resources you need to make available to support your decision;
6. go through a prototype-beta-final (or interim) solution to clarify the needs in point 1.

#2: assemble a Web-savvy team

Web publishing is a cross-cutting discipline that requires a lot of Web-specific technical and communication expertise: content development, branding, design, usability, search-engine friendliness rely on and interact with coding standards, URL standards, redirects, browser compatibility, speed, scripting quality. Assembling a Web-savvy team is necessary whatever the size and scope of a site and its supporting CMS. The right mix of skills should be there right from the requirements collection and CMS selection phases: anyway, you’ll get there. Just remember: the sooner the better.

#3: publishing goes beyond pushing the ‘publish’ button

A.k.a. get your priorities right. Usability, search engine friendliness, speed, URL standards, multiple language management (if applicable) are often overlooked in favour of the internal politics involved in the design phase. The Web is not an internal network to gratify egos and a Web site is not a beautiful piece of digital architecture to be admired from afar. Mitigating the internal politics is a tough job, and needs to be managed anyway. So be careful about what you ask staff and managers: e.g. deciding on a 2- or 3-level navigational hierarchy is a designer’s job, not a content owner’s. And please don’t get me started on choice of colour schemes…

#4: give IT what belongs to IT

The IT department should be consulted on the system administration aspects of installing a CMS in-house, security, licensing costs, integration requirements and server performance: these are absolutely important criteria, but only if among others. With due exceptions where they exist, an IT professional profile is not equipped with the Web-savviness to make  decisions on good content development, usable design, effective branding, search engine friendliness. See #2.

#5: multilanguage sites should be born multilanguage

Multilingual Web sites require ad-hoc CM functionalities: the way a CMS manages multiple-language versions in terms of storage, workflow, publishing and serving it to search engines is very important to be evaluated beforehand. Even if a site is started with only one language and will go multilanguage in the future, the CMS should be evaluated on the needed capabilities because these are tough to retrofit. Also the interface design should be able to scale in other languages: French or Italian, for example, have longer words than English, so a horizontal tabbed navigation bar tailored on English words may turn to be too short for other languages.

#6: adoption relies on usability

These three factors can play a significant role in the selection of a CMS:

  • the known or expected frequency of publishing/update,
  • the number of people who will be involved in the publishing workflow and
  • their professional profile.

If it is a small group of frequent publishers, you can rely on something a bit more sophisticated in terms of workflow and backend interface, and invest in proper training that they will not forget because practice will help them learn. If it is a large, diverse group of occasional publishers, you may want to simplify templates and workflow, because infrequent use of the system is no incentive to learn. In this latter case, you can focus on spending resources on editing, cross-linking, optimizing etc. Backend usability should be considered in terms of both interface and process, which publishers will perceive as the same thing. In a nutshell: usability of the backend is a key driver of adoption (and saves energy on documentation, training and helpdesk support).

#7: content migration is a project in the project

Migration is a fierce beast to tame: get ready for manual verification of content (even if you have migrated from a database to another), URL rewriting and redirects to prevent broken links. Actually, here no CMS will help you really, unless you migrate from one simpler to a more sophisticated version of the same one. How to take your content out of a CMS can be an important factor to evaluate, should you need to reassess the CMS choice in the future. Ruthless pruning of out-of-date content helps (whether content is migrated into or out of a CMS).

#8: requirements should be specific

If something worked well in your old site, keep it! If you need to improve many areas, be ready to experiment, revise, redesign and refine (see #1). Only time and practice through iteration and learning will help you define more and more specific requirements for your context.  So you want to think twice about spending all your money on development and configuration and not keeping any for refining content, functionality, design, navigation, search and traffic analysis.

Faith or principles?

What we are facing in the CGIAR now is unprecedented: a broad programmatic approach that will generate a great diversity of knowledge and information types, with a much stronger focus on research themes and results than on institutions and brands.

Before jumping onto any CMS bandwagon, we should be defining the principles that will drive the next phase of the CGIAR on the Web.

What do we know so far? The Web site as a beautiful window on scientific publications is dead; reputation management is done in more places than the newsrooms and the annual reports; conversations are as important as citations.

We have learned a lot and it is perhaps time to formulate the principles of a new, agnostic approach to Web publishing in the CGIAR. So let’s start this game:

  1. stop trying to reinvent the wheel but not go for full standardisation either. Web publishing is a creative process: standardising creativity is an oxymoron;
  2. focus on the content we want people to find, use, react to: this has deep implications on content type definition, workflows, editing, design, search, overall findability and traffic analysis;
  3. make it easy for people to contribute to the wealth of knowledge online and build communities around it;
  4. make our knowledge travel: technical standards, formats, languages, conversations and communities are the enablers of this journey;
  5. be humble: build bit by bit, test, verify, ask for feedback, start again;

What’s your rule of the game?

Photo credits: Pawns by coniferine, Lab by clix, Balance prime by styf22