This morning’s session is described as a ‘panel’ session – with a mixture of speakers.

First up is Richard Brierton from the University of Sheffield on ‘Replacing your CMS’. University of Sheffield have used Polopoly CMS since 2003, with 600 editrs, 100,000 pages, and 14,000 new pages per year. However Sheffield were running an old version of Polopoly (version 8) – and Polypoly had decided to rewrite the product for version 9 – so Sheffield were on an unsupported version, but the upgrade path not straightforward.

Negative feedback on the CMS system from users – “breathtakingly shit” was one phrase used in a feedback form! So time for a change – but want to preserve the good stuff while getting rid of the bad. Lots more experience with CMS now than when they first implemented in 2003.

Try not to blame the system for failings when they are about implementation or policy decisions. If CMS is the answer, what is the question? Making CMS easier to use actually increases the number of people you need to support – when you set the entry bar to editing web content, you are dealing with small numbers – but as you make it easier to do, you get more people, with less experience, editing content on your website. Lots of the problems you see are about bad practice creating content – e.g. using ‘click here’ for links.

Users don’t deliberately set out to make bad sites. No matter how many ‘checks’ you put into your CMS to encourage best practice, it doesn’t get away from the need to educate – e.g. requiring an ‘alt’ description for images doesn’t make people put in sensible descriptions – and the CMS can’t make this happen – it is about education.

Richard lists his ‘7 Commandments’ (more what you’d call “guidelines“):

• Keep the 90% (of users) in mind all the time
• … oops – missed a few here – hope it wasn’t “thou shalt not kill your web manager”, or “thou shalt not covert thy neighbours website”
• Editors will often best-guess when unsure
• Avoid unnecessary flexibility
• Most editors don’t care – most people are doing other jobs – they aren’t that interested in the web, but need to publish information

Practicalities… Sheffield had to:

• Develop a new CMS
• Develop a migration process – mix of generated HTML, parsing content XML form old system, used CouchDB to store content, used Polopoly import tools – not just migration, but Sheffield team also cleaned up content
• Roll-out departments one-by-one – don’t need to migrate all content in one go – but does mean supporting two CMSs during migration period