Content Management Systems use at the UW

I’m working (with lots of wonderful colleagues) on creating a catalog of services offered by UW Technology. Last month I needed to work on publishing the draft content, and that required browsing to the content from a hierarchical list of terms (the categories of services). We had been working in Sharepoint, but people told me that creating a hierarchical content browse is not easy in Sharepoint. I looked around a bit and found that Drupal has native support for what they call “taxonomy”, which looked like it would suit my purposes, and off I went exploring. When I asked a Drupal question on our techsupport list, I was astounded by the number of responses posted back to the list. That got me wondering what people are doing with content management systems at the UW, so I put out a quick survey (using Catalyst WebQ) and posted the notice to several campus lists.

Fifty-four people responded to my survey! That alone speaks to a lot of activity in the CMS world here at the UW. By the number of people who are in the beginning stages of implementation, it’s probably safe to say that widespread use of CMS at the UW is a fairly new phenomenon. While I didn’t specifically ask what factors were driving people towards CMS adoption, several were mentioned: Allowing content providers the ability to enter and edit their own content without knowing HTML; the ability to organize and reorganize content easily; and being able to control look and feel of pages across a site or multiple sites. One person noted that it’s not necessarily easy: “The learning curve has been HUGE for those that arent tech savvy, as well as some of those that are.”

11 people said they’re using multiple CMS. That might speak to the the fact that one system can’t accomplish all of what people want to do, or they’re in the process of switching from one platform to another, or it might just be that different efforts got started on different systems and the same person ended up having to support both resulting sites. One person explained, “We have a home grown cold fusion system that is outdated. We use Movable Type for simple blogging and now have 3 web sites published using Plone.”

The most popular system at the moment is Drupal (16 mentions), followed by Plone (11) and Sharepoint (11), then WordPress and Joomla (5 each) tied with various custom systems.  One of the custom system implementors offers this advice: “This approach is not for the faint-hearted. It has required us also to manage our own servers, something we’d much rather not be doing, but for financial and (at the time)technical reasons was necessary. Also, we are heavily reliant on a single individual’s programming skill, which at times makes me anxious.”

Other systems in use include  Movable Type, Ektron,  Confluence, TextPattern and Alfresco. Five people said they’re using a wiki platform for content management, and one is using Microsoft’s older Content Management Server. 

cms systems in use at UW

Perhaps the most interesting finding is that Drupal users are happier with their choice of CMS than users of other systems. I don’t know what to make of that, but it’s clearly true among this self-selecting sample.

uw-cms-satisfaction003

When asked why they chose their particular system responses ranged from inheriting a previous choice to the availability of specific kinds of features. It appears that different implementations are prioritizing different features. One person said they picked Sharepoint over an alternative platform “…because the document management was more robust, e.g. document check-in/out and version control”, while another said their choice of Plone was influenced by “Fine-grain permission control on content, extensibility and availability of plug-ins…”.

A couple of people stated they had picked Drupal in part because it makes it easy to host multiple sites from the same installation. One said “This CMS lets us host multiple web sites, each with its own theme, without having to install a separate instance of the CMS or its plugins. We have plans for three additional websites, geared for specific department programs, so this will be a help!”

Several people noted they had picked a choice because it was open source, though nobody specifically mentioned wanting to modify core source code – perhaps what really attracted them to open source platforms is that they’re free. 

One person noted they picked Drupal over others because experience with PHP seems easier to come by than other languages such as Python or .NET – but I’d like to know if people really are finding a need to delve into source code language when using any of the CMS systems.

There were a couple of mentions of specific choices being made because they were able to leverage existing IT infrastructure, particularly around authentication, identity management, and roles. One stated “For intranet use a couple key criteria were support for groups/roles and LDAP. Drupal’s LDAP support was less hackish than Mambo at the time; Joomla! may have improved that.”

Several people noted that they picked their choice because of the community around that platform – either other UW departments using it or a large Internet community offering support and modules. Both of those were particularly true of the Drupal users, and to a lesser extent the Plone and Sharepoint respondents. One respondent said “We use Plone because the libraries’ is using it and there is a lot of support at the UW for it. It also seems to have a great user base outside the UW and the project group are committed to improving it and responsive to requests for changes”, while another noted Drupal’s “large, active development community; best of breed modules”.  Some Sharepoint users said they picked Sharepoint because it fit well with the Windows platform use in their unit. One person noted that they really had wanted Sharepoint but their department forced them to choose Plone because it was supported.

I think there’s lots of interesting information here – comments are open, and I hope it’s the start of more discussion. What do you think?

Here are sites that people said were ok to share, grouped by the CMS used:

Drupal

http://www.washington.edu/facilities
http://www.biostat.washington.edu/
http://www.washington.edu/facilities/transportation
http://f2.washington.edu/treasury/riskmgmt/

Plone

http://heal-wa.org
http://www.rad.washington.edu
http://catalyst.washington.edu/

Sharepoint

http://www.foster.washington.edu

Joomla

http://www.washington.edu/alumni/columns/dec07/index.php

WordPress

http://depts.washington.edu/tc/wordpress
http://staff.washington.edu/fmf/

Custom

http://www.pathology.washington.edu
http://dmg.caup.washington.edu
http://www.ischool.washington.edu
http://www.uwnews.org
http://csde.washington.edu

Other

http://mullinslab.microbiol.washington.edu (Movable Type)
http://www.washington.edu/uaa/gateway/advising (Textpattern)
https://moodle.washington.edu (Moodle)
http://hfs.washington.edu (Ektron)

7 thoughts on “Content Management Systems use at the UW”

  1. Thanks for posting the results.

    As a Drupal user, developer/contributer it warms my heart to see people using Drupal 🙂 drupal is a great CMS and application framework

    Like

  2. NetID authentication was my original question to the list that generated responses. To summarize what I heard:

    – There are some UW-specific Drupal install instructions at: http://www.washington.edu/computing/web/publishing/drupal.html

    At the bottom of those instructions it says:

    “If you want to use Pubcookie authentication on your Drupal site, you should use the Webserver authentication plugin.” which lives at:

    http://drupal.org/project/webserver_auth

    There’s also a shibboleth drupal module that a couple of people are using successfully:

    http://drupal.org/project/webserver_auth

    and Dan Druliner sent some instructions for using the PubCookie drupal module, which you should be able to find on the techsupport mail list archive.

    http://drupal.org/project/pubcookie

    Does that help?

    Like

    1. Many Drupal modules can (and should) be configured to require a login to post COMMENTS, submit WEBFORMS etc. These modules typically send logins to Drupal’s user/login page.

      If you’re using the PUBCOOKIE module for authentication, you can redirect users to the pubcookie module instead by adding the following to Drupal’s .htaccess file:

      # Redirect logins to pubcookie
      RewriteEngine on
      RewriteRule ^user/login.*$ login/pc [NC,L]

      This assumes you’re using pubcookie’s default “login” setting for the login directory.

      Like

Leave a comment