Digital Marketing & Communications

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

Development Plan Report Number 1

📥  Design, Show & Tell

Last month, I made a trip to the Library to delve into the archives of the University. Together with colleagues in Imaging, Design and Printing Services (IDPS), the plan was to get a crash course on brand design.

The head archivist, Lizzie, had sourced boxes full of printed materials for us, ranging from prospectuses to annual reports, promotional posters and pamphlets.

As designers we were first drawn towards the prospectuses. Published annually, it provides a fascinating insight into the prominent design trends in the year of publication. Our 90s 'rave' period is probably one to forget.

As is often the case, our most interesting discovery came from a rather unexpected source.

Development Plan Report Number 1

In 1965 an unassuming document outlining plans for the new University in Bath was published. With a brown and cream two-tone cover and type set entirely in Helvetica (known at this time as Neue Haas Grotesk) Development Plan Report Number 1 wears its 1960s origins proudly on its sleeve.

The report itself is a beautifully typeset outline of the plans for the proposed University of Bath. It’s stuffed full of abstract, organic diagrams and line drawings that are almost cellular in their approach. Throughout the report living, studying and social spaces are referred to as organic entities, flexing and changing to suit the needs of their occupants.

Origins of the logo

The first real surprise adorned the back cover - A large black and white photograph of the Sulis head found in the local Roman baths.

The Sulis head

Bas-relief from the pediment of the Temple of Sul Minerva in Bath

The creative decision to position this particular image here has had long-lasting ramifications for our design direction. The Sulis head has been inextricably linked with the University from its conception.

Which is why it was such a delight to discover a small hand-rendered version of the icon on the inside front leaf. This subtle design element cements the relationship between the nascent University and the Sulis head icon.

Sulis head icon on the inside cover

Sulis head icon on the inside cover

The first diagram of the university

Having discovered the impact the report had made on the University's brand identity we dug deeper, looking for yet more insight. In the first section - Aims and Principles - we found 'The first diagram of the university' (the actual title of the image).


The first diagram of the University

This incredible diagram illustrates a number key design tenets repeated throughout the report - namely a campus that grows outwards from a central hub (the spine/nucleus), close integration of residential, academic and social spaces and restrained (but not constrained) campus structure.

The beauty of this diagram is how well it effectively communicates relationships between traditionally disparate spaces. The campus is visually described in anatomical terms - It feels like a living entity, exactly as intended.

University patterns

Development Plan Report Number 1 eveals that the University of Bath was conceived from the very beginning as something new, something different, an institution to challenge.

The plan discusses possible residential and social patterns at length. Two of these patterns are based on the structure of existing academic insitutions  - A traditional 'Redbrick' college and the 'Oxbridge' model. A third proposed pattern is considered new and unique to Bath.


Three patterns for University structure


In the Redbrick pattern there is little relationship between the academic activities of the departments and the social activities of the students. These elements remain isolated from each other.


With Oxbridge the pattern consists of a loose ‘community’ of independent colleges and scattered teaching departments. Colleges lose some of their academic significance to the departments and students live either within the college or in separate lodgings.


In the Bath pattern both study and socialising are closely linked in a concentrated urban setting. The university is conceived as a single varied community. There is no attempt made to separate or isolate the different facets of student life.

A parade of limited length

At the core of the proposed new campus is the parade. Designed to flex and grow as requirements change, the parade is never more than (about) 2000ft long - roughly 8 minutes walk from end-to-end at a leisurely pace.

Once again the thinking behind this concept it outlined in a series of beautiful abstracted images. Lacking in actual detail these illustrations still manage to convey a sense of movement and space between the edifices that make up the central area of the campus.

That the last illustration (the selected option) is still recognisable as the parade today is incredible.


Flow patterns through the parade at the heart of the University

A view of the future

It was clear from just the short time we had to spend with the Design Plan Report Number 1 that things hadn’t changed as much as we might have originally thought. The founding principles of the University still hold true today including the Sulis head representing the University at a core level.

The beautifully executed line drawings summon up an image of a sophisticated, unified campus blending all aspects of student life into a seamless experience.

We came away inspired, motivated and with renewed optimism that the University brand was not far off alignment.

Making a Slackbot for editorial guidance

📥  Development

In the Digital build team, we have two hours every Wednesday to work on our own personal development. I recently spent a few of these sessions making my own Slackbot.

A slack-what?

Slack is a messaging application designed for work teams. We've used it for several years now and found it an extremely useful communication tool – it's a great way to keep everyone in the loop while keeping our email inboxes relatively clear.

A Slackbot is a program that interacts with users through Slack. It can react to user input (like a user saying a certain command) or external input (like a trigger from another website to post a message in Slack).

Slack comes with its own bot, @slackbot, which responds to several default commands and has some customisation options.

Using @slackbot's reminder functionality

Using @slackbot's reminder functionality

Unsurprisingly, lots of other digital services have built their own bots to integrate with Slack. We use these to get notifications in Slack when something important happens, for example, if a team member starts a new story in Pivotal Tracker or a new version of Ruby is released.

This bot notifies everyone in the #beta channel when something deploys

This bot notifies everyone in the #beta channel when the Content Publisher deploys

Building my own Slackbot

The content team has written a lot of guidance for our lead publishers, from editorial style to using specific content types in the Content Publisher. We use this guidance a lot ourselves. I decided to create a bot that could make it easier to retrieve this guidance from the comfort of the Slack window.

I built my bot using Ruby. The slack-ruby-bot gem makes it really easy to get a basic bot up and running. After registering the bot with Slack and setting up an API token, I added it to a channel.

The bot responds to anyone who greets it with a cheery "Hi @username!" out of the box, but then it was up to me to add my own functionality.

Setting up a very basic Slackbot command

Setting up a very basic Slackbot command

We've had a lot of raging debates about our editorial style for bulleted lists, so inevitably this was my Slackbot's first new feature:

Not this again...

Not this again...

Getting variables from the user

It's also possible to build more complex features. Slackbots can get variables from user input (regular expressions come in handy here), so I added a feature that lets users request a particular guide.

I created a hash with the names of guides and their URLs. When the bot receives the command, it identifies the term provided by the user and checks the hash to see if there is a corresponding guide. If there is, it posts the URL for the guide in the channel.

Requesting guidance on using images

Requesting guidance on using images using the command 'rtm' (or 'read the manual')

This might save some time for users, but they still need to leave Slack to read the information. What if we want the bot to provide guidance directly in Slack?

Retrieving information from the web

Our editorial style guide is the longest, most detailed guidance we have for creating content on Sometimes it can take a while to find what we're looking for. What if the bot could do it for us?

We could follow the same format as the guide search feature and just store all the information in the code. But our editorial style guide is constantly evolving, so this could quickly become out of date. And it'd be absolutely massive. It's better to have the bot to search the guide itself directly.

Nokogiri is a Ruby library for parsing HTML and XML documents. It's an incredibly useful tool for searching or processing the content of a webpage. I decided to use Nokogiri to search for and retrieve content in the editorial style guide.

Here's how the feature works:

  1. A Slack user requests content from the editorial style guide using the command "style guide for [search term]".
  2. The bot recognises the request and gets the search term.
  3. The bot uses Nokogiri to get the content of the editorial style guide from the website.
  4. The bot checks each heading to see if it matches the search term.
  5. Once a heading matches, the bot collects the content of each subsequent paragraph, heading or list until it reaches a heading that's the same level or higher.
  6. The bot processes the collected information to format lists and headings.
  7. Finally, the bot posts the results in the original Slack channel.

If the bot can't find anything, it'll notify the user so they don't have to wait for an answer that isn't coming.

How should we refer to the Chancellor? The bot has the answers

How should we refer to the Chancellor? The bot has the answers

If we're discussing a style question in Slack, the bot can provide the answer to everyone in the channel – hopefully making it easier to settle some debates.

Downsides of Slackbots

The bot should be useful when you want it, but stay out of the way when you don't. Nobody wants a bot which spams the chat with unnecessary messages or notifications.

It's also important to be aware of potential security risks. When you give a Slackbot access to a channel, you're allowing it to potentially access a lot of sensitive information – what everyone is saying, when users are online, or even when they are typing.

I created an entirely separate team just to test my bot in, so it hasn't made it to our actual chat yet. If we do unleash it upon our actual Slack team, we'll definitely need to do some more research into the security aspects first.

Go forth and build bots

While my Slackbot hasn't made it into production use yet, I'm still glad I built it. It was an interesting and fun little project which I hope has the potential to become really useful for our team.

If you use Slack, I'd recommend having a go at making your own bot. There are some powerful tools for building your own bots in your choice of languages – Node.js is especially popular.

If you've built a Slackbot, or have a favourite one that makes your working life much easier, let me know in the comments. I'm looking forward to seeing what everyone's come up with.


Digital team sprint notes 1 - 14 November

📥  Sprint notes

What we did

  • Added subtypes to Team Profiles
  • Enabled drag-and-drop sorting for members of a Team Profile
  • Changed the ordering of the 'Enquiries' and 'Address' fields on Department pages to make their location more predictable
  • Allowed publishers to preview a content item without sending it to the Review state first
  • Increased the amount of spacing under embedded media content
  • Improved layout consistency between different screen sizes
  • Published new content about the University's research integrity and ethics
  • Changed our own process for writing content from scratch
  • We handled 27 items of content support. These included:
  • Resolved 154 requests for support

And last but far from least, we welcomed Tom Dennis to the team as a new Content Producer!

What we're going to do

  • Update the links in the footer of the new pages to point directly to the correct locations
  • Improve our testing by automating data transfer between our staging and production systems
  • Reduce the size of headings in the sidebar of filtered lists
  • Improve the consistency of lists on Person Profiles
  • Make sure that the subtype of a content item is consistently displayed across Collections, Landing Pages and the content item itself
  • Allow lists of Team Profiles to be filtered by subtype
  • Improve the layout of Team Profiles on small screens
  • Add new subtypes to the Publication content type


Hello world: my first two months in Digital

📥  Communication

It's a little bit strange to be writing a post like this after saying goodbye to three of our team. Liam, Kelv and Tom were (... but they're not dead, so are?) amazing people to work with for the last two and a bit months, and while I haven't known them as long as the rest of the team here, I miss them.

There's something in that sentiment that speaks volumes about my first two months here: everyone has done so much to help me get up to speed and feel welcome that it already feels like I've been here for an age (though not aeons like Tom Natt).

Where I come from

Before the University, I worked for Apple just down the hill as part of their business to business team. I can't say anything bad about Apple--it's a great place to work, and I wouldn't be here now without my experiences there. But as great as it was, I was always searching for something more to push me, something that would open up more creative possibilities.

My education isn't in the STEM world, or services--I'm trained as an actor. I have left this behind for the most part, but the root drive to be creative has never left.

Joining Digital

Over the last couple of years I've been inching my way towards software development. At first it seemed too good to be true--work that was challenging, equal parts logic and creativity, embraced learning constantly, and lead to financial solvency (!). I was worried that I'd find I hated it, that the combination of logic and creativity was a myth, that learning would cease after a while.

The more I exposed myself to it, the more convinced I became that it was the *right move* for me. A way to feel excited about even the small things I do day to day.

I'm not a developer--I'm not there yet. But Digital is an opportunity for me to learn alongside developers while supporting them and the Product Owner with what I'm already great at: service management. As the Digital Supporter most of my time is spent on the latter, but more and more I'm handling technical tickets and requests myself.

Being part of Digital

Right now I'm working on building an app that will pull together our service management statistics for us from the last month. Right now it's a mostly manual process.

Our service ticket tool has an API that exposes all the data we need though, so the idea is to use that to request all of our data there, compile it into a human friendly spreadsheet, create some handy charts, and have it emailed directly to our stakeholders automatically every month.

It's not much yet, but I have a pretty good idea of how all the different pieces work together, which is a huge victory in and of itself.

I still can't quite believe how lucky I am to work somewhere that encourages this kind of learning and development into what is technically a different job role, and to have colleagues both still present and departed, who are willing to help me as I teach myself.

It has been a great first two months. I look forward to each and every month to come.


My first two months in numbers

  • 1 Show and Tell
  • 1 accepted pull request for our blog styling
  • 1 deleted blog (not related to the PR...)
  • 1 restored blog (directly related to the deleted blog...)
  • 2 apple pies baked (even though I'm a heathen American and don't watch Bake Off, I was in the Bake Off pool)
  • 10 board games played
  • 960 support tickets resolved
  • 14 new friends made (d'aww)

Goodbye titles are hard

📥  Communication, Team

This is my last week as an employee of the University of Bath. I have been coming up The Hill daily for roughly the last fifteen years - first as a student, then as staff - so it's an emotional time.

The University has changed significantly in that time, and yet there is a strong sense of the familiar everywhere I look. The library is a great example - all new equipment and an improved layout but I still see the corners I used to haunt as a mathematics undergraduate more than a decade ago. The places my group used to sit and puzzle through the latest problem sheet and the floor where we definitely didn't create a small camp during an all-night coursework session.

Similarly, the Web Team / Web Application Team / Web Services / Digital has changed people, moved department, moved offices three to five times (depending how you count it) and yet the belief in the web and the desire to build the best and most interesting things we can remains the same.

I've been in this team a long time and learned a huge amount. I started as a junior developer (not that we had that title at the time) and learned about Java and PHP web development as well as the various bits of infrastructure underpinning all this. I wrote Personfinder, which eight years on is still a favourite application amongst our users and I found some notes the other day where one of the sysadmins in BUCS (as it was then) took me through restoring servers from tape backup. Fortunately I have never had to use that information!

After several years of application development we moved our focus to OpenCMS and thus began the first great CMS transition where we moved a load of Dreamweaver sites into the new system. Through this time we were still developing applications and looking at new ways to be productive. It was around then we first dabbled in Scrum and Agile with positive, if mixed results.

Many years of CMS work later, we saw changes in government and their approach to digital and this heralded the rise of GDS, the coming of Ross and the second great CMS transition. We retooled to use Ruby on Rails, growing in confidence as a software house and built our own content management system. The last few years have seen concentrated development resulting in a system we are all proud of and which is making genuinely positive changes in content publishing around the University.

I've learned so much in my time here, and I am incredibly grateful for the opportunities. One of the great things about the Digital team here is the openness to change and the chance to develop beyond the traditional bounds of the job description. I am moving on to become a Lead Developer at GDS and I can honestly say that wouldn't be happening if not for my experiences here.

So, after 53 Show & Tell presentations, thousands of lines of code, hundreds of retrospectives, loads of accepted features (and more than a few rejected...), dozens of slightly terrifying server repairs, a couple of conference talks and one instance of the bringing down the entire University website it is time to move on.

I will look back on my time here with fondness and I'm going to miss everyone here a great deal. So long and thanks for all the commits.

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