How Safari became the number one browser at St Andrews

Last week I logged into Google Analytics to take a look at browser statistics for the University website. I was surprised to discover that Safari is now the most popular browser among visitors to the University website.

In January 2012, 29.5% of all visits to the University website were made using Safari. This compares to 26.5% for Internet Explorer. Chrome has 21.4% and Firefox has 20.1%.

It is an unusual finding. Take Wikimedia’s statistics, which show 29.5% of traffic coming from IE users, and only 6.1% coming from Safari users.

Here at St Andrews, Safari was also the most popular browser in December 2011. But it hasn’t always been this way. So I decided to take a look through the previous months to figure out the trends.

Browser trends since September 2010

I looked as far back as September 2010, the last month when Safari was still only the third most popular browser among our visitors. At that time, as you would probably expect, Internet Explorer had a healthy lead in front of the other browsers — 41.4%. Firefox had 24.4%, Safari had 22.1% and Chrome had 10.5%.

Since then, the big four browsers have converged, so that they each now account for 20-odd percent of visits.

There has been a strong decline in IE usage. Firefox usage has also decreased, although it now appears to be making a small resurgence. But, while Firefox was once the clear favourite among non-IE users, today it is only the fourth most popular browser.

Chrome has experienced massive growth. It has now overtaken Firefox and shows no sign of stopping.

Safari has experienced a steady increase over this period. Chrome is growing more quickly, but it began from a lower point.

Is Safari so popular anywhere else?

Last week I tweeted about the fact that Safari is the most popular browser among our visitors.

The most popular browser among our website visitors is now Safari with 29.3%. IE has 26.6%. Chrome 21.4%. Firefox 20.15%. ^dbss

— St Andrews Web Team (@stawebteam) February 2, 2012

There were some interesting responses.

@stawebteam Do you have a lot of Macs on campus? Our Safari usage is nowhere near that high!

— Michael Nolan (@MikeNolan) February 2, 2012

 

@stawebteam interesting. Nowhere near that on ours. Any theories/explanations?

— Webdunk (@Webdunk) February 2, 2012

So I took a look at the operating systems used by the University website’s visitors.

In January 2012, 33.1% of visitors were using a Mac. I would guess this would be much higher than most other websites. For instance, Wikimedia estimates that only 8.6% of its visitors are using a Mac.

Usage of Macs among our visitors has grown from 26.0% in September 2010. This clearly contributes a great deal towards the popularity of Safari, which is further bolstered by the growth of iOS devices.

Quite what explains why we have so many Mac users at St Andrews is another question! Perhaps you can come up with some theories.

Web team support calls from 2010-2011

(Click the graph to see a larger version.)

This morning I’ve been gathering data for a meeting with have with the University Lean team tomorrow, including this graph of support calls (above). I thought I’d share something of what I’ve discovered.

The project with Lean is to help us design a more efficient way to manage projects and to explore how to better balance moving projects forward with our on-going, and unpredictable, support calls.

In the academic year 2010-2011 the Web team recorded how many calls we received each week. This included:

• Emails to our IT Helpdesk call management system
• Support-related emails to our personal inboxes
• Telephone calls
• Personal visits to the Web team offices

Basically, if it wasn’t related to an on-going project then we recorded, grouped into calls that took up to

1. 10 minutes
2. 60 minutes
3. 120 minutes or more

And we further categorised them as

• Advice—e.g. could you tell us what template to use for this website? Do we support IE6 now?, etc.
• Fix—e.g. this page is broken please fix it, please remove this document from the server, etc.
• Request—e.g. could we have a meeting with you about x? Could you create a generic page template for this web application, etc.

Support calls (2010-2011)

	Advice	Fix	Request
Semester 1	434	722	509
Semester 2	328	547	382
Total	762	1,269	891

That’s a grand total of 2,922 calls over the course of 35 weeks. Or approximately 83 calls per week.

What it shows us immediately is what we’d long suspected: that the start of each semester is the busiest time of year for us. This should help us to plan projects and which parts of the year to keep clear to make room for more support requests.

Something that this has highlighted too is to look into how to reduce the number of calls asking us to make fixes to existing content, structure or CMS elements.

No doubt we’ll report back as we progress through this project with Lean.

Replacing the website header when printing web pages

Until this week, printing web pages resulted in the University crest looking broken and ugly. We needed to find a way to replace this for printed documents. We achieved this with a few tweaks to one jQuery file, common to most webpages on the site, and two style sheets (style.css and print.css).

The issue

The University crest displayed on the University website is a GIF with transparency applied to St Andrews Blue (#00539b). It looks like this:

Displayed on a St Andrews Blue background it looks fine; printed onto paper, it looks very bad and doesn’t reflect the professional image that the University would like to project.

I’ve been meaning to fix this for months in the print-specific style sheet but other things kept me from addressing it, until this week.

In discussion with someone from our Print & Design unit we decided to use the monochrome crest and header as used on University letter heads, which currently looks like this:

We didn’t want to assume that users would be printing the document on a colour printer, so we set the text to black and ensured that the monochrome header accompanies it.

Method

Broadly speaking, there are two methods of including an alternative images on a webpage, with which we can use CSS to control under which circumstances it is displayed:

1. Apply a background image.
2. Insert the image within the document, as content.

Applying the header image as a background-image was ruled out immediately as browsers generally disable the ability to print web page backgrounds unless the user enables that functionality. That’s not reliable enough a solution.

That left inserting the image into the document. Again, two methods:

1. Drop the image directly into the document (in T4 Site Manager this would mean adding it to the Style), or
2. Inject it into the DOM using JavaScript.

As there are over 20 styles—in true Blue Peter style—for speed, I chose to use (double—sided) JavaScript.

EDIT: Correction, there are currently 114 CMS styles (read themes or page layouts), and over 435 in total. I didn’t have the time to edit all of these manually. So for speed I chose to use JavaScript. For a longer explanation of this see the comments. End of edit.

I also provided a way for those few with JavaScript switched off who wished to print the page to at least view the text from the H1 heading “University of St Andrews”.

Code

The following is the code currently used on the University website:

HTML

Here’s the header on the main University website (omitting the full code for the Google Search):

<!—header –>
<div id=”header” class=”span-33 last”>
<h1><a href=”external-1-home.html” title=”University of St Andrews home”>University of St Andrews</a></h1>
<a href=”external-1-home.html” title=”University of St Andrews home”><img src=”images/header_crest_1413.gif” width=”42″ height=”52″ alt=”University crest” /></a>
<form id=”googlesearch”… /></form>
</div>

jQuery

First we add a class of .js-enabled to #header. That way we can provide a fall-back for any users who do not have JavaScript enabled, otherwise they would see no header whatsoever.

Next we ‘prepend’ the print-header div above .container so that it appears at the top of the document, before all other content.

// Load print-friendly header image into DOM after the page has loaded.
$(document).ready(function() {
$(‘div#header’).addClass(‘js-enabled’);
$(‘.container’).prepend(‘<div id=”print-header”><img src=”images/print-header.png” />
/div>’);
});

Screen style sheet

This is very simple: do not display the newly inserted piece of HTML code on the screen.

/* Hide print-only header from displaying on screen. */
#print-header {
display: none;
}

Print style sheet

First we hide all elements of the #header that we do not want to print: the Google search box (form), the crest (img) and then only if JavaScript is enabled (#header.js-enabled) the entire header.

If JavaScript is disabled then all that will remain is the H1 element.

/* Hide screen-only header when printing. */
#header.js-enabled,
#header form,
#header img {
display: none;
}

So, let’s style the H1 element, which in this case also contained an anchor tag. We’ll remove the default underlining of the link.

/* Style non-JavaScript heading */
#header h1 a {
text-decoration: none;
}

That is the non-JavaScript users catered for, and the appropriate elements have been hidden also for those with JavaScript enabled. First we need to display the #print-header that we inserted using JavaScript and then hid using the screen style sheet.

/* Display print-only header when printing. */
#print-header {
display: block;
}

Next, we have to constrain the size and proportions of the image.

#print-header img {
height: auto;
max-width: 100%;
width: 20cm;
}

Conclusion

Here, then, is a comparison of the printed page before we carried out this work with how it looks now, both with and without JavaScript enabled.

Above: Print preview before, with poor-looking crest

Above: Print preview now, with JavaScript enabled

Above: Print preview now, with JavaScript disabled

I think it looks much better now, more professional.

Afterword

I won’t mention that I accidentally broke two other websites who were pulling in the jQuery common file that I edited. If that was your website: sorry.

A lesson on why we should separate CSS and JavaScript files between projects: even if they initially share features and functionality, they might not always. We don’t do that now, but we did back when we set up these sites.

New Accommodation website

Another major website I worked on over the summer was the new Accommodation website, which went live in October.

I think it is quite a distinctive and bright looking website. This is largely due to the excellent use of photographs.

Photo galleries

It was widely felt that the photographs used on the old accommodation webpages could have been improved. So there was a big focus on making good use of good photographs on the new website.

A big feature of the new residence webpages is the gallery of photographs. We settled on using the GalleryView jQuery plugin for this. It is fairly flexible, with plenty of options to configure. So when I was asked to make changes to the functionality of the gallery, it was fairly straightforward to update it.

Managed properties

Much more challenging was the managed properties page. This hasn’t gone live yet. But behind the scenes it works, although it’s not the most elegant of solutions.

We were asked to create a page that will contain information about a large number of individual properties — 80 or so. There is not enough information about each property to justify giving each property its own page. But, each property needs to have its own gallery, which opens up in a lightbox.

There was scope to split them up into five categories, so I have given each category its own webpage. This leaves us with around 15 or 20 per page. But whether there are 80 or 20, this leaves us with the problem of giving each property its own unique gallery while remaining on the one webpage.

This was a considerable challenge to implement within TerminalFour Site Manager, at least the way our Media Library is set up. The solution, as I said, is not ideal. It is certainly not the most user-friendly for the content owners to update. But it is good once again to push the limits, and learn what can be achieved when you set your mind to it.

No rush

Despite the sometimes tricky requests, I found the people at Residential and Business Services good to work with. They had brought on board a web expert who was able to do a lot of the heavy lifting and had great ideas for the website.

But best of all, we were given plenty of advance warning to work on the website several months before it was due to go live. In stark contrast to some others, who sometimes expect us to magic up an amazing website at the last minute with no prior warning, we were able to finish the majority of the work on the Accommodation website three or four months before it was due to go live.

It certainly made a nice change to be able to stop working on a website for a number of months rather than desperately rushing around at the last minute.

New Museums and Collections website

I say “new”, but the Museums and Collections website actually launched a good few months ago now. But I have been so busy over the summer that I haven’t got round to writing about it, until now.

I recall that the very first meeting I had when I began working here two years ago was about the Museum Collections Unit’s web presence. The ultimate result was this new website, which we worked on during the spring and summer.

The visual design was created by Steve Evans, the Web Manager. It was then passed on to me to build within our content management system, TerminalFour Site Manager.

It is a fairly complex website, and definitely the most challenging project I have worked on. I really enjoyed stretching my limits and working with T4 Site Manager in new ways.

Creating the homepage

My first task was to create the ‘four panels’ page, as I called it. This is the overarching Museums and Collections homepage, which links through to the individual websites for each of the four museums. Each museum is represented by a square, which expands to reveal more information when the user hovers over it.

This uses JavaScript, which has not been a particular strong point of mine in the past. But I am beginning to wonder if that has changed, because I surprised myself when I managed to achieve this result quite quickly.

Personally speaking, this is not the sort of design I would normally opt for. But in the end I think it has turned out quite well and feedback from others has been positive.

Building the website in T4 Site Manager

The five websites themselves all share the same basic building blocks, but are subtly given unique identities. For this, I had to be quite creative in the way I built the website in T4 Site Manager, in order to avoid unnecessary duplication. I did not want to create several styles (which can be a pain to maintain in the long run) and templates that all looked almost but not quite the same.

This meant creating lots of navigation objects and ‘related’ sections instead. This is one of the trickiest parts to get right. It is a jigsaw puzzle with lots of different potential solutions, but each with their own little pros and cons. So it takes some careful thought. But it’s easily worth it for the long-run benefits it brings in terms of ease of maintenance.

A bit of creativity in using existing navigation objects was also required to give each museum’s website its unique identity. This allowed me to use the same style (page layout) for each website, while still being able to assign different CSS stylesheets to each website’s homepage, and separate stylesheets again for the lower level pages. This is what enables each website to have its own colour scheme, yet still all use the same style.

Other interesting bits

While working on this website, I also used the Google Maps API v3 for the first time for the maps on the visitor information pages. As far as I know, it is the only part of the University website that uses this newest version of the Google Maps API.

I was surprised to find it pleasingly easy to work with, and I think it provides a smoother user experience than version 2. The newer version is designed to work better on mobile devices too.

Another interesting part of the website is the virtual tour of MUSA’s Learning Loft. This was another first for me, working with Flash as well as JavaScript (normally we only use Flash for videos). But again this turned out to be reasonably straightforward in the end, and looks really good on the webpage.

Visual design

Initially the Museums and Collections website was going to be a more conventional affair. But Steve was inspired to create something more striking after seeing some of MUSA’s physical promotional material. Steve’s decision led to him creating a brilliant design. The Museums and Collections webpages are now, in my view, some of the very best looking pages on the University website.

On reflection, the decision to go with an image-heavy design makes perfect sense for a Museums and Collections unit that can draw on 600 years of history for its visuals. There are some fantastic images of some of the objects in the collections, which helps make these webpages particularly appealing to look at.

Summary

The new Museums and Collections website was a brilliant project to work on. It threw all sorts of challenges at me, but this was a great opportunity to learn. It took a while to get it right, but I think the result is a really eye-catching website.

Vote for the UK Web Focus blog

Our friend Brian Kelly, the UK Web Focus for Higher Education institutions based at UKOLN (“a research organisation that aims to inform practice and influence policy in the areas of: digital libraries, information systems, bibliographic management, and web technologies”) at the University of Bath, has been nominated for a social media award in the Computer Weekly Social Media Awards 2011.

Brian has been put forward for IT Professional blogger of the year, and (I’m pretty sure) is the only blog representing the higher education sector.

Voting closes on Friday 25 November 2011, so please vote now – it will only take you a couple of minutes.

Moving our team task board online to Trello

For the last few years the Web team have been using, and adapting, a form of Agile/Kanban board to manage what tasks need to be done and by whom. It has served us very well, but this week we moved it online to Trello, a free, hosted service from Fog Creek Software.

Why we went digital

When we started using the board the Web team consisted of three people: Steve the Web Manager, me (Gareth) the Assistant Web Manager, and Chris the Web software developer.

We all sat in the same room together, and the board was just a few steps away from our desks. It was handy, and quick, and accessibly. But as the team has grown we’ve now spilled out into an office on another floor of the same building.

It’s not quite so easy now for all five members of the team to add to or move tickets around the board. Occasionally some of us work from home too.

The main catalyst, however, was in response to a recent crisis in which our intrepid leader, Steve, fell of a ladder and broke his foot (you can see photos of his recent x-rays on TwitPic). He could be working from home for some time now and we wanted to make him feel included so we moved to Trello.

Trello

It was pretty painless to set up and add users to our newly created organisation and board. I then spent a couple of hours migrating our open tickets over from the whiteboard into Trello.

Labelling and assigning tasks to users was simple thanks to Trello’s excellent keyboard shortcuts.

I did wonder if I’d miss physically moving cards from one column to the next, but Trello has a neat little trick whereby when you ‘pick up’ a card it rotates it a little to indicate that it’s been picked-up. It’s really effective and surprisingly satisfying:

We’ve decided to trial working with Trello for a few months, certainly while Steve is recovering and may have to work from home.

So far the response from the rest of the team has been very positive (after we switched off email notifications). It’s attractive, it’s simple and it’s intuitive. No doubt we’ll report back in a few months with our thoughts on how the move from analogue to digital has gone.