When we started using OU Campus in October of, we signed up for the 25-user license package, and opted for the SaaS (software-as-a-service) model or ‘hosted‘ plan, where OmniUpdate handles the hosting and delivery of the service to us, and all CMS users access the system solely through a web browser . At that time, our public website was served from an ANCIENT HP NetServer, which looked like a desktop PC on steroids (see https://360tech.com/catalog/images/NET%20SERVER%202.jpg for an example of what I’m talking about). That HP NetServer had a robust 18GB RAID 0 array, and was running FreeBSD Linux, version 4.3. It was a 600MHz dual-processor system, and it weighed at LEAST 4,000 pounds (or so…).
To allow OU Campus to publish to this server, we created an eDirectory user (we are a totally Novell campus) and granted FTP permissions through our firewall to their system using their servers’ static IP address (which we setup in the “Accounts -> Sites” of OU Campus…very straightforward), and I added that IP address to the Linux server’s ‘hosts.allow‘ file.
In June of, we migrated the website off of that Linux dinosaur (it had been running faithfully since August ofat that time), and onto a Dell PowerEdge 1750 1U Rack mount server running Novell NetWare 6.5, Apache, MySQL, and and PHP. This server was a dual 2.8GHz Xeon CPU system with 36GB RAID array and 2GB RAM (so a BIG step up). We used a combination of Novell network copy and OU Campus to move the site over to the new server and publish the up-to-date content (site export and import in OU Campus is very nice).
In August of (of course, on the first day of the FallSemester @ about 10:00 am), the hardware in that Dell PowerEdge 1750 server experienced a major problem, so we switched over to a Dell PowerEdge 1955 Blade server (with similar specs as the 1750 above) and were back online within 20-30 minutes. Manipulating site configuration in OU Campus during these moves was no problem at all.
Getting our site ready for editing was not difficult, although it was somewhat labor-intensive to add editable region tags to each ‘existing’ website that I wanted to hand over to individual departments for editing. OmniUpdate’s staff tagged a large number of pages for me, and offered to assist me in the setup of my initial couple of templates, although at that time, the website that I had inherited had no rhyme or reason to it (there were at least 6 or 7 completely different page layouts, not to mention the endless series of “one off” web pages/sites that had been created by individuals who were clearly not familiar with how to put together a website, yet had been given ‘carte blanche’ FTP access to their site’s publicly available web directory on the web server), so I told them I would just start slowly, tagging individual websites as I trained each department to edit their own content.
At the same time, I slowly began removing these aforementioned individuals’ direct FTP access to our web server, and began ‘nudging’ them towards using OU Campus as I tagged their particular departmental website for editing and uploaded it into the CMS. Every single one of them, once presented with a basic overview of the OU Campus interface, fell in love with it immediately and were relieved to not have to use DreamWeaver or FrontPage anymore. Additionally, these users use the CMS all of the time (user adoption has been 100% here for each person trained), and they always have nothing but good things to say about OU Campus each time I talk to them.
Currently, I still do not have a single ‘template’ created within OU Campus (chock up that stroke of brilliance on my part to foregoing OmniUpdate’s offer to create them for me back in ’06, yet I have never set the time aside to create them since…). Fortunately, you don’t have to have templates in the system to use it, however, having templates does give you more control over what happens when a new page is created. I do have plans to setup some templates in the near future (for content repurposing at the time the page is published using XSL and XSLT transformation to output multiple file types and content formats from that single publishing action), however I have not yet put them together.
Staffing requirements to manage OU Campus has been just me. I don’t have any other web staff here with me, and I’ve never had a student worker to assist me, so the overhead to manage existing users and incoming web publishing approvals is very manageable. With the simplicity of administration of OU Campus, I don’t honestly think another staff member is necessary. We increased our user license count to 100 this past fiscal year (which quadrupled our available user accounts, but only doubled our cost), and every new department and/or user that I train eases the deluge of incoming update requests just a bit more each time. At this point, we have setup 40 of the 100 available user accounts, most of which have been handed over to departments for managing their site’s content, so I would venture to say that the actual ‘user’ group on our campus is effectively double that number at this point in time, and I have been getting requests from other departments to set them up as well, so I anticipate that number rising dramatically within this next year…very good news.
Our annual cost of ownership was initially just under $12,000.00 (on a 3-yr. contract with a 25-user license), and it is currently $25,000.00 (for 100 user licenses) plus $4,000.00 annual support. We host the website(s), our ‘vvc.edu’ top-level domain and a full Class C IP address range ourselves, plus we have an on-campus OC3 backbone connection from a partnership with Verizon (we get a portion of the OC12 that we host on our facility for them), so that lowers our costs in that respect. The only salary to factor in to this would be mine (I’m the only web staff member at our institution), but I’d be doing this work with or without OU Campus, so that cost doesn’t apply to this study.
As we have increased our usage, OU Campus has never had any issues with reliability or stability in any way. Additionally, I recently created a new program website for our college that is hosted on Network Solutions’ servers, and OU Campus easily connected to and provides full editing access to that site (I setup the first page of that site with editable CMS region tags, so that has been a very simple and painless roll-out on the new site). This coming year, I plan on integrating OU Campus with our campus bookstore’s online store site (provided by “Campus Hub”) as well as exploring options for integrating it with Microsoft’s SharePoint Server content, as well as publishing XML course catalog data from our student information system, and providing a XSL/XSLT transformed web front-end for searching through our existing course information without having to edit any of it within OmniUpdate at all (I’m also planning on having that output a searchable, mobile friendly, course catalog web interface…so we’ll see how that goes…keeping my fingers crossed here…).
In just about every way, OU Campus has met and exceeded my expectations.
- Users love it and consistently USE it after I train them
- Once you get a page / template setup with editable regions, and you start creating new pages (or, even better, as your users start making new pages), it’s a pretty “hands free” setup for non-technical users to fully contribute to and manage their online content from anywhere with an Internet connection.
The only thing that has been a challenge for me has been when I give users too many options on their WYSIWYG toolbars, and then they put all kinds of crazy colors and fonts on the page, and then I have to “reign them in” as I ‘take away their toolbar candy’ (like Font Size, Font Family, Text color palette options, etc.)…I know, I know…you’re sitting there reading this like…”What did you think would happen?”….and you’re exactly right. But hey, we learn from our mistakes, and I’ve since stripped just about all ‘formatting’ options from the toolbar, and I’ve been working on incorporating CSS styles into the toolbar’s “Styles” drop-down menu, so that the users will be able to style their content, without breaking the page layout/design/etc.
At this point I can’t claim to be a power user of the OU Campus CMS. We purchased it to put content management in the hands of the content creators around our campus, and it has done exactly that, but we’re not really pushing the envelope here.
As far as integrating OU Campus with other systems, currently we’re not doing any of that, although I am planning a couple of projects like that (which I mentioned briefly above), so we’ll see how that goes. Based on my experience so far with this CMS, if the content can be accessed and manipulated, I am confident that OU Campus will have no problem providing management of that content.
OmniUpdate support absolutely second-to-none. When you call them, they answer the phone (important!), they are extremely knowledgeable and can concisely answer just about any technical question you ask, and every question/issue I have ever had is typically resolved in less than 1/2 of a business day. Their support site (https://support.omniupdate.com) is extremely thorough, and they have setup a private Ning network for OU clients at: https://ocn.omniupdate.com. This is a very good resource, and a good way to get quick answers regarding questions you might have. You can also join the OmniUpdate group on the University Web Developers Ning network at: https://cuwebd.ning.com to get involved in discussions with other higher ed web development folks about CMS topics.
Overall, I have been nothing but pleased with the simplicity of administering and managing the OU Campus system for our institution. It has definitely simplified my web content management strategy, it has improved the status of updated content on our website by providing an interface that our users consistently use, and continues to do so more and more each day. Keep in mind, however, that every CMS system roll-out will involve a lot of time to do it right, regardless of what CMS you choose, so you’ll want to be prepared to take that on, but take heart…it is worth it to put in that time.