Ruth Kneale, whom I’d met previously at the LSW meetup and one of the dinearounds, was one of the presenters. The other two, Amy Radermacher and May Chang, are university librarians at Concordia University and the University of Maryland respectively.
Ruth’s presentation (which she will post) was called “From Static to Dynamic: Choosing and Implementing a CMS.” She quickly went through the definition of a CMS, and explained why it was needed for her institution:
- To avoid one person being the sole person who can administer and edit a site (bottleneck)
- Ease of administration
- Increasing team collaboration
- Improving functionality
- Improved website presentation (standard look-and-feel across site)
Her starting point was that they had no money (which made open-source the way to go) and any solution had to be LAMP (Linux, Apache, MySQL and PHP).
Must-haves:
- Audit trail
- Content approval
- WYSIWYG editor
- Granular privileges
- Friendly URLs
- Versioning
- Content resue
- CGI support
Should-haves:
- Sandbox
- Online administration
- Inline administration (administration from within the page being edited)
- Mass uploading
- Site map/index
Nice-to-haves
- Contact management
- Drag-and-drop
- Photo gallery
- Events
- Calendar
- Web statistics
Her first decision was whether to go with a content management system or a wiki. Sources she used to help make her decision:
She narrowed the field down to 9 Web content management systems and 9 wikis, and created a frighteningly-detailed comparison spreadsheet. Reasons for excluding candidates:
- Missing functionality (in some cases, missing functionality that was claimed to exist)
- Hidden costs (e.g., charging based on the number of viewers of content)
- Currency of support
- Required database underpinnings
- Ease of installation (or lack of same)
- Ease of use (or lack of same)
- Evaluation on OpenSourceCMS.com
The candidate evaluations included local evaluations including user feedback, and resulted in a final field of Drupal, MediaWIki, TWiki and WebGUI.
Local users created and edited content and gave feedback. They really wanted a familiar look-and-feel, as well as some terminology changes. Wikis were seen as too much work.
Ruth’s next steps are to expand functionality, import the existing site (which is apparently a painful manual process), training more staff on how to use the CMS (again, the bottleneck thing) and migrating everything to a new server by 2008. The whole evaluation process is documented on her blog, and she’s going to put up her presentation on SlideShare.
Amy and May presented on quick succession, and in contrast to Ruth they were not initially involved in the selection of a CMS. As an aside, I loved this, and wish more panels were group panels with people discussing their different experiences.
Amy’s goals were to have a more uniform website, to improve ease of use for multiple non-technical users and to increase the number of editors while maintaining design consistency. The IT department, which led the CMS implementation, did not realize how dynamic the library’s website was compared to other university sites (always changing, growing, adding tools).
She had issues with access to source code and control over the design, links (All the university’s links were dumped into a single folder, which made library website performance slow and hurt findability), the site structure and the pace of testing and development (deploy times were automated, needed permission to test).
However, the outcome was improved campus communication, especially once IT saw all the problems, and the library is now involved with the implementation of the university portal.
May’s story was similar - the library has to go through campus IT for development, but is generally involved except for the implementation of a CMS. The University Relations Office saw the content management system as a marketing tool, whereas the library and other units saw it as a service point. The key success factors May saw, as someone who’d been involved with multiple implementations in multiple places, were:
- Early involvement in CMS evaluation, selection and implementation and user feedback
- Negotiating flexibility
- Developing in-house expertise
- Communication
- Being clear about the drivers of a CMS
One point she made was that you’re not limited to using a Big Name package like Collage, Joomla or Mambo. You can work with file directories, XHTML, CSS and includes and roll your own.
I really enjoyed this session, and not just because Ruth bribed us all with candy. The speakers were engaging and honest, did not simply read from their notes and had a good back-and-forth with the audience (which included someone who apparently had strong opinions on Joomla).
Technorati Tags: il2007