Everyone knows that it’s essential to build accessibility into projects at the earliest possible stage. However we created our accessibility principles before work even started on building EdWeb – our new Drupal based CMS.

This month in our support clinic we’ve been considering digital strategy: firstly, developing one; then promoting adherence to it, once in place.

The first site went live in the new EdWeb CMS this week. As it’s the beta version of the CMS we didn’t want to have a huge launch with a fanfare at this point. But it’s still a major milestone for us.

The foundations are now well and truly laid for the delivery of the University’s new content management system. The Polopoly replacement is based on the open source Drupal platform and will provide a much better user experience for web editors. It will also deliver responsive content – fit for phones and tablets.

This months’ Web Publishing Community saw our latest update on the Drupal project (EdWeb), an update on Google Analytics events tracking, and a presentation from Andy Todd about his experiences of creating training videos for the IS Skills team.

I ran our usability testing training course again yesterday, with another 20 members of staff leaving having seen their website or application in a totally new light. In this post, I want to consider what happens after usability testing. You’ve identified some problems; how do you see your fixes through?

We have over 300 sites and 70,000 pages to migrate from Polopoly into EdWeb – our new Drupal-based Content Management System. We are planning to do this over 3 main migration phases starting in March 2015. We recently started communication with our web publishing community to allocate them one of these phases.

We’ve been hearing a lot about Google Analytics (GA) lately. In July Stratos blogged about the implementation of GA event tracking in the Polopoly CMS and last month, Duncan posted about updates to our GA guidance to cover events and the latest design refresh.

We’ve recently been considering the need to provide a distinct name for the CMS we’re developing to bring clarity to what we are providing, and future project communication.

Managing your website through a large scale (or enterprise-level) content management system can occasionally feel like a frustrating or restricting experience. I know this because I’ve been a web manager myself, and I field enquiries and comments from time to time in this vein. I had one such email recently, and would like to share it […]