Insight on Picking a CMS from a Lone Programmer

Insight on Picking a CMS from a Lone Programmer

Introduction

           The choice to go with a new content management system (CMS) was a result of two higher education institutions consolidating into one university.  One college was using Microsoft SharePoint as their web editor, which fit the culture at the institution.  As a smaller institution, there was not a programmer on staff but there was an IT person with web skills.  At the larger institution, there was a programmer on staff along with two other IT people managing the website.  They were using Ektron but reviews from content editors were poor due to difficulty editing content and adding more advanced features.  Administration decided it was a good time to explore other CMS options.

Interview

           The lead on the committee to pick another CMS was the lone programmer of the institution.  Because the web team manages the website, I was referred to Programmer X about choosing the CMS and customizing the website for the library.  The library worked closely with Programmer X to get their site up and running but library staff were only assigned as content editors.  While content editors were a part of user tests, the choice of the CMS was ultimately the decision of the IT department with approval from administration.

           With direction from administration, the criteria for a new CMS was: something that could be rolled out quickly, something that was cheaper or the same price as Ektron, and something that would allow the advanced features and easy editing that content editors were looking for.  It was imperative that there was a small learning curve for both the site administrators and the content editors due to the short timeframe.  As a result of the criteria and looking at other university websites, Programmer X focused on Drupal, OmniUpdate, and Cascade Server as options.

           Drupal was Programmer X’s primary choice since it was Open Source and free to maintain.  Being Open Source, it would allow advanced customization and easy integration with features necessary for specific units, such as the library.  User tests were positive and a proposal to pick Drupal was submitted to administration.  However, it was denied because it would require hiring an additional programmer.  Administration felt it was a better choice to continue to maintain the same infrastructure and staffing with on-going maintenance costs than hiring a new programmer and completely changing the infrastructure to accommodate an Open Source product.

           After Drupal was eliminated, the web team held user tests for OmniUpdate and Cascade Server.  Site administrators felt both were equal in capabilities and user tests showed that reviews of the products were about even.  Programmer X then took both products and began experimenting with creating content in a sandbox environment.  In the end, it took longer to create a basic website in OmniUpdate than in Cascade Server.  Along with other rollout issues, this would make implementing a website using OmniUpdate take longer than the four months the web team had.  Cascade Server was less heavy on programming allowing the rest of the web team to assist Programmer X more with development.  Ultimately, based on recommendations from the committee, administration chose Cascade Server as the CMS for the new university.

           Cascade Server works much better for the web team as well as the content editors.  In fact, Programmer X made the comment several times that he did not miss Ektron at all.  The library was able to institute some Web 2.0 features, such as improved mobile access and an online chat function.  This was possible in large part to the block feature in Cascade Server.  Programmer X stated that this feature alone advanced the website well beyond what they had before.  The web team provided training to content editors at rollout.  The learning curve was so small that within less than a year they were giving advance training to content editors.  However, since most of the web team focused on training content editors, when they returned to site administration on the back side, they had to have refresher training.  Reviews from both content editors and site administrators have been positive.

Reflection

           Working in higher education for ten years, I am used to the bureaucracy that comes with it.  I have worked in an academic library as a student assistant as well as conducted numerous interviews with academic librarians for class.  To me, it always seemed that academic libraries were autonomous, largely allowed to function as they see fit.  I did not expect IT services, specifically web management, to not follow this same pattern.  The library has the ability to propose new technology for better service but, at the end of the day, IT makes the decision.

           Though a part of a larger IT department, the web team maintains a good working relationship with content editors.  They work with content editors to achieve the look and service that they need. I recognize this positive relationship contrasts other experiences from academic libraries.  Connell (2013) states that those libraries that had a seat at the table in the selection of the CMS for their parent institution were far more satisfied with the result than those who had no input (p. 51).  While the library at my institution was not able to choose the CMS, they did have input through user tests and were able to request specific features on their website.  I believe this lends to the more constructive response to the change in CMS, along with the effort to maintain positive working relationships after implementation.

References

Connell, R. (2013). Content management systems: Trends in academic libraries. Information Technology and Libraries, 53(3), 313-321