Digital Marketing & Communications

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

One Hour Upgrade - April 2017 edition

📥  One Hour Upgrade

Although flat-out with sprint work, the team managed to squeeze in a quick One Hour Upgrade before the Easter break.

As it had been less than a month since the last upgrade, I was expecting fewer stories for consideration. As it turns out, I needn't have been concerned - a massive 16 fresh stories were added to the backlog, of which 8 were voted on to the ‘To do’ board.

Once again, pairing on stories was popular - 5 of the 8 stories were tackled by dynamic duos. There were a couple of cross-team partnerships in the mix but we could always do with more.

What was started

  • Tegan and Iris spiced up the deploy screen, adding more at-a-glance info and a fresh new design
  • Justin K spent his hour improving our Trello-based induction board for new developers
  • Rhodri and John worked through the summary paragraphs on our guides, improving consistency and relevance
  • Tom T began the hunt for a good HTML 5 video player for our Wowza live streams

What we got done

  • Dan’s attempt at a simple 'pens and pads' order turned into a clean out of the stationery cupboard. Turns out we have enough post-its to last for a while
  • Hanna and Rhian put together a proof-of-concept screencast for Content Publisher training

What we learned

  • We need to find a way to encourage more cross-team pair-ups for One Hour Upgrade
  • Our current video streaming services are still reliant on Flash
  • We have a lot more stationery than originally thought. We definitely don’t need any more Sharpies

What’s next?

Our next One Hour Upgrade is scheduled for 12 May 2017.

Observations of a Digital Editor (a three-week analysis)

📥  Communication

I’ve been with the Digital Marketing and Communications team for a few weeks now, and these are the things that I can say with certainty:

  • I’ve seen both Star Wars and Star Trek imagery around the office, which means that there’s either an uneasy peace between factions or a cordial ceasefire
  • Justin’s ability to kill fruit flies is both impressive and disturbing
  • Dan’s penchant for producing a fly-kill scoreboard would be infinitely more disturbing, but his Game of Thrones coffee mug overrules this concern and makes him ok in my book

This is clearly a good time to come into the team. With the bulk of student recruitment content going live on my first day (and thus the dragon roared, as is its wont), there’s a tangible sense of achievement and the conquering of a mountain in the office. It makes for a feel-good atmosphere, which has naturally helped me to settle in.

The Content Publisher and me

In my time here, I will have a few key things to achieve:

1. Update our internationally targeted content to ensure we’re delivering messages prospective and current students want and need

2. Keep this consistent with the overall transition project

3. Do this sufficiently well to ensure that Miao doesn’t look at the website when she returns from maternity leave and wonder why it’s fluorescent green, in Comic Sans and based around a gif of a dachshund dressed as a reindeer

To reassure Miao and others, none of these issues appear on my first creation, the new international landing page.

This was created using the Content Publisher, which I can recommend for its ease of use. Thanks to the Content Publisher our content is much more focused and streamlined compared with that on the OpenCMS site, and I’m looking forward to carrying on in this vein for all things international. The Content Publisher also allows us to be flexible with our content when required, which means we can be more time-sensitive with our messages going forward.

Agility training

Digital practises the Agile methodology, which in grossly oversimplified terms means that we work on projects in two-week ‘sprints’, reviewing and reworking our content collaboratively as we go.

I’d heard about Agile previously but not been involved in an organisation using it, so there are definitely a few teething issues there for me to work on. Being used to working on about four billion things needing my attention at once, I’m finding Agile more focused, and the departmental methodology is one that encourages collaboration.

This may, of course, all be a case of the team ushering me in slowly. Once they read this post I’ll probably be sent forty billion content maintenance requests.

Digital Marketing in China workshop

A few weeks ago, I attended a workshop at the RSA (Royal Society for the encouragement of Arts, Manufactures and Commerce) focusing on how UK universities can develop their messages for prospective students from China.

This was eye-opening in many ways. In particular, the purposes and structure of videos shared on Chinese social media platforms are often atypical to what we see in the West. This raises a number of questions regarding the content we currently have, and what we may wish to create and promote in the future.

In summary

To avoid turning this blog post into a long-winded dalliance through my tangential ruminations, simply put there’s plenty for me to think about. You have me until Miao returns in December. Feel free to swing by and say hello. (more…)

 

Visual regression testing with Wraith

📥  Design, Development, Tools

Last week I talked about how we chose Wraith as our visual regression testing tool.

After lots of discovery and preparation, we were now ready to get our first real tests up and running.

Screenshot of tests in Wraith

Example of a failed test in Wraith. Differences are highlighted in blue – in this case, I've modified the summary slightly.

In this post, I'll go through how we run our tests locally and as part of our continuous integration process. But go make a cup of tea first, because this will be a long one...

(more…)

Choosing a visual regression testing tool

📥  Design, Development, Tools

We've recently been working on getting visual regression testing up and running for bath.ac.uk.

Back in October, Liam blogged about our earlier research into visual regression testing. But if you need a refresher...

Visual regression testing in a nutshell

Visual regression testing is a way of automatically checking webpages to catch any unwanted changes, or 'regressions', in the design.

These unwanted changes are a risk we run every time we modify the code for the design of the site. Sometimes a single tweak in one place can have unexpected consequences for another aspect of the design.

We could just eyeball lots of different pages to see if anything looks wrong, but this takes a lot of time, and there's always a chance of missing some tiny difference.

It would be much better to write some automated tests which take screenshots of the pages before and after we've modified our code, and then highlight any changes.

Changes are highlighted in blue. Oops, that shouldn't have moved.

Differences are highlighted in blue. Oops, that should not have moved.

Basically, it'll save us loads of time and keep bath.ac.uk looking great!

We were excited to crack on, but before we could get our tests up and running, we had some decisions to make.

Choosing a tool

There are a lot of different options out there for visual regression testing. We'd previously followed a tutorial using WebdriverCSS, but struggled to make the tests run consistently and generally found it a frustrating experience.

We decided to investigate alternatives. Our discovery process included:

  • reading any guides and documentation
  • checking the release history to see how well maintained it was
  • getting it running locally if possible
  • writing and running some basic tests

Some of the tools we looked at were:

And the winner is...

After doing the research and discussing the options with our designers and developers, we decided to go with Wraith.

We ain't afraid of this ghost

We ain't afraid of this ghost

Built by BBC News developers, Wraith has also been used by the Guardian and the Government Digital Service.

It's written in Ruby, our dev team's language of choice. The config and tests are written in YAML, which we felt was easier to work with than the alternatives (usually JSON or JavaScript). When we tested it out, it took less than an hour to install everything and write and run our first tests.

It also offered two options for running the tests – you can compare new screenshots to historical ones, or compare the same page across two different environments (for example, staging and production).

Deciding what to test

We'd chosen a tool, but we still needed to decide what to use it on.

Like many visual regression testing tools, Wraith allows you to test entire pages or individual elements.

Testing individual elements makes finding differences much more precise – otherwise one change high on the page can have a knock-on effect on everything below it. Having a comprehensive pattern library can make it even easier to test individual elements.

All of this sounded great, but our pattern library isn't in a testable format yet, and writing tests for individual elements is time-consuming.

We wanted to get up and running as quickly as possible, so we decided to test full-page screenshots of real pages in each content type. This will provide a solid level of coverage, and of course we can always keep improving our tests and making them more comprehensive.

We also had to decide what screen resolutions to test at. We checked our Google Analytics stats for 2016 and found the top 3 resolutions across desktop, mobile and tablet.

One size (1280 x 800) appeared in both desktop and tablet, so this left us with 8 sizes to test against – ranging from 1920 x 1080 all the way down to 320 x 568.

Next up: implementation

We now had a plan for writing and running our first real visual regression tests.

In my next post, I'll talk about the process of getting Wraith set up and fitting the tests into our workflow.

 

Editorial style never goes out of fashion

📥  Communication, Style, content and design

Keeping it stylish

We editors like to keep ourselves in style. I'm not saying we're obsessed with the sartorial (although we do enjoy a nice cable-knit jumper), just that we like to make sure we're following and updating our Editorial style guide. These are the guidelines that help us, and other content creators, keep the website's content clear and consistent.

Clarity for us means making our content accessible to all (including those using screen readers and translation tools) and writing in plain English by avoiding jargon and idioms in our marketing, PR and informative content. This isn't 'dumbing down', it's writing so that everyone can understand it without losing the meaning.

Consistency is about giving the user a smooth journey through the site. The importance of this (or a warm wool jumper) should not be underestimated. If you visit a website and every page has a different colour scheme and layout, you'll probably be a bit confused. You might even think you've accidently jumped to a different site. In the same way, inconsistent writing styles can have a jarring effect on the user and make their experience confusing. Imagine thinking you're in cable knit only to look down and see a string vest. Not pleasant.

Having a consistent writing style also helps us create our online identity. When we consistently use the same words, and specifically the same meanings for words, users can recognise us more easily in a crowded internet. Our writing style is our identity, like a jumper you'd wear all the time that everyone agrees is 'very you'.

What we're wearing this season

The problem with our cable-knit jumper is that it's a bit bulky. A tad cumbersome. Also, it makes our neck itch, but that's nothing to do with the style guide. The jumper needs reknitting into one that's easier to wear, lighter, with detachable arms perhaps. And now I'm stretching it. The metaphor, not the jumper.

The Editorial style guide is similarly unwieldy. It's currently one page, arranged in sections like 'General style preferences' and 'University references'. As full of useful information as it is, you really have to know where to look to find what you want. In many cases, you have to search the page for a specific word, hoping it pulls up the right results.

From a maintenance point of view, this structure makes it difficult to add or amend the content. We have to fit it into one of the existing sections or create a new one, making it harder for users to work out where they should look for answers. Some things need more detailed explanations, which we can't add now without them clogging up the page.

Style gurus

We're fans of the Guardian and Observer style guide and the Gov.uk style guide as examples of good practice. Both are arranged alphabetically, rather than in thematic sections, so it's easier to guess what word to search for. Both provide short comments on points of style, but for some longer explanations, the Gov.uk style guide links to other guides.

Next season's styles

Based on these style guides, our plan is to rearrange our style guide into an A-Z of everything. Users will be able to search a single page for a point of style, but there will be aliases to make everything easier to find. For example, if you search 'lower case', you'll be told to see 'Capitalisation'. If you look for 'dot dot dot', you'll be pointed towards 'Ellipsis'.

In most cases, we'll give you a brief explanation of the point of style, how to use it, and examples of house style. Some things need a little (or a lot) more detail. For these, we'll link out to other Guide pages. These will cover things like:

  • apostrophes
  • inclusive language
  • academic terms
  • words to avoid

These points are all covered in the current style guide, but by giving them their own Guide pages we'll be able to go into them in much more detail. We'll be able to expand our explanations of inclusive language, for example, and give a much fuller list of words to avoid, a useful piece of content in the campaign for clarity.

We'll also link to our other writing guides, like 'Writing for the web' and 'Creating and writing blog posts'.

Keeping ahead of the trends

We'll continue to add to the style guide and improve it. The English language, like fashion, is constantly evolving. New words are always being invented and old words are always being misused, which means we always have plenty to add to the list of words to avoid. Here are a few of my current 'favourites':

  • toolkit
  • utilise
  • initiate
  • leverage
  • whilst

Style for everyone

Cable-knit jumpers are not for everyone, but the Editorial style guide certainly is. Anyone writing marketing, PR or informative content for the website should refer to it, not just the Digital Content team. It's also useful for people writing on the blog or even in print. Achieving consistency across all University communications is a big challenge, but having a single style guide to follow is a good step towards this.

The important thing is for everyone to keep the style guide in mind and use it as they write. This can be hard to do, even as an editor responsible for maintaining it. It takes a critical eye and an awareness of the types of things that you might need to check. Things like house style for quotation marks, bullet points or commas, whether 'biannual' means twice a year or every two years, how to write about currency, how to write the plural of 'master's degree', whether we hyphenate 'full-time', whether 'instalment' has one 'l' or two...

These are the things I dream about.

 

If you have any suggestions to improve the style guide, you can email web-support@bath.ac.uk.

 

I love it when a sprint comes together

📥  Team

Last month marked my two-year anniversary at the University. I’m a Web Content Editor, and I’ve held the position at two faculties. I joined as maternity cover for Saskia in the Faculty of Science and later moved to a permanent role at the School of Management. Maybe one day I’ll have ticked off all four Faculties. I think you get a certificate for that.

In short, Faculty Web Editors (FWEs) plan, develop and deliver digital content. (Management is technically a School, not a Faculty; but for simplicity’s sake we’re referred to as FWEs.) While the focus is largely on our ‘local’ web sections, we often work on projects for the wider bath.ac.uk too. It’s a varied, interesting role and quite a lot of fun too.

One of my favourite things about being an FWE are the opportunities for collaboration. We often collaborate with the Digital team, which is great, but we work together as a mini-team on special projects as well.

I like to think of us as a crack commando unit that comes together to solve problems, a bit like the A-Team. Stretching this already-weak metaphor to breaking point, that definitely makes me Templeton ‘Faceman’ Peck.

Why we do it

Collaboration is important to ensure each Faculty has input into central projects. It lets us consider the problem from all angles, and develop solutions that hopefully work for all of us.

It also helps us maintain a consistent approach to how we each do things. This ultimately helps our users and reflects better on the University. The conversations we’ve had around how we should consistently refer to course titles would make your head spin.

We can share best practice too. When one of the other Faculties is doing something innovative or better than we are, I'll take note.

And of course, four heads are better than one. Proofing each other’s work, suggesting changes and writing together helps us all make better content.

Ways we collaborate

Although we work in different buildings, we’re in contact nearly all of the time. Like a lot of collaborators, we use Slack instant messaging to avoid clogging up our inboxes. This allows us to quickly:

  • canvass opinion
  • discuss approaches
  • ask questions
  • share interesting articles/tools we’ve found
  • (occasionally) vent spleen
  • share stupid GIFs

Being able to ask the other FWEs for advice, and get a near-instant response, is very handy. It’s a great comfort to know that when I’m not sure or confused about something (which happens more often than I’d care to admit), I’ve got three very supportive, capable people to fall back on.

But the magic really happens when we’re all together in person. It’s not uncommon to see us huddled around a table in Digital base camp. This tends to be when we’re working on sprints. These are week-long efforts to focus on one project, and how the Digital team organise their work.

Recently, we’ve worked together on:

  • modelling our course content, and pulling it together for digital and print use (although I can’t take nearly as much credit for this one as my colleagues)
  • an ongoing piece of work looking at the University's various research entities and how to present them in the Content Publisher
  • working to get content brushed up for the Faculty web sections launching on the new bath.ac.uk

By working away from our desks we get the chance to focus only on the task at hand. It also means we can directly harass the Digital team when we need their expertise or something fixing. Win-win.

Why we work well together

It helps that Matt, Becky and Saskia are very nice people and I’ve learned a lot from the sprints we’ve done. We share mutual respect, tolerance and openness to ideas. They’re also pretty cool about me making obscure references to 80s TV shows.

I think we have a shared interest in making the content we’re responsible for as useful for our users as we can. We’ve got a good mix of backgrounds and each brings different experiences and expertise to projects. And it helps that we all get on pretty well. When not working together, we have regular catch-ups and even manage the occasional post-work beer.

There’s a sense of camaraderie when we collaborate, and a willingness to help each other to achieve our goals. I'm looking forward to the next sprint already. Not least because I still need to decide which of the others is Howling Mad Murdock.

 

One Hour Upgrade - March 2017 edition

📥  One Hour Upgrade

This March we brought the sunshine with a productive One Hour Upgrade.

We had a record 19 stories submitted to the backlog, pruning those down to a manageable 8 with careful voting and some team discussion.

Participants opted to pair on 4 of the stories, with all the pairs comprising of team mates from the same discipline - content, development or design.

What we got done

  • Sean and Justin K got stuck on writing tests whilst trying to update our inventory parser to allow output ordering.
  • Rod attempted to tackle a tidy-up of our Google Drive account. He made some progress but had to admit defeat this time around. Due to Rod's competitive nature it's likely we'll see this story again next month.
  • Hanna and John mapped out an entirely new approach to our training processes and documented this on Trello.
  • In his first One Hour Upgrade, Rhodri reviewed the proposed audio for a project page screencast. He also discovered a new-found liking for his own voice.
  • Tegan and Dan investigated the accessibility of our main site navigation and came to the conclusion that nothing needed to change. They then updated various wiki pages documenting browser accessibility plugins.
  • The dynamic design duo also looked at creating a new Slack icon for the digital team. Ideas were sketched out and a few worked up in Sketch. Final designs will be put to the vote with the team later this week.
  • Tom looked at allowing content item editing via URL in the Content Publisher. The story's in review and will be finished off soon.
  • Iris remedied the weird title truncation in our filtered lists. It's in accept/reject and should ship soon, so no more chopped off titl…

What we learned

  • We should encourage more cross-discipline pairing on stories.
  • Directory tidy-ups seem like an easy win but rarely are. Because files come from across the team it's almost impossible for a single person to judge their relevance.
  • Before undertaking a One Hour Upgrade dev task consider tests that might need to be written first. Can both be the tests and the work be done in the hour?
  • Representing the digital team in a 128 x 128 icon is tricky.

 

Making our Slackbot open source

📥  Development

Back in November, I blogged about writing a Slackbot for our team to provide editorial guidance on request.

We recently decided to make the bot open source. You can now see all the code on Github.

A very brief introduction to open source

'Open source' basically means making your project's code public so people can read and reuse it. This means everyone can use your code themselves if they want, or adapt it to make something new. They might even make their own contributions to your project.

Our team and our users benefit a lot from open-source projects, so it's something we're always keen to do ourselves. One of our digital principles is 'Work in the open', and open-sourcing code is a great way to do that.

We've shared several of our projects on the uniofbathdmc Github.com account, so this was an obvious new home for the bot.

Moving to a public Github repository

Until now, the Slackbot lived in a private repository on the University's Github Enterprise environment. On Github.com, if you want to copy code from one repository to another, you can easily fork it. But moving from Github Enterprise to Github.com is a little more complicated.

Before making any of the code public, I did a little bit of housekeeping, including:

  • adding a LICENSE file with details about the Apache license 2.0
  • updating the README to make the set-up instructions clearer for potential new users
  • reviewing the code and commit history to make sure we wouldn't expose anything that was confidential or a security risk

Once everything was in order, I created a new empty repository for our team's Github.com account.

The next step was to change the remote for my local version of the repository. This meant that any changes I made would be sent to the new repository instead.

Once the remote was updated, a quick git push in the command line uploaded the bot to the new repository. Hey presto, open sourcery!

Rewriting history

I opened up Chrome to look at the new repo on Github.com. All my files, commits and history were there, but all those commits were from my private Github Enterprise account.

That account doesn't exist on Github.com, so it looked like all the code had been written by the mysterious if243, with no indication of who that was. I decided to tweak this so all the commits came from my own Github.com account.

The git-filter-branch command allows you to modify your commit history. I used this to change all the authors and committers from my private account to my public one. As usual, StackOverflow was a big help.

One git push --force later, all the commits had been updated and the project history was much clearer.

The bot's open-source future

The bot is now open source, but that doesn't mean it's finished. Any more changes we make to the bot will be in our public repository. And now that the code is open to all, there's a much bigger opportunity for other people to get involved too.

This also gives us the chance to experiment with some cool tools which are available for free to open-source projects, like CircleCI and Hound.

It's a small offering, but it still feels nice to contribute to the open-source community that's given us so much.

 

A day in the life of a developer

📥  Development, Team

This is the first in a 'Day in the Life' series for the different roles in the Digital team. If you've ever wondered what our team gets up to on an average day, or what it's like to work in a particular digital discipline, read on.

Here's a typical day as a developer, based on what I did on a recent Monday.

What I spend much of my day looking at

What I spend much of my day looking at

I get in around 9am and immediately make a coffee before cracking on with some work. Our team plans our work in two-week segments called 'sprints', and this is the last day of one. I start reviewing the code for some recently finished work so we can try to get everything ready to be signed off at the end of the day.

At 9.45, our daily standup happens. Everyone in the Digital team stands in a circle and says:

  • the most important thing they did yesterday
  • the most important thing they'll do today
  • any blockers that might prevent them from doing that work

Standup only lasts about 10 minutes, but it means that everyone in the team knows what they're meant to be doing and what everyone else is working on.

After standup, I finish looking at the reviews. Everything looks good, so the stories are now ready for the Development Manager to look at and accept (or reject – but let's hope not).

Next I get together with a few other team members and do our fortnightly infrastructure review. We set aside an hour to make sure our documentation is up to date and identify any potential problems or upgrade work we need to do.

After a break for lunch, my afternoon is nice and clear. I spend the afternoon working on a new feature for the Content Publisher. 'Unpublishing' allows our editors to temporarily remove a page from the live site without deleting it entirely, so they can continue to make changes and republish it later if required. Having hours at a time to really get my head into a problem is one of my favourite parts of this job, and working on something our users will find helpful is always satisfying.

The day finishes with a retrospective about the completed sprint. Everyone in the build team shares what they thought went well during the sprint, as well as any issues they encountered. I really like our fortnightly retrospectives – they're a good way to wrap up a sprint, celebrate our successes and discuss ideas for making the next one even better.

So, that's what it's like to be a developer in the Digital team.

 

From Awe to Roar – My first weeks in Digital

📥  Team

It has been just over two weeks since I joined the Digital team as a developer. Before, I had spent ten years working for a small business in a similar role, plus dabbling in accounting, data analysis, operations and database engineering. I decided I needed a new challenge and a change of environment and was lucky enough to be given this opportunity.

Big changes, big relief

After being in a slightly insulated environment for so long, I was worried I might be spending these initial weeks struggling to get to grips with a new way of working, a new team and new systems. Would my new colleagues be scary? Was my knowledge still relevant? Would I be able to remember where the office was?

It wasn’t as scary as I’d feared! There were definitely major differences to adapt to, but luckily I’ve found myself in the midst of a hugely talented and helpful group of people.

The team here were very welcoming and I instantly felt at home. In the stand-up meeting on my first day, everyone gave an introduction and described their tasks for the day. They ranged from being able to log in to their computer (me!) to lofty content and development tasks (everyone else!).

Newbie on Rails

My first tasks didn’t involve a huge amount of coding, but there was a wealth of knowledge to be gained from investigating the existing code and seeing how it all fits together. I had worked on large projects before, but I hadn’t encountered one of this size without having already been involved in its development. It was very interesting to see all the gears and pulleys behind the scenes and the differences in implementation from what I had dealt with before.

Although I don’t consider myself an expert in Ruby on Rails by any stretch of the imagination, I had worked almost exclusively with it for almost a year before coming here, so I was able to hit the ground running. I’m looking forward to being able to expand my knowledge of Rails further, as well as adding some other language strings to my programming bow further down the line.

I find it particularly rewarding to solve problems, so having the chance to help out fixing bugs and tracking down issues has been oddly enjoyable – earlier this week I dusted off my SQL skills and delved into a database to help determine why a particular piece of code wasn’t co-operating.

Dragon Day

At the end of my first two weeks, the tasks were completed and ready to go live. It was the day I had been waiting for ever since I was offered this position: Dragon Day! A little explanation for anyone currently looking confused: when an update goes live, whoever produced the update has the opportunity to press a button to make an impressively-sized dragon toy roar. The roar is followed by a round of applause from the rest of the team.

When it was my turn to push the button, I really got the feeling that this was the right place for me, that the team is a supportive and cohesive one, and that the work of each team member is valued.

I’m looking forward to plenty more roars in the future!