Digital Marketing & Communications

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

Are we there yet? 3 years in agile design

📥  Design

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

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

How good were The Good Old Days?

In ‘The Good Old Days’ done meant done.

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

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

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

The Minimum Viable Product

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

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

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

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

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

Just ship it…

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

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

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

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

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

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

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

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

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

The MVP of embracing agile…

… is an awkward hug with good intentions.

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

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

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

 

Digital team sprint notes 15-28 November

📥  Sprint notes

What we did

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

What we’re going to do

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

 

Development Plan Report Number 1

📥  Design, Show & Tell

Last month, I made a trip to the Library to delve into the archives of the University. Together with colleagues in Imaging, Design and Printing Services (IDPS), the plan was to get a crash course on brand design.

The head archivist, Lizzie, had sourced boxes full of printed materials for us, ranging from prospectuses to annual reports, promotional posters and pamphlets.

As designers we were first drawn towards the prospectuses. Published annually, it provides a fascinating insight into the prominent design trends in the year of publication. Our 90s 'rave' period is probably one to forget.

As is often the case, our most interesting discovery came from a rather unexpected source.

Development Plan Report Number 1

In 1965 an unassuming document outlining plans for the new University in Bath was published. With a brown and cream two-tone cover and type set entirely in Helvetica (known at this time as Neue Haas Grotesk) Development Plan Report Number 1 wears its 1960s origins proudly on its sleeve.

The report itself is a beautifully typeset outline of the plans for the proposed University of Bath. It’s stuffed full of abstract, organic diagrams and line drawings that are almost cellular in their approach. Throughout the report living, studying and social spaces are referred to as organic entities, flexing and changing to suit the needs of their occupants.

Origins of the logo

The first real surprise adorned the back cover - A large black and white photograph of the Sulis head found in the local Roman baths.

The Sulis head

Bas-relief from the pediment of the Temple of Sul Minerva in Bath

The creative decision to position this particular image here has had long-lasting ramifications for our design direction. The Sulis head has been inextricably linked with the University from its conception.

Which is why it was such a delight to discover a small hand-rendered version of the icon on the inside front leaf. This subtle design element cements the relationship between the nascent University and the Sulis head icon.

Sulis head icon on the inside cover

Sulis head icon on the inside cover

The first diagram of the university

Having discovered the impact the report had made on the University's brand identity we dug deeper, looking for yet more insight. In the first section - Aims and Principles - we found 'The first diagram of the university' (the actual title of the image).

university-diagram

The first diagram of the University

This incredible diagram illustrates a number key design tenets repeated throughout the report - namely a campus that grows outwards from a central hub (the spine/nucleus), close integration of residential, academic and social spaces and restrained (but not constrained) campus structure.

The beauty of this diagram is how well it effectively communicates relationships between traditionally disparate spaces. The campus is visually described in anatomical terms - It feels like a living entity, exactly as intended.

University patterns

Development Plan Report Number 1 eveals that the University of Bath was conceived from the very beginning as something new, something different, an institution to challenge.

The plan discusses possible residential and social patterns at length. Two of these patterns are based on the structure of existing academic insitutions  - A traditional 'Redbrick' college and the 'Oxbridge' model. A third proposed pattern is considered new and unique to Bath.

pattern-types

Three patterns for University structure

Redbrick

In the Redbrick pattern there is little relationship between the academic activities of the departments and the social activities of the students. These elements remain isolated from each other.

Oxbridge

With Oxbridge the pattern consists of a loose ‘community’ of independent colleges and scattered teaching departments. Colleges lose some of their academic significance to the departments and students live either within the college or in separate lodgings.

Bath

In the Bath pattern both study and socialising are closely linked in a concentrated urban setting. The university is conceived as a single varied community. There is no attempt made to separate or isolate the different facets of student life.

A parade of limited length

At the core of the proposed new campus is the parade. Designed to flex and grow as requirements change, the parade is never more than (about) 2000ft long - roughly 8 minutes walk from end-to-end at a leisurely pace.

Once again the thinking behind this concept it outlined in a series of beautiful abstracted images. Lacking in actual detail these illustrations still manage to convey a sense of movement and space between the edifices that make up the central area of the campus.

That the last illustration (the selected option) is still recognisable as the parade today is incredible.

parade-patterns

Flow patterns through the parade at the heart of the University

A view of the future

It was clear from just the short time we had to spend with the Design Plan Report Number 1 that things hadn’t changed as much as we might have originally thought. The founding principles of the University still hold true today including the Sulis head representing the University at a core level.

The beautifully executed line drawings summon up an image of a sophisticated, unified campus blending all aspects of student life into a seamless experience.

We came away inspired, motivated and with renewed optimism that the University brand was not far off alignment.

Making a Slackbot for editorial guidance

📥  Development

In the Digital build team, we have two hours every Wednesday to work on our own personal development. I recently spent a few of these sessions making my own Slackbot.

A slack-what?

Slack is a messaging application designed for work teams. We've used it for several years now and found it an extremely useful communication tool – it's a great way to keep everyone in the loop while keeping our email inboxes relatively clear.

A Slackbot is a program that interacts with users through Slack. It can react to user input (like a user saying a certain command) or external input (like a trigger from another website to post a message in Slack).

Slack comes with its own bot, @slackbot, which responds to several default commands and has some customisation options.

Using @slackbot's reminder functionality

Using @slackbot's reminder functionality

Unsurprisingly, lots of other digital services have built their own bots to integrate with Slack. We use these to get notifications in Slack when something important happens, for example, if a team member starts a new story in Pivotal Tracker or a new version of Ruby is released.

This bot notifies everyone in the #beta channel when something deploys

This bot notifies everyone in the #beta channel when the Content Publisher deploys

Building my own Slackbot

The content team has written a lot of guidance for our lead publishers, from editorial style to using specific content types in the Content Publisher. We use this guidance a lot ourselves. I decided to create a bot that could make it easier to retrieve this guidance from the comfort of the Slack window.

I built my bot using Ruby. The slack-ruby-bot gem makes it really easy to get a basic bot up and running. After registering the bot with Slack and setting up an API token, I added it to a channel.

The bot responds to anyone who greets it with a cheery "Hi @username!" out of the box, but then it was up to me to add my own functionality.

Setting up a very basic Slackbot command

Setting up a very basic Slackbot command

We've had a lot of raging debates about our editorial style for bulleted lists, so inevitably this was my Slackbot's first new feature:

Not this again...

Not this again...

Getting variables from the user

It's also possible to build more complex features. Slackbots can get variables from user input (regular expressions come in handy here), so I added a feature that lets users request a particular guide.

I created a hash with the names of guides and their URLs. When the bot receives the command, it identifies the term provided by the user and checks the hash to see if there is a corresponding guide. If there is, it posts the URL for the guide in the channel.

Requesting guidance on using images

Requesting guidance on using images using the command 'rtm' (or 'read the manual')

This might save some time for users, but they still need to leave Slack to read the information. What if we want the bot to provide guidance directly in Slack?

Retrieving information from the web

Our editorial style guide is the longest, most detailed guidance we have for creating content on bath.ac.uk. Sometimes it can take a while to find what we're looking for. What if the bot could do it for us?

We could follow the same format as the guide search feature and just store all the information in the code. But our editorial style guide is constantly evolving, so this could quickly become out of date. And it'd be absolutely massive. It's better to have the bot to search the guide itself directly.

Nokogiri is a Ruby library for parsing HTML and XML documents. It's an incredibly useful tool for searching or processing the content of a webpage. I decided to use Nokogiri to search for and retrieve content in the editorial style guide.

Here's how the feature works:

  1. A Slack user requests content from the editorial style guide using the command "style guide for [search term]".
  2. The bot recognises the request and gets the search term.
  3. The bot uses Nokogiri to get the content of the editorial style guide from the website.
  4. The bot checks each heading to see if it matches the search term.
  5. Once a heading matches, the bot collects the content of each subsequent paragraph, heading or list until it reaches a heading that's the same level or higher.
  6. The bot processes the collected information to format lists and headings.
  7. Finally, the bot posts the results in the original Slack channel.

If the bot can't find anything, it'll notify the user so they don't have to wait for an answer that isn't coming.

How should we refer to the Chancellor? The bot has the answers

How should we refer to the Chancellor? The bot has the answers

If we're discussing a style question in Slack, the bot can provide the answer to everyone in the channel – hopefully making it easier to settle some debates.

Downsides of Slackbots

The bot should be useful when you want it, but stay out of the way when you don't. Nobody wants a bot which spams the chat with unnecessary messages or notifications.

It's also important to be aware of potential security risks. When you give a Slackbot access to a channel, you're allowing it to potentially access a lot of sensitive information – what everyone is saying, when users are online, or even when they are typing.

I created an entirely separate team just to test my bot in, so it hasn't made it to our actual chat yet. If we do unleash it upon our actual Slack team, we'll definitely need to do some more research into the security aspects first.

Go forth and build bots

While my Slackbot hasn't made it into production use yet, I'm still glad I built it. It was an interesting and fun little project which I hope has the potential to become really useful for our team.

If you use Slack, I'd recommend having a go at making your own bot. There are some powerful tools for building your own bots in your choice of languages – Node.js is especially popular.

If you've built a Slackbot, or have a favourite one that makes your working life much easier, let me know in the comments. I'm looking forward to seeing what everyone's come up with.

 

Digital team sprint notes 1 - 14 November

📥  Sprint notes

What we did

  • Added subtypes to Team Profiles
  • Enabled drag-and-drop sorting for members of a Team Profile
  • Changed the ordering of the 'Enquiries' and 'Address' fields on Department pages to make their location more predictable
  • Allowed publishers to preview a content item without sending it to the Review state first
  • Increased the amount of spacing under embedded media content
  • Improved layout consistency between different screen sizes
  • Published new content about the University's research integrity and ethics
  • Changed our own process for writing content from scratch
  • We handled 27 items of content support. These included:
  • Resolved 154 requests for support

And last but far from least, we welcomed Tom Dennis to the team as a new Content Producer!

What we're going to do

  • Update the links in the footer of the new pages to point directly to the correct locations
  • Improve our testing by automating data transfer between our staging and production systems
  • Reduce the size of headings in the sidebar of filtered lists
  • Improve the consistency of lists on Person Profiles
  • Make sure that the subtype of a content item is consistently displayed across Collections, Landing Pages and the content item itself
  • Allow lists of Team Profiles to be filtered by subtype
  • Improve the layout of Team Profiles on small screens
  • Add new subtypes to the Publication content type

 

Hello world: my first two months in Digital

📥  Communication

It's a little bit strange to be writing a post like this after saying goodbye to three of our team. Liam, Kelv and Tom were (... but they're not dead, so are?) amazing people to work with for the last two and a bit months, and while I haven't known them as long as the rest of the team here, I miss them.

There's something in that sentiment that speaks volumes about my first two months here: everyone has done so much to help me get up to speed and feel welcome that it already feels like I've been here for an age (though not aeons like Tom Natt).

Where I come from

Before the University, I worked for Apple just down the hill as part of their business to business team. I can't say anything bad about Apple--it's a great place to work, and I wouldn't be here now without my experiences there. But as great as it was, I was always searching for something more to push me, something that would open up more creative possibilities.

My education isn't in the STEM world, or services--I'm trained as an actor. I have left this behind for the most part, but the root drive to be creative has never left.

Joining Digital

Over the last couple of years I've been inching my way towards software development. At first it seemed too good to be true--work that was challenging, equal parts logic and creativity, embraced learning constantly, and lead to financial solvency (!). I was worried that I'd find I hated it, that the combination of logic and creativity was a myth, that learning would cease after a while.

The more I exposed myself to it, the more convinced I became that it was the *right move* for me. A way to feel excited about even the small things I do day to day.

I'm not a developer--I'm not there yet. But Digital is an opportunity for me to learn alongside developers while supporting them and the Product Owner with what I'm already great at: service management. As the Digital Supporter most of my time is spent on the latter, but more and more I'm handling technical tickets and requests myself.

Being part of Digital

Right now I'm working on building an app that will pull together our service management statistics for us from the last month. Right now it's a mostly manual process.

Our service ticket tool has an API that exposes all the data we need though, so the idea is to use that to request all of our data there, compile it into a human friendly spreadsheet, create some handy charts, and have it emailed directly to our stakeholders automatically every month.

It's not much yet, but I have a pretty good idea of how all the different pieces work together, which is a huge victory in and of itself.

I still can't quite believe how lucky I am to work somewhere that encourages this kind of learning and development into what is technically a different job role, and to have colleagues both still present and departed, who are willing to help me as I teach myself.

It has been a great first two months. I look forward to each and every month to come.

 


My first two months in numbers

  • 1 Show and Tell
  • 1 accepted pull request for our blog styling
  • 1 deleted blog (not related to the PR...)
  • 1 restored blog (directly related to the deleted blog...)
  • 2 apple pies baked (even though I'm a heathen American and don't watch Bake Off, I was in the Bake Off pool)
  • 10 board games played
  • 960 support tickets resolved
  • 14 new friends made (d'aww)

Goodbye titles are hard

📥  Communication, Team

This is my last week as an employee of the University of Bath. I have been coming up The Hill daily for roughly the last fifteen years - first as a student, then as staff - so it's an emotional time.

The University has changed significantly in that time, and yet there is a strong sense of the familiar everywhere I look. The library is a great example - all new equipment and an improved layout but I still see the corners I used to haunt as a mathematics undergraduate more than a decade ago. The places my group used to sit and puzzle through the latest problem sheet and the floor where we definitely didn't create a small camp during an all-night coursework session.

Similarly, the Web Team / Web Application Team / Web Services / Digital has changed people, moved department, moved offices three to five times (depending how you count it) and yet the belief in the web and the desire to build the best and most interesting things we can remains the same.

I've been in this team a long time and learned a huge amount. I started as a junior developer (not that we had that title at the time) and learned about Java and PHP web development as well as the various bits of infrastructure underpinning all this. I wrote Personfinder, which eight years on is still a favourite application amongst our users and I found some notes the other day where one of the sysadmins in BUCS (as it was then) took me through restoring servers from tape backup. Fortunately I have never had to use that information!

After several years of application development we moved our focus to OpenCMS and thus began the first great CMS transition where we moved a load of Dreamweaver sites into the new system. Through this time we were still developing applications and looking at new ways to be productive. It was around then we first dabbled in Scrum and Agile with positive, if mixed results.

Many years of CMS work later, we saw changes in government and their approach to digital and this heralded the rise of GDS, the coming of Ross and the second great CMS transition. We retooled to use Ruby on Rails, growing in confidence as a software house and built our own content management system. The last few years have seen concentrated development resulting in a system we are all proud of and which is making genuinely positive changes in content publishing around the University.

I've learned so much in my time here, and I am incredibly grateful for the opportunities. One of the great things about the Digital team here is the openness to change and the chance to develop beyond the traditional bounds of the job description. I am moving on to become a Lead Developer at GDS and I can honestly say that wouldn't be happening if not for my experiences here.

So, after 53 Show & Tell presentations, thousands of lines of code, hundreds of retrospectives, loads of accepted features (and more than a few rejected...), dozens of slightly terrifying server repairs, a couple of conference talks and one instance of the bringing down the entire University website it is time to move on.

I will look back on my time here with fondness and I'm going to miss everyone here a great deal. So long and thanks for all the commits.

So long, and thanks for all the gifs.

📥  Team

On Friday 11 November, myself, Tom and Liam will be saying goodbye to the University of Bath.

I will have served for 14 years, 3 months and 13 days. Well, longer than that actually as that's when I started in a permanent position. Initially, I was working at the School of Management on a temp contract.

Tom Natt will have worked here for 12 years 2 months 17 days. His stint at the University is also longer than that figure. He joined as an undergraduate student back in 2001.

Liam McMurray will have done 8 years and 29 days. No gotcha there. That's how long he's been here.

Tom and I are founding members of the team. In the initial incarnation, we worked to an almost agency-like model. We took on projects for clients around the University and received funding for that work. This was because we needed some way of procuring funds for a team that was so new and not yet well established.

Liam joined as the team began to move away from this model. We started to focus attention on the critical parts of our website. Our homepage and our sections on studying saw multiple improvements from this concentration of effort.

Shortly after that, the team adopted Agile working practices based on Scrum. This helped us tremendously in our work. We continually prioritise and organise our work in order to deliver based on our users' needs.

Relatively recently we've embarked on an ambitious programme of transformation of our website. This involves putting our content through an evaluation against user needs. This a crucial basis for how we are transitioning content to our Content Publisher, and away from our legacy CMS.

It is fair to say that since the team's formation we have seen huge changes and improvements. After a very long journey, it feels the right time for the three of us to say goodbye. It is of course with much sadness. There is also a little bit of jealousy as we know that the team will keep improving. It's hard not be a part of it anymore.

The great thing about the Digital team is that, as someone once said, they keep being ambitious.

Digital team sprint notes 18 - 31 October

📥  Sprint notes

What we shipped

  • The first Faculty to transition into the Content Publisher is now live. You can browse the new Faculty of Engineering & Design section here.
  • Improved layout consistency by updating the vertical rhythm and typographic scale
  • Improved the legibility of long pages by updating the sizing for all our headings
  • Content that appears in the sidebar on large screens no longer butts up against the edge of the sreen on small screens
  • When a publisher updates a content item which doesn't belong to their organisation it no longer changes which organisation owns it
  • Publishers can now choose the ordering of people listed in Team Profiles
  • Changed our titling of "Team members" on Team Profile pages to be more generic
  • Provided a sitemap.xml file to make sure that all our pages published by Content Publisher are indexed by Google and on-site search
  • We handled 15 items of content support including:
    • updates to visa pages to point to new Tier 4 booking system
    • updates UG funding pages to reflect funding on offer for 2017 entry
    • updates to UG tuition fees pages
    • found alternatives to Vimeo for video content aimed at audiences in China
  • resolved 143 incoming requests for support

What we're going to ship

  • Improve layout consistency between different screen sizes
  • Increase the amount of spacing underneath embedded media content
  • Allow publishers to re-order members of a Team Profile by drag-and-drop
  • Add new subtypes to Team Profiles
  • Change the ordering of the 'Enquiries' and 'Address' fields on Department pages to make their location more predictable
  • Improve our testing by automating data transfer between our staging and production systems
  • The first part of allowing publishers to put a content item into preview without requiring it to enter the Review state

 

Work hard, bake hard

📥  Team

The Great British Bake Off is popular in our team, probably because our team is composed of humans. So, of course, we have enforced fun to go with it.

We call it the 'sweepbake' or 'sweepsbake' (opinions are divided on the extra s).

The rules are simple:

  • everyone in the office randomly draws a Bake Off contestant
  • when your contestant is eliminated, you must bring in baked goods, ideally homemade

The result is an onslaught of delicious carbohydrates that lasts for about three months.

Here are some of the treats we enjoyed this year:

Rhian's cheese straws

Rhian's cheese straws

Phil's cupcakes

Phil's cupcakes

Miao's cookies

Miao's cookies

Sean's apple pies

Sean's apple pies

Iris's lemon snickerdoodles

My lemon snickerdoodles

Fortunately, the campus has excellent gym facilities and some lovely running trails to balance all this out.