Updated 16 December, 2010
While my colleagues in IT are reading this post and, with mouths agape, thinking “WHAT, you giving a plug to Open Source CMS?”,  I still remain a hardcore champion of Enterprise Content Management (ECM) to suit the right needs and when the right resources and commitment are in place.  And so begins my plug for what I found to be a robust, scalable, usable and well-engineered Open Source CMS – WordPress.

Blogs and Wikis have revolutionized Web publishing, paving the way for wider adoption of their publishing tools and instilling simple publishing processes, hence changing the culture in organizations.

The problem is, when faced with the to CMS or not to CMS conundrum, IT managers are presented with the whole gamut of information management solutions (Web, document, digital asset, and so on), all of which promise Content Management. Just take a look at this “list of notable content management systems that are used to organize and facilitate collaborative content creation”, and you will see a variety of Open Source and proprietary solutions, supported technologies, portals, frameworks, and blogging platforms, as well as licensing models.

To quote my good friend and colleague in IT management, Tobias Carlander of World Food Programme, when evaluating and choosing solutions, “there is no silver bullet”.  Large organizations, both international public and private companies, often struggle with choosing information systems which can be a part of a heterogeneous IT landscape.  And so when evaluating IT solutions, IT managers must consider interoperability, sustainability, and alignment to strategic information and content management objectives among the highest priorities.

Why CMS

The release of the CGIAR Ongoing Research Web site is the result of an effort to both enrich and expand the exchange and reuse of the CGIAR agricultural project information, as well as support new views of agricultural research, as the new CGIAR research agenda unfolds and is put into action.

This effort required migrating the Ongoing Research Web site and editorial system from a Web application framework to a proper CMS in order to:

1. provide scalability and sustainability for the future development/expansion of the system, even with regard to where it is hosted;
2. improve user experience, for both visitors of the Web site and those who contribute to it;
   
   Notes about usability:
   A usable Web site depends greatly on the efficiency of the Web site’s User Interface Structure [User Interface Structure – Web, Human Factors International] and therefore is not directly related to the choice of CMS, rather to how it is planned and implemented.  However, I certainly believe that a CMS can facilitate the implementation of a well-designed User Interface Structure by separating content from design/presentation (i.e., themes).
   

   Customized Editorial Interface: Catalogue Browse/Search

   A usable editorial interface (in our case, one where scientists and researchers voluntarily provide project information) can be greatly aided by a usable CMS.  Why? Because when customizing/extending beyond the basic blog or Web site, developers can take advantage of libraries and methodologies already in the CMS to deliver usable interfaces to extended functionalities.  Here is a good example of a usability testing report done on WordPress 2.7′s Administration (editorial) Interface.

3. facilitate the reuse and syndication of content;
4. better define the publication process (draft and preview of content, workflow);
5. better manage users and roles, controlled taxonomies and master lists.

A Pragmatic Approach

After reading the latest literature on Open Source CMS and having consultations with Open Source CMS experts (thank you to Peter Casier of WFP and mastermind behind Blog Tips) and colleagues, I evaluated and investigated the core of three Open Source Content Management Systems (Drupal version 6.17, WordPress version 3.0, and Plone version 3.3.5) by downloading, installing, and configuring the systems.  I looked at each system’s core CMS functions (e.g., managing content and metadata and delivering it on a Web site).

The Selection

All three systems were easy to install and set-up as a basic CMS.

While Plone is quite beautiful from the pure developer point of view (I will not compare apples and oranges, that is general-purpose languages like java and python to server-side scripting languages like php), it does not really fit our express need to have a multitude of hosting options.  Also, Plone appears to be a framework in which one must build or attempt to install combinations of modules and other frameworks for developing the system beyond the basic hierarchical Web site.  Also, developing the system beyond the very basics requires a much higher skilled programmer.  It is quite similar to the implementation of a portal to manage Web content.  It should be mentioned that since my evaluation, Plone 4.0 was released and promises many new and important CMS functionalities.

There are no great differences between WordPress and Drupal with regards to hosting and scalability.  But when it comes to user experience, out of the box, WordPress wins hands down.  Note that Drupal 7 should correct and/or improve upon many of its challenges with usability.

After the initial evaluation of Drupal and WordPress, in order to make a final decision, I put the systems to the test by putting on my developer hat and building a few of the required functionalities (a migration data loader, invitations to contribute to the system, multi-authorship of projects, and querying projects for display in the interactive map interface).

The Final Evaluation

Development

• WordPress: custom plugins and modules are widely available and easily developed and deployed; APIs are offered and promote compatibility; it has a large community of both core and contributing developers;
• Drupal: is developer friendly, but modules must be built ground up (vertically) and most time require dedicated development resources for obtaining an end-product;  vertical development in this fashion many times means that extending an information object (say for a future enhancement) would require developing at the core, creating a need for re-integration and consequently promoting a higher rate of bugs and incompatibility issues.

Maintenance

• WordPress: upgrading the core is simple and safe (you always should back-up); updating/upgrading plugins and modules is simple;
• Drupal: upgrading the core is quite a chore and many report that it requires clean installation then a subsequent migration; upgrading plugins or the core can cause instability, as there is no compatibility verification between the core or the APIs that the core exposes.

Hosting

Both have a large number of hosting providers to choose from (Dreamhost, GoDaddy, Host Gator).

Implementation

With the advent of version 3, WordPress can no longer be considered just a blogging platform. Version 3 improves on or adds several important CMS functionalities: custom post types (which should be called custom content types), custom taxonomies, and custom menu management. Add this to a system which provides a solid user-centered editorial interface and has the concept of Web publication at its core, and you have the recipe for a sound solution.

I developed the entire back-end and non-visual design front-end customizations of our WordPress CMS to satisfy requirements of the system.  This involved migrating content and users from the old system, extending taxonomies by linking them to master data, configuring custom content types, creating new user roles, making information required for publication, making master lists browsable and searchable in the editorial interface, and much more.

I used several plugins from the WordPress community of developers to extend roles and permissions.  I also developed two custom plugins to implement business rules for email notifications, required fields, Google Maps and Charts integration, and managing and linking to master data.

I only found one core issue with the system, which I reported on WordPress’ issues tracking system, and to my amazement a few hours later, WordPress core developer Andrew Nacin responded and had a patch ready for testing: they are serious, too.

WordPress vs. Drupal… really?

The problem with WordPress vs. Drupal is that the literature you read comparing the two can be misleading and quickly outdated.  So be careful when you read “The best solution is…”, and WordPress is good for blogs and simple sites but Drupal is good for complex Web sites, etc.  Technically, either of the two would have been able to fulfill our requirements.

My final thoughts on choosing an Open Source CMS:

Did I make the right choice? Have you recently selected or evaluated a CMS, or are you planning to do so?  Please share your experiences and comments below!

The CGIAR Ongoing Research system is a practical example of how we apply the Enterprise 2.0 and  collaboration principles to the CGIAR’s core work: research. The way the system was designed, the technologies we selected to implement it, the collaboration process with the Regional Plan for Collective Action, all tell a story of how the Program has chosen to innovate the way to connect, share and collaborate online.

I was first given the challenge of opening the doors to Ongoing Research in late 2008 with the Eastern and Southern Africa (ESA) map, a proof-of-concept prototype using Google Maps and Data APIs.

My goals in designing the ESA system were to: facilitate the contribution of information regarding ongoing research in Africa, expose this information to a broad public, and link the information to that which is published in CGMap project plans (MTPs).

In a nutshell, adhere to ICT-KM’s Triple A Framework.

So for all of 2009, the ESA Prototype Map was launched as a catalyst for meeting these goals, as well as to prove the concept that project leaders and researchers throughout the CGIAR are eager to connect and give visibility to their work.  We had a great response from scientists and researchers who found that contributing to the map was easy and time-effective.   The Google Map interface was well appreciated for navigating projects by country.  A survey was performed which asked researchers about the usefulness of the prototype map, and again the results were quite good and verified that the Who is doing What, Where and with Whom is paramount.

Surveys and feedback also highlighted the need to go beyond the prototype, with extended roles for contribution, site search and several analysis features.  But where should this information “live”, and how should it be managed?  Could we and should we use one of our existing systems or frameworks?

In the latter half of 2009 I assessed various possibilities of integration with our systems, but I finally decided on an Open Source solution.  Coming from a solid corporate (banking) background, it felt almost wrong to choose Open Source, but I must say that the choice of Linux, MySQL (Sun Microsystems, now Oracle), and Symfony, an open-source Web application framework, was a perfect fit for the technical requirements and budget.  I was already familiar with Linux, having worked solely on Unix-based systems in the corporate world.  Also Sun’s products have always been a part of my foundations in technology.  Google Maps (the Google Maps API) has been a fundamental component in CGMap, opening access to research project factsheets.  The Google Maps API allows using maps within Web applications, providing a vast set of customizable geo-features.

The introduction of these technologies was not the only innovation in this project.  We used Agile software development, a group of software development methodologies which uses iterative development to allow requirements and development to constantly evolve.  This catered to the need to express requirements  and changes while the system was being built.

To talk more about Symfony and Agile software development, let me introduce you to Jacopo Romei, Agile development coach and specialist in open standards and open source.  Jacopo developed the recently launched Ongoing Research Web application.

Before handing over to Jacopo, I want to say that working with Jacopo on this project was a great pleasure, and he proved to be passionate not only about building for the need, but also about understanding the need.

Over to you Jacopo …

“Thanks Michael.

First I’d like to clarify what the whole point is in using an agile methodology. Put in simple words it’s all about turning changes into opportunities. The traditional approach to software development aims to ossify requirements until the next release, exposing the project to becoming unfit for the context it’s released into at the end of the development cycle. While we are used to say requirements should reflect market I strongly believe we should stick to a far better motto: requirements are the current market.

Obviously it doesn’t come for free, but the agile development community spent the last 15 years minimizing the cost of change and then, most importantly, removing the fear of change.

The prototyping phase of the ESA map and the rich analysis it brought with it was a goldmine that allowed us to start developing a system close to users’ needs. Of course, we also wanted to make sure we could face a change in requirements or an emergent and previously overlooked aspect of the design.

Symfony granted us enough modularity to break the project into low-coupling, high-coesion modules to develop a full rewrite of the prototype on top of MySQL. It also made room for one of the pillars of agile development: feedback. We adopted a full and continuous quality approach. With its full fledged automated tests library, Symfony provided the perfect environment to write a complete suite of automatic tests to keep the bug rate low and regressions rare. Every change in the code was locked in a cage of executable tests providing us with relentless feedback on the quality of our code letting us focus on real productivity – ever thought about debugging as a completely non-productive activity?

Even more important tests acted as a solid reference to drive development when requirements changed. Yes, requirements changed along the road. Once again. Even after having spent months on a prototype. Even with close-to-perfection sharing of project goals among all stakeholders.

Agile development methodology helps teams to embrace change to the point that the design phase is diluted over the activity and changing requirements is never a showstopper.

We split the development cycle into 12 very short iterations (each was 5 workdays long). Each iteration was meant to share results among developers, usability experts, information architects and project managers. We met the goal of releasing a working-bug-free though not-complete-yet system at the end of each iteration.

I paid most of my attention to keeping communication fluent between me, Michael and Antonella to reduce the risk of unexpected outcomes on both sides. We expressed user requirements in a very fine-grained way, called user stories, expressing software features from the user point of view, hiding any technical detail not useful to express the final user experience. Those small deliverables were the meeting point among all of us throughout the iterations, so we were all up to speed with what had been done and what was left to do.

Eventually, we met our common goal within the initially planned 12 iterations with just one extra day. Over the first week from the beta release of Ongoing Research, the user community reported only one serious bug. The system is working and keeps growing with an increasing collection of CGIAR projects that contributors create, manage and maintain.

Agile methodology is a way to drive software development if you already believe in values like communication, feedback, simplicity and respect. Removing the fear of change is a key aspect too. Everything was possible here at ICT-KM, since we just let those values drive decisions, day by day, face to face. Even through a Skype call! ”

The goal of CGMap is to make CGIAR research projects fully accessible and available.  So we’ve continued ‘pedaling’ towards this fundamental goal in order to open new paths to accessing our research project factsheets.

The key to systematically making information available and exchangeable is what we call Syntactic Interoperability, the underlying concept behind RSS feeds, SQL databases, and Web Services.  CGMap is no stranger to interoperability, as it was born to receive data via XML from a completely different system.

Today, we are releasing a new version of CGMap, CGMap 2.0, that completely opens the access to new and improved project factsheets, giving donors, researchers, partners, and search engines, as well as systems and Web sites catering to them, direct access to CGIAR research projects.




In this release:

• Sitemaps:  Search engines can use our sitemaps to index research project factsheets; systems and Web sites can use the sitemaps to list and link to factsheets as applicable (for example, by CGIAR Center/Challenge Program, time period, project code);
• Improved project factsheets:  The new factsheets provide details of the planned outputs of the project, thereby providing a clear window into the ‘What, Where, and When’ details of the research. The factsheets have a simpler visualization of the project Overview and Rationale, Outputs, and Financial Tables, so that navigating or printing a project factsheet is much easier. Also, the factsheets can be bookmarked and directly linked to, so any applicable circumstance is possible (for example, a link from a Center/Challenge Program’s Web site, a bookmark in a researcher’s browser, or a link from a partner’s project Web page).

So don’t be surprised if you are searching the Web for, say, chickpea research in India, and you find the factsheet ICRISAT-6: Producing more and better food at lower cost from staple open-pollinated cereals and legumes in the Asian SAT (sorghum, pigeonpea, chickpea and groundnut) through genetic improvements.

The CGMap team is gearing up for the release of research plans to the world via KML, the Open Geospatial Consortium international standard for the geographic annotation and visualization in earth browsers, mobile maps, and Web-based maps. CGMap is the epitome of ICT-KM’s ‘Triple A’ approach, and once CGMap lands on the Web’s engines through KML, the project plans in CGMap will have an even greater Accessibility and Applicability potential.

Search engines will now have geographic coordinates of the who, what, and where of CGIAR research. This means that searching for ‘maize and wheat genetic research’ will give results on CIMMYT projects, along side other relevant sources, like FAO.

Scientists, researchers and beyond … investors, partners … who use tools like Google Earth to study and plan activities will be able to build scenarios which provide a more intelligent context to their research. For example, a researcher using an earth browser to plan maize and wheat genetic research activities will be able to focus on any geographical region/location, search for maize and wheat genetic research, see results, add layers of required data (e.g: the Köppen climate classification), and save the scenario built on the fly.

Who is doing What and Where in the CGIAR?

From my first day with the ICT-KM Program, this has been an underlying question and driving force in most of my work with the Program. CGMap, launched in late 2008, is the CGIAR’s prime source of MTPs, the Medium Term Plans in which CG Centers and Challenge Programs express both their strategy and coherence to the CGIAR objectives and priorities.

Recent posts on the Social Media Tools Series have shed light on how social media tools provide researchers a more effective landscape for the collaboration and dissemination of research information. Exploiting research projects geographically will give rise to sharing and collaborating by using CGMap’s existing resources, the CGIAR project plans (who is doing what and where).

Stay tuned for future landings on maps and earth browsers of the CGIAR’s Ongoing Research: Focus on Africa (a.k.a. Eastern and Southern Africa – ESA).

Read on for a rare glimpse into the workings of the CGMap application. Although this article is a little technical, we’ve tried to keep it as simple as possible, in the hope that it will guide you towards a better understanding of what goes on in CGMap’s navigation room.

Putting Research on the Map: Pushing the Envelope of Google Data APIs

Increasing the impact of agricultural research is a shared interest of the CGIAR Centers and their partners.  In 2007 and 2008, the CGIAR’s Regional Plan for Collective Action surveyed and collected information from the Centers and their partners on research projects being carried out in Eastern and Southern Africa (ESA), a key geographical region for agricultural research.

In 2008, the Regional Plan for Collective Action and the ICT-KM Program joined forces to realize the next natural step for the Plan: putting active research projects in ESA on the Map.

The ICT-KM Program promotes initiatives that accelerate the CGIAR’s efforts to generate, safeguard and share knowledge in new ways.  In fact, the Program’s 2008 launch of CGMap revolutionized the access to and the analysis of CGIAR Medium Term Plans (MTPs) and their related data (financial, geographic, topic) across CGIAR Centers and Challenge Programs.

Beyond Boundaries: Google Data to a Database and Records Management System

CGMap established the precedent for the contribution and diffusion of CGIAR research.  At the ICT-KM Program, our challenge with ESA was to deliver a cost-effective, quick-to-market system to facilitate the contribution of the ESA research projects from 2009 and beyond, and put them on the map.

We’d already had vast experience with the Google Apps Case Study, a joint initiative with the CGIAR IT Managers, as well as Google Maps and Google Search on CGMap.  As such, we were aware that the Google Data APIs provide simple, standard syndication protocols for reading and writing data/information/content.

However, the Google Data APIs, particularly the service-specific Google Spreadsheet API with Forms, do not provide relational databases.  Nonetheless, after a brief study of the application’s documentation, we knew that we could make a simple and technology-neutral system with relational data for both contributing and mapping the research projects.

How we did it

Defining Data Records We identified and defined the information to be captured, as well as the record classification for identifying unique records and tracking the latest revisions.We then created a spreadsheet in Google Docs, with the first sheet containing the required information structure.Our model can store records and the history of records. As such, a complete revision history is always stored in the system.
Defining the Data Elements A second sheet was created to hold a definition of the data elements stored in the data records sheet.  The following elements were defined: text, check lists, select lists, and data fields.  We also defined ‘system’ configuration fields for logical/automated fields.This data element definition sheet allows us to identify aspects of the data, such as, “is the field required?”,  ”in what order should the data appear?”, or “does the information stored in the field come from an external source, and if so, which one?”.For example, the Countries field is: required checklist and the values are stored and defined in a separate source (a controlled list)
Defining Controlled Lists In a separate spreadsheet, we defined sheets to contain controlled lists for Countries (with geo-center point latitude and longitude, ISO and UN codes), CGIAR Centers, Partner Types, MTP Projects Lists (from CGMap with the CGIAR Center acronym), CGIAR Regions, as well as a sub-list of African Countries.
Providing a Simple Interface to Contribute Data Building on the contribution mechanism provided by CGMap and taking advantage of Google Data APIs, we built an HTML form using the Google JavaScript libraries (JSAPI) to access the data record element definition (see Defining the Data Elements above). This rich and interactive form is presented to the contributor with all the required fields and values based on the data record element definition. We take advantage of the Google Data APIs’ mashup components to utilize the Yahoo Interface Libraries (for calendar date selectors) and our own custom scripts for checking the integrity of the information provided by the contributor.Saving the record submits the information, via the Google Spreadsheets Forms API, to the data record spreadsheet.
Putting the Research on the Map Again, we took advantage of CGMap’s ability to navigate research projects via a map interface.A map is built using the Google Maps API, then we query the data records to obtain the latest records’ country field, which contains ISO Alpha-3 country codes.  The center point of each country with a record is plotted with a map marker by looking up the country’s coordinates in the Countries controlled list spreadsheet.When clicked, the map marker opens an embedded page (the project list bubble).  This page recognizes the currently open country map marker, and then queries the data records for those projects in that country.The project list bubble displays the project title with a link to display the data record as a fact sheet.  It also utilizes the Google Charts API to build a contextual map that provides a geographic visual overview of the project.The fact sheet queries the data records for all fields in the requested record.  A larger contextual map is then displayed, and based on the record elements definition, each field is displayed in the sheet.  When a record contains MTP project relationship data, the Google Search API is utilized to search CGMap to display relevant links to CGMap Project Factsheets.

Take a peek at the ESA Research Maps!