Digital Marketing & Communications

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

The pursuit of Appyness

📥  Digital strategy

We love apps. Apps can provide interactivity and features that web pages simply can't. They can tap in to your phone's hardware to use the camera, connect to your address book to help you remember birthdays or send push notifications when important events occur.

A photo taken with Snapchat

Snapchat is a great example of an application which uses a phone's hardware. Photo by Ariel Chang.

But there are many things that web pages can do just as well as apps. They let you get updates on news and events, connect through social media or buy things online.

So, once every few months, when we are approached by someone with either an idea for a mobile app or a brochure from a vendor who promises the world, we ask a few questions.

  1. Does this information already exist on our web pages?
  2. If yes, then what extra benefit would an app bring? Who would maintain the two versions?
  3. If no, then does it exist anywhere else? How would making this into a University of Bath app improve it?

It often turns out that the information or functionality does already exist. Unless a new app is likely to provide a highly polished and professional interface (think about the Amazon, BBC News or Facebook apps) then we recommend that teams spend the equivalent time and money improving their existing web pages. This could be either by transitioning them to the Content Publisher to make them work better on mobile devices, or simply using usage data to improve the existing services they deliver.

Mind the gap

In the cases where we agree there's a space that a dedicated University of Bath mobile app might be able to fill, we ask three questions before beginning a trial:

  1. How can we tell how often it's being used and which features are popular?
  2. How does it look, feel and behave at the front and back-ends in real use?
  3. What are the security implications of this app?


Gathering usage data is critical, and yet many apps we've seen don't deal with it at all. We are committed to making decisions with data, and because we know that 77% of users never use an app again 72 hours after they installed it, we want to ensure there's a good return on investment.

Apps that are free to a user aren't free to the University. They have ongoing costs in terms of developer licenses, contracts, maintenance and brand association. This means that usage data (which is very easy to collect in mobile apps) is a requirement for being able to measure success.


We also always ask to use the app for a short while ourselves so we're not assessing a special demo version, or making a decision based solely on what it says in a brochure. This helps us to judge if the reality meets the promise. Is the content easy to update? Does the custom branding work well across multiple devices? Does the app work as expected?


If an app collects or uses user data we put it through a security check. If the source code is available, we will review it. The Security Manager in Computing Services will also take a look at any Data Protection statements and ask a provider to answer questions about data security and storage. It is not uncommon for apps to want to store personal data on servers in the United States, which breaks the University's eighth principle of Data Protection and means the provider will need to switch to a European data server.

In summary

Whilst we maybe have a more permissive view than the Government Digital Service, we always ask that University groups understand their users' needs and can ensure the quality, sustainability and security of an app before starting a trial.


Progressive enhancement and team memberships

📥  Beta, Development

We recently shipped some changes to how we order team members in our Team Profile content type.

These improvements came in several stages, each building on the last, so this seemed like a good opportunity to talk about progressive enhancement.

What is progressive enhancement?

The Government Digital Service's service manual has a great explanation of progressive enhancement:

It’s based on the idea that you should start by making your page work with just HTML, and consider everything else an extra.

This is because the only part of a page that you can rely on to work is the HTML. If the HTML fails there’s no web page, so you should consider the rest optional.

We prefer this approach to immediately building a feature with all the extras (like JavaScript) and then trying to make it degrade gracefully (or just keeping our fingers crossed that it doesn't break).

Progressive enhancement is important for accessibility. By making sure your feature works with HTML alone, you can be more confident that your feature will work for people who are:

  • using assistive technologies
  • on slow or compromised connections
  • don't have JavaScript enabled for some other reason

Progressive enhancement is also well-suited to Agile, as you can start with the core functionality and then iterate.

Introduction to the feature

Users have two options when it comes to creating team profiles:

  • 'Create manually' – create a list of names and roles using Markdown
  • 'Select from Person Profiles' – add Person Profiles to the team to pull through the member's name, role, photo and other important information

When we first built the 'Select from Person Profiles' feature, users had no say over the order in which the team's members were listed on the page.

Members with the 'Leadership Profile' subtype were always listed first. All other members were then listed in alphabetical order. Our users reported that this wasn't ideal and it was often important that members be listed in a certain order. For example, the manager of a team should probably be listed first, even if they don't have a 'Leadership Profile'.

Adding the order with HTML

Our earlier version of the Team Profiles interface did have some JavaScript. Adding the order was complex enough that it was easier to strip out any existing JavaScript and go back to basics.

After some complicated data structure changes behind the scenes, we had a shiny new field called 'Order in team'.

Team members in the base implementation

Team members in the base implementation

Users could now specify the order by entering numbers into these fields. When they saved or published the page, members would appear in the order they'd chosen, both in the interface and on the page itself.

Saving the page also added more empty member dropdown menus, so users could add more members if they wanted to.

We now had the core functionality, even if there was still room for a bit of polish.

We shipped this version of the feature and then moved on to the enhancements.

Adding the magic with JavaScript

We had the essential behaviour of the feature, but there was still room to improve the user experience.

Now that we had a feature which worked with HTML only, we could add enhancements for any users who also had JavaScript enabled.

Our JavaScript addition did several things:

  • replaced the multiple dropdown menus with a single one, which adds new members to a list below
  • allowed users to drag and drop the members in the list into their desired order
  • hid the member order fields, but updated them behind the scenes whenever users rearranged the members through drag-and-drop
  • added a remove button for each member to take them off the list

These enhancements make it quicker for users to add, reorder and remove team members.

Team members with JavaScript enabled

Team members with JavaScript enabled

If the user doesn't have JavaScript enabled, none of these enhancements kick in, but the feature still works as before.

This means the Content Publisher can still be used by broad range of people, no matter which technology they're using.

What comes next?

We don't work with JavaScript nearly as often as we do Ruby. As such, our practices need a bit of work.

Because the JavaScript implementation changes the interface, this means inserting HTML into the page. Currently we store this HTML in the script itself, which is messy and difficult to read. It's probably time for us to get familiar with a JavaScript templating engine – Handlebars.js seems like a likely candidate.

Trying (and failing) to test the drag-and-drop behaviour in Capybara also revealed that we need a better way to handle feature tests and JavaScript. We've got some planned investigation into Poltergeist which will hopefully sort this out.

While neither of these changes will be apparent to users, it should make our development process smoother as we roll these sorts of JavaScript enhancements out to other parts of the Content Publisher.


First impressions – five reasons why I love working in the Digital team

📥  Blogs, Team

They say a week is a long time in politics. But it seems just seven hours can be a political aeon. Because the day before I started my new role in the Digital team, I went to bed in a prospective mood, only to wake to the shock-and-awe news of Trump's election success. With two proud Americans on the team – and the rest of the department seemingly of sound-mind and warm blood – I walked in to an office that was in a palpable sense of shock. But that didn't stop the team welcoming me with open arms and big smiles. These guys are made of strong stuff, I thought.

What I'm doing here

My role here is that of Digital Producer. In time, I'll be planning and producing new content for the transitioned website. For now, I'm getting to grips with all the facets, faculties and faces of the University, and its marketing and web teams.

I come from the world of consumer journalism. Specifically, design and tech websites and magazines (which means I haven't tapped any phones; but I have reviewed a lot of them). In that life, I chased referral traffic and copy sales. If ever the mantra 'done is better than perfect' rings true, it's when you and a thousand other publications are wrestling for search dominance during an Apple unveiling. Fun? Sure. Rewarding? Regularly. Hectic? Definitely. Shambolic? Often. By comparison, the Digital team here is a well-oiled machine. Laser-focused, calm and professional. My new co-workers come from varying backgrounds, but what strikes me most is the air of expertise and attention in producing the best work possible, quickly, and with little-to-no fuss.

The story so far

In my first two weeks, I've sat in on planning meetings; taken part in sprints and fast-turnaround tasks. I've watched as seemingly impossible requests are explored, executed and delivered within what should be unscalable deadlines. I've been to two Show & Tell events – single hour sessions every second Friday, where the team and invitees present success stories and share knowledge – and been blown away by the confidence of the presenters and the quality of the work. And above everything – I've not heard a cross word exchanged.

Plenty of opinion, yes. Healthy debate and cross-examination, sure. But all for the greater good of the task in hand.

This isn't just refreshing. It's positively energising, and a world away from the frazzled grind of consumer journalism.

Why things are GOOD

In keeping with my previous career, though, I thought it might be appropriate to get the last of the clickbait out of my system with a time-honoured listicle.

Behold my five favourite things about working in the Digital team, and what I've learned in the last three weeks.

  1. People care. They care about the quality of the work. They care about how it's presented. They care what it says about the Digital team and the University.
  2. Reason underpins everything. There's no punts; no execution without validation. Hunches are locked in a top drawer. It's not empiricism, it's user-centric design at its finest. And it works.
  3. Office furniture is for sitting on, not for hurling at staff writers. Critical interrogation is welcomed here. Without having to duck from an airborne keyboard as you spike someone's copy or question their caption writing.
  4. I’m surrounded by really smart people, both the academics and University staff; and the direct team I work with of developers, editors and designers.
  5. There's a clear goal, and it's not improving a bottom line or turbocharging share value. It's in producing the best quality work possible within a deadline that does the job it was designed to do.

Have I landed on my feet here, I asked at the end of my first week. Yes. Definitely. A week might be a long time in politics – but in the Digital team, time's flying and I'm having fun.


Are we there yet? 3 years in agile design

📥  Design

It’s been almost 3 years since I joined the University of Bath digital team and, despite committing wholly to the agile workflow, I’m still struggling to reconcile certain aspects of our working practice with the freelance life I left behind.

As a designer with almost 20 years of experience and weened on a thoroughly waterfall design process the thought of handing over ‘unfinished’ work to a stakeholder is still an uncomfortable one.

How good were The Good Old Days?

In ‘The Good Old Days’ done meant done.

As an interactive designer I’d often be tasked with producing dozens of pixel-perfect page designs illustrating every conceivable content type, state and variant. These layouts were honed, polished, considered works-of-art (at least in my mind).

And these designs were considered final. The end of the design process. I was done. These static snapshots of a site were then presented to project stakeholders as a fait accompli.

“Do you like the design? This is what your site will look like”
“Yes. It looks great.”
“Wonderful. Summon the developers - we have a site to build!”

The Minimum Viable Product

In the Digital team, we use agile methodologies when designing and developing. In basic terms, this means that we are constantly iterating, improving and updating small, discreet elements of our designs based on feedback.

The upshot of this is that the first version, the thing you launch, the live site, is not perfect. In fact it never will be.

The MVP (Minimum Viable Product) is a base-level, functional version that lets the user do what they need to complete a task or locate a piece of information. For a designer, used to polishing a design within an inch of its life before letting anyone see it, the MVP is a rude awakening.

Things aren't perfect, they aren't the best they could be. They most certainly aren't finished. However they do meet the users needs for a functional, viable experience.

The lack of control still makes me feel nervous but designing for a specific user need has changed the way I think about my work.

Just ship it…

It can sometimes seem like an agile project has no plan, no overall vision for the end result.

From a design perspective, this can be frustrating when working on the conceptual elements of a design. Trying to get a grip on what *everything* looks like and how it holds together can be tricky when working on a single aspect of an interface component or tiny piece of functionality in seeming isolation.

The understanding of when an MVP can be described as viable is a skill in itself. The PO (Product owner) holds the product vision and is the arbiter of 'ready' - they say if a component, a template or a feature is in a position to ship.

And shipping happens as often as possible. One of the basic tenets of agile is that we look to get things in front of real users as quickly as possible. Any feedback the users provide is then used to refine or create further user stories to iterate on the previous work and make it better.

I may not have my pixel perfection but I do have real, genuine data from those on the coal-face using the things I have designed.

Caring (for your users) is sharing (with your users)

Putting things in front of people is still scary after all this time. No-one likes criticism. We certainly don’t like watching anything we have worked hard on fail.

The flip-side of this is that user-testing is a liberating, eye-opening experience for any designer. Watching a user struggle to find your meticulously crafted call-to-action or swiftly complete a complex multi-stage task brings you closer to your users.

I love this new-found connection with the end users of the products and services I design.

The MVP of embracing agile…

… is an awkward hug with good intentions.

Learning to embrace agile has certainly been a challenge. Three years in and my user stories could always be better, my fear of bad feedback has only slightly diminished and my frustrations at shipping something that (I think) looks like a dog has chewed it a bit have not abated.

However, the openness of communication and the interaction with the people who use the things I make on a day-to-day basis have meant that I believe my design skills have improved immeasurably.

Maybe it is possible to teach an old dog new tricks.


Digital team sprint notes 15-28 November

📥  Sprint notes

What we did

  • Updated the links in the footer of the new pages to point directly to the correct locations (Copyright, Freedom of Information etc.)
  • Reduced the size of headings in the sidebar of filtered lists
  • Improved the consistency of lists on Person Profiles
  • Made sure that the subtype of a content item is consistently displayed across Collections, Landing Pages and the content item itself
  • Allowed lists of Team Profiles to be filtered by subtype
  • Improved the layout of Team Profiles on small screens
  • Added ‘Minutes’ and ‘Programme specification’ subtypes to Publications
  • Viewport meta tag is now correctly formatted to improve mobile layout
  • Profiles with no role information no longer display a massive bio pic
  • Added space under the ‘Accessibility’ information on Events sidebar
  • Resolved 189 requests to web-support
  • Resolved 14 items of content maintenance. These included:

What we’re going to do

  • Update how we build our stylesheets to make them easier to use for new staff
  • Ensure that the application logs are being managed correctly to help us find any problems
  • Set up email notifications when errors occur
  • Carry out some discovery on the best way to move content items through different workflow states
  • Improve our documentation for people getting Content Publisher running for the first time
  • Add a “Booking closed” option to the Event content type


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.