Digital Marketing & Communications

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

Goodbye Alpha

📥  Alpha, Beta

On Friday 27th we finished the testing of The ‘Alpha’ was a project to trial an experimental design, infrastructure and editorial approach for a new University of Bath website.

The point of the Alpha

The Alpha went live in January 2015. During the Alpha we redirected on-campus users to the trial version of the site whenever they wanted to view the homepage or About section, with publishers using an experimental content management system when they needed to update those pages.

Between January and the end of February we actively monitored the Alpha site’s performance, gathered user feedback (through surveys and interviews) and developed the content and features much as though the Alpha was the ‘business as usual’ site. Now that the Alpha is closed the redirects are turned off and it’s back to the old pages and CMS (for the time being).

From the Alpha exercise we have learned a great deal about what our publishers and end-users need from a website that does a better job of representing the University of Bath. Over the next couple weeks we will be writing up the learning from the Alpha. The report will be submitted to the Digital Steering Group and made available to colleagues across the University.

Digital team sprint notes, 24 February - 2 March 2015

📥  Sprint notes

In this last sprint we:

  • officially closed
  • completed sprint 0 for the development of the beta version of the new
  • updated the Opinion blog so we can republish posts from The Conversation, and wrote guidelines on how to do this
  • updated our Founders Day pages in preparation for this year's celebrations
  • received 50 tickets into web support and resolved 37 of them
  • received 10 content maintenance tasks and completed 7 of them.

In our next sprint we will:

  • continue work on the CMS beta
  • complete updates to the accommodation section
  • deliver a draft content strategy framework for /students
  • complete discovery on event booking.

One Hour Upgrade part 4

📥  One Hour Upgrade

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 digital communications at the University of Bath better.

Things we did

  • improved the automated response when someone submits an item to our What's On calendar
  • installed the NVDA screenreader on an office laptop and wrote some instructions on how to use it
  • sourced a selection of photos for later use on our First Year student landing page
  • installed a plugin on our Opinion research blog to link back to The Conversation when a post appears in both places
  • optimised our SVG logos, improving the rendering on different screen sizes and reducing the overall file size
  • fixed some of the biggest 404 errors coming into the site over the last month
  • set up our continuous integration server to automatically check our Ruby code with Rubocop and generate an HTML report.

Five of the tasks were completed within the hour, the other two were completed within a few minutes after the whistle but we made some allowances since this was our last Upgrade for a few months whilst we turn our attention to developing our new beta website.

Things we learned

We used the experience of the three previous Upgrades to set up a sprint board for our ideas in the morning and then reserved 15 minutes before the hour deciding who would do what. Six of the tasks had people pairing on them and Kelv took on the Rubocop setup by himself.

We've only spent four hours in total performing these upgrades but have seen dozens of concrete improvements across many of the areas we work in and look forward to the next one!

Digital team sprint notes, 17 - 23 February 2015

📥  Sprint notes

In this last sprint we:

  • worked with the University Events team to ship a new Open Days landing page based on the template we developed for
  • ran a benchmarking exercise to inform the development of the business section
  • published a feature about one of our researchers who listens to icebergs
  • shipped a new Postal Services section
  • completed a round of testing with users from our faculties and student marketing team on the alpha of a new online prospectus editor. The results gave us some great insight and will heavily influence further development
  • received 44 tickets into web support and resolved 39 of them
  • received 13 content maintenance tasks and completed 11 of them.

In our next sprint the Digital team will:

  • expand the team on our second discovery sprint into events booking applications
  • complete an audit of our international social media channels
  • perform a Sprint 0 on developing our beta CMS and website.

Typesetting the Alphas

📥  Alpha, Design

It's almost 10 years ago now that Oliver Reichenstein published his thoughts on the fundamental influence of typography on web design.

Web Design is 95% TypographyOliver Reichenstein

At the time the article provoked a lively discussion amongst the design community. Today you're unlikely to find many voices disagreeing with Reichenstein – unless it is to argue for an increase in the quoted percentage by a few points.

Designing a typographic system to underpin the large-scale redesign of the University's website is a complex and involving task. The seeds of our thinking regarding a full typographic review have been germinating since early-2014 when Liam presented his thinking around the haecceity of Bath.

The development of the alphas provided an excellent opportunity to implement a vibrant new typographic approach for the University of Bath.

Setting out our requirements

The first step was to outline the minimum criteria for our new typefaces. These criteria fit broadly into 3 categories:

  • Functional - The key technical requirements
  • Aesthetic - Legibility, clarity, flexibility and flair
  • Connection - The personality and the feel of the typeface


A full, flexible character set

It was clear from previous flawed implementations of open source/free typefaces that a full and varied character set was a must. When assessing typefaces we looked for diacritics, non-Latin characters, beautiful ligatures, alternative characters and more.

Reliable, performant delivery method

Typefaces with multiple weights and variants can clock in anywhere up to 1MB in size for the full set. We needed configuration options to reduce loading time, the option to self-host on local servers and other methods of cutting down were all explored.



A well-designed, crafted typeface should render optimally whatever device it is displayed on. Proper hinting and optimisation for screen display is vital.

Legibility and clarity

Our chosen typefaces must work at varying sizes and lengths of content. Clarity and legibility of text is paramount.



How does the typeface 'feel' when set on a page? Does the typeface genuinely reflect the University of Bath and the persona we have in mind?


It's too easy to create a false relationship where none exists - we wanted typefaces with genuine meaning and subtext that enhanced the user experience.

With our criteria in place we started looking at typefaces. Many, many typefaces …

Over a handful of sprints we narrowed our typeface selection to a shortlist from foundries such as Dalton-Maag, Jeremy Tankard, Hoefler & Frere-Jones and other typographic luminaries.

And what did we find?

To meet our technical criteria we elected to use typefaces in the Opentype format delivered as web fonts via Opentype gives us the flexibility to add or remove typographic features as and when we need them - key to reducing the initial load time for multiple fonts. The web font delivery service is fully featured, robust and offers a variety of font hosting options.

Early on it was decided that we should work towards selecting typefaces from a single foundry. Selecting our typefaces from one source meant that we could be sure that each face would share a commonality in design-thinking, style and concept. These values help to ensure different typefaces work together harmoniously when paired on the page.

To this end, we have selected two typefaces from a well-respected, long-standing UK type house now based in the Netherlands, The Foundry.

One of The Foundry's principle designers David Quay has a history with Bath having been the lead on the team that developed the Bath city typeface used for signage, way-finding and infographics. The Foundry are well regarded for their work in creating legible, elegant typefaces that have a quintessentially English feel but global appeal.

The typefaces

Foundry Origin

A beautiful, modern slab/Egyptian serif for headlines

A sample paragraph of text set in the Foundry Origin serif typeface

Foundry Origin - A quiet design with a big presence.

Foundry Sterling

A clean, legible sans serif for body copy

A paragraph of text set in the Foundry Sterling typeface

Foundry Sterling - A modern sans with a quintessentially English flavour

If you're quick, you can see the typefaces being used on and before the Alpha exercise comes to a close at the end of this week.

Digital roadmap update for February 2015

📥  Roadmap

The eagle-eyed will have noticed that our sprint notes have been leaner of late. We’ve been paring them back so they provide an account of just work that’s shipped. This has been in anticipation of a new monthly post that describes the progress we are making on our digital roadmap. This is the first edition of said post.

Roadmap progress in January 2015

  • We released to allow us to test the new infrastructure, design thinking and content strategy that we think we will use for an all new
  • In preparation for the development of the new, we published an initial directory setup, style guide and pattern library for our beta content templates at
  • We developed a content inventory tool to help us work out what content is going to move over to the new platform. We had it run through Admissions, Engineering and HR by way of a pilot, from which we learned a lot and identified additional features that are required for that process to be effective.
  • Following a review of user feedback and a benchmarking exercise, we’ve consolidated information about traveling to and from the University into one section
  • We shipped the first iteration of International Relations Office webpages at, which explains the mission and composition of that team.

Roadmap updates for February 2015 and beyond

  • Our priority from March to September will be on building the Beta version of the new and transitioning publishers and their content onto that platform. Every timeline on the roadmap has been updated to reflect this.
  • The CMS timeline has been split out into two separate timelines - CMS Beta and Beta Transition - to make it easier to see what’s happening and when across both of these pretty complex aspects of moving to a new publishing platform.
  • Having made good progress on building a backend content store for our courses, we have added projects on the Prospectus timeline for the development of corresponding frontend templates.
  • The Services timeline has been refocused on the design and development of online tools and transactions, starting with Person Finder and a Service Status tool.
  • A first release of our Performance dashboard has been incorporated into Infrastructure.
  • Students is updated with projects to provide renewed editorial focus and develop more defined, measurable user journeys.
  • Research updates include with projects to provide renewed editorial focus and improved distribution of content.
  • The sequence of Internationalisation has been adjusted to make space for the development of more profiles on social media channels used by overseas audiences and to fall into sequence with Beta site development.
  • Projects to improve the quality of site search results have been added to Search and timed to accommodate the impact of Beta transition.


Using Rails

📥  Development

After ten years of Java and PHP, the Digital team have started writing all new applications, including our new CMS, in Ruby on Rails.

There are two reasons why now is a good time for us to do this. The first is that Rails is considered old hat, which means that it's now a tried and tested platform. The other is that improvements in our server virtualisation infrastructure mean that we no longer need to wait for Ruby packages to be available for our Solaris servers, because we can create new Linux servers as and when we need them. Solaris was a big blocker because the most recent Ruby package for Solaris is 1.8.7, which was released all the way back in 2008.

We are happy with our Java and PHP applications, and won't be looking to rewrite those in the near-term. We will continue to write applications in those languages where appropriate but are convinced that the Ruby community has shown itself to be strongly united behind Rails, making updates and community support much better than it is for the many competing Java and PHP frameworks.

Rails isn't perfect. It has regular security vulnerability announcements and then, assuming the patch is simple, we need to schedule the downtime to patch our applications. We have a channel in Slack which is subscribed to the rubyonrails-security mailing list and so we find out about new vulnerabilities quickly.

We're not currently planning on hosting public-facing applications with Rails, keeping them for internally-facing applications like the CMS editor. This will give us time to understand how to scale up our servers and applications appropriately and, since the CMS creates static HTML files it means we will be able to leave our powerful webservers doing the job they're already optimised for.

There's been a lot of learning involved in going from a blank-slate to a production-ready Rails application, and there'll be more to come, but we're happy with Rails and confident that it will serve us well in the coming years.

Digital team sprint notes, 10 - 16 February 2015

📥  Sprint notes

In the sprint we just completed, the Digital team:

  • conducted two rounds of user research on the Alpha site with students and staff
  • made the Prospectus Alpha look consistent with the other apps and loaded up shared data to make creating and editing courses quicker, in advance of user testing
  • carried out an audit of social media channels used in 11 of our priority overseas markets
  • wrote features on tobacco packaging and on underwater acoustics research
  • placed updated Postal Services pages into internal quality assurance
  • wrapped up Beta design elements and patterns into a single, consistent repository
  • planned and rehearsed upgrade of the University wiki
  • completed 13 content maintenance tasks (of 13 received)
  • received 91 technical support requests and resolved 61.

In our next sprint, the Digital team will:

  • release a new Open Days landing page
  • run discovery work to find a new event booking application
  • continue constructing a candidate taxonomy for the Beta publishing platform
  • user testing and development of the Prospectus Alpha
  • run discovery work on the presentation of commercial services on
  • release updated Postal Services pages.

Show & Tell, 13 February 2015

📥  Show & Tell

It was a big crowd for our 5-minute talks today and, whilst Dan was drawing the pictures below, we covered a wide range of topics, from industrial-scale printing and webinars to an overview of git and shipping a new website section. Tom and Charlotte kicked us off:

Performing content inventories

Our site is really big and so it can be really scary to think about listing out and analysing all the resources in it by hand. Tom has created a PHP application which automates the extraction of data from the CMS and the filesystem and then pairs it with data from Google Analytics, ready for pasting into Google Sheets.

A drawing of a cake

All the data gets mixed together and bakes a lovely data cake

Being able to have all this data in a single location for each of our sites is essential for helping us plan our migration to the new CMS.


Nearly 60% of the postgraduates for some of our humanities courses come from outside the UK and so to help increase our conversion rates from "prospective student" to "actual student", Matt's faculty have started running course-specific webinars. These allow the academic and administrative staff to present highly-targeted information directly to people who are interested, and to be able to answer any questions they may have.

A drawing of a globe and a clock

Getting the timing of your webinar right is crucial

Presentations need regular points of audience interaction, from interactive Q&As to using low-barrier polls like asking where the participants where they're from. This ensures that interest is maintained throughout.

So far all the webinars have had oversight from the central team but they hope that as they set up guidelines and build up more experience the relevant staff will be able to run the webinars themselves.

Printing the prospectus

This year we're printing about 60,000 prospectuses.


Our Github workflow

📥  Development

We are only 10 months into adopting Github Enterprise for our version control system and have many things still to learn. Near the start of that period we needed a workflow for managing the contributions that our team of devs, designers and editors make to our projects.

We decided to have a look at what was out there first and adapt something to our needs, taking into consideration our relative inexperience with Git in general.

Pick one

This helpful guide by Atlassian to some workflows was good at giving us an intial overview. We were able to discount the various workflows for either being to complicated for us (Gitflow) or too basic (Forking workflow).

We looked at the Github Workflow as well and found it suitable for our level of experience and how we wanted to work.

Change it

There are a couple of minor things we do differently though in our team. First of all we don't work against a branch called master.

What we have instead are staging and production branches. These reflect our platforms that we deploy to. staging is actually the default branch of all our project repos.

We always branch from staging to work on our features. Our Pull Requests are for merging back into staging. We then merge into production from staging. This last bit is still a bit clunky as we have to issue another PR for that merge.

Push it

Salt n Peppa - Push It


The staging branch for a project deploys automatically. Changes to repos send triggers from Github to Bamboo (using the built in Bamboo Service Hook) to run build and deploy plans. For production we'd rather have control over when this happens. So while builds are still automatic for production, we manually trigger deployments at the push of a button.

We are using mina to push our apps to our servers, executed by Bamboo. Bamboo has an official Ruby plugin which we are using. This includes running Bundler tasks.

More polish?

What we have so far is a little bit rough still on some edges (the PR to production for example), but overall we are finding that this workflow model is working well.

This is not to say that as we gain more experience we won't revisit the various models of workflow in the future.