During our all-campus sessions earlier this year, you heard me mention that we were investigating alternative web architectures to the current WordPress setup. I also know that many folks around campus want to know why.
WordPress is hugely popular. It is a PHP web application that was originally created as a blog engine, a fast way for people to publish pages about a particular topic. A blog, as websites go, has a unique structure. There are usually a few informational pages and a multitude of one-off posts about a variety of subjects. In order to facilitate content exploration, blogs added the ability to group blog posts by author, date, category and tag/keyword. Categories are usually high-level groupings that seldom change while tags are quite dynamic. The dynamic nature of tags lead to the creation of tag clouds, a user interface element that increases a tag’s font size based on its popularity (whereby more popular tags are larger than less popular ones). These elements typically live in a sidebar, often on the righthand side of the page, along with a site search input and a link to archives.
A Blog by any Other Name
As a blog engine, WordPress is hard to beat. Due to its popularity and lack of licensing fees, though, many site owners have conscripted WordPress to serve as a content management system for traditional websites. The larger and more complicated the site, the more finicky WordPress becomes to manage. Missing core functionality is handled with plug-ins. There are loads of excellent plug-ins in the WordPress marketplace. There are also loads of stinkers. We end up spending a fair amount of funds on plug-in fees and specialized hosting to keep our (free) WordPress sites running well.
Other universities use WordPress. They also tend to parse their network of sites out into lots of smaller sites. This keeps the page counts smaller and avoids the need for cascading user permissions, for the most part, but creates other problems with search engine optimization (SEO) and user experience (UX). In general, we are moving to consolidate smaller sites into larger ones. Managing user accounts is a pain point. So is plug-in maintenance, as well as dealing with cascading user permissions and workflow. In the end, for our marquis sites, WordPress has become cumbersome for my team to support.
We began our search with a feature matrix and a list of the biggest vendors in the CMS market for higher education. We talked to our peers. We read industry blogs and attended webcasts. We read white papers. And we refined our list of candidates to our top three: Hannon-Hill’s Cascade, OmniUpdate’s OU Campus and Terminal Four’s T4. Each vendor made multiple demonstrations of their tool and allowed us to ask lots of questions about features, training and support. We then narrowed the field to our top two and proceeded with several technical review sessions where we could see how each product worked behind the scenes.
In the end, we selected OmniUpdate as our CMS.
People like the user-friendliness of WordPress and have concerns about a successor tool being less so. OmniUpdate is user-friendly. In fact, the majority of content is editing using in-context tools which basically combine a preview feature with editing tools. You can see a preview of this in action here:
OmniUpdate created their CMS specifically for higher education back in 2001. They have compiled a very large roster of our peer institutions and are committed to ensuring our long-term success. In addition to some sneak preview events where we’ll have various campus community members sit in on some CMS demonstrations, OmniUpdate offers weekly training sessions for new users, as well as monthly developer Q&A sessions for folks who are interested in custom development. The Web Office will also conduct hands-on training sessions with each project team as sites are migrated over to the new platform during Phases 2 and 3.