WCMS Evaluation Tips

1,942 views
1,860 views

Published on

This is a very old presentation providing some tips on how to evaluate a web content management system (WCMS) along with some details on our in-house WCMS.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,942
On SlideShare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
12
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

WCMS Evaluation Tips

  1. 1. slate + tips for evaluating a wcms Dave Olsen, WVU Web Services September 30 2008
  2. 2. What We’ll Talk About • Defining CMS • About slate • Tips for Evaluating a WCMS • A Quick Tour • Questions or Comments
  3. 3. Defining CMS "A CMS is a tool that enables a variety of (centralised) technical and (de-centralised) non technical staff to create, edit, manage and finally publish (in a number of formats) a variety of content (such as text, graphics, video, documents etc), whilst being constrained by a centralised set of rules, process and workflows that ensure coherent, validated electronic content."
  4. 4. Defining CMS Simplified: It’s a system that manages content. The not so simple part? Defining “content.” also realize that once you have a “system” you’re locked into it’s way of thinking about content (e.g. organization, types)
  5. 5. Flavors of CMS by Content • Document Management (PDFs or Word docs) • Records Management (student recs.) • Web Content Management (slate) • Portal (MIX) • Digital Asset Management (photos) • Enterprise Content Management
  6. 6. What is slate? • A web content management system focused on rapid production of traditional web sites at WVU • Developed to “scratch an itch” in our unit • Under on-again off-again development for 3 years • Hosting 150+ production sites • Managing 500+ users • Handling 300,000+ page views a month (very old data)
  7. 7. Some Technical Details • Ruby on Rails Framework • Apache 2.2 w/ mod_proxy_balancer • Microsoft SQL Server • F5 load-balanced 2-server cluster • Subversion
  8. 8. Why did we develop a WCMS in-house? • NIHS: Not Invented Here Syndrome • The ability to build a product that addressed our goals more directly • It started as a small project (e.g. no funding) that has mushroomed
  9. 9. Initial Goals for slate • Limit the disruption to the current process of creating templates for sites • Allow broad design flexibility • One install of a WCMS to deliver multiple sites • Try new technologies • Work with centralized services where possible • Make it simple to publish content
  10. 10. Evolution of Goals aka What We’ve Learned • Making it easier to use (e.g.WYSIWYG) • Better documentation. • Need lots of training. • Focus. Focus. Focus. • Faster release cycles of new features and fixes • Trying to take advantage of being a WCMS. Especially where content can be shared across web sites
  11. 11. Examples webservices.wvu.edu
  12. 12. Examples thequestion.blogs.wvu.edu
  13. 13. Examples wvudownloads.wvu.edu
  14. 14. Tips for Evaluating a WCMS • Figure out what you’re open to: • Homegrown: evaluate just like a vendor • Commercial: need lots of hand holding? • High-end: got big demands? • Open Source: want a customized solution? • What are the licensing terms? Pay by seat, site or install?
  15. 15. Tips for Evaluating a WCMS • One product will not fit your entire organization. • Identify things that you like from your current process. You don’t want to change it too much because no one wants more work. • Don’t underestimate the ease of customizing and managing templates. It’s not all about content.
  16. 16. Tips for Evaluating a WCMS • It’s not about the features. It’s about the process. • Ask for full demo’s that you can prep content for yourself (e.g. don’t accept just the sales pitch) • Get referrals and try to visit organizations that are using the product. Real feedback is what you’ll need. • Thoroughly evaluate examples provided and ask vendor if anything was custom
  17. 17. Tips for Evaluating a WCMS • A good product will not be simple. Evaluate: • community • documentation • support & training • evolution (e.g. how often their are new releases) • maturity
  18. 18. Other things to consider... • Is there a solution that helps manage content based on guidelines you have to follow? e.g. HIPAA • What are the security threats for both the application and platform? • What about versatility? Can it deliver blogs, image galleries, other? • There may be some hidden costs to take into account (migrating content, electricity)
  19. 19. Demo Time
  20. 20. Questions or Comments?

×