Digital Marketing & Communications

We've seen 1s and 0s you wouldn't believe content by the numbers and the next steps

📥  Beta, Development, Style, content and design, Tools

In March, the Digital team set out on an ambitious project to inventory

Our purpose was to learn more about the content we create and the publishers who write it. Gathering this knowledge with a thorough inventory process is something that I have wanted to do ever since I joined Bath in 2011.

This is what we found, how we found it and what our findings mean for how we plan, govern and build better content.


Deploying Rails applications using Mina and Bamboo

📥  Development, Tools

We use Mina to deploy our Ruby on Rails projects. With our deployment scripts written and packaged into a gem we wanted to make use of our continuous integration server to build and deploy automatically to the production and staging environments.

Our continuous integration server is Bamboo which needed a little configuring to play nicely with Ruby. The packages containing the Ruby binaries were installed on the server and recognised by Bamboo (via auto-detection on the Server Capabilities admin screen) then we added the free Bamboo Ruby Plugin to give us Bundler tasks. This kept the deployment plans easy to understand by avoiding as much as possible the need for manual scripting.

The important tasks for us were "Bundler Install" (obvious what that does) and "Bundler CLI" which let us run our mina deployment commands using the bundler environment with "bundle exec". A bit of messing around with SSH keys and it all works beautifully.

The final setup is:

  • A Bamboo build plan pulls the code from github and makes it available as an artifact (tests are run here)
  • A Bamboo deployment plan takes the artifact, runs "bundle install" to get the code required for deployment then runs the mina tasks to push it to the server

Bamboo allows us to trigger each of these steps automatically so we can deploy a new version of our application just by merging code into the appropriate branch in our repositories. We deploy to both our staging and production environments in this way which makes for a simple workflow, all in Github. The results of the build are sent to us via email and appear in our Slack channel. Bamboo has also let us schedule a rebuild and redeploy of our staging environment on a monthly basis so we will be alerted if a piece of infrastructure has changed and caused our tests to start failing.


Digital roadmap update for June 2015

📥  Roadmap

Version 11 of our Digital roadmap has been approved by the Digital Steering Group, and looks ahead to July and beyond.

Progress made in June 2015

  • Delivered CMS content input and output features, and established editorial roles and permissions.
  • Coordinated and tracked content inventory audits across all departments.
  • Provided training in how to conduct a content audit and produce user stories.
  • Assessed candidate software for creating interactive location maps against prioritised user needs.
  • Established the first version of a process by which new corporate social media accounts can be requested, set up and made available to colleagues across the University to support their engagement goals.
  • Produced content marketing plan for 50th Anniversary online channels.

Priorities planned for July 2015

  • Continue development of the new back-end and front-end content type templates and integration of workflow features (see fortnightly sprint notes for more details).
  • Support publishers in uploading and creating new content in the Beta publishing app.
  • Upgrade GroupManager, the app that simplifies the management and creation of groups (for use on the likes of controlling which groups of publishers can create or edit content on behalf of a department).
  • Continue integration of Eventbrite into event listings to provide booking management and manage the administration of multiple event organisers.
  • Apply our new visual identity and patterns to site search interfaces.
  • Set up a cross-departmental group to provide editorial coordination of student recruitment content.

Next update

University staff and students can find the detailed version of the Digital roadmap on the wiki.

The next version of the Digital roadmap will be Version 12 and is scheduled for release w/c 27 July. As it will be marking 12 months of running a Digital roadmap, expect the next roadmap to contain a number of significant updates to our strategy and plans as well as improvements to the roadmap format itself.


Improving the international country pages

📥  International, Style, content and design

We provide international applicants with specific information on entry requirements, funding and scholarships, university services for international students, how to contact an agent and forthcoming visits. All of this information is on our country pages.

As part of the development of the Beta site and the University's new International Strategy, we aim to improve the international content across the website. In June, we performed an audit of 51 country pages and discovered that:

  • content did not address specific user needs
  • there was duplicated information that also appeared in the prospectus
  • user journeys were fragmented making it difficult for applicants to find information
  • the layout of the information was not consistent.

As a result, we have made the following immediate improvements:

  • created tailored content to meet specific user needs for each country
  • removed duplicated content
  • updated the entry requirements, scholarships, agents and forthcoming visits information
  • re-ordered and re-named the tabs to improve user journeys.

For the next step, we will continue to monitor the external traffic to these pages and make iterative improvements based on the data.


Tracking the progress of the Beta: one whiteboard, 300 spreadsheets

📥  Beta, Tools

Very early into the Beta, we started to face a big question: how do we track the progress of the Beta programme?

We use Trello and Pivotal within the team, but we didn't just want to track what we were up to - the Beta involves dozens of people, working on hundreds of sections and almost a million assets. We needed to be able to see the progress of individual sections, whole organisations, and the entire programme overall.

We went with one of our favourite solutions: stick things on the wall.

In praise of the wall

Our office walls do more than hold up the occasional Zelda poster. We use them to as sprint boards, team schedules, annual leave calendars and reminders of our delivery principles.

The biggest benefit of sticking something on the wall is that it's very visible. You can quickly glance at it while you're working, or discuss a project without crowding around one person's desk - which is great when we have office visitors.

So we stuck our tracker on the wall, and named it the Totally Awesome Content Trackatron.

Rich "smizing" in front of the Trackatron

Rich does his best smize in front of the Trackatron. We added a lot more cards after this.



Digital team sprint notes, 9 - 22 June 2015

📥  Sprint notes

What we did

  • Created browseable lists of events and designed filter options.
  • Released the front end templates for events and event listings.
  • Released front end template for team profiles.
  • Refined the CTA elements to make it clearer that they indicate a next step.
  • Set up groups of publishers based on their departments.
  • Stayed in contact with lead publishers going through audits and kept our tracking of audits up to date.
  • Created visualisation to show the predicted usage of content types based on audit data.
  • Provided content auditing training.
  • Updated user story training materials based on feedback from pilot session.
  • Completed audits of first tranche of sections managed by Marketing & Communications.
  • Began auditing of international content, including IRO section.
  • Provided support to Open Day online and around campus.

What we will do (23 June - 6 July 2015)

  • Create filterable lists of events.
  • Enable the clearing of old editions of content items.
  • Enable more granular control of roles and org-based access to content.
  • Iterate the colour palette and optimise the display of site fonts.
  • Continue support of publishers carrying out content audits.
  • Deliver training in content creation using agile methods.
  • Continue auditing content managed by Marketing & Communications.
  • Development of general communications about the release of the new
  • Preparation of student induction materials.
  • Development of separate production environment for
  • Update of Group Manager application.
  • Review of custom location mapping software.

If you want to know more about any of work listed on these sprint notes, email

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.

Automatically shipping early and often

📥  Beta, Development

We're an agile team, but rather than dogmatically follow a proscriptive capital-a Agile methodology we try to hew closely to the principles behind the Agile Manifesto.

Principle 3:

"Working software is delivered frequently (weeks rather than months)"

We're trying to do better than that. Sixty days after starting, we made the 100th release of our beta CMS to the staging server and the 21st release to our production server.

As Kelv has described before, "staging" is where features get deployed as and when they are completed so that we can run acceptance testing before they move into our production and training environments.

This little milestone represents many hundreds of individual changes by both developers and content writers over the last few months. Because each change is automatically sent to our servers when it's completed, this milestone happened completely transparently and with no fuss. This is exactly as it should be!

This is the first project where we've used Continuous Delivery. It did take some time to plan and set up the infrastructure in advance, and because we're still in development we're yet to battle-test the fact that the frequent deployments are totally seamless for people using the CMS. Nevertheless, the fact that we can deploy whenever we choose is a massive time-saver, allowing us to maintain a state of flow for sustained periods.

Some of our other projects are still using point-in-time pre-scheduled releases which we need to run manually and they already feel archaic. We're hopeful that we can take many of the processes we've developed during the CMS beta and apply them to these other applications, removing the burden of having to remember (or look up) many different deployment configuration intricacies.


Digital team sprint notes, 23 May - 8 June 2015

📥  Sprint notes

What we did

  • Designed and added the front end template for events.
  • Designed front end template for team profiles.
  • Improved location detail fields in event content type to provide on and off-campus options.
  • Created a browseable list of all events published in the new Beta CMS.
  • Added field length validation guidance to content type fields.
  • Continued to support departments’ content audits.
  • Made first forecast of the order in which departments will transition to the new CMS.
  • Designed and arranged the first user needs analysis workshop.
  • Created senior management leadership profiles using the new content types.
  • Published improvements to guidance for international applicants on each country page.
  • Technical support received 74 tickets and resolved 67.
  • Content maintenance received 4 support requests and 3 were resolved.

What we will do (9 - 22 June 2015)

  • Deploy the front end template for team profiles.
  • Design and build the first version of filterable lists.
  • Create the first iteration of organisation-based roles and permissions in the CMS.
  • Organise remaining briefings on the Beta transition.
  • Organise remaining audit bootcamps and next user story workshops.
  • Organise next user story workshops.
  • Carry out auditing on international and marketing sections of
  • Start the design and build of the 50th Anniversary website.
  • Produce first version of process and guidance for requesting an official University of Bath social media account.
  • Supporting the June Open Day.

If you want to know more about any of work listed on these sprint notes, email


How to share in the rewards of user research

📥  User research

Our priority principle is 'Put users’ needs first'. Lately we’ve been helping University teams to carry out their own user research. We've found it very effective and we now want to encourage more departments to get involved.

Why we prioritise user needs

There are people out there who know how to make your department's digital presence the best it can possibly be. Those people are the users of your information or services.

For our users, is a tool to get things done. Some sections of the platform cater for general users, such as information about our courses or directions to campus. Other sections of the platform serve very specific groups of users, like the content management system used by our publishers or guidance for alumni mentors.

Putting users’ needs first assumes that what’s best for our users is what’s best for the University. So when we are designing, developing or creating content for, our users and their need for quick and simple access to information and tools are informing and motivating our every effort.

How we develop an understanding of user needs

Putting users first is just lofty principle unless we make a concerted effort to learn about our users. We need to continually work away at developing a better understanding of how our ‘users’ breakdown into cohorts, what the needs of those cohorts are, and how they would like those needs to be met.

Some other organisations benefit from the budgets or the specialist in-house staff to maintain a continuous flow of user research being fed into their digital development processes. We have neither, but we haven't let that frustrate us.