MAKING THE CASE FOR CMS Internet
NINA MCHALE & KEN VARNUM Librarian
O c to b e r 1 9 2 01 1
What reasons have
you been given that
you can't use a CMS
for web development
in your library?
MOVING TO CMS: THE ISSUES
1. Centralization of development
3. Democratization of content
4. Control over your own destiny
CENTRALIZATION OF DEVELOPMENT
One system to rule them all
Simplify everything through consolidation
Who had it?
Who gets it?
Put right staff in right place
Outsource hosting, worry about customizing?
Emphasize your brand
Standardize site navigation
Push core services & functionality
Reduces cognitive overload for your patrons
Galvanizes and promotes library identity within
your community (campus, city, etc.
Doesn’t mean all departments/branches need to
look the same.
If no brand exists, the scope of the problem is
well beyond the web folks.
DEMOCRATIZATION OF CONTENT
CMS separates content creation from
Lack of administrative oversight of content
Focus on consistent message
Perceived (or real) loss of control
Removes most skill barriers from
Someone’s expertise may become valueless
Some HTML still may be helpful for advanced
CONTROL OVER YOUR OWN DESTINY
You’re not dependent on someone else to
make things happen
When you want a new function, you can do
it – often by mixing & matching existing
Ability to respond quickly to patron needs
You may inherit responsibility for
application (CMS) and web server security
A security compromise could put your
parent institution at risk as well
CMS CONCERNS FROM 3 DIRECTIONS
IT CONCERNS: FUNCTIONALIT Y
“CMSs are too limited. We’d have to mold
the site to the CMS, rather than build
exactly what we want.”
Most CMSs are very flexible and can be
extended by contributed packages of code
(i.e., Drupal modules)
Make a CMS choice carefully; research what
strengths and weaknesses of each are and
show how they are or aren’t a good fit.
IT CONCERNS: ENVIRONMENT
“We don’t have a place to put it.”
“Make one. Pretty please?”
“We’re going rogue.”
Web hosting options are inexpensive
Many hosting companies have “one click”
CMS install for popular CMS software
Support may be better than what you get in-
IT CONCERNS: MAINTENANCE
“No one will be able to maintain the
system; it will become a security issue.”
Adopting a CMS does require taking on a
If the site’s functionality is not too
complicated, upgrades are not difficult.
See if IT will agree to maintain server
environment; strike a balance.
IT CONCERNS: SECURIT Y, 1/2
“Open source software isn’t secure.”
The nature of open source development
communities actually makes it more secure
The managers of these sites think open
source CMSs are secure:
NYT blogs (WordPress)
IT CONCERNS: SECURIT Y, 2/2
“Too many people will have access to the
In most CMSs, only web admins require direct
Content creators add content via a browser
Existing accounts (i.e., LDAP/AD) can be used
Permissions of CMSs allow very granular,
precisely controlled access
ADMIN CONCERNS: TERRITORY
“We have to use our parent organization’s
Content Management System.”
What are limitations of that CMS?
Does that truly give your users the best
Who “owns” web services within the library?
Public Service s?
“Library staff will have free reign on the
Develop a content strategy
Who speaks on the site, and what should they
Set standards for content, branding, etc.
Establish web publication workflows with
editorial review (CMSs support these!)
Train library staff on all of the above
ADMIN CONCERNS: STAFFING
“We don’t have anyone who can do this for
you. No one has the time or the skills.”
“I can do it.”
Install the CMS on your laptop and develop a
Time saving aspects of CMSs can free up
time doing tedious work (link checking,
reports, stale content) on a static site to learn
how to maintain a CMS-based site.
ADMIN CONCERNS: COST
“A CMS will be too costly.”
Learning the CMS will be an initial
investment, even if it’s free, in terms of
Web authoring software (Dreamweaver, etc.)
is no longer necessary for content creators to
draft content and connect to the server
Cost of licenses
Cost of staff time learning specific software
versus web-based input of most CMSs
STAFF CONCERNS: TECH SKILLS
“They’re too hard to use.”
Web staff may have to learn the CMS initially
Most CMSs use browser-based editing for
If staff can type in a web browser, they can
add content to a CMS
STAFF CONCERNS: CHANGE
“This will be a big change; will we be able
to manage it?”
“You won’t have to use Dreamweaver
“You won’t have to use FrontPage anymore.”
“You don’t have to use HTML (if you don’t
Point out these and other benefits that will
make life easier for content creators.
STAFF CONCERNS: AUTHORIT Y
“We won’t have control over our content.”
How much control do they have now? What
are their specific concerns?
Organization must establish rules for content
(workflow, procedures, etc.)
Most CMSs have very robust
user/permissions systems that allow staff
access to precisely what they need for their
work, and no more
THE ONE QUESTION SURVEY:
What reasons have you been given
that you can't use a CMS for web
development in your library?
Nina McHale Ken Varnum
KenEliminate redundant interfaces - Makes creating, managing, and *using* content easier for all - Can make granularity of content harder to see - If you can do one function, you can do all - More burden on center to keep everything up; harder to delegate - Parts of your library may feel loss of control; may become data providers without the “pleasure” of maintaining the interfaceTeach one system - Everyone can be [somewhat easily] taught to use the system on the authoring side - Requires training effort. Easier/harder than Dreamweaver/raw HTML?Democratize content creation - Everyone can be an author – yay! - Everyone can be an author – uh oh. Does everyone understand how to speak with the library’s voice? - Editing/review processed may be needed; can increase bureaucracy when anyone can write, do you trust them to do so?One design (with subdesigns) for all - Gives your site an identify - Lowers user burden to understand where they are and how to get where they’re going - Your operating units may perceive a lack of autonomy - Their expertise is probably not server maintenance, graphic design – but content. Let them do that.
NInaEmphasize brand: - Make sure you patrons are clear where they are (which library and which department). Are you serious (academic)? Fun (public or youth)? Specialized (subject or region)? Let that show - What the heck is your brand, anyway? Can you articulate and design one?Navigation: This is information architecture - Let your users where they are in the context of your site - Provide sitewide access to the services they use and need (not the same thing!) the most - Do you have a complex organization? Hard to set limits on how broad or how deep a subsection’s navigation can/should beCore Services & Functionality - What do you offer that’s unique, special, or just very useful? - Does hiding things that are *almost* that important hurt? - Can your patrons understand what your key services & functions are from a simple label?
KenFunctionalityEnvironmentSecurityMaintenanceTerritoryContent, branding, messageStaffingCostChangeTechnical skillsAuthority (too much or too little)Where are users? They don’t care. They just want a website, dang it.