1. MAKING THE CASE FOR CMS Internet
NINA MCHALE & KEN VARNUM Librarian
2011
O c to b e r 1 9 2 01 1
@NINERMAC @VARNUM

2. ONE-QUESTION SURVEY
What reasons have
you been given that
you can't use a CMS
for web development
in your library?
bitly.com/cmspoll

3. MOVING TO CMS: THE ISSUES
1. Centralization of development
2. Branding
3. Democratization of content
4. Control over your own destiny

4. CENTRALIZATION OF DEVELOPMENT
 Eliminate redundancy
 One system to rule them all
 Simplify everything through consolidation
 Control
 Who had it?
 Who gets it?
 Staffing levels
 Put right staff in right place
 Outsource hosting, worry about customizing?

5. BRANDING
 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.

6. DEMOCRATIZATION OF CONTENT
 CMS separates content creation from
programming
 Lack of administrative oversight of content
 Focus on consistent message
 Perceived (or real) loss of control
 Removes most skill barriers from
authoring
 Someone’s expertise may become valueless
 Some HTML still may be helpful for advanced
users

7. 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
tools
 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

8. CMS CONCERNS FROM 3 DIRECTIONS
1. IT
2. Administration
3. Staff

9. 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.

10. 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-
house

11. 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
maintenance regime.
 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.

12. 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:
 whitehouse.gov (Drupal)
 wikipedia.org (MediaWiki)
 NYT blogs (WordPress)

13. IT CONCERNS: SECURIT Y, 2/2
“Too many people will have access to the
web server.”
 In most CMSs, only web admins require direct
server access
 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

14. 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
experience?
 Who “owns” web services within the library?
 Admin?
 IT?
 Public Service s?

15. ADMIN CONCERNS:
CONTENT/MESSAGE
“Library staff will have free reign on the
site.”
 Develop a content strategy
 Who speaks on the site, and what should they
say?
 Set standards for content, branding, etc.
 Establish web publication workflows with
editorial review (CMSs support these!)
 Train library staff on all of the above

16. 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
sample site.
 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.

17. 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
employee time
 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

18. 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
content creation
 If staff can type in a web browser, they can
add content to a CMS

19. STAFF CONCERNS: CHANGE
“This will be a big change; will we be able
to manage it?”
 “You won’t have to use Dreamweaver
anymore.”
 “You won’t have to use FrontPage anymore.”
 “You don’t have to use HTML (if you don’t
want to).”
 Point out these and other benefits that will
make life easier for content creators.

20. 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

21. THE ONE QUESTION SURVEY:
YOUR RESPONSES
What reasons have you been given
that you can't use a CMS for web
development in your library?

22. CONTACT INFORMATION
Nina McHale Ken Varnum
nina@milehighbrarian.net varnum@umich.edu
@ninermac @varnum
milehighbrarian.net rss4lib.com