Digital Marketing & Communications

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

Topic: Development

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?


Is IE6 really used in China?

  , , , ,

📥  Development

According to Microsoft's own stats, Internet Explorer 6 still accounts for more than 20% of web browser usage within China.

Around a quarter of our 4,500 international students are Chinese (source PDF) and so we've always been really hesistant about switching off support which would affect a demographic which accounts for over 200 people.

But is this concern well-grounded? For several years we've listed IE6 as a browser with 'degraded support', but it's now been more than ten years since it came out - does the usage really justify still accounting for a browser which had existed for 6 years by the time the iPhone was released?

Chinese visits by browser

Chinese visits by browser, August 2012 - November 2012

Google Analytics tells us that over the last three months, IE 6  was used for more than 15% of visits from China - this is 5 percentage points more popular than the highest ranked version of Google Chrome, which sits at just below 10%. The only mobile browser to appear in the top 10 is the iPhone 5's browser, but even this sits at just 5.5%.

As a whole, IE is utterly dominant, and Firefox doesn't appear at all - a very different picture to the one we drew a few months ago when looking at our overall traffic which concluded that IE, Firefox, Chrome and Safari take approximately a quarter of the market each.

To answer whether we still need to support IE6 we really need to look at which areas of the site those IE6 users are accessing, but in the meantime this is some interesting food for thought.


Doing things better: relaunching our online Undergraduate Prospectus

  , , , , ,

📥  Communication, Design, Development, Team, Tools

Our current online Undergraduate Prospectus launched back in February, after a year's worth of hard and rewarding work. From that time there were two key aspects of the project that gained us huge successes, which I will be outlining in this post.

Focus Group sessions

Something that we'd started with the redesign of our homepage, we continued and enhanced with the revamp of the prospectus. I cannot understate the value in carrying out this activity. Suspend your cynicism that this is a vapid, marketing focused (well, it is but actually it's more consumer focused) assumption affirming, lip service to finding out your user's needs. This is the only time you gather qualitative data from your target group. Otherwise you're mostly guessing.

I mentioned affirming assumptions. That's actually a good thing. Our Esteemed Designer wasn't sure about the pink highlighter circling around the Apply button, but when we took it to our first focus group at a nearby school we were pleasantly surprised by the enthusiasm and positive reception. This was a group of Gifted and Talented young people in year 12, very much amongst our target demographic. They felt that our colourful design was right for 16-17 year olds and not "dull like other universities, who treat us like we're 30".

The colourful design is right for us as 16-17 year olds and not dull like others, who treat us like we're in our 30s

Another session a few weeks later (this time with around 60 students - a logistical triumph!) repeated this sentiment: that the colours and the pink highlighter on Apply resonated with them.

What's interesting is that we could easily have ditched that design element. Because we didn't feel sure, or our stakeholders in their 40-50s might have objected. The feedback from the focus groups gave us the confidence, and the evidence, that it was The Right Thing To Do.

This was the first time I'd personally been involved in running a focus group and interacted directly with our "clients". Having feedback that what you're doing is good, is deeply rewarding. Since then I've also been involved in running focus group sessions for the School of Management website. I hope to be involved in more of these.

The Play Framework

This point is on the technical implementation of the prospectus, but one worth stating. Up until now we would be using some heavyweight, enterprise level software frameworks to build our systems with: Struts 2, Spring and Hibernate. The very same toolset that blue-chip companies will use. But in being so heavyweight for a small team of developers it means, excuse the pun, a lot of weightlifting to get small things done. For example we would have to do a lot of work on configuration and setup to support the features we want to build. This was a burden that got in the way of achieving the goal of building the actual feature. And would also be hard to maintain.

We had plenty of experience to go by that lead us to this conclusion, like building the previous prospectus with this toolset.

Before starting this project last year we were assessing a new Java web-app development framework called Play. Our first reaction was that it felt a lot like Ruby on Rails, but this is no surprise as Rails espouses "convention over configuration" and Play is simply following good conventions.

The main things we love about Play are:

    The focus we can place on building features compared to our previous working practises
    The plugin system where commonly required features are already implemented which you can (ahem!) plug in.
    But mostly it's the rapid deployment during development.

The traditional workflow for Java requires an intermediary compilation step and you have to sit there while you wait for it to finish. With Play you simply refresh your browser as soon as you've saved your file.

These two aspects of the the online Undergraduate Prospectus project have helped to make it the success it is now. Play made getting something up and running quicker than we have in the past - by allowing us to not burn time on startup costs. Running the focus groups has ensured that we are delivering to our prospective students what they desire and require. Two ingredients we'll be using again in future projects.


Review of browser usage stats

  , , , ,

📥  Development, Tools

I recently thought it would be worth looking at our browser stats to see which browsers people are actually using when they visit our site. When I saw the recent numbers I was a bit surprised and thought it would be worth reviewing the changes over the past few years to find out:

  • Where have we come from?
  • What has changed in the past 3 years?
  • Where are we now?

I also wanted to produce some graphs to display the information visually rather than having lists of numbers in tables.

Show me the graphs

I'm going to jump straight in to the results now, but the details of where the data came from and how I produced these charts is covered later for those who are interested.

What our users were using in July 2008:

Browser Share / % Visits - July 2008

What our users now use (March 2012):

Browser Share / % Visits - March 2012

These 2 charts are massively different! They show how much has changed in the browser market, and consequently in web development, in less than 4 years.

No Chrome, no Opera, no Android to speak of in July 2008 (see disclaimer at the bottom) and Internet Explorer's share has more than halved.

How did we get here?

The change over time from July 2008 to March 2012:

Browser Share / % Visits per month

The same data as above, in a line chart:

Browser Share / % Visits per Month

So we see the steady decline of IE, the rapid growth of Chrome and (to a lesser extent) Safari and the squeeze of Firefox. Opera is the constant tiny fraction and in recent months we see the Android browser appear in the stats.

So what?

I believe it's important to have an understanding of the browsers that people visiting our site are actually using. We can then develop the site to work best for them. That may mean ensuring pages render well in older browsers or being able to use some new technology because our users' browsers support them - either way we can make things better for people visiting the site.

What about IE?

There is one last graph which I find interesting and should help to answer the recurrent question "Which versions of IE should we support?":

Internet Explorer Version Share / % Visits per Month

There appears to be a strong argument to ignore IE6 (finally!) and focus more on IE8 and 9. Unfortunately IE7 doesn't look like it's going away any time soon.

What's next?

There is of course a lot that we can do with the Google Analytics data. I'd like to look at the different versions of all the browsers, filter by country/language/OS and also compare our stats with other websites.

If you have any interesting browser stats for comparison, let me know in the comments.

Getting the data

I wanted browser stats for the last few years so I went straight to Google Analytics (GA), found our profile for external traffic and delved into the numbers.  However, it soon became clear that gathering data for the past few years from the web site would take ages (as I'd need to export data for 45 months individually).

So, I decided to get the data from GA using the API.  After looking around for existing code to help me, I settled on a pure JavaScript solution as a starting point.  This not only grabbed the data from GA but also generated graphs from it using Google Chart Tools.  It seemed perfect!

Or so I thought.  But, as so often is the case, I needed to modify the original code a lot more than I first expected, to get it doing what I wanted.  There were a few issues to overcome, including 414 errors (which were new to me) from the Google Chart API (documented in the FAQs) and the limited dimensions of Google Charts.  A really helpful tool for checking the data coming from GA was the Data Feed Query Explorer.

Once I had tweaked the code, understood the data formats and chosen my chart colours, I was able to get useful output and generate the graphs I've included in this post.

All data sourced from Google Analytics via the Data API. Values less then 0.5% have been ignored. All data is from external visits to the web site. Graphs were drawn using Google Chart tools and are accurate to 2px. Use caution when interpreting the graphs. Past performance is no guarantee of future success. Lines can go down as well as up.