Digital Marketing & Communications

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

Topic: Development

A more accessible landing page for staff

📥  Design, Development

In a large organisation such as ours the range of input and navigation methods covers a wide spectrum ranging from mouse/pointer and touch screens to screen readers and voice recognition. We have a duty to ensure all users can access our information no matter how they navigate the site. Our delivery principles reinforce our commitment to put users needs first and foremost.

I've just completed a sprint to resolve a number of accessibility issues on our internal staff landing page - a high traffic page used by university staff on a daily basis. Some of our colleagues had raised issues regarding their ability to efficiently navigate the multi-tiered menu that provides access to key online tools and services for staff.

University of Bath staff page

Some visitors to the staff landing page had problems whilst accessing submenus

The issues

  • Accessing the Javascript-powered flyout submenus was at best erratic and at worst completely impossible using only keyboard input
  • Contextual feedback for assistive technologies was absent. Users unable to see the visual indicators were not aware the links had related submenus
  • 'Clickable' links were not explicitly declared as such
  • Some links were only used as 'hooks' for the Javascript functionality. These links were navigational dead ends for users unable to access the submenus

Our solutions

  • Increased the 'touchable' link area to encompass the image and the title. A small win for touchscreen device users 🙂
  • Added relevant ARIA roles via HTML and Javascript. These provide additional information to visitors using assistive technologies regarding the role and status of elements on the page
  • Rewrote the Javascript functionality to ensure the menu is fully navigable via keyboard

But does it work for everyone?

Not quite yet. But we are working on it…

Although these changes are a positive step towards unlocking our content for all our users the solutions implemented above only really deal with those who navigate via keyboard, mouse or touch.

We're now actively looking at ways to give our users with voice recognition software the best possible experience on the University of Bath website. Simplifying navigation options and avoiding jargon will go a long way to helping those using only their voice to get around.


A Week With The Digital Team

📥  Communication, Development


I'm Rob, an A-level work experience student who was fortunate enough to be given the opportunity to join the digital team last week.

The past week has been a great experience, after being introduced to the self proclaimed king of the nerds and the rest of the team it was straight to work with Tom on the development of a replacement application for the old go.bath URL shortening service which is the first Padrino application to be shipped by the team.

Ship It

It was a great week working with the team, and I am very grateful for the skills that they have helped me to develop; from working amongst them in the twice weekly coding-practice sessions, to the weekly show and tell presentations and also being a part of the agile development practices.

Thank you very much for having me!

Thank You


Concatenate, minify, embed, serve.

📥  Development, Tools

Building a modern website which also performs well is hard. The amount of JavaScript and CSS we add to our pages is going up, but we still need to keep them loading quickly.

Tools like Grunt and Gulp help us manage these expectations by automating some of the hard work, and so it was that the development team spent Thursday in Bath's co-working hub, The Guild, learning about how to make best use of these tools from University of Bath alumni Jack Franklin and Ollie Jennings.

In the past we've used a similar tool for automating some of the hard work of managing and deploying back-end applications, so we were really interested in getting an in-depth look at tools designed for doing the same thing for the front-end bits of our sites.

Grunt and Gulp are both JavaScript-based build tools. They do pretty much the same job as one another, but with a different approach to task processing (Grunt is a synchronous build tool, Gulp is asynchronous), and using a different syntax.

Using either of the two it is trivial to convert SASS to CSS, concatenate your JS and CSS, minify them and then automatically add all your JS and CSS to your HTML in specific locations.

The session learning about the two tools was excellent, with everyone in the team learning lots, and it's likely that we'll soon start working with Grunt on packaging up and delivering our front-end assets!


Farewell IE 8. It's been emotional.

📥  Development, Tools

Dodo by Ballista at the English language Wikipedia

Perhaps the wrong kinds of emotions...


Web folk of the world feel anguish in supporting out of date versions of Internet Explorer, particularly when trying to use current features. For one site with users on IE 7, they famously offered to buy people brand new computers as a more cost effective means. And even though Windows XP (and with it IE 8) will be officially unsupported by Microsoft in a few days time, there is still a campaign to get its global usage below 10%.

Our recent work to upgrade our Research website to Foundation 5 was the latest encounter with IE 8 problems. For one thing, Zurb (the creators of Foundation), do not support IE 8. Foundation 5 comes with jQuery 2.0 and that doesn't support IE 8. Up until working on the Research site we got away with it, but this site in particular made more use of JavaScript than our other sites built in Foundation - including this very blog that you are on, Dear Reader.

What do the stats say?

We did try to make our code work in IE 8, but we found that the core Foundation scripts were throwing errors which caused our other JavaScript to not execute. It looked like a huge amount of time and effort to solve, so we did the sensible thing and looked at our IE 8 usage stats. It was my task to get the figures.

I looked at the recent trends and found that in the first quarter of 2014 overall IE 8 usage of our total traffic from outside the university accounted for 4.13%. I also wanted to check the conventional wisdom that it's mainly China stuck on Windows XP that push those numbers up. The numbers for visits from China on IE 8 came in at a surprisingly low 0.41%.

IE 8 is going the way of the dodo

The trend is definitely downward as for the first week of Q1 the share was 5.07% down to 4.52% by last week of Q1 whilst the previous year's Q1 share was 7.73%.

With these figures we were able to take the executive decision to demote IE 8 to "degraded support" status. OK, so it's not really the end of IE 8 for us but it should mean we spend less time doing work that doesn't have much of a benefit.

And with that discovery, there was much hollering and high-five-ing in The Digital Cave.


Here are the stats in a friendlier table:

IE 8 browser share of all external traffic to

Period % of total visits
Q1 2013 7.73%
Q1 2014 4.13%
From China Q1 2014 0.41%
1st week Q1 2014 5.07%
Last week Q1 2014 4.52%


The hard work behind the code


📥  Development

The other day, Ross wrote about the Digital team's delivery principles. I have been working on modernising our development infrastructure for the last few weeks and our fortnightly open house Show & Tell meeting (part of #6 - "work in the open") gave a great opportunity to talk about why this work is really important.

Behold the presentation:

Prezi talk on continuous integration
Yes, I used Prezi - don't judge me.

Principle #5 is "do the hard work behind the code":

The success of a great digital product or service doesn't rest entirely on what appears on screen. To deliver accurate, pleasing and sustainable products and services means investing in simple instructions, efficient workflows, accurate monitoring and great support.

In the above presentation three of the steps deal with testing and deployment to servers. This can be cumbersome and time consuming and there isn't a visible benefit for our users. Reducing the processes to a series of clicks saves developers time and mental energy which allows them to focus on developing.

It has taken quite a bit of effort to get everything behaving as we wanted. Building Play applications, downloading dependencies through the corporate firewall, running the tests, error-free deployment to load balanced Tomcat servers - all of these simple tasks become much more difficult when asking a server to do them. Finally though, we have reached a position where Bamboo is doing all of this for us automatically (or on demand in the case of deployment) and so the focus of developing our applications is back on the product rather than the infrastructure supporting it.

Continuous integration and deployment tackled. Now to write some new applications!


Nice web type in Internet Explorer 7 and 8

  , ,

📥  Communication, Design, Development

Recently we revamped our myriad font stacks (pun intended) to a single one utilising a single web font. The font chosen (Raleway) was available in a number of different weights, affording us the flexibility of presentation that we had previously relied on several different typefaces to achieve. Unfortunately, we soon discovered a feature of older versions of Internet Explorer than meant - when presented with a number of different font weights - it arbitrarily assigned one to everything and ran with it. Stylesheet bedamned. Phil, our dev manager, couldn't let this stand and quickly identified and created a workaround to the problem. I'll let him explain:

In essence, to enable smoother (and correct) implementation of font weights in IE, you need to specify and load each weight individually, ideally in the document and before the stylesheet that applies them. Here's the code we used:

<!--[if lte IE 8]>
        <link href="//" rel="stylesheet" type="text/css">
        <link href="//" rel="stylesheet" type="text/css">
        <link href="//" rel="stylesheet" type="text/css">
        <link href="//" rel="stylesheet" type="text/css">
        <link href="//" rel="stylesheet" type="text/css">

The result is we can now deliver smoothly rendered and correctly weighted fonts for everyone using Internet Explorer (7 and upwards), and given that a significant section of our site visitors run Windows—and have a version of IE installed—this is a very good thing.


The User Experience of Social at WebDevConf 2013

📥  Communication, Development

Last Friday I attended WebDevConf 2013 in Bristol where web developers, designers and even those just interested in making the web better got together to meet up and listen to some really interesting and inspiring talks.

One talk that I thought was really relevant was the one given by Luke Murphy-Wearmouth about not keeping social media separate to your website but to integrate it in the right way and that your website should be social by design.

Luke started by mentioning that there were 3 main social interactions: share, subscribe and discuss and that we want social validation and reciprocity.

Use common sense when sharing pages. There are certain websites that go the ‘easy’ way and just put “Share this page” as part of the template so that it appears on every page. This is not always the most appropriate implementation. He took an example of a booking site where it got to the payment screen so you could enter your credit card details but at the top it said “Share this page”. Why on earth would a user want to share their payment details on their social networks? He also discussed positioning where a website puts a summary of an article at the top of a page with “Tweet this” underneath it before the actual article itself or even have the share or tweet this buttons before the article. Not only does this break the flow of the page but would users really want to tweet or share pages before they have even read the article?

Two good examples of integrating social media are:

  • On a retail site selling clothes asking you to “ask your Twitter followers or Facebook friends if this would suit you”
  • On an event booking site adding a social media API such as Doodle so that when you are looking to book a ticket you can you can use this to find out what date and time is better for your friends.

Talking about making purchases on the web, some sites have a “go back to the previous page” on the booking confirmation screen where the last page was the payment details screen. Think about why a user would need or even want to go back to this page.

Above all, use common sense and think about the integration of social media rather than treating them as 2 separate entities.

View the presentation slides from the talk


Moving stylesheets forward dynamically

  , ,

📥  Communication, Design, Development

When I started 5 years ago, the university had a myriad of small stylesheets governing how each section - sometimes down to a single page - looked, on average these were small files and shared a lot of rules, generally due to one being copied as the starting point of the next.

The team soon embarked on a huge project to create a standard, consistent visual identity and to ensure this was applied correctly and easy to maintain we created one "global" stylesheet to replace all the narrow-scoped ones.

This global stylesheet has been modified and added to over the last half-decade as more demands are made of it, until it now weighs in at over 1600 lines of rules. We've often discussed ways to make this file easier to work with and update, usually around breaking it up into smaller, more specific files that were then brought back together for publishing. There just wasn't an elegant way of doing this at the time. It was also apparent that several attributes (particularly colours and typography) were repeated throughout the document, and possibly overwritten further down as new rules were appended.

This really frustrated the team as we knew there should be a better way of doing this.

As part of relaunching our Research section we wanted to move from plain, hand-typed stylesheets to something more powerful, flexible and easy to maintain - which meant looking at either SASS or LESS as CSS preprocessors, which also meant we could address the issues of scalability and repetition that had started to bog down our global stylesheet.

We went with SASS as it was a better fit with our existing infrastructure, and I personally found it easier to pick and integrate into my workflow. Over the next few weeks I'll post about the lessons we've learnt from using SCSS in the wild, but first I thought it'd be good to share some of the key reasons for adopting this approach to creating CSS files.


A simple ruby file allows you to customise the configuration of your project, and gives your processor (we used compass locally, and scssphp remotely due to current lack of a ruby dev server). This meant we could define the folder structure and also the level of commenting and compression applied to the output scss files. It also meant we could have separate dev and production config files:

Our defined structure - we have a preference for a HTML-based naming convention to files, so out went "stylesheets" "images" and "javascript" in favour of "css", "img", and "js". We also added an underscore prefix to the default sass folder to ensure it always appeared at the top of any directory.


Define once, reference often. Prior to having custom defined variables we'd have to manually re-enter the same information over possibly dozens of rules, and then search and replace them whenever a change to the presentation was required. A great example of this would be defining font-stacks and global colour schemes:

$headings: 'Raleway', sans serif;
$copy: 'Lucida Sans', 'Lucida Grande', 'Lucida Sans Unicode', 'Bitstream Vera Sans', sans-serif;
$interaction: AlexandriaFLF, "Palatino Linotype", Palatino, Georgia, "Times New Roman", serif;

$linkcolour: #ee3388;
$bodycolour: #404040;

This could now be dropped into rules, safe in the knowledge that future iterations would only require one update in one place.


A simple but powerful benefit of using scss is that you can create partials - files of small specific rules that can be included into larger files at compilation. Our current list of partials gives an indication of the purpose of each - meaning simpler debugging, and also the ability for several people to work on areas of our site without having to constantly commit changes to the same main scss file and then compile remotely.

  • _normalize - a standard set of rules to remove differences between browser rendering. Based on the file that ships with sass builds of Foundation 4.
  • _baselayer - a set of rules to apply common presentation elements, all our basic visual styling is here.
  • _colour - predominantly the variables for our current global colour palette
  • _typography - again, mostly variables and functions

We still have a lot of work to do.

Okay, so that's a quick up to speed of why we made the switch, and where we're up to. As mentioned, I'll be writing posts whenever we have significant discoveries, decisions, and/or solutions to share - for instance the following are all currently up for debate:

  • Agreeing naming conventions
  • How best to break up our stylesheets using partials
  • Being able to compile remotely and locally in the same fashion
  • Optimising existing CSS into SCSS
  • Deciding what (if any) mixin libraries to @include - compass and particularly bourbon look interesting.


When there is just too much to do

  , , ,

📥  Development

As a department looking to assist all other groups in the University, there is always a huge demand on our time. We do our best to help everyone, but inevitably there are times when we need to do three things and only have time for two. To help (I believe the phrase is "temporarily increase capacity") we've been experimenting with outsourcing. In theory, it is the perfect solution - instead of spending time to get a product, we spend money and (wallet permitting) everyone is happy. Our experiences haven't been quite so straightforward.

Know what you want

When you're working in-house you can afford to change your mind as you go along with minimal disruption. When you're working with an agency that causes disruption, delays and eventually a noticeable degradation of results as your allotted time is exceeded.

Basically, working with an agency is a waterfall process. Can you work with an agency in a more agile way? I'd like to think so, but we've not managed it yet.

What this means is that you need to do your homework. The project specification needs to be significantly more detailed than you might be used to in house.

Know what you're getting in to

Think you're just buying extra capacity? No. What you're really doing is swapping operational burden for management burden. Someone needs to be available as a constant point of contact, someone will need to review the incoming product, someone will need to ensure the deployment infrastructure is in place, someone will need to put it live. All this means time - so the question becomes "how big does the project need to be, before it's worth someone else doing it?"

If you think you can skimp here, remember all those times when you've been making something and your client hasn't been available to make important decisions? Well, now you're the client. You need to be around.

Know what you're getting

We have had instances where we have asked for site redesigns and been shown some interesting effects - but when we've come to do the integration work we've found essential javascript functionality has been missing. Why? Could be a lot of reasons, but the key is to specify up front exactly what you expect as a deliverable. If it's not written down, don't expect it.

Know where it's going

You know what is being delivered and you're on top of the process for it getting to you. At some point it's going to need to run on your systems. Someone needs to stay ahead of development, ensuring that databases have been configured and the infrastructure exists. Sure, you can try putting the agency directly in touch with your sysadmins but solving infrastructure problems takes time and if you're paying consultancy rates it's going to get expensive - and if your sysadmins don't work for the same department their priorities are inevitably going to be different to yours.

Know what's going on

Unless you're paying someone to run a service for you, at some point there is going to be a handover. You need to know what has been going on and, likely, which decisions have been made along the way (and why). Once again, this is a time investment. Unlike before, you can skimp here - but if you do, you'd better be ready with some more money when something goes wrong in the future.

We've learned these lessons (and others) the hard way. Recently we have worked with Beef on the revamping of our new internal homepage (on-campus beta release last Thursday, full release next week - more to come!). Our previous experiences helped no end and we had one of our smoothest experiences to date. There are still lessons to be learned, but we're confident we're moving in the right direction.


Want to cycle bits of your page? We can help

  , , ,

📥  Development

Right in the middle of our homepage is an area of featured news which cycles on a timer. When we were originally implementing this feature back in 2011 we had a look for a library to drop in, but couldn't find one which met all our requirements:

Progressively enhanced
The page needed to present a working page to visitors without javascript - the most important feature needed to be loaded and we didn't want the left/right controls on-screen if they weren't going to do anything.
Cycling HTML blocks
Most gallery-type features will cycle an image, but we had an image in a div, usually with some text underneath. In practice, we really need to be able to cycle between arbirary blocks of HTML.
Low initial page load
The obvious way to solve this problem is to transfer all the data on initial page load and show / hide different elements as required. The problem with that solution is that it loads all the assets up front, and we were talking about a series of high quality images. To be kind to our visitors on low or limited bandwidth connections we wanted to only load elements when they were actually going to be seen.

We also had to consider the maintainability of the library and the content it displays - obviously the homepage changes frequently so it couldn't be a major job to do it!

We couldn't find anything which solved all these problems so we rolled up our sleeves and created our very own jquery plugin. It has proven useful to us - not only on the homepage, but also elsewhere on our site. Now, a few years on, we have released this code under the Apache license for the world the enjoy. You can find it on github under the "bathweb" organisation. Keep an eye on this - we aim to release other interesting and (hopefully) useful code in the future.

The repository contains a working example and all the docs you'll need to get it up and running. Why not check it out and have a go?