Making a convincing case to change from non- or lightly-managed web sites to a content management system (CMS) can seem daunting. However, you can build a strong case that will help convince administration of the benefits of CMSs. In this talk, two librarians who manage large public and internal websites at the University of Michigan and the University of Colorado Denver give you all of the ammo you need! Gain insight on why having a CMS is better than not having one and why an open source CMS tool (such as Drupal and MediaWiki) are viable, functional, and efficient solutions. Audience participation in the form of group therapy will be encouraged!
Concurrent session delivered at Internet Librarian 2011, October 19, 2011, with Nina McHale.
Kotlin Multiplatform & Compose Multiplatform - Starter kit for pragmatics
Â
Il 2011 Making the Case for CMS!
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
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
Hinweis der Redaktion
NIna
NIna
Nina
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?
Ken
NIna
KenFunctionalityEnvironmentSecurityMaintenanceTerritoryContent, branding, messageStaffingCostChangeTechnical skillsAuthority (too much or too little)Where are users? They don’t care. They just want a website, dang it.