Digital Marketing & Communications

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

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!

 

Me first big ship

📥  Beta, Design, Team

Ahoy there! Me name is Tegan and I be Digital’s fresh meat. I joined on the first o' December last year. I’m not long graduated from university, with twenty months in industry, tamin’ the wild seas of the web.
I’m a design buccaneer, a user experience swashbuckler. I conduct hearty user research, rescuin’ marooned users from the shores of confusion, and I make user interfaces delightfully easy to use. I also have a fair working knowledge of code which helps me parlay with devs.

Batten down the hatches an’ I’ll tell ye a little tale ‘bout me first big ship.

</pirate>

Sail, ho! There be a ship!

When we release a new feature or change, we call it ‘shipping’.

This ship had a mission: to grab your attention, inspire you to keep reading and build upon the University of Bath’s visual language with a new visual cue.

This element will be used by Collections, thematic pages with handpicked articles. But it may expand to other aggregate content types, like departmental landing pages.

We’ve called this new element a Hero – it’s well-built and displays outstanding achievements and noble qualities! I kid, it’s actually a technical term for a prominent banner on a page.

Hero image is a term used in web design for a specific type of web banner, prominently placed on a web page, generally in the front and centre.

 

The blueprints

Pile of paper with wireframes of the new Collection hero

To start off the design process, we collected data from current users to see what their behaviour is currently.
Using the scroll heatmap, we could see where people linger on the page.

Scroll heat map snapshot

This heat distribution demonstrates that people don’t spend much time above the fold (the top bit of the webpage that is visible without scrolling down). Users quickly scroll below the fold to read the actual content. This is the hottest spot on the entire page.

Next, we checked out how other people do it. What are the current standards, what does and doesn’t work? This process is called peer review and it is a great opportunity to draw inspiration from what other people have done.

Stop. Sharpie time!

I squirrelled away in a meeting room with the collection of Sharpies and A3 paper to punch out weird and wonderful ideas and directions.
I developed a handful of these ideas further, then mocked them up as high fidelity prototypes and presented them to the product owner for feedback.

Armed with feedback, I iterated on my designs with more sketching and more mock-ups to bring back some new and improved ideas to the table.

I collaborated with Sharpie champion and user experience privateer, Dan, to create a new piece of visual language for featured images. This hinted at the existing call-to-action arrow shape with a bit more visual embellishment.

The prototype on artboards in Sketch app

14 artboards later, we were ready to demonstrate the design on a multitude of device sizes and its limitations. These were shown to the Director of Marketing & Communications for final approval.

Sail ho! The design was approved!

All hands on deck!

To breathe life into this new element, we needed to wire it up to the Content Publisher. This required input from multiple disciplines: designers, developers and content producers.

My role was to create the front-end by gluing HTML and Sass together, while Iris developed the working bits to add a new hero section in the editor, and content seadogs composed some explanatory microcopy.

Collaboratively working with Iris was a breeze, and each piece of work slotted together like a jigsaw puzzle. The build took 2 days, with a further day of squashing bugs and browser compatibility testing. 36 git commits later, we were ready for review.

As this was my first time working with both the Foundation framework and the university's visual language, Origins, I think I did good! Some code structure optimisation and minor (but significant) design changes came to light in review, but all the required amendments were quick and soon got the green light.

Pull requests to production put the build into motion. It was time to weigh anchor and set sail!

Fire in the hole!

The deployment dragon roared out across the sea (department) as the ship... shipped.

Peter Pan ship flying into the distance

This feature was a huge blocker for launching the Research collection, so having it ship was an achievement for the whole crew. You can now see the Research Collection live, or read Hanna's post about it from a content perspective.

This is, admittedly, not my first ever ship here at Digital. So far I have set sail to several little ships, or... dinghies, but this feature was my first big one. Drawing upon my own skills and those of the people around me, we have created a cool new element to drive forward a new chapter in the University of Bath’s visual language development.

I raise me grog to the crew and all future ships!
Yo ho, yo ho, a pirate’s life fer me...

 

Early review of research ethics content performance

  , ,

📥  Beta

In October, I worked on improving the information we provide about research integrity and ethics. To deliver the new section, I worked with subject matter experts in the Vice-Chancellor's Office and the Office of the University Secretary.

When we started, the content was basically a single page with multiple tabs, many many links and subheadings which were generic or duplicated. Together, we set out on a quest to make the process simpler and important tasks easier to spot and complete.

We shipped the new content in mid-November, so it's still early days. But we can already see from the analytics that we've made a huge improvement.

Making things simpler

Our biggest aim was to make it easier for users to understand what they need to do to conduct ethically responsible research. For this, we reworked parts of the original content into a plain English guide.

Plain English is about writing in a straightforward manner so that the content can be more easily understood by a wider audience.

Looking at the analytics, this guide is by far the most visited individual content item, with 517 pageviews compared to the next item with 344. It has an average time on page of 2:29. These stats suggest that it's being both found and read.

On that note, the fact that we can even start to draw comparisons between individual items of content is a huge improvement in itself. With the old page, all we had was basically an overall number of visitors to the whole page and our best guess.

Coherent user journey

One of the biggest changes is that the new Collection is making it easier for people to move on to the next step in completing their task. The bounce rate has gone down from 64% to 30%, which suggests that people are finding the content relevant.

The main purpose of both the old page and the new Collection is to point users to the relevant information. The change in the average time on page (old 4:32, new 1:15) suggests that it's a lot easier for people to find what they're looking for. This is supported by the fact that 80% of the people are moving onto another item of content compared to 63% on the old page.

There is also a big difference in what content they're moving onto to. From the new Collection, users go to the main items of content in the section - the top three items are two guides and our statement on ethics and integrity. From the old page, users were moving onto a more random set of content scattered across the website with no clear indication of any shared top tasks.

Celebrating success

So yes, it's still very early days. But after nearly three months since going live, the analytics would seem to suggest that users are finding it easier to navigate and read the content we’ve created.

In a transition project of this size, these little successes are worth noticing and shouting about. By sharing them, we are able to not only keep our stakeholders informed but provide a useful example for colleagues in the wider Higher Education community.

I compared data on the new content from the launch date to present to data on the old content from the same timespan one year earlier.

 

Adding a state machine to a Rails application

📥  Development

We recently implemented a state machine in the Content Publisher. While this isn't a change many people will notice, it does lay the foundation for further improvements which we hope will benefit our users.

This work also contributed to my ongoing education in computer science concepts and design patterns. Hopefully this post will share some of what I've learned.

Introduction to state machines

A state machine, or finite-state machine, is a computational model. It's designed to manage things which can be in one of several pre-defined states. Items can transition between states, but can only be in one state at a time.

A properly-implemented state machine can define:

  • what your states are
  • what things can do while they're in a certain state
  • when something is allowed to transition from one state to another
  • what happens when something transitions between states

A good example of what I mean by 'states' is what happens when you order a product online. Your order goes through several states: 'received', 'processing payment', 'packing', 'out for delivery', 'delivered', possibly even 'returned'.

While the state the order is in changes during the process, it will only ever be in one state at a time. The order can be in a 'packing' state or a 'delivered' state, but never both at the same time.

There are also rules about how the order moves between states – for example, your order won't move from 'delivered' back to 'packing'.

And different things can happen during the states. Maybe you can cancel your order when it's still in 'received' or 'processing payment', but not once it's in 'out for delivery'.

All these rules and processes are set through the state machine.

The state of states in the Content Publisher

States are a key part of the workflow in the Content Publisher. Content items can be in 3 states: 'draft', 'in review' and 'published'. All items start out in 'draft', but as our users work on them they progress on to

But we might want to add more in the future, like 'scheduled for publication' or 'archived'.

While the Content Publisher has states, and items can move between states, we don't manage these in the clearest way. The logic which controls which states items can be in is spread across the codebase, which makes it difficult to read or to modify.

We decided it was time to implement our own state machine.

State machines and Ruby

We could build a state machine ourselves, but there are so many popular state machine gems out there that we wanted to look at those first.

I started by checking Ruby Toolbox to see what the most popular state machine gems are. The top one is state_machine, but this is no longer maintained, making it a risky proposition.

The next most popular gem is AASM, short for 'acts as state machine'. AASM is well-maintained, with an active community and pretty good documentation – all important if we want to welcome it into our codebase.

I also looked into several other gems, including workflow and transitions. But AASM seemed the most promising, so I tested it out by building a prototype in a fresh Rails app.

AASM in action in our discovery prototype

AASM in action in our discovery prototype

The prototype confirmed that AASM ticked all our boxes. It was time to implement it properly.

Adding a state machine to the Content Publisher

The next step was to get AASM up and running in the Content Publisher to replace our existing functionality.

Implementing AASM was more complex here than in the prototype. This was mostly because we've been working on the Content Publisher for nearly two years and so had a lot of code to change.

This gave me a good opportunity to get more familiar with a broad range of our code – everything from role-based permissions to version control.

If you're thinking of using a state machine in a Rails application, I'd definitely recommend trying to put it in place as early as possible to minimise the amount of refactoring.

After many commits and an extensive review, we finally shipped to production on 16 January.

What comes next?

While our switch to AASM made no immediate difference to our end users, it does make our code better and more extensible.

We've now laid the foundation for adding new states or transitions, which could enable new features – like scheduling an item to publish later, or unpublishing a live item.

We'll be doing some more research into how we can improve our workflow, so keep an eye out for more changes in the coming months.

Shiny new Research

  , ,

📥  Beta

This week, we went live with the new Research Collection. It’s not an insignificant milestone - it’s the first top level section we’ve launched in our content transition project.

new-research-collection

The Research Collection is the first Collection to feature the new hero item.

The new Collection introduces many improvements.

Showcasing a wider range of content

In the new Collection, we’ve introduced different strata for different types of content. This makes it possible to feature, in a consistent way, different items like videos, podcasts or articles from our researchers outside bath.ac.uk platforms. We can now add range and depth to our research content which previously relied heavily on news items and case studies.

Better workflow

As an Editor, I’m slightly in love with our Content Publisher. Creating and featuring content is so much easier than it was in our old system. There are still a couple of things we need to sort out with the workflow before the process is uber smooth, but the editing experience is already hugely improved.

Simpler tasks

In our research section, we publish both editorial (feature articles and news items) and transactional (downloading documents and information) content. As part of the transition, we spent a lot of time making the transactional content simpler and clearer.

In the new system, the content benefits from better labeling under specific content types, plain English and simpler language in general. A good example of a batch of content we were able to improve like this is the research integrity and ethics content.

Next steps

So that’s all live now and I’m looking forward to getting some user data to find out how the new section is performing. But before that, I’m going to have a big, well-deserved, glass of wine with colleagues tonight to celebrate.

One Hour Upgrade - January 2017 edition

📥  One Hour Upgrade

The first One Hour Upgrade of 2017 was a compact but busy event with a number of interesting proposals put forward for consideration.

In total, there were 16 new stories added to the backlog by 7 participants. Of those, 8 stories proved particularly popular, receiving at least two votes. Given the small team on this One Hour Upgrade we experimented with each participant having fewer votes than usual.

5 stories eventually made their way on to the ‘To do’ board ready to be tackled on the Friday.

What we got done

  • Dan tidied up the User Research section of the wiki, pruning out old, redundant info and creating a centralised location for our User Research efforts.
  • Tegan fixed an accessibility issue with links in our calls-to-action. Apparently a combination of bright pink and yellow is not exactly AA compliant.
  • Iris and Sean updated the Content Publisher header with an updated product name. Tom T provided a code review within the hour.
  • Justin O and Tom D made further updates to our travel advice pages, working on a collection to bring all of the information together in a single place.
  • John worked through a number of outstanding blog posts, ensuring our blogging editorial calendar stays on track.

What we learned

  • Having fewer votes available meant participants focused on voting for stories they'd actually like to work on during the upgrade hour.
  • One Hour Upgrades should be scheduled so that they don’t fall on a Show and Tell Friday. Otherwise our available working hours on that Friday are significantly reduced.
  • If a technical or design story is in review at the end of 60 minutes, it will be considered ‘done’ and moved to the relevant board.
  • Stories that could involve soldering are not good candidates for One Hour Upgrade. However, everyone is keen to upgrade the Dragon of Deployment.

What’s next?

Our next One Hour Upgrade is scheduled for 17 February 2017.