Web CMS deployments in the NHS

A presentation I did about a technology-agnostic process for selecting a web Content Management System (CMS) in the UK National Health Service (NHS). With some specific notes on Plone.

Transcript

1. 1 My name’s Shaun Hills Web developer at NHS Connecting for Health. Used to work in Surrey HIS out in Surbiton.
2. 2 What I can't cover •I'm a web developer, so the nuances of the National Programme are often outside my expertise. Please understand if I can't answer all your questions about the NPfIT •If you do have anything specific though, here's my email address: shaun.hills@nhs.net. Send your question through and I'll try to make sure it gets answered. I sit just across from the guys who handle our enquiries. •If you have any questions about the London portal, please contact Ruth Colbridge. She’s put a post online on the Webteam forum.
4. 4 We have some developers (me for example, the nhs.uk team for another), but mainly we handle comunications about, procurement, project management, deployment of the NPfIT Web stuff: Service delivery •www.nhs.uk •Healthspace Comms-related •www.connectingforhealth.nhs.uk •www.chooseandbook.nhs.uk NPfIT project-related e..g www.onlinemim.nhs.uk Legacy NHSIA websites Internal NHS CFH web projects Healthspace and www.nhs.uk have dedicated teams Our team looks after most of the comms-related deliverables, the NHSIA sites as well as some of the internal applications NHS CFH ICT looks after most of the internal projects, we look after the intranet
5. 5 •What’s the NPfIT? Who knows? Show of hands? •Here's what it covers. Unfortunately this is going to be deliberately brief; our website content's slowly getting better, so I'd encourage you to have a look if you'd like to know more! •NPfIT isn’t delivery of standardised web systems like CMSes and hosting! outside NPfIT remit •We're happy to get/provide advice though •That's the theme of the rest of the presentation...
7. 7 Who here’s already got a CMS in place? Who’s not got one, but is considering deploying something? If so, why?
8. 8 OK, to get started, here’s some of my definitions A web CMS is a system that allows you to update content on your website It could just be a bunch of people with copies of Dreamweaver More commonly it's site management program written in something like PHP or .Net, with a database backend. What it always is, is a combination of technology(s) and process Most people think of it as a technical question, and that's what I'm going to focus on. But process is important. DMS and CMS have complementary functionality; often you’ll want to deploy both
9. 9 So when might you want to look at deploying a CMS? What’s “non-trivial”? It’s arbitrary, but my rule of thumb is that anything over about 10 pages is non-trivial. You need systems to manage this, even if they’re just processes. Dynamic reuse – for example NHS CFH news items Anyone think of any other signs you might need a CMS?
10. 10 This slide is slightly opinionated  Who here runs a home-grown CMS? Infrastructure that you’d otherwise have to build includes: •User management •Authentication/authorisation •Templating system etc Of course, you don’t “buy” an Open source CMS normally, but it’s still not coded from scratch.
11. 11 So, what do people think of these? Any pros/cons I’ve missed? Beware of vendor “support” though. Many CMSes are very small companies with quite poor support, or small companies implementing big products and the developers aren’t as familiar with the code base.
12. 12 Quite often the idea that open source is cheaper is a fallacy. License cost is a small part of many deployments, compared to staffing costs for example. However the more license costs you have, thr cheaper OSS becomes as code and customisations you’ve already written become sunk costs. So the marginal return on OS CMSes is good. And you can reuse others’ code, which is even better We saved something like £20k in licenses at Surrey HIS over the period I was there working on Plone Sometimes they’re easy to extend. Sometime you’ll spend two days wading through code to try and work out some seemingly minor thing. However generally they’re more standards-based and therefore easier to integrate with other systems. All speak LDAP, RSS, WebDAV etc. Not having a vendor can be a good thing, but watch out for inactive projects, unless you don’t mind carrying the codebase yourself! Any comments/things to add here?
13. 13 Everyone’s got a bit of bias, especially if you’re a tecchy. Try not to bring it to the table. “preferred architecture” are the big-picture issues: What platform do you want to run it on? What skills do your developers have? Do you have budget to train them in a new system? There are hundreds of CMSes out there. This will narrow it down a lot. Requirements, requirements, requirements. If it needs to support inbound RSS syndication, say this. If the editing interface needs to work in Firefox, say this. The lower-level the better. You ultimately want to have a big list of functional requirements, where each requirement is one function. Then score each CMS, either by weighting each requirement or skewing the scores. You don’t want a linear scale because some requirements will be more important than others, and a CMS that meets half your requirements well and the other half not at all, is worse than a CMS which meets all of them halfway. I’ve got an example over the page…
14. 14 Here’s a sample of the requirements matrix we used at Surrey HIS. Names obscured to protect the innocent. Bt notice how we give large negative scores to CMSes that don’t meet requirements. There are other ways to do this; e.g. “the wheel”
15. 15 Show of hands – is anyone else in the room using Plone?
16. 16 We don’t recommend or mandate the use of Plone at all. Remember, it’s not part of our remit! However it’s a good fit for a lot of typical NHS requirements, which is why we use it. If anyone else in the NHS uses it, they’re welcome to any code or extensions we write. Zope is written in Python
17. 17 I was involved in the selection of Plone at Surrey HIS We used the functional evaluation matrix you just saw. Plone came out ahead It had other benefits e.g. lower costs across multiple deployments Unlike many OS CMSes, it’s easy to deploy – Plone on a stick! It also runs just fine on Windows. Plone community is large, generally professional and helpful. Several companies provide commercial support. It has excellent accessibility (and multilingual capability) out of the box There was some precedent, as other NHS organisations were already using it.
18. 18 Note – this could equally be called “CMSes, a retrospective” as some of it’s to do with our project management practices etc rather than anything to do with Plone. It’s worth explaing “easy deployment” vs “alien technology”. Plone is really easy to get running and make basic customisations. Then you hit a Z-shaped learning curve while you try to get used to the (unconventional but very powerful) way Zope has of doing things.
19. 19 What Plone does (CM) it does very well and there’s often no need to extend its base capabilities. Sometime it’s easy to do this because of the power it gives you, sometimes not so easy. Sometimes PHP et al are better for writing a little web app from scratch. The "allow everyone to maintain their own content" is a bit of a false hope Unless they're good writers Unless the system is uncommonly easy to use, responsive and virtually bug- free This can be partly addressed through training, but not completely. Some degree of editorial control is still required for a good site We now have a dedicated "web editor" resource We're currently trying to find a good balance between centralising editorial control and giving it all to users What we're typically finding is that many of our users still send content through to the web team for uploading. Of those who don't, they'll still send content through when they strike something they can't do e.g. detailed table formatting. Of those who don't, the minority actually produce "good" (well written, accessible) content. Get it as close to right up front as you can! If you know you need to scale, plan ahead.