Digital Marketing & Communications

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

Digital Roadmap update for March 2015

📥  Roadmap

After a brief hiatus, our Digital Roadmap looks ahead from March 2015.

Progress update from February 2015

  • Carried out user research to improve content item navigation
  • Introduced Collection pages tailored to particular audiences or specific subjects
  • Users can now explore content types using filtered lists
  • Introduced a Facebook page for prospective undergraduate students starting in 2017
  • Made it easier for our users to find and listen to our Public lectures by migrating our podcasts to Soundcloud

Priorities planned for March 2015

  • launch a Professional Services beta, including Accommodation and Hospitality, International Relations and Student Services
  • Investigate the University's activity in South Africa to support a 'takeover' of our new Worldwide Collection page
  • Carry our Staff profile user research
  • Work on the first iteration of our performance platform

Next update

University staff and students can find the detailed version of the Digital Roadmap on the wiki via We will release the next version of the Roadmap on w/c 11 April 2016.


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'!


Digital team sprint notes 9 - 22 February

📥  Sprint notes

What we did

  • Turn the names of the Organisation and Content Type links at the top of a content item into links to the appropriate lists of content
  • Changed the styling on those links to make it easier for visitors to move around the site
  • Improved microcopy for our Projects content type to more clearly denote the type of project
  • Unpublished almost all items in the production CMS in preparation for transition
  • Prevented Google and other crawlers indexing our new CMS-related folders on in preparation for transition
  • Some errors in our Funnelback configuration generated nearly a thousand tickets into our support system (great for testing its features!)
  • Received 369 other issues into support and resolved 304
  • Got nearly all our new Student Services content ready to be fact-checked by the subject matter experts
  • Started transitioning our content design guidance and style guides into the CMS from the wiki
  • Updated the Worldwide collection to bring it in line with our CMS-generated content
  • Completed preparation for testing the Person Profile content type
  • Performed some discovery on the information we display at the top of each content item

What we’re going to do

  • Add additional metadata to CMS pages and allow this to be tracked and reported on by Google Analytics
  • Configure for selected web pages to allow us to get better page usage data
  • Create the list of all Organisations (eg. Departments)
  • Create the list of all Groups (eg. Graduate School, Committee)
  • Display the associated Organisations and Groups on an Organisation Landing Page
  • Finish transitioning our editorial style guides and CMS formatting guidance
  • Get accommodation, eateries, hospitality and security content ready to go live
  • User testing for the summary section at the top of every page


Digital team sprint notes 26 January - 8 February

📥  Sprint notes

February has seen the plague sweep through Digital towers, but we soldier on!

What we did

  • Extended the character limit on titles (and updated guidance about doing this).
  • Allowed visitors to filter the lists of content its owning organisation.
  • Changed how we display the list of available content types from landing pages.
  • Made the content type label on each item link through to the filtered list for that type.
  • Worked with colleagues at the University of Bristol to arrange testing of our information hierarchy.
  • Created a beta of the backend of our UG Prospectus application (the frontend was waylaid by all our designers being ill!).
  • Ran beta CMS training for some new staff.
  • Created templates in MS Word to allow us to collaborate with infrequent contributors to
  • Audited the popular news items on the current

What we will do

  • Contact the universities of Exeter and Cardiff (as part of the GW4 Group) to arrange more testing.
  • Ensure that we are listing all content items on our filtered lists.
  • Turn the owning Organisation or Group displayed at the top of each content item into a link to the relevant filtered list.
  • Stop Google indexing the beta for a little while.
  • Unpublish most of what we've published so far in order to prepare for a real site to go live!
  • Review all of the Student Services content in the beta in order to put it into acceptance testing before it goes live.
  • Prototype some course discovery tools.
  • Audit the events on
  • Transition our content design guidance to the beta CMS.

What tech we use to test our CMS: Minitest and Capybara

📥  Development, Tools


The road less travelled

For the Editor side of our new CMS, we have made a couple of choices in testing that are a little bit off the beaten track.

For starters we are using Minitest instead of RSpec. Most Rails devs will pick RSpec as that's what comes out of the box. And Rails devs who have been around for a few years are already familiar with RSpec.


You say shoulda, we say assert

We favoured Minitest because of the low barrier to entry it provided us. As a dev house that had mostly written apps in Java in the past, we're already comfortable with unit tests. We're also already familiar with the assertion style. We felt that as a new DSL to learn it's a much smaller and easier set to absorb than compared to RSpec.

On top of that we're using Capybara to run functional tests. This is yet another DSL to learn. We could've overwhelmed ourselves with DSLs! This is again written in Minitest assertions.

This is not without any downsides.

With RSpec and specs being the most common approach, examples and documentation are almost all written in that way. So we still have to negotiate the nuances of spec tests when reading examples. But because we're still unfamiliar to spec tests they're slightly impenetrable. On balance we've lowered the barrier to adoption and got to shipping code quicker. We were already on a learning curve with Rails itself so the early win was worth it.

The wider picture

With our stack we have 2 discrete services, glued together by Redis. Our current problem is that we only have tests for the CMS Editor and not the end to end publishing process. We do have some unit tests on the CMS Publisher middle layer. This is the bit that receives data from the CMS Editor (via Redis) on publish (or preview) and calls Hugo to render out our pages as static HTML. What we want is a way to test the functionality from the point of creating a new piece of content all the way to rendering it out as a final piece of HTML. Currently the impact to the front end from changes we make on the CMS Editor (for example) are obscured from us.

What we'd like to do is make use of something like Docker and auto deploy all the apps via our CI server Bamboo. We'd then have an end to end containerised system we could run full functional tests against. We'd also end up with the front end outputs which we could run regression tests on.

This is all stuff we plan for the future. Hopefully the next time I post we'll have achieved some of that!

Digital team sprint notes, 5 - 25 January

📥  Sprint notes

This was an extra-special three-week sprint to get our timings back in line with some of our other meetings, and it means we got some bonus work done!

What we did

  • Fixed several publishing and preview bugs.
  • Changed the position of the "Supporting information" section on the Campaign content type.
  • Removed the 'subject' field from the Case Study content type.
  • Allowed publishers to filter content in the CMS by its owning Organisation.
  • Contributors can no longer change the owning or Associated Organisations or Groups of a content item.
  • Established a set of design benchmarks using the most popular combinations of browser version, resolutions and operating systems which our visitors use.
  • Designed the styles for the links at the top of each content item.
  • Reallocated all of the Organisation Landing Pages to the correct Organisations.
  • Resolved 152 tickets in our support queue, 98.4% of which were resolved with the first reply.
  • Moved all of our podcasts into the University's official Soundcloud channel and wrote guidance on how to manage this.
  • Reviewed the usage of person profiles in the beta and on competitor sites.
  • Analysed existing news stories to see which should be transitioned into the beta.
  • Updated some of our content guidance and CMS usage instructions.

What we will do

  • Turn the owning Organisation and content type at the top of each content item into links to the relevant places.
  • Enable lists of content items to be filterable by owning Organisation or Group.
  • Begin a series of regular user tests.
  • Deliver a beta of our UG Prospectus application.
  • Begin a three-month trial of to manage our support helpdesk.

Who can do what, and where

📥  Beta

We now have over 100 people using the new CMS, drawn from 48 organisations and 28 groups. We also recently crossed the threshold of 1,000 content items in the CMS (woohoo!) And aside from organisations, all those numbers are bound to go up.

How do we make sure that users:

  • see only the content that's relevant to them, rather than every single thing in the CMS?
  • can edit only the content their organisation or group is actually responsible for?
  • can feature only the most relevant content on their landing pages?

The answer comes down to permissions – both for users, and the organisations or groups they belong to.


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.

Digital team sprint notes, 8 - 23 December

📥  Sprint notes

A slightly longer sprint in the lead-up to Christmas and here's what happened:

What we did

  • Provided preview functionality in the new CMS.
  • Implemented content type strata on organisation and group landing pages.
  • Changed 'Able' to 'Available to supervise research degree projects' on Person Profiles.
  • Restricted access to your items in the CMS to just publishers in your organisation or group.
  • Created a prototype of the Beta homepage for testing with users.
  • Created a new 404 page for the new site.
  • Fixed a bug with page deletion.
  • Updated the lead publisher guidance for several content types.
  • Reviewed six sections which have been transitioned into the new CMS.
  • Supported the Winter Graduation ceremonies.
  • Said goodbye to Ross!

What we will do (5 - 18 January)

  • Fix some bugs in the publishing and previewing workflow.
  • Provide filterable lists across all content types.
  • Allow publishers to filter the list of content items in the CMS by Organisation.
  • Add a new section to landing pages to display specially curated content items.
  • Make sure that all landing pages are allocated to the correct Organisation or Group.
  • Document our standards for testing UI on different devices and configurations.
  • Review the next four transitioned sections.
  • Discover some inventory and usage details for our podcasts.

The design function Christmas wishlist 2015

📥  Design, Tools

After a busy year, the onset of Christmas always provides a brief moment to step back and reflect upon everything that has happened over the last 12 months.

2015 has been our year for honing workflows, trying out new tools and technologies, and shipping, shipping, shipping.

This intensive regimen has left us shouting "This is great!" almost as much as "Why can't you just work, dammit!" Here are the top five things the Digital team design function would really like to find under our Xmas tree to make us feel all happy and fuzzy.

5. A GUI Git client with interactive rebasing

42 un-squashed commits in that PR? You have fun with that…

My chosen Git tool - Tower - lacks the functionality to make interactive rebases. This means I end up having to drop into the command line to squash commits for my PRs and that’s just asking for trouble.

Please Santa, can we have a well-designed, feature-rich Git GUI client with interactive rebasing for Xmas?

4. sudo vagrant ‘please just work’

Vagrant has been a real boon allowing us to run up an exact copy of our publisher and editor apps on our local machines. However it can be a bit of a nightmare to manage if you don’t lean towards the technical side of things.

Please Santa, can we have a better way of managing/configuring Vagrant boxes that doesn’t mean I have to know what my $path is?

3. Web fonts that work everywhere

As a design team we’ve really gone hell for leather with regards to our implementation of web fonts this year. Although we’re very proud of what we’ve achieved, it has been hard work tackling cross-browser rendering issues, OpenType hassles, caching and pre-loading, font verification and much, much more.

Please Santa, can we have a standardised web font format that works perfectly on EVERY browser and platform?

2. A version of Sketch with the line-height bug fixed

We’ve pushed almost all of our preliminary design work through Bohemian Coding’s Sketch over the last 12 months. I've been working with Sketch since the heady days of version 1.0 but the software was completely new to Liam. Although he could see the benefits of the stripped-back interface and laser focus on interface design, he was constantly infuriated by Sketch’s little ‘eccentricities’ and general bugginess.

Please Santa, can we have a version of Sketch that’s stable, reliable and fixes that awful line-height bug once and for all?

1. Project Comet to hurry the heck up

Adobe’s last great hope? Maybe that’s a bit dramatic, but Project Comet is looking like a genuinely interesting contender in the race to grab the interface design crown.

Please Santa, Comet looks better than anything Adobe has made in ages. Can you get them to speed it up a bit? (Or at least get us on the Beta.)

Have a very merry Christmas and a happy new year! May all your workflow wishes come true!