Digital Marketing & Communications

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

Topic: Communication

Exploring new ways of writing about our research

📥  Communication

One of the most common content types we currently use for our research content is a press release. Or a news item, which is what we call them after slightly repurposing them for the website. In the past three months, we’ve published roughly 40 research-related news items.

The thing about press releases is that they are tied quite heavily to two very specific points in the research lifecycle - winning a research grant and publishing a paper. Similarly, case studies, of which we’ve published six in the past three months, are tied to a particular point in the research project - to complete the classic case study structure, the results of the research have to be in.

Softer, narrative content

The new content we’re suggesting moves away from all these time-related restrictions. It places the emphasis away from published papers and research results. The story becomes about the researcher, their journey, personality and aspirations. The style of writing is softer, more narrative.

This is a result of a Digital research content strategy we launched in late 2015. It sets out how we want to develop the way we communicate about our research online to reach new audiences and make most of all the cool research that’s happening at Bath.

We recently published two of these kinds of stories. One of them is about an ambitious Syrian researcher who’s on the brink of finishing his PhD with a promising career ahead of him, potentially in a leading international architecture company. The other one is about how one of our senior researchers came to be the host of the UK’s beloved annual Royal Institution public lecture series.

The first one was written by me, the latter one by our Research Marketing Manager Andy Dunne. We edited each other’s articles and various team members were involved in polishing and proofing. Publishing each one felt like a genuine team effort!

Off to a good start

The early analytics of the new kind of content look very promising. Looking at the pageviews of our research content in last three months, the story about the Syrian researcher is comfortably the most popular piece of editorial content we’ve published. The news item that comes closest has over a third less pageviews.

The article about our researcher hosting the Christmas Lectures is in the fourth spot after an old case study about some of our most well-known research (consistently one of our most popular pieces of editorial research content), and a news item about a clinical trial of our smart bandage prototype. That one was published in late November while our feature article was published on the 21 December, so I’m expecting the feature to rack up some more views in the coming weeks.

Why I like it

From a very practical point of view, the best thing about this new kind of content is its longevity. While news items act as a useful reference back to a specific point in time, the feature-style content stays topical for much longer. It’s a far more natural type of content for reusing without edits - whenever a relevant news story arises or a new research paper is published by the academic, it can simply be tweeted or pinned to the landing page of a department as it is.

A nice additional bonus in the process has been seeing how well this content fits into the new templates of beta.bath.ac.uk. Compared to the old templates, the user experience as a publisher has also been top notch! It’s been super easy to upload and publish these.

On a personal note, I really enjoyed the process of interviewing and writing. As an Editor, it’s rare I get to be involved at that stage - my job’s more planning, delegating and subediting. Getting to meet the researcher, listen to them passionately talk about their work and trying to capture that passion in the copy is a process I sometimes miss from my journalism days.

 

The neverstarting story

📥  Beta, Communication, Development, Team

Do you ever have a piece of work that never quite makes it to the top of the to-do list? Something that needs doing but is not really crucial enough to be prioritised that highly. It lingers in the background, knocking on the door of your subconscious every time you think of the project.

We had something like that. A story in our backlog which so very nearly made it into sprints, but never actually did. This happened so many times over 5 months that it became known as the 'cursed' story.

Then one day it acquired a different nickname. The original product owner was so fed up of it not being done that he wrote this comment on it.

PO comment

And the 'champagne story' was born.

But the comment didn't seem to help because nearly a year passed before it finally made it into a sprint. The story itself seemed to become more daunting the longer it was unstarted. It was essentially about republishing related content when an item gets published. Important but not groundbreaking stuff.

In the end the story got reduced in scope and then finally made it into the backlog for a sprint. It just so happened that I was the person who picked up the story and actually got the feature done. After all the delays and near misses, the feature itself was quite straightforward to implement.

So you are probably thinking that there was much rejoicing at this being done and I went home happily clutching a newly acquired bottle of champagne? Well, not quite. You see, the product owner had since moved on from our team, so there was a question over whether the champagne would arrive. The team put out a few gentle reminders.

Reminder

The message was out there and we waited. At the same time this was happening, it was my turn to bake for our GBBO sweepsbake. And that is when I had an idea.

What if I baked a cake in the shape of a champagne bottle to celebrate the story being done? And what if I delivered it anonymously to the office? I wondered what would happen.

Cake

 

Detective

It was a fun day. I sat back and watched as people in the office were trying to work out who had made this cake. There were some top detective skills put into practice but somehow I managed to get away with it until the following day when I owned up to being the secret baker.

All in all, I enjoyed finishing the story and baking an interesting cake for the team. I learnt a lot about my colleagues and how much fun they are to work with.

Keep shipping! (and baking)

And it's goodbye from him

📥  Communication

After more than a decade, tomorrow is my last day working in the Digital team.

The team's had different names, and I've had different roles, but my mission has always been the same: improve the University's online presence through applied use of technology. While trying to live up to this, I've been privileged to work not just with the developers, but also our editors, product support and designers.

Tech

With our recent work on the Content Publisher I'm happy that the platform and technology for doing that are now better than they've ever been. The team can now continue to build and innovate on top of a solid foundation to provide the University with the web publishing platform that it needs, evolving as user expectations increase over time.

Help

Only a few years ago we had no dedicated support channels - instead we rotated the responsibility for looking after our users around the team. I can hardly remember those dark days any more - we've since introduced standards, reporting and guidance to be proud of. We've still got high ambitions in improving our service here, but with a user satisfaction rating of 96% it seems safe to say we're on the right path.

Words

A much harder problem has been managing the content on www.bath.ac.uk. For a long time there was no governance on how, why or when content was added to the site and so we've found find ourselves with a challenge.

The way we've approached this is to help each department change how it thinks about its web content, and where possible to be guided by our Delivery Principles.

This is no minor undertaking. Michael Slaby, Obama's 2008 chief technology officer, said it better than I could:

It's just change management. It's not complicated; it's just hard.

It's not only hard, but it needs to be continuous - large organisations have a tendency towards inertia that the internet and its users don't. The passion and energy of the people in Digital to take this on this challenge has been critical to our successes. It's something which I've also been amazed to watch them impart to others. The thousand new pages we've published in the last 12 months, and the thousand which are in various states of review and fact-checking right now wouldn't have been possible without the support and energy of all those departments we've been working with so far.

Colours

When most organisations come to revamp their website, the primary focus is on look and feel. What colours does it use? What's the logo? For us it's been something more, a complete change in how we think about the site. A break from organisation-out thinking to be user-in. Most people coming to bath.ac.uk don't know or care about which group is a sub department of which faculty, what they care about is being able to find the right information quickly, and being able to understand it easily. Our research so far has shown that our new templates, navigation and content guidance are doing this. They'll also continue to evolve as more departments come into Content Publisher and I look forward to watching the changes in the future.

Finale

We've had a number of people join the team in the last few weeks and I've been pleased to see them start to discover some of the things that kept me here so long - a variety of projects and products, an opportunity to expand your skills in many direction, a commitment to quality and an amazing team spirit.

I can only hope to find myself in another team with such a selection of hard-working, dedicated and passionate people in my next role. Thank you all.

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.

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.

transition-board-zero

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.

student-rec-board

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.

content-type-cards-checklist

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.

epics-transition-board

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
good-transition-housekeeping-trello

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

 

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: https://github.bath.ac.uk/digital/visual-regression-testing/ (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.

 

Going on an adventure

📥  Communication

After almost three years working at the University of Bath, on Friday 23 September I will leave my role as Digital Content Editor and Digital Supporter for AHS.

I’m going on an antipodean adventure, travelling around New Zealand for a year.

While I’m incredibly excited about what is the trip of a lifetime, I’ll be sorry to leave behind great colleagues, friends and work that I am immensely proud of.

During my time here I’ve transformed professionally, which has been an adventure in itself. A former magazine sub-editor who wrote album reviews for online and print in his spare time, I now use an agile approach to design, create and curate digital content that meets specific user needs.

This is in no small part due to the expertise, guidance and enthusiasm of the Digital Marketing and Communications team.

Working with them has not only been excellent fun, but it has given me an assured understanding of how people perceive web content, how we all actually use the internet and how we can make the experience more useful and intuitive.

Creating something that works

I’m particularly proud of transitioning our Accommodation, Eateries, Events and Security content from the previous incarnation of the University CMS and website to our shiny new one. In fact, we were among the first departments to make the switch.

Our new site, inspired by the principles at the heart of gov.uk, puts users first. It’s a hugely positive move that is already bearing fruit.

Take our Student Accommodation content. Previously we had content across several different folders, resulting in disjointed and duplicated information.

Now it’s all in one place, with a group landing page we can modify depending on the time of year and stage of the applicant journey.

While earlier in the year we pinned accommodation application information to it, now - as we approach intake weekend - we can push useful and relevant arrival information to our users.

Information about what you should and shouldn’t bring with you, where to pick up your keys and how to send luggage to the University if you’re moving from overseas.

That has undoubtedly helped the content to perform much better this summer.

For example, when applications for accommodation opened back in April, our analytics shows signs that user engagement and has improved.

  • Increased sessions on day applications open - 2015 (4,498) vs 2016 (7,997)
  • Monthly unique pageviews leapt from 64,623 in 2015 to 91,592 in 2016
  • April 2016 bounce rate down vs 2015, from 43.69% to 32.56%
  • Exit rate also fell from 25.49% in 2015 to 18.23% in 2016

Combine that with an increase in entrances and average session duration and it looks like our content is easier to find and more useful.

Tailoring our content to meet specific user needs is working.

Thinking about content in this way - putting the user first - is so simple, so sensible and yet still relatively rarely implemented.

Well I’m taking this with me, out into the world.

Decluttering dusty old windows

When I was at University, way back in the mid-2000’s, I was told that a website was an organisation’s shop window.

Many organisations also heard this and have piled everything they have onto their website and left it all there, gathering dust, not really knowing why they put it there but pleased they have because now it’s in the window and people will know. They’ll know about all the things in the window. Right? Or will they just walk past thinking, “That place looks a mess”?

Shops don’t put all their products in the window at once. Not good ones anyway.

Stores like Selfridges invest great skill, research and consideration in their window dressing. They carefully and deliberately showcase the things that their customers want or need at a time when they desire or require it.

So why treat a website any differently? Declutter. Find out what your users need, give them that clearly and simply enough that anyone can understand it, and adapt to changes in user behaviour. Repeat.

I can’t stress enough how much this has influenced me, and how much agile content excites me.

I’ll always remember and be grateful for what the University of Bath has taught me, and I couldn’t have hoped to learn from a better bunch of people.

It’s been a blast folks. Thank you.

Steve and his partner will be blogging and podcasting during their trip round New Zealand, and you can follow them on Twitter.

The University of Bath's Digital Design Principles

  

📥  Communication, Design, Digital strategy, Style, content and design

Based on our current Digital Delivery Principles, I recently sat down and drafted a set of Design Principles. These were shared at one of our Show and Tells as a presentation, but I thought I'd reproduce it here on our blog for a wider audience.

1. Design for real people

”Remember who you are designing for”, is the most important thing we can do.

Every design decision we make should solve an actual problem that a site visitor has, or facilitate a real user need. Design should serve the content it presents, design in the absence of content is not design, it’s decoration. We always keep in mind that the end user of a page can be very different to us, with different needs, expectations, and abilities, and ensure that our design does not exclude them from getting the answers they need.

2. Design with data

Successful design starts from a clear and informed position.

Our approach is inclusive: we're building a site that will provide the optimal experience for a visitor whoever they are and whatever device they are using. To achieve this we conduct user research to better understand what people expect. We test changes, features and assumptions with users to get insight and feedback that ensures we are delivering on that expectation. It is as important to remove failing features as it is to add new features into our design, and the ability to know what works and what doesn't only comes from data.

3. Be simple, fast and effortless

Good design, when it’s done well, becomes invisible. It’s only when it’s done poorly that we notice it.

We maintain a pattern library to ensure the design of elements is consistent, and this ensures that our interactions speak to users with a single voice, building trust.
We strive to ensure that our design affords our visitor with an experience that feels fast – they should be able to find what they need on the page without a delay. Images are optimised for the device they are viewed on, visual enhancements are loaded progressively, and do not disturb the flow of content on the page.
We minimise pain-points as much as possible with an awareness of good practice, to provide an effortless experience.

4. Make bold choices

We measure ourselves against the very best, and we should not come up short.

The success of the University of Bath is based on calculated risk-taking, knowing when to break from convention, and when to reprioritise your approach to better fulfil the requirements of the people who depend on you. Instead of simply matching what other institutions offer, we challenge them with innovative approaches and ideas that better serve users’ needs.

5. Always evolving

We believe that things can always be made better, and we know that good design is never finished.

It is pointless to sink 2 months into crafting the most beautiful interface if it does not allow the visitor to complete their task, or does not work on a mobile device. We release a design feature as soon as possible, and then iterate on that delivery to improve it.