Digital Marketing & Communications

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

So long, and thanks for all the gifs.

📥  Team

On Friday 11 November, myself, Tom and Liam will be saying goodbye to the University of Bath.

I will have served for 14 years, 3 months and 13 days. Well, longer than that actually as that's when I started in a permanent position. Initially, I was working at the School of Management on a temp contract.

Tom Natt will have worked here for 12 years 2 months 17 days. His stint at the University is also longer than that figure. He joined as an undergraduate student back in 2001.

Liam McMurray will have done 8 years and 29 days. No gotcha there. That's how long he's been here.

Tom and I are founding members of the team. In the initial incarnation, we worked to an almost agency-like model. We took on projects for clients around the University and received funding for that work. This was because we needed some way of procuring funds for a team that was so new and not yet well established.

Liam joined as the team began to move away from this model. We started to focus attention on the critical parts of our website. Our homepage and our sections on studying saw multiple improvements from this concentration of effort.

Shortly after that, the team adopted Agile working practices based on Scrum. This helped us tremendously in our work. We continually prioritise and organise our work in order to deliver based on our users' needs.

Relatively recently we've embarked on an ambitious programme of transformation of our website. This involves putting our content through an evaluation against user needs. This a crucial basis for how we are transitioning content to our Content Publisher, and away from our legacy CMS.

It is fair to say that since the team's formation we have seen huge changes and improvements. After a very long journey, it feels the right time for the three of us to say goodbye. It is of course with much sadness. There is also a little bit of jealousy as we know that the team will keep improving. It's hard not be a part of it anymore.

The great thing about the Digital team is that, as someone once said, they keep being ambitious.

Digital team sprint notes 18 - 31 October

📥  Sprint notes

What we shipped

  • The first Faculty to transition into the Content Publisher is now live. You can browse the new Faculty of Engineering & Design section here.
  • Improved layout consistency by updating the vertical rhythm and typographic scale
  • Improved the legibility of long pages by updating the sizing for all our headings
  • Content that appears in the sidebar on large screens no longer butts up against the edge of the sreen on small screens
  • When a publisher updates a content item which doesn't belong to their organisation it no longer changes which organisation owns it
  • Publishers can now choose the ordering of people listed in Team Profiles
  • Changed our titling of "Team members" on Team Profile pages to be more generic
  • Provided a sitemap.xml file to make sure that all our pages published by Content Publisher are indexed by Google and on-site search
  • We handled 15 items of content support including:
    • updates to visa pages to point to new Tier 4 booking system
    • updates UG funding pages to reflect funding on offer for 2017 entry
    • updates to UG tuition fees pages
    • found alternatives to Vimeo for video content aimed at audiences in China
  • resolved 143 incoming requests for support

What we're going to ship

  • Improve layout consistency between different screen sizes
  • Increase the amount of spacing underneath embedded media content
  • Allow publishers to re-order members of a Team Profile by drag-and-drop
  • Add new subtypes to Team Profiles
  • Change the ordering of the 'Enquiries' and 'Address' fields on Department pages to make their location more predictable
  • Improve our testing by automating data transfer between our staging and production systems
  • The first part of allowing publishers to put a content item into preview without requiring it to enter the Review state


Work hard, bake hard

📥  Team

The Great British Bake Off is popular in our team, probably because our team is composed of humans. So, of course, we have enforced fun to go with it.

We call it the 'sweepbake' or 'sweepsbake' (opinions are divided on the extra s).

The rules are simple:

  • everyone in the office randomly draws a Bake Off contestant
  • when your contestant is eliminated, you must bring in baked goods, ideally homemade

The result is an onslaught of delicious carbohydrates that lasts for about three months.

Here are some of the treats we enjoyed this year:

Rhian's cheese straws

Rhian's cheese straws

Phil's cupcakes

Phil's cupcakes

Miao's cookies

Miao's cookies

Sean's apple pies

Sean's apple pies

Iris's lemon snickerdoodles

My lemon snickerdoodles

Fortunately, the campus has excellent gym facilities and some lovely running trails to balance all this out.

What I've learned in my first few weeks as a developer

📥  Development, Team

A little over two weeks ago, I started a new job in the Digital team as a Junior Developer.

While this job is new to me, the team isn't – I first joined in January 2014 as a Content Producer. But I'd been thinking about a possible move to development for a while, and found myself taking every opportunity to nose around our codebase and ask questions about how things worked. This escalated to building stuff in my free time (like a Rails app that makes it easier for our office to plan our massive orders for Schwartz Bros burgers). After a slightly scary interview, I was lucky to get the best of both worlds: moving my career in a new direction while staying with the team I've loved being part of for the last few years.

My new mission: build cool stuff that makes our users' lives easier. And while I've only just started, I've already learned a lot.

Turns out I am OK at this

Since this is my first job in development, I was a little nervous that it would take me a while to get up to speed and become a useful member of the team.

Fortunately, Phil and Tom apparently didn't share my nerves and had already drawn up a healthy to-do list for me to tackle. I was excited to be shipping code within my first week.

After getting through three relatively small stories, I moved on to my first bigger feature: making it possible for users to choose the order in which Team Profile list their members. As with all our team's work, this is now being reviewed by another developer and I'm looking forward to the feedback.

Content and development skills do overlap

The day-to-day of content and development might look pretty different. But our team shares a single set of Digital Principles, and those principles work for content, design and development alike.

Many of the things that were important when I was a Content Producer are still important as a Junior Developer, from working in an Agile way to taking the time to properly document processes and decisions. And striking the right balance of being clear and concise is valuable for writing both content and code.

Having experienced the challenges of content production and transition for myself, I also hope that will help me bring some unique insights to our development work.

Looking like a cool hacker

I've spent more time in the command line this fortnight than I probably have in my life. There's a lot to remember, but I'm already starting to see how it can speed up my workflow.

I've also started using the text editor Vim, which comes with Unix and is accessed through the command line. Vim looks arcane and terrifying. But it's actually not that difficult to get to grips with and has already saved me time.

Looking cool is still a perk.

Shipping useful things feels great

The first piece of work I shipped was a pretty small change to the list of all items in the Content Publisher. Previously, Person Profiles were just listed by the role holder name. I amended this to include the person's name as well.

This was a small tweak, but it solved a problem our users had been struggling with for a while – picking one Senior Lecturer out of a list of dozens is frustrating if you have to check each one individually.

Pushing to production to a round of applause felt really good. Knowing that it's something users have been looking forward to made it feel even better.

Development is fun

Okay, I already knew this from doing it in my free time. But it turns out it's fun professionally too. (Whew!)

Getting stuck on a problem can be frustrating, but the thrill of "it works!" when I finally hit the solution has yet to get old.

I'm also fortunate that everyone else is happy to answer questions, offer advice and help me out when I get stuck. Making things on my own was fun, but I prefer being part of the team. And I'm looking forward to continuing to learn.

Also, we're hiring right now – find out more about working in the Digital team.


Digital team sprint notes 4 - 17 October

📥  Sprint notes

We're looking to hire two Ruby on Rails developers, so read a bit more about the team and come join us!

What we shipped

  • Team profiles now get republished when an associated Person Profile is published
  • List of users in the Content Publisher is now ordered alphabetically by display name
  • Superscript is now enabled in Markdown
  • List of content items includes role holder names for Person Profiles
  • Better item spacing on landing pages
  • Publishers can now search for content items in the Content Publisher
  • List of existing content items is paginated
  • 34 pieces of content maintenance
  • Lots of Student Recruitment content making good progress through the content transition board

What we're going to ship

  • Improve layout consistency by updating the vertical rhythm and typographic scale
  • Improve the legibility of long pages by updating the sizing for all our headings
  • Content that appears in the sidebar on large screens will no longer butt up against the edge of the sreen on small screens
  • When a publisher updates a content item which doesn't belong to their organisation it will no longer change which organisation owns it
  • Allow publishers to choose the ordering of people listed in Team Profiles
  • Change our titling of "Team members" on Team Profile pages to be more generic
  • Add new Team Profile subtypes
  • Provide a sitemap.xml file to make sure that all our pages are indexed by Google and site search


The brief history of the content transition board

📥  Beta, Communication, Tools

We recently returned to a content sprint that was started a year ago. Digging up the old Trello board made us feel a bit nostalgic and quite pleased with ourselves - we’d come a long way since then.

When we began the content transition project we didn’t really have a clear idea how to organise the process. Our first attempt at a transition Trello board reflects that.


Our first iteration of the transition Trello board.

The idea was to build it around the top level stages in the process. Each card represented a stage in the process such as content analysis or completing a specific set of training.

Comparing that board to what we have now made us chuckle.


The transition Trello board in its current form.

So what’s happened in between those two versions of the board?

We realised we need to build the boards around actual content

In the next iteration, we had cards for each new content type and copied into a checklist everything identified as that content type from the inventory spreadsheets.


We trialled posting all the content from the inventories onto cards based on content type.

We would make an individual card for each item on the checklist and tick it off the list when that had been done to track progress.

For a reason none of us can remember, we put those cards in a column called “Epics”. Obviously, they are not epic user stories and this caused confusion - in amongst ourselves as well as with the publishers we were working with.

We quickly realised it was very difficult to avoid duplication or prioritise content.

We realised we need some actual epics to organise content in a meaningful way

The next iteration was already a big improvement. We organised the content into cards so that each covered, more or less, an epic user story.

We then pasted the relevant content from the inventories into the checklist again but this time used the full URL so it was easy to check the content without having to copy and paste and type in the domain manually.

Why on earth we weren’t doing this from the start, none of us can tell you. Sometimes even the most obvious things escape you when you’re immersed in a process.


Categorising content based on user stories worked better.

We realised we needed to take a step back from transitioning individual pieces of content

Although we were trying to structure to-be-migrated content around user stories, we quickly ran into problems again.

Working through heaps of content as a team at a fast pace meant we ended up working on user stories that were very similar. As a result, we created duplicate content without realising it.

It was time to take a step back. We went back to the principles and started from user needs. This time, we were careful to keep existing content out of sight at the user story planning sessions. This helped us stay focused on what the content should be rather than what it had been.

Having individual old pages on a checklist must have, subconsciously, made us think we need to transition each page as an individual page. So we stopped that, and started including them on the card as a reference instead.

We also improved our housekeeping discipline around individual cards. Each card now needs to have:

  • a user story
  • links to all the relevant existing content
  • links to draft in the new Content Publisher (backend) and preview
  • someone identified as the content subject expert

Each card has to have enough information for anyone of us to be able to pick it up.

We have also tweaked the stages each card goes through. “Doing, review, done” has morphed into “Substantive edit, 1st review, more edits, fact-checking, final proof and ready for live”.

The process takes a long time but we have made peace with it for now. If we’ve learned anything in the process of transitioning content so far, it’s that you can’t rush good content.

There’s still room for improvement - there always is - but for now, this is working for us.


Slaves to the dragon

📥  Communication, Team

We’re currently recruiting for three new people: a Content Producer and two Developers. This got me thinking about what I most enjoy about the team I work with and the work we do.

Being the newbie

I’m a relatively new member of the team. I started in January this year on a six-month maternity cover contract. If your maths skills are as good as mine you’ll notice that I’ve now been here for ten months. That’s because my contract was extended, which is great as I get to spend more time working with this team on the major project we call Transition.

This might sound like I’m spinning some sickly, sycophantic yarn, possibly in the hope of another contract extension, but I really do think it’s worth explaining how this team works because it’s not like anywhere I’ve been before.

My background is in book publishing, where I did digital marketing for a few too many years. I then spent a while developing my editorial skills through freelance work and as the web editor for a magazine site in Bristol. You don’t need my full CV, but it’s worth noting that I haven’t come through the ranks of academic content production to get here. Very few of the Content team have.

The team that sits together, ships together

Because I haven’t worked at a university before I've had a lot to learn — so many acronyms, so little time. But the exciting thing has been learning from everyone — the Content team, the developers, and the UX designers. We sit in the same room, which is a first for me, and as a team, we constantly share what we know. There are daily stand-up meetings and fortnightly Show & Tell presentations. We even have dedicated time slots for developing our skills, personally and as a team.

We work in our own interpretation of Agile, which I hadn't done before, but I picked it up really quickly with everyone's help. Working this way keeps us focused and on target as a unit.

We’re all about shipping, so much so that we have a flippin’ dragon that roars every time we make something live. There’s a real sense of team achievement when we ship an improvement for the user. We work hard to get things done, but when it’s 5 o’clock, we go home and we come back fresh the next day.

Best team ever!
(too much?)

As I mentioned, we all come from different backgrounds, so the office is full of interesting people, all of whom are endlessly friendly and ready to chat. I felt instantly welcome when I started and was immediately invited to join a load of Slack channels about comic books, video games, parenting, running, house hunting…

Everyone here is passionate about something, from cooking to travel to films to D&D; we all have something to talk about, something we love beyond our jobs. Being able to share these passions with our colleagues gives us the energy we need to produce great work. We’re here all day, but we don’t have to leave ourselves at home.

This extends to the dress code - of which there is none to speak - although I haven’t really put that to the test yet. Maybe next week I’ll wear my Spider-Man costume and see if anyone minds.

A blue plastic dragon


One Hour Upgrade part 5

📥  One Hour Upgrade

A photo of Phil prioritising the One Hour Upgrade improvements with post-it notes

Prioritising the One Hour Upgrade improvements.

The idea behind One Hour Upgrade is for each member of the Digital team to spend 60 minutes working on their own initiative to make our digital processes, infrastructure or products better.

Using the lessons learned from our previous upgrades, we spent 30 minutes on Thursday making suggestions and prioritising them by voting for our favourites. On Friday, everyone picked up items either by themselves or in teams and focused on delivery. After 59 minutes, the countdown kicked in.

Things we did

  • shipped a new 404 page (we had to add some Google Analytics tracking later)
  • brought the Travel Advice transition Trello board up to date and shipped one of the two remaining pages
  • built a new Trello board for managing blog posts with an improved process and guidelines for publishing them
  • designed a form for submitting new requests to our support helpdesk
  • built a prototype video extolling the many and varied virtues of working with us (spoiler: cake)

Things we learned

  • we have a whole lot of ideas for improving almost every aspect of what we do (36 submissions during planning, 18 of which got votes during prioritisation)
  • separating planning from the upgrade hour works nicely
  • technical improvements are hard to get shipped in the time - these should always be paired
  • we love doing this and are going to make One Hour Upgrade a regular thing that happens on the first Friday of every month

Digital team sprint notes 6 September - 3 October

📥  Sprint notes

What we delivered in the last two sprints

  • Admins can create and publish Collections
  • Collections are now listed at
  • The layout of our static lists matches the layout of our dynamic filtered lists
  • Publishers can restrict access to Publication attachments
  • Admins can now add up to 8 labels to a content item, up from 5
  • We created a prototype of a visual regression testing platform (we used this guide)
  • Tore down the alpha projects we've created over the last few years
  • Made our Collection and Landing Page templates share some markup and styles to make them easier to maintain
  • Delivered 79 items of content maintenance

We were also joined by Sean Moran-Richards as our new Digital Supporter and Iris Faraway as our new Junior Developer, welcome aboard!

In the next sprint we will deliver these things

  • Publishers will be able to search the editing backend for the content they want to edit
  • The list of content presented to publishers will be paginated
  • Person Profiles listed to publishers will include the person's name as well as role
  • When a Person Profile title is changed, any relevant Team Profiles will be updated and republished automatically
  • The layout of a pinned item on a Collection will improve
  • The sizing of our headings in content items will improve, on all screen sizes
  • We'll improve how people use Team Profiles to represent different types of team

We'll also be starting the next of the sprints on our Student Recruitment transition - one of the most visible areas of!



Visual regression testing

📥  Communication, Design, Style, content and design, Tools

Our new site consists of 15 different layout templates. Each one of these is further broken down into numerous different design patterns for consistently displaying content. The rules that govern the presentation of these patterns (or elements, if you are familiar with atomic design) are generated from a combination of the Zurb Foundation framework and our own 'Origins' framework - all in all over 2000 rules spanning almost 6500 lines of css.

With this level of complexity it is extremely hard work to track the effect of any changes, almost certainly there is an unexpected knock-on effect of changing, re-specifying, or removing a rule.

Up until now, we have relied on our in-depth knowledge of the site to know where we expect changes to appear, and we use Browserstack to quickly check a representative sample set of our layout templates.

However, this requires a fair whack of time to run, and also needs a person to sit and look at each snapshot that's generated. And they need to know what to look for.

None of that is optimal, we needed a way to automate this process. Enter visual regression testing.

We followed this online guide by Kevin Lamping for setting up a prototype for a visual regression testing framework for Origins and the site templates.

Our prototype is in a repository here: (you will need a University of Bath login to view this). It contains a README with instructions on how to get it up and running.

Essentially, what it does is use some clever existing technology (WebDriverIO, WebDriverCSS, graphicsMagick, Selenium standalone and Node) to make a brower load a specific page, take a screenshot of a defined element, and then compare it to a baseline image. If there is any visual changes, it will then create a 'diff' file showing the change - and also alert us by throwing an error.

Snapshot of the website header

First we create a baseline image.

Snapshot of an updated website header

Then, when a change happens, another image is generated and compared against the first.

A diff file of changes to the header

If there are any visual changes, a third file is generated showing these changes.

Currently we are manually running these tests, but ultimately we will integrate into our continuous delivery framework so that the test run automatically whenever a new build of the css is pushed to our staging server.

Pretty neat.