Things to Consider Before Deciding to Adopt a Content Management System

Burt, thanks again for the opportunity to come and speak about Content Management System
and all of the things that you have to think of in order
to successfully adopt it.
I have four main talking points that I wanted to cover today. One is what a content
management system is,
two why anybody would want to adopt a CMS, three
is it a change that's right for you,
and ultimately if you do decide to adopt a CMS
how do you go about the process of adopting it, rolling it out, training people to use it
and all those types of things?
So let's start out with part one, the what part.
A CMS is software
that lives on a server
that's accessed via a web browser
and is used to create content
and modify assets and manage content overall.
A pretty broad definition of what a CMS is and using that
there are a lot of different types of software packages that could be considered a CMS.
I have a slide that's going to
be coming up shortly at that addresses that.
Within each CMS, typically there are multiple levels that people can use to manage content.
A default CMS, when you get it, is going to typically ship with four different roles. One's
an administrator role, one is a developer/designer role,
an editor and a contributor.
At the top level, the administrator level, basically is God, they run the system, they install the software,
they configure things, when there are patches that come out they apply it to the server;
they basically keep your software healthy and running happily and add new features and
functionality when you ask them to do so.
A developer is responsible for creating content,
creating macros or asset factories that are used to create common types of content.
An editor is able to create
and post and approve content and ultimately a content contributor
is somebody who's assigned tasks to create content and then submits it up to the editor
for review.
So those are the four main roles that almost every single Content Management System has.
Often these different roles are blended together, there's crossover.
The top two roles in the stack, the administrator and the developer, are often
run by the same person so
for instance you install WordPress to run a blog,
you're more or less your own administrator/developer for that.
The developer role might be shared to some extent by somebody else who might have created a
theme or template that you installed, but more or less you’re responsible for running your own system.
Also the editor and contributor roles are often flattened and merged together.
The reason to have the two is so that you can take advantage of work full processes.
So you can have
a staff of five writers who are essentially assigned to write or developed some content
and ultimately an editor goes through and makes sure that it conforms to whatever style guide your
writing to, that it's using the right terminology for your institution,
et cetera. But a lot of times people merge those two rows together and simply
post the contents to their website.
So we're talking about the varieties of CMS's that can be implemented.
So with the definition of software that's installed on the server that people access through a
web browser and they populate content,
these are nine major categories that
fit into that. So informational websites like an organizational website like msu.edu
would qualify as that,
blogs like on WordPress or Blogger or Typepad, or any of those types of services. Technically
forums are software that you enable community to start discussing and uploading and sharing
content.
Internets which are more
like informational websites that are controlled by password protection, but
aren't necessarily enabled to have people
post comments or respond to things; portals, online instruction, social networks like Facebook are
technically Content Management systems;
online stores and essentially rich
media and interactive applications that are posted online. So
there's a lot of different kinds of content management systems out there.
There are two basic ways that CMS's function,
there are "pushed" based CMS's and there are "pull" based CMS's and I want to show you how
both of them work.
A "pull" based CMS:
a visitor comes to a website
the CMS software is residing upon a web server,
it couries a database that has all of the content, all the rules for how templates and layouts are
supposed to look and how everything relates to one another.
The CMS software takes the data it receives from the database, it puts it together in a
way that makes sense, and then it delivers it back to the person who visited the website.
So it's kind of like a quick
roundabout circuit.
Examples of "pull" based CMS's:
WordPress is a "pull" based CMS,
Drupal is Joomla is,
most all of the open source systems are.
A "push" based CMS
the website, the visitor comes to the website
and a web server containing
the data that they request simply returns it back to them,
more or less like a standard web server.
So part of the question is where does the CMS come into play for that?
The CMS server itself is actually residing
in a separate location from the web server,
it's connected to a database--the database contains all the content information, assets, and rules
for how the
information is supposed to be displayed--
but ultimately all of that content is bundled up and sent over to the web server for delivery.
So the two environments are completely separate
and there are pros and cons to doing an implementation like this which we will get into as we go along.
Ultimately when a website visitor comes through they get the content from the server.
So comparisons of the two in terms of pros and cons of each,
and a little kind of caveat, this is rated G.
There are a lot of CMS's out there. When I was putting this presentation together
I went out to cmsmatrix.org and there was
over a thousand CMS's out there, so
it's hard to have really clean rules saying
"this type of CMS does this" and "this other type of CMS does that" 'cause there's lots
of gray in between and each can be customized to more or less do whatever you want it to do.
So these are just general rules.
A "pull" based CMS
has a persistent connection to the database. So the things that are really great about
that is you can do dynamic interaction. So like WordPress has comments;
if a user
loads up a page
and they want to say something they can go to the form widget, they can type and that
data goes back to the database and it's either processed
to be published automatically
or it goes into a moderation queue. But that persistent connection to the database allows that interaction
to more or less happen in real time.
Developers can manage the look and feel of features and functionality and editors can manage all
of the content on the site. Those last two things are
going to be pretty much common on any CMS.
Using a "pull" based CMS
for multiple sites you would essentially install the software on a web server
and you could use that to run
kind of micro sites or landing pages within your site.
But if you wanted two sites that were very very different; so like
president.msu.edu is very very different from admissions.msu.edu,
they're on separate servers, they have different purposes.
In order to use that CMS on those different sites
you'd essentially have to do separate installations;
pretty easy to do.
The challenges of this deployment method come when you try to scale it up
to a large level. So it's not a big deal if you're using WordPress to run your own
site, like I use it to run my blog.
But when you have, say ten or twelve installations, WordPress releases updates all the time, usually
once a month,
which means you get to patch it on all twelve installations which
can be time consuming and not very fun.
Sharing assets across the sites can be a challenge as well.
This is a gray area again, you can install some tools that make sharing of content easier
but if you really wanted to write say
a program description;
so the Registrar's Office says "this is what the program description is, here's the requirements"
and then that's used on the admissions site,
on a college-level site, on a department-level site,
it would be really hard to easily
have that work from one site to the next.
Typically the user roles are,
it's not possible to always have really granular roles. And what that means is
the editor and the content contributor roles that we talked about before,
when you have a site,
more or less if you're an editor you can edit anything in the site.
So if you had separate sites, so like say we
installed WordPress or Drupal or whatever else on
the msu.edu web server we
could host admissions on that, we could host the President's site on it, but
somebody who's hosting student life could also update the President's site.
And there are ways to have that not happen but in most cases the open-source "pull" based systems
don't have that level of granular use, say people have access to specific files.
Also all of the content that is managed on the site has to be managed in the CMS. So if you're
going to a "pull" based CMS
more or less all of your content has to be served from that, you can't have
a file within a directory that's served from a different location. So if you have
an about directory that has your mission statement and vision statements and everything
else, but you have a dynamic part that has a staff directory
all of that has to reside in the CMS, it can't reside in another system, so it's kind of an
all-or-nothing approach to
managing your content.
And ultimately customizing the software can be time-consuming
and difficult to scale up. So
one of the things that we've found--
probably all of us when we're developing websites-- is we come up with a really
great look and feel and template and design
and a client comes in and they want something different that the temple wasn't designed to do.
So they want some kind of
animated thing on the home page, or they want a staff directory, or they want a blog or an RSS feed.
So we typically customize
everything that we do.
Well each of those customizations, depending on how you do it, with a "pull" based CMS can
become very very difficult to replicate. So if you
modify the code that came with the system you have to remember that you modified it so that
when you patch it you
re-apply your modification and also make sure it doesn't break anything in terms of security.
Really easy to do on one site but as you get into ten or more sites it becomes a royal
pain in the neck.
A "push" based CMS:
contents pushed from the CMS and database to the web server, so there's no persistent connection
between the web server and the database/CMS.
What that means is that you can have
dynamic content but
it can't necessarily have
a significant amount of interaction. I'm going to get a little bit techie
here so please forgive me if you are a non-techie.
You can have an XML file that serves like a database, so it could have
staff information like name, email address, and phone number
and you can have PHP files that more or less transform that based on what buttons a user
presses. So it's kind of dynamic
but they can't comment on the content, they can't rate it, they can't
more or less feed content back to the database that then
transforms the experience or information that's out on the website.
Developers manage the look and feel of the features and functionality just like the other
site, editors manage all of the content.
And portions of the site can be managed in the CMS, so one advantage
of a "push" based CMS is that
it pretty much doesn't care what pages in the site it's managing. It can manage 80% of the site
so like an example of an admissions website, they have custom software that handles applications,
processing, and status.
You can leave that part of the website within
the proprietary system and wrap the design look and feel and the help pages and all of the other content
within the CMS.
So it allows you a little bit more flexibility in terms of migrating from one platform to
the next.
Using a "push" based CMS for multiple sites. So if you're going to,
you've got your first site up and running and you want to launch a new website
you essentially get your configure information for all the different web servers that you
have, each with their own domain,
and you configure
the CMS to push content out to each of them.
The potential advantage of this is that if you patch the template
or content in one location it automatically feeds it out to all of them. If you patch
the CMS software for security
reasons it patches
every single site that uses the CMS for maintaining the content.
The challenges to using a "push" based CMS:
the dynamic/live interactive content
is a real disadvantage of this platform. So you can't really do comments,
you can't do voting, you can't do discussion forums.
There's always workarounds, you can install other software that would allow you to do that,
you can use Discuss to manage
conversation features, you can integrate your websites with Facebook
to have commenting of content,
but ultimately as a turnkey solution it just doesn't work
with all of that, initially.
User content in multi-site management can be very very complicated so on paper it sounds really great, you
do templates once and you publish them out everywhere
but again, typically the clients want to customize the site to some extent.
So trying to figure out
what baseline solutions going to work for most of the people,
how do you give them enough flexibility and options so that things can be modular and they
can personalize the site in some way
requires a lot of planning because every user is significantly different.
And more or less leveraging the full advantages takes a significant amount of time and planning.
So that's the end of part one,
there are CMS's out there.
Part two why would you want
to use a CMS?
There's a handful of benefits of why you would want to use a CMS.
Ultimately a lot of the content contributors feel frustration because they have content
and they want to publish it right now but
in order to publish that content they have to call Bob over in the technical area, he's out doing
a service call and
so they send him an email and so it might get published at some point in time.
Bob is a smart person and he actually should be working on databases or other things
and so publishing content is like a low-skill level, not high priority thing in his day.
So ultimately using a CMS can make everybody happy.
The developers can make really cool features that people want to use, the constant contributors
can publish content to their sites really easily, it sounds really good.
A CMS allows you to apply some rules and standards so
part of our fear as web developers of giving the keys over to
the clients is that
they will cut and paste code in that breaks the site, they'll delete something and the site will
break and ultimately things won't look very good so that's kind of a nightmare that we all avoid and just
don't give them access to sites.
So with the CMS you can protect
the user from making mistakes and you can also protect the integrity of your site so
that they don't have the ability to go in
and make text that's blanking or that's too big or uploading an image that's
fifty megs and really should be just fifty K.
You can prove content quality so if you
implement workflow for really important information like tuition details, requirements for graduation
that you want multiple pages in your site to use
you can have one content writer
write it once and then it's repurposed across all of those sites.
If they find an error, which often they do,
they can update it and it gets updated everywhere so it keeps it simple and clean for everybody.
There's a potential to reduce long-term operating costs and I think one of the concerns
with this is that
people think that CMS is going to solve all of their problems. It's kind of like in the early nineties
where all you had to do to be successful was to have a website you could be the next Amazon.
Long-term there's the potential to save money
because a lot of us get in situations where we get a site up really really fast and the person
who made it for us
goes on somewhere else and is doing great things
and then we don't know what to do with it, and so we essentially do the whole process over again
and that cycle repeats every one to three years.
That's kind of expensive and time-consuming
so using a standardized platform means for one,
there's always an on campus or institutional level of support that can assist you from
wherever you're left at when
your tech support people move on to other pastures.
There's also the potential to save money on software licenses.
So there's about ten thousand people who work at Michigan State;
say we want one in ten of them to be able to access web sites.
If we bought licenses for Contribute, which I don't know how much they run these days
but lets a hundred dollars,
a hundred dollars times a thousand peoples' a hundred grand.
That's significantly more than it costs to get any enterprise level content management
system or pay
somebody to implement one for you.
And that's a cost that more or less is a recurring cost that happens whenever Adobe upgrades
their software.
So there's potential to have cost savings that could be meaningful or take revenues that could
be put into other more meaningful things.
There's also the potential to have
deep and meaningful levels of staff development.
So kind of like trying to build a winning basketball team if everybody is learning to
play the same game then
they can help each other and
improve their overall effectiveness.
I pulled
a use case; I surfed the web,
Googled a whole bunch of things trying to find out what's the business case for a higher education
institution to adopt a CMS?
And I came across a statement at Utah's
university website
and I highlighted the parts that I thought were meaningful. So they say good content management
makes content more widely available and helps maintain the quality and
integrity of information as it's used.
The value of content is increased by making it reusable in other places beyond
its original purpose. An article could be used in a recruitment area, it could be used in a student
office, it could be used on an admissions page and quickly
updated and kept in sync.
So from their perspective they're really seeing the value in terms of being able to manage the
quality of information and repurpose it throughout the entire organization. So they're really getting into
some of the core concepts of content management, they're going beyond just publishing content.
In fifteen minutes it's not possible to give you absolutely everything you'd want to know so
I added a couple footnotes on here, where to learn more about how universities have
successfully adopted these, check out Carnegie Mellon and Ball States' website. They have
overviews that talk about what CMS is, how to adopt it, what types of support are in
place, how they got it to work.
And these slides,
do you share them with the rest of the group via email?
Alright, it'll be online somewhere.
I also collected four different perspectives on CMS so the first, the higher ed CMS usage
was a new one to me, it was a survey that was done in March 2010
and they had a whole bunch of people in higher ed say what kind of CMS's they're
using. So it's really interesting to see how it breaks down
between Drupal and Cascade and WordPress and everything else.
The others are specific use cases so
some folks are using Drupal to do online education, some folks are using WordPress to run
their writing center website
and the Cascade server, which is the university enterprise CMS,
there's a case study up on the vendor's website about how Indiana University has adopted
that to manage their live content.
So part three: how do you decide if CMS is right for you?
CMS is going to be right for you if you have more than one person who is going to be managing content.
If you don't have more than one person CMS is probably not worth it for you.
If you have
team members who are contributing at different levels, so you have somebody who is a basic
user and you have somebody who is a
coding ninja, they can make whatever you need just give 'em a little bit of time
they are like Batman, they'll come back with an excellent solution.
If you need to maintain a high standard of quality and consistency, you wanna lockdown places
of the layout so that people don't break things,
if you want to share contents, if you want to automate and schedule content; for me this was
a huge thing as I began using CMS related stuff. So
I can schedule contents to launch at the start of fall that says, "Hey students, welcome
back to campus" and when it's graduation time it can say, "Have a nice holiday break
and good luck with your graduation and work after that".
It's also the ability to implement workflows for content creation and review.
CMS might be wrong for you
if you lack reliable and adequate resources in terms of support
and training and technical development.
I think that's really important regardless of how great the tool is or how
inexpensive it was or how open it was or how expensive and fully feature-rich it was, if you don't
have proper support it just isn't going to work and it's probably not worth doing it.
If you plan to send updates only to one person who posts everything using the CMS, it's
probably not right for you.
The whole point is to enable a lot of people to be able to manage content.
If this is your first time using a CMS and you have a really really important
site that's gotta go online or it's even past due,
this is not the right time to adopt a CMS.
Also if you believe a CMS means immediate versus long-term reductions of
cost or time required to maintain content it's probably not something you are going to want to go into.
Or also if you want complete freedom of layouts. So in some cases we need to be able to make
immersive rich experiences, so if we're doing a micro site that's for recruitment of students
while long-term that could be designed to be maintained through a CMS, in the short term because
of QuickTime turnarounds and other interactive features
it's probably not ideal to go into the CMS.
How am I doing on time?
One minute, okay.
So standard workflow process people have stuff they want to do, they send it to the web
person, the web person says "yeeha" and puts it on the website.
Afterwards a whole bunch of stuff can happen, the web person says, "Guys I set up something that
you can handle most of the content".
I think the key here is you can't handle all of the content, there are going to be some cases where you still are
going to need your developer but in most cases you'll be able to do stuff.
So a writer can be assigned something, they can send it to an editor, they can publish it.
A helpful person can say, "Oh my God, I found something that's like so antiquate
and out of date, it's embarrassing, we really need it off now", they can just go ahead and take it offline.
And all the navigation is automatically updated so all the links aren't out there.
Part four: getting there.
Four phases for getting there, one
have a plan.
Have people who are your executive stakeholders who want you to do this and understand why
you're doing it.
Have clear objectives, tactics, and deadlines, if you don't have deadlines you never gonna
get it done.
Organize a team that has a lot of different skills, you need a technical person, you need a marketing person,
you need somebody who knows either how to do everything because they're Superman,
or you need a bunch, a group of people that can be your
kind of wonder force that get's everything done.
Phase 2: evaluate your options. Identify what you want the CMS to do. There's
over a thousand out there and there's a reason why because they're designed for doing different
things. If you want to run an online store
there are certain ones that are good for that and others that aren't.
I like the first page of the manual for Drupal if you're learning how to develop it, it says
if you want to run a blog
this might not be the CMS for you, you might want to use WordPress or some other
familiar tool.
Test evaluate it,
ultimately pick something,
migrate your content. I'm going to
cut through these so we can get to questions.
Figure out what content you're putting out there, train your people, implement it,
or outsource implementing it if you don't want to implement it yourself,
and ultimately long-term you have to support your people.
You have to have sufficient training in place, you have to be prepared to answer the questions,
show them how to use it.
Be prepared for the first two to four weeks after they start using it that they're going
to call you everyday day, or multiple times a day so be available for that
each time after you train somebody new.
And also be prepared to figure out how you're gonna handle change, you're ultimately going to say,
go through a phase of saying, "The tool is really great, we love it, it's wonderful" to "You know this
doesn't do what Facebook does, it doesn't do, we need it to do something different".
So you have to figure out how you're going to handle change, how
are you going to evaluate new features and keep your platform secure,
or how are you going to prioritize those things as they come through?