Digital Marketing & Communications

We've seen 1s and 0s you wouldn't believe

Topic: CMS

In April the University website is changing

📥  CMS, Communication

Just over a year ago, the University began work on an ambitious project to develop a new website and publishing platform to replace our nearly decade-old content management system.

We are now ready to begin launching the new

The new website is:

  • optimised so people can use it on their desktop, tablet or mobile phone
  • easier to navigate and search
  • faster

The Professional Services departments going live over the next few weeks are:

  • Accommodation, Hospitality and Security
  • International Relations Office
  • Student Services

The launch forms part of a larger Professional Services transition programme which will roll out over the next three months, allowing us to trial the new design and content with a larger audience.

We’ll use feedback from this trial to help us to continue to improve the website.

To make sure go live is trouble-free, we’re working with each Professional Service to identify the best time to launch. When we go live, we will archive the old site.

All old web addresses will continue to work, redirecting you to the equivalent content on the beta. These redirects will remain live for six months.

Over the last 12 months, the Digital team has worked with publishers from across the University to transition their content to the new website. This work involved:

  • auditing over 500,000 content items
  • identifying what content to migrate, archive and delete
  • writing a goal for each content item as we migrate it to the new platform
  • transitioning content

In less than five months, the University publishing community has re-written and uploaded nearly 1,400 content items to the new publishing platform.

To make sure each page is correct, we've asked subject experts to check the facts. If we’ve missed something, email, tell us what's wrong, and we will contact the editor responsible.

Alternatively, if you have a suggestion on how we can make the new website and publishing platform even better, you can submit your feedback using the 'Suggest an improvement' link at the bottom of every page.


Getting ready to go live

📥  CMS, Style, content and design, Tools

As you might have noticed from our latest sprint notes, we're getting pretty close to shipping some of our first full sections of the beta site.

We've had a handful of individual pages live for months now, all for new content. But soon it'll be the first time we replace an existing section with new content from our new CMS.

Before we ship anything, there are a few things we have to do to get these sections – and the beta site as a whole – ready to meet the world.

Our review process

All content in transition goes through a five-stage process:

  1. Substantive edit and review
  2. Copy edit
  3. Fact-checking
  4. Final proofread
  5. Sign-off and go live

We use Trello to manage this process. Every section has a board, every stage has a column, and every piece of content has a card. As the content goes through the stages, it moves across the board, and eventually into the final column: 'Complete'!


How we implemented file uploading in our CMS

📥  CMS, Development


The setup

We have built into our CMS the ability to attach files to our Publication content type. Here I'll go cover the steps and hurdles we went through in implementing this very common feature.

On our first pass we took the often sensible approach of keeping scope small. We decided to build the ability to attach one file. Then we would iterate towards multiple attachments in later sprints.

Our first decision early on was to pick Thoughtbot's Paperclip library to help us implement this feature. Thoughtbot have a strong reputation among the Ruby community and we admire their approach of keeping things simple.

As part of our first iteration we had to do a ton of work around infrastructure set up too.

  • we needed dedicated network file storage for:
    • staging
    • training
    • and production
  • plumb in these file mounts to the CMS Editor so that we can show the file back to the user
  • changed our Mina deploy scripts to add an alias into RAILS_ROOT/public
  • and then copy the file on publish to the web server along with our HTML static page outputs


The twist

After we shipped this first iteration we discovered a bug. Once you uploaded a file and hit save, if you encountered a Rails validation error you would lose your new attachment. So you'd fix your validation error but you wouldn't know that you had to upload that file again. This was especially bad if you were editing to change the attached file. If you had to fix other changes, you wouldn't realise that the attachment reverts to the original.

Twisting further

But Paperclip can handle this right? Wrong! It's a known bug (since 2009) that they won't fix! The most commonly suggested fix to this bug is to re-implement with an alternative library called CarrierWave.

A developer having a bit of a rage


Act two: So CarrierWave...

...fixed this bug. It involved a rewrite of the code, but at least we could re-use all the infrastructure we'd set up. Next up, multiple attachments!

Another twist!

Our first attempt at implementing multiple attachments brought back the bug...

A developer having another rage


A developer having even more rage


The final act

This time CarrierWave wasn't caching the attachment because we had applied it on the parent object in our polymorphic model. The fix was to re-do the code (again). Thankfully this time not as drastically as before. We are still using CarrierWave after all. We simply (!) applied CarrierWave to the Publication object itself rather than to its parent.

This model is closer to what we started with in our first implementation as well.

So now it's all simpler.


Despite all the hardship I was reminded that 10 years ago when we built the LMF we had to support file uploading. In that time we had to do a lot more of the work ourselves. Even though we had things like Apache Commons' IO library, all that gave us was binary streams and we still needed to write code to handle output to disk. That all took much, much longer than this rollercoaster attempt we made in Rails many years later. It's been an interesting contrast.

Introducing the new Bath CMS

📥  Beta, CMS

Today the University’s new content management system went live, and publishers in departments around the University will begin using it to publish their content to the web.

This marks a major milestone in transforming how the University communicates and delivers services digitally.

published status notfication in CMS

Published item

Roll out

We are coordinating a rolling launch so that each department is supported by the Digital team as they develop new pages. The first group of departments will transition in September and our goal is to have completed the last group by the end of 2015.

We are looking forward to seeing the new site gradually unfurl and we’ll be posting updates as departments and sections of content switch over. Staff and students on campus can see a preview of the new website as it takes shape at

You can find links to pages that have transitioned to the new site by looking at the sitemap page.

Big benefits

We studied what publishers at Bath needed from a CMS and developed the software to meet those needs. Any publisher using this new CMS will be better off than they were before.

Our new CMS is designed to be simpler, quicker and more pleasant to use. The most important features are:

  • templates that make it quicker to create and edit content
  • dashboards that make it easier to find and manage your content
  • editorial tools that make it simpler to ensure consistent quality.

It will improve the quality of content and enable more staff to publish material online without the need for specialist training in using the software. (more…)

Publishers, prepare for launch

📥  Beta, CMS

On 2 September our new content management system will go live and department web publishers will be able to start using it to upload content. Which is very exciting.

Because of the large volume of content that is being transitioned, we will be moving departments across in groups (between now and December) so that the Digital team can be on hand to provide support.

People discussing design mock-ups

Digital will support departments as they move their content

A new CMS for a new site

The new CMS is very easy to use and will support the new University website. While your department is getting its content ready in the CMS, you will be able to see the work in progress at

Once your department is happy with its content, a date will be agreed to 'switch-over’ to the new site, which is the point that you’ll no longer be able to visit the old version.

The CMS will go live with the essential features that publishers will need to use to get their information online. We'll be adding new features over the coming weeks and publishing a prioritised feature list online so that you can see what is coming next. And, of course, you’ll be able to put forward suggestions for new features and improvements to existing ones.

Ready, steady

While you are waiting to transition your content you can:

  1. keep refining the user needs for your content
  2. practice with the content types in the training version of the CMS
  3. show off the new CMS and site designs to colleagues in your department.

There will be a 'transition checklist' provided to each lead publisher in the weeks ahead of each department's transition to help coordinate everyone's activity.

If you haven't been involved in the project to date and you want to know when your content is moving across, the best thing to do is contact the person who heads up your communications activity in your department. If you aren't sure who that person is, contact us via


Improving support for lead publishers during transition

📥  Beta, CMS, Communication

Transitioning our content to the new CMS is a lot of work. The early part of the transition in particular involves lead publishers of departments and services across the University reviewing their content, deciding whether to transition it or not, assigning it a content type (like Guide or Project) and giving it an action (like major edit or delete).

With more than 40 Lead Publishers auditing hundreds of inventories, the content team gets a lot of questions.

Pressure on editors

Up until recently, these questions were sent directly to the three Web Editors in the team who are assigned to Lead Publishers as their single point of contact. Individual Editors were the only ones who could see the questions and the only ones who could respond. This threw up a number of issues for all involved:

  • as a team we couldn’t estimate for delivering support in our sprint planning
  • the work wasn’t being captured in any of our boards or planning
  • the increased workloads impacted on the Web Editors’ ability to deliver other sprint work
  • sometimes Lead Publishers weren’t receiving a response for a number of days, which meant that some of them were unable to progress their work.

Our new process

In true agile fashion, we have pivoted and iterated our support process.

Now, our Lead Publishers email all questions to a dedicated email address that the entire content team has access to.

Each morning one of the Web Editors checks the inbox and triages the queries. They then add the questions to a dedicated Trello board, give each a category, evaluate its complexity with points and assign it to one of the team members, with the aim of the Lead Publisher getting a response within a day.

Bringing support into the fold

This is the second sprint in which we have been using the new support process. During that time we have received more than 60 emails to our shared address. This has translated into 35 tasks completed and recorded on our support board.

Being able to record our workload more accurately has been reflected in our sprint velocity and helped in scheduling other sprint work.

This is important as dealing with stakeholder queries is an integral part of our work, one that requires sufficient time and attention and had previously not been accounted for by our scheduling processes.

Sharing the workload

The new process has taken the burden of support work off the shoulders of our Web Editors and allowed other members of the content team to step in.

Work has been spread across the team more evenly, freeing up the Web Editors to progress more of their allocated sprint work, while giving the rest of the team a greater role in support and stakeholder engagement.

Supporting our publishers

Sharing our support process has also resulted in a better experience for our Lead Publishers. If a member of our team has an especially high workload or is out of the office, it no longer impacts on how long it takes for questions to get a response. We can now consistently provide faster support, and that makes the Beta transition process faster and better for everyone involved.


Building a boot camp for auditing web content

  , , , , ,

📥  Beta, CMS, Training

Auditing inventories can be a daunting task. Publishers auditing inventories as part of the transition into the new publishing app will have to review a lot of content while also having to consider content types and migration options. To help, we are providing training 'boot camps' for all the stages of this process.

The first thing we need to train publishers in is how to audit their content, determining what to transition, archive or delete. Rather than visit every department offering one-to-one training, we decided to hold an audit boot camp session for groups of six or more at a time. We would talk through the inventories we created, inform people of what auditing will involve and enable them to self-facilitate this process.

Designing a boot camp

When sitting down to design our boot camp, the first thing we did was set our objectives. By the end of the session publishers must be able to:

  • carry out a review of the inventory
  • make informed decisions on content types and migration actions
  • know their next steps, timescales and deadlines for the project.

We decided to make the boot camp a three-hour training session and created a 180-minute timeline. Having blocked out time for introductions, a break and a summary, we started thinking about how much time we had and how long to spend on different elements.

We knew that we needed to give our trainees an understanding of:

  • what agile content is
  • the cost of maintaining content in terms of staff time
  • our inventories and their analytics data
  • the content types available in the new CMS
  • the next steps publishers will need to take
  • how Digital will support them going forward.

With these objectives in mind, we created a series of presentations, handouts and exercises. Rich wrote a presentation on agile content and designed an icebreaker exercise in which trainees would be assigned cards representing content with a number of points on them, in which they had to select cards adding up to no more than 20 points. This would be followed by a walkthrough of our inventories and content types, and exercises in which people would get a chance to select content types and decide what to transition, archive or delete in a practice inventory. There would be time at the end for questions and discussion.

We planned this all to come in at 160 minutes, to give us some leeway for when exercises or talks inevitably overran.

Putting a plan into practice

Our first session was with the Faculty Web Editors. We had two trainers (Rhian and Rich) and one observer (Justin), and all three wrote notes from the sessions, recording what worked, what timings needed to be revised and what could be iterated on.

What worked

Our icebreaker exercise proved very effective in underlining the relationship between the value of content and how much it costs to maintain. The discussions that followed it and other exercises were very valuable for both trainers and trainees.

Based on observations within the session, the attendees seemed to appreciate the 'practical exercises' more than having to listen to talks and walkthroughs. Having to work as a group and spend time figuring out the relationships between content helped them put the project in perspective.

What needed tweaking

While our first session was successful, it showed us that 20 minutes wasn’t nearly enough slack, and three hours wasn’t long enough for the entire session. We had to rush through some of the discussion towards the end, just when it became clear that this was very important to our publishers.

Take 2

Publishers attending Audit Boot camp

Our publishers are put through their paces at audit boot camp - and are rewarded with biscuits.

We made several improvements based on the the first session. We added an hour, mainly to ensure that publishers would have enough time to talk to each other, put forward ideas and ask questions. We were ruthless in editing ourselves, and cut back the length of Rich’s Agile talk from 10 to 5 minutes to free up more time to focus on the skills required for auditing and selecting content types.

Our second session ran a lot smoother, with the extra hour allowing us to explain things more fully and have a more detailed back and forth discussion.

How we applied this to other boot camps

The audit training session is only the first of three different boot camps for publishers. Trainees who have attended audit will then go on to boot camps for User Story Planning and Content Creation.

We learned valuable lessons from our first session, namely to consider the following when planning a boot camp:

  • have a very clear idea of the outcomes and objectives you want the session to achieve
  • ensure all presentations and exercises contribute to these objectives
  • make sure there a plenty of practical exercises, and not too much time spent just talking at trainees
  • allow trainees plenty of time to talk about what they are learning
  • make sure by the end trainees are clear on what they have to do next, and feel enabled to do so.

If you wish to find out more about our training, then email your “single point of contact” in the Digital team. To book yourself on a session, complete our booking form.


📥  Beta, CMS, Development, Tools

We've changed just about everything to do with how we manage for the alpha, and this includes the underlying technology.

The live is hosted dynamically from a monolithic Java-based CMS (OpenCms) running on Solaris servers with Oracle as a back-end database and all the code is in Subversion.

The alpha site is being served from static HTML files generated by Hugo. The inputs are provided by multiple Ruby on Rails apps running on Linux servers using MySQL, MongoDB and an off-site service for data storage, and all the code is in our local GitHub Enterprise installation and is deployed from Bamboo by Mina.

The difference could not really be much bigger! It's certainly been a challenge to get up to speed with so many new things all at once but we think that this stack, or some version of it - that's what alphas are for! - should be more future-friendly than our existing infrastructure.

We'll go into more detail on how we're using each piece of technology in the following days and weeks.

Launch of

📥  Beta, CMS

We are pleased to announce the launch of a new test version of The launch of the Alpha is a major milestone in our programme to improve the University’s digital communications.

Included in the Alpha are a new homepage, new page templates and a new content management system. Each of these Alpha elements represents our new approach to leaner, user-centred publishing online.

The purpose of the Alpha is to put our approaches to the test with a larger user base than we’ve previously had access to. From January 12th - February 28th we are redirecting all staff and students to the Alpha homepage and About section. During this time we’ll capture feedback and data to steer the next stages of development, which will be the Beta [site and CMS] to completely replace the current from Summer 2015.

The Alpha was produced in between our other project work over the course of 3 months by a small multidisciplinary team. We based the design and development on data and insight drawn from analytics, casual feedback, discovery projects, support tickets and structured user interviews and testing.

The Alpha infrastructure could not replace the current at this stage. Over the course of the Alpha period we will be publishing follow up posts to this one explaining in more detail the approaches we've taken with design, technology and the editorial model, where we hope that they'll take us as well as what we are learning from the experience.

If you visit the Alpha, we hope you find it a positive step forwards. Feedback is always welcome and can be provided via the survey on the Alpha pages, via or in comments on this post. We look forward to hearing from you.


Show & Tell, October 24 2014

📥  CMS, Design, Development, Show & Tell

We celebrated 11 months of Show & Tell last week with another Show & Tell. On the agenda this week: editorial calendars, rebasing, analytics and some exciting new alphas.

Flow - Charlotte

Last month, Rhian talked about how she and Charlotte had searched for an editorial calendar tool that did everything they needed, but didn't come packed with superfluous features. After initially turning to Google Spreadsheets, they've now spent two weeks trialling Flow, and Charlotte updated us on their first impressions.

They particularly liked how Flow offers:

  • a clear calendar view, with the option to drill down into the details
  • quick scheduling and tagging of items
  • dragging and dropping items between dates
  • the option to look at individual calendars, or an overview of everything.

Overall, we like Flow and we might use it for more editorial calendars in the future.

Ace of Rebase - Tom N

We've been using GitHub more and more for our version control. Mostly this has been a happy and prosperous time, but one aspect of Git has been repeatedly responsible for screams of horror in the office: rebasing. To provide some context for the screams, Tom talked us through what rebasing is, why you should do it and what can go wrong.

Git allows multiple people to work on a project simultaneously and engage in jolly cooperation. One master copy of the project exists, with everyone working on different features in their own individual branches, which are copied from the master. You can then merge these branches back into the master copy and combine everyone's work.

But what if other people have merged their branches into the master copy before you? Your branch is now out of date. You may know the feature you've been working on will still play nice with the new master, but if you try to merge it back in normally, you might overwrite work that people have done since.

This is where rebasing comes in. Essentially you need to change history and pretend your branch started with the current master, not the one you actually started with several versions ago. You can then add your work to the project without wiping out anything else that's been done since you started it.

Boromir: "One does not simply Git rebase it!"

Boromir, who destroyed the fellowship of the sprint team after overwriting the repository.

Rebasing is fiddly stuff - when it's done right, it's great, but get it wrong and you could lose a lot of work on a project. Tom's top tip for avoiding extreme pain and suffering was to use interactive mode when you rebase, or everything goes boom. analysis - Takashi

Are we putting the right amount of effort into the right places? Takashi recently did a top level analysis of to compare the size of our various sections with how much attention they get from our users. He presented his findings, which included:

  • our study section gets the most traffic
  • the Computing Services section is our biggest in terms of size and number of files
  • many CMS users have edited less than ten pages in the last six months, but some have edited over 500
  • the rate of users accessing from Google is rising, while traffic from Facebook is dropping
  • visits from social media tend to be shorter and less engaging.

Takashi also wowed the room with some good-looking treemaps and fielded some questions about his information visualisation secrets (Google Spreadsheets).

Prospectus alpha - Rhian and Liam

Rhian, Liam and Tom T have spent several weeks working on a new app to collect and update the information in our prospectus.

We want our prospective students to get a consistent experience, so we need to integrate the content we put on the web and print versions of our prospectus.

Rhian and Liam gave us a demo of the shiny new Ruby app and showed us how adding a new course would work. User testing has already given the team some very useful feedback, so they'll be testing it with more of the app's future users as they continue to work on it.

Future iterations will tackle workflow and version control, and we hope the new app will be an improvement for the people who create the prospectus and the people who read it.

CMS alpha - Dan

The CMS alpha is the biggest project we're working on at the moment, and Dan's been handling the user interface (UI) for the editing app.

The UI for the CMS needs to be:

  • clear
  • concise
  • consistent
  • accessible.

After setting out these requirements, Dan gave us all a demo of the UI he's been working on and showed us what editing different content types will look like.

Ros from Monsters Inc with "FORMS" in big letters

Sometimes you've just gotta have them.

The new UI looks much more straightforward and user-friendly than our current CMS, and it also confirms to Level AA of the Web Content Accessibility Standards.

Work on the alpha continues this week. If you want to find out more, have a look at Ross's blog post about our plans for the CMS.