If we adopt a CMS, what else should we have in place before choosing one, assuming we should have one at all? What kind of problems will it not solve for us? I am with a small private college (under a thousand students) with limited human and financial resources. Most of our staff and faculty are 50ish, and not Web-savvy.
Our current website is built and maintained in the traditional way with Dreamweaver. We want to empower people to create their own content, and I wonder if there is some way other than a CMS so that they can have the basic necessary permissions to do so.
I'd love to hear from anyone who has been through this decision making process or could point me in the direction of how to find out more about how to create such a process.
We went with OU Campus from OmniUpdate. And Yes it has solved many of our Contribute problems. There is no extra software for publishers to purchase and IT to install and/or maintain. It offers some additional tools that Contribute didn't offer (like a link checker and site wide search and replace).
We just launched it a few months ago so obviously we don't know everything about it and there have been a few bumps along the way (there's no such thing as a smooth migration) but overall we are pleased with it.
I'm going to crash the Michael party. I'm in this exact situation. Our site is managed via Dreamweaver on the developer end, and Contribute on the user end. The entire site is several thousand pages large by now, but we're surviving because we've written dozens of what I call "mini" CMS web apps in house to handle various content issues. For example, we've got web apps to manage news and calendars, faculty profiles, academic programs and catalog info, various forms and applications, etc.
But there are still many, many static pages out there. We require at least one person in each department that has a website to use Contribute to manage these static pages. They take a training class that I teach before getting access. I will say that Contribute comes with a number of headaches, but since we implemented the Contribute Publishing Server 6 months ago things have become a little easier (certainly not pain free though - the client app is very quirky and the whole system can be unstable at times. This is definitely not a product Adobe cares about too much).
So I've been in the process of evaluating CMS's for over a year. I haven't seen anything yet that knocks my socks off, but I know we'll need to transition at some point. Using Wordpress on a small scale has been a good experience and we've become adept at customizing and extending it as needed. But for a campus-wide CMS, since I know almost everything out there will offer the basic mechanics of editing pages, I'm mostly concerned about usability for the sake of our users - and this is where most CMS's fall down. Overly complex and not intuitive. Major training required. I'd kill for a CMS designed by Apple (no, not iWeb). So many enterprise software makers seem to forget to hire interface designers (*cough* Blackboard *cough* but that's another rant entirely).
A CMS will not be a silver bullet for content strategy. Whether you have a static site or a CMS, you still have to deal with process, workflow, accountability, policy, training, etc. Some bells and whistles like flagging pages older than a month for review are nice. But overall, I'm definitely not looking forward to the process of converting our site from static to CMS. That's going to be a major project, and of course my project whiteboard always tends to be full. What we'll likely end up doing is moving to a CMS one department at a time, chipping away at it for a year or two. And I'm going to propose that we actually start pruning the site, removing as many pages as possible before starting. There's a lot of old clutter floating around.
Thanks for crashing the Michael party and for a really articulate review of this whole process. I think we will also approach the transition to a CMS one department at a time. And I imagine that, for us, content strategy will be harder to grasp than choosing a CMS or other technical issues.
Some in this thread are sold on particular CMS solutions. Have you found any that didn't "fall down" in the area of user friendliness?
I also would like to know if you build your own web apps or are using third-party ones; I would love to have something like that for catalog information. I have been using regular expressions for this purpose, but I'm not good enough at Grep to write really good ones.
Managing the content on 900 web pages is not a small task, and a CMS will most definitely help you (more importantly, it will help your departments) to keep the content on your institution's website accurate and up-to-date. The important thing to consider in this discussion is "whose content is it anyway?"
It's the individual departments' (academic or operational) content, and there isn't any need to modify anyone's job description for them to keep their own information up-to-date. After all, when they distribute a flyer about a departmental event or meeting, or write an email message to send to a particular list of recipients about something they are doing, there is truly no difference between that function, and the function of posting that same information (that they are creating anyway) on the institution's website.
I have dozens of departments (mostly administrative and clerical support personnel - non-techies) editing, creating and maintaining content on their areas' website, and they feel empowered and proud of their contribution by using the CMS to 'get it out there' for students, faculty, staff and the public.
The most important factor in 'choosing' a CMS is - will my users actually 'use' it?...or, will they feel overwhelmed by the technical nature of the 'web posting' task before them, and forward the request over to you for completion (which won't improve your situation at all). I am happy to report that our selection of a CMS has been universally adopted and I don't have to re-train the "once-per-semester/year" users, because our solution is so easy to use.
We've used several CMS products (open source, locally-hosted and remotely-hosted), and through that entire process, I ultimately decided to put my recommendation behind the OmniUpdate OU Campus CMS.
As a one-man-web-shop, I could no longer provide reasonable turn-around times on web requests from the institution, and a CMS provided a streamlined, workflow-controlled, permission-based environment in which I could provide individuals with the ability to manage their content, without turning them loose to wreak havoc on the branding, accessibility and usability of the website.
The intuitive and simple editing processes that are in place in OmniUpdate's OU Campus provide users with a very simple interface to use, yet the system is enterprise-ready in its ability to scale to your environment, and flexible in its ability to provide both you (as the web admin) and your users a straightforward method of managing your content just about regardless of where it is hosted, or on which platform. I've even spoken with colleagues who are using OmniUpdate's OU Campus CMS to manage content within their own vendor-provided portal environments, because it does so in a much easier and more powerful way than that which is provided within those environments.
Please feel free to contact me if you have any questions about our nearly 5-year old OmniUpdate implementation, and about how I will never consider another CMS ever again.
I have to respectfully disagree with some of what you said, in practice if not in principle:
It's the individual departments' (academic or operational) content, and there isn't any need to modify anyone's job description for them to keep their own information up-to-date.
I guess that depends on each individual college. What's really important here is that ownership of information does not fall neatly on departmental boundaries. Take financial aid content, for example. Most colleges have a Financial Aid department, but content related to financial aid appears everywhere from Enrollment/Admissions to Bursar to individual program offerings. In order to maintain consistency of message on all these different pages, it's really important that someone be directly responsible for maintaining that consistency, regardless of where it resides on the site.
CMSs can provide good ways to make this easier, but if it's not in someone's explicit responsibilities it's too easy for each person to assume the next one is taking care of it. And you're lucky if a prospective student calls to ask why information is inconsistent instead of just moving on to the next site.
That's a good point that you make, and maybe I'm fortunate to work with a group of people who are anxious to ensure that their information is accessible, up-to-date and accurate, and who are willing to put forth the effort to manage their department's web content.
From a basic operational and functional perspective, if an administrative support person is responsible for providing clerical support for that department (including distributing information related to that department's function to campus constituencies), then editing that department's web content is simply a natural extension of the scope of their job description.
The way that I have provided an overview of the function of a Web CMS to my colleagues in academic and operational department administrative support roles is to explain to them that the college website is simply another method of communication available to their department to help them get the word out to potentially-interested parties. I have also told them that, due to the fact that I am not the creator or curator of information about what they are doing in their area, it doesn't make any sense (operationally) for me to be 'creating' information about 'their' department, especially when they are already doing that on a daily basis.
When I have explained that fact to the administrators, deans and other managers of those areas, they have - in almost every case - agreed that use of the Web CMS to assist them in informing their constituencies about their department and its functions on the campus is definitely within their scope of responsibility from an operational standpoint, and it is typically at that time that they assign one of their administrative support personnel (or even a student worker) to be the custodian of their web content from that point going forward.
I have to ditto Justin's posts. We are a small campus and until recently I was the primary web person - meaning that departments would send me web content changes and complain because it took so long for me to implement those changes. We decided to go to the distributed ownership model, select and implement a CMS, split out our content into an intranet and Internet, do a complete redesign, and edit a lot of content from the previous website while we were at it. It was a huge project. I would not do it again that way, BUT eventually we were left with an external website that was much more manageable. We do suffer from the change in culture where each department is responsible for keeping their content up to date. We have early adopters and resistors - and I could name each person who would fall into both categories, way before we went live with the new site!
I still assist departments with posting occasional content. I make recommendations about how the department's web section should be organized. I create and maintain all our user accounts and do the training. But the CMS we chose (also OmniUpdate's OUCampus) is very user-friendly. Most of our users catch on quickly and only occasionally ask for referesher training. Sometimes our web-savvy users find ways around our style guide and I have to reign them in and ask that they remove the purple font, animated gifs, etc. But I had that issue before we went to a CMS solution.Now, two years after implementation, I find my role shifting from that of content poster to offering best practice ideas to departments. I'll be glad to communicate my experience with you privately if you'd like.
It sounds like your approach in CMS implementation was reasonable, but you said you would not do it again that way. What would you do differently?
If you haven't already, audit your content. If you are able to migrate any of it it a CMS it will be a good chance to clean up your site. I forget the final numbers but we had something like 80,000 pages and less than 25% of them were being linked to. There was a lot of old content, test pages and, in some cases, people using the web server for file storage.
We have a decentralized model and that presented a few extra headaches during the migration. Not all publishers are created equal so some pages had badly formed titles, headers, missing alt tags, html in the metadata, etc. When we tried to import them into a CMS that likes good, well formed code we got more than a few problems.
We have a webteam of two but thankfully for the first week or so after we launched we were able to "draft" a few of our more web savy staff to help so were we able to get the top level pages and sections up and going quickly.
So my top advice would be...
1) If you migrate, use it as a chance to audit your content and trim the fat
2) Have some people you can call on for extra help. There are only so many hours in a day and no automated migration is going to be 100% accurate.
3) Know that it will be a lot of work initially but it will pay off in the long run. A good CMS will help you maintain web standards, cut down on waste, and eventually let you focus more on development and less on babysitting users.
We just implemented our system in March and it is still fresh in my mind so I you have any questions feel free to contact me.