We’ve recently launched the latest version of The BMC website (http://www.thebmc.co.uk) and we’ve had some great feedback. One of the ideas to motivate and incentivise the staff to write articles was to provide analytics for each article right in the CMS. That way they could easily see how popular their article was without having to trawl through google analytics every time.

As the site is written in ASP.net web forms I went straight to http://code.google.com/apis/analytics/docs/mgmt/v3/mgmtLibraries.html to look for a c# library which at the time of writing this is still in beta. I ran into a few problems getting everything to work out of the box. Here is what I did to get everything running smoothly

OpenAuth 2.0

With version 3 of it’s analytics api Google strongly pushes you to use OpenAuth 2.0, there is already a mature library which google uses in it’s samples – DotNetOpenAuth to do the leg work. Unfortunately I was getting the follwing error when trying to redirect to gain authorisation;

DotNetOpenAuth.Messaging.ProtocolException was caught

Message=Precondition failed.: !authorization.AccessTokenExpirationUtc.HasValue || authorization.AccessTokenExpirationUtc < DateTime.UtcNow || authorization.RefreshToken != null

Thanks to the following thread http://code.google.com/p/google-api-dotnet-client/issues/detail?id=174 I established I needed to add

response.Headers["Location"] += “&access_type=offline&approval_prompt=force”;

to the outgoing request, this would force the refresh token to be added to the response.

Retrieving Data

Now that I could authenticate the application I could start querying analytics for data. I soon ran into a problem with the ReportResource.GetRequest.Dimensions property, internally it’s converted into a List<string> but that conversion fails with.

Newtonsoft.Json.JsonSerializationException was unhandled by user code

Message=Error converting value “ga:date,ga:pagePath” to type ‘System.Collections.Generic.IList`1[System.String]‘.

The only way I could get it to to work was to copy the Google.Apis.Analytics.v3.cs to my project and stop using the pre compiled dll. I then changed the Dimenstions property and dimensions field of the QueryData class to type String rather than IList<String>

As I said this file is generated from Google’s services so it is only a temporary solution.

As these c# libraries are only in beta hopefully these kinks can be ironed out soon.

You may or may not be familiar with the concept of tropes; according to the website devoted to such things, www.tvtropes.org, Tropes are “devices and conventions that a writer can reasonably rely on as being present in the audience members’ minds and expectations.” In other words, tropes give viewers a reference point – some sort of familiarity within a story that the viewers can relate to, which underpin the rest of the story’s more explorative elements.

Web sites and apps also use conventions to root the user in tried-and-tested, familiar surroundings; enhancing and streamlining the user-experience; re-calling stored and understood data from the memory banks to minimize the amount of cognitive overload when digesting new information.

Introducing new conventions

As the web is still in its relative infancy, new conventions are being created all the time. Consider iPad apps, such as Twitter, where you drag the timeline down to refresh with up-to-date entries – thanks to its intuitive nature, this was quickly proven successful and became a standard UX element for touch devices.

Even the dusty old floppy disk icon for saving files was once a brand new convention that was quickly adopted by UX designers back in the day (although they were probably called something much less cool back then). As with many conventions, a previously understood metaphor was used for transferring a user’s understanding from a traditional environment to a digital one.

Speed is not always the end-goal

Sometimes conventions are artificially inserted, in order to make an interface match the user’s expectations. Loaders are a perfect example, whereby users are so accustomed to seeing their actions greeted with a ‘thinking’ response from the machine that faster loading times may negate the need for a dedicated loading graphic; therefore, they may be artificially displayed for a short time to reassure the user.

A similar concept is the page turn transition in iBooks. Calling on a real-life metaphor, it uses a very visual example of reassuring the user that they’re moving to the next page of content – eschewing the worry of slowing down the experience for instead encouraging familiarity and understanding.

So, conventions can enhance a user’s experience of a website or app, but is this always the case?

There’s an argument that in certain specific cases where information-retrieval is not the primary goal, that bucking the trend can lead to more exploration making the experience more engaging and immersive. As ever, the key is to understand your users and their goals, and build an experience that’s appropriate to them. We’re not quite talking Mystery Meat Navigation here, but

if the user is expecting that a degree of exploration will be a key element of their visit, they’ll happily persevere without the usual pointers; as long as the experience is intuitive, there should be no frustration on their behalf and, as mentioned above, new conventions may even be created.

The gulf of expectation

The upshot is, whether conventions are followed or flouted, the interface must be intuitive enough to retain the user’s attention. What happens when a user completes a command must closely resemble what that user was expecting to happen, also known as the gulf of expectation. According to the Godfather (aka Jakob Neilsen), most usability problems come from a mismatch between a user’s mental model and the application they are using, so ensure there are no nasty surprises and your users will love you for it.

JavaScript frameworks are a godsend. Before we had the likes of Prototype, MooTools and jQuery doing anything in JavaScript was tedious and painstaking. So tedious and painstaking that unless it wasn’t anything more complicated than hiding an element I probably wouldn’t have bothered.

Image of cows, barely relevant © Joost J. Bakker

Then along came the frameworks, no longer did we have to check what browser and version the user was running, we could just code once and be happy forever. Well, almost. Even today when adding options to a select box I still have to wrap a non IE friendly statement in a try block to make it cross platform. But, still, it’s a massive improvement.

For no reason other than it was the first framework I really stumbled upon, I’ve been using MooTools since version 1.something, and it’s awesome. The abstraction for cross browser compatibility aside, it’s got a a load of functions that make doing fairly complicated effects, ajax calls and UI improvements a piece of cake. It also had also built on ProtoType’s OOP style inheritance into something that appealed to me coming from that background. Which brings me to jQuery.

I had obviously heard of jQuery and it always seemed the more popular sibling to the unappreciated MooTools, but every time I though about turning to the dark side I wasn’t convinced. I’d have a cursory glance at the API and seeing that it still wasn’t based on ‘classes’ like MooTools, I’d turn away in disgust. Now of course there’s nothing that MooTools can do that jQuery can’t and it does really come down to personal preference in terms of what style you prefer. Yes one framework may be faster for certain operations, but we’re talking slight differences and I imagine they’re all much of a muchness overall.

However we have decided that from now on all future projects are going to use jQuery as the framework of choice. Why did we decide to do this now? Aside from nasty conflicts with ASP.net web forms JS library (which I don’t blame the contributors of MooTools for, but then equally they aren’t doing themselves any favours by refusing to look at it currently), I think the weight of community support and speed of development releases has finally shifted the balance to such an extent that jQuery is now the only sensible option. A quick completely non-scientific example.; searching StackOverflow for “mootools” gives you 2,860 results, “jQuery” brings back 112,207. Now I know that’s just one source and it’s not exhaustive, but still it’s a large difference. Which framework am I going to get more help on when I need some pointers, or which framework will I be able to easily get some UI components to use in my next web app?

So for these reasons we’re giving MooTools the hoof, it’s a shame really as I much prefer its class based API and layout. Now looking forward to learning a whole new framework and all the fun that entails!

I have recently started the development of a social networking site for gamers.

The designs for Gameaface – as christened by our client – are complete and signed off ready to be coded.

Building the site on top of a social networking framework makes sense, but which framework to use.

After looking through various frameworks, the two main choices are Elgg and Social Engine. Elgg is open source. Social Engine matches the features that we need better than Elgg.

Initial thoughts of Social Engine are that it is aimed at people who want to set up a site very quickly and with little alteration from the Social Engine defaults. Styling the site is done by creating a theme and changing CSS as required. Making structural changes involves dragging and dropping widgets and components onto pages using the admin control panel which is fine for people who want to make very basic customisations, but doesn’t have the flexibility required for a complete overhaul.  The documentation is seriously lacking and only explains how to use the admin interface to make changes; for example, to add an additional page into the signup process involves a fruitless search through Google (There isn’t much of a community using Social Engine yet).

Aside from that, there are a lot of features to the system and there are plenty of additional components that can be purchased to fill in the gaps.

Google recently added reporting of site speed to Analytics and further to Tom Critchlow’s post Google Analytics Now Tracks Page Load Speed, I have looked at the implications, use and shortfalls of the new site speed stats.

Adding site speed metrics into Analytics implies that Google is going to give more weight to site speed in its ranking algorithm. Even if this doesn’t happen, site speed has a big effect on the number of page views, time spent on site and conversion rate (see SITE SPEED FOR DUMMIES by Craig Bradford).

Site speed tracking isn’t enabled by default, you have to add an additional call to the Analytics script on your site (See Google for instructions). I can only assume the reason for this is that tracking the load time makes an additional call to Google’s servers which would ironically result in a slower load time for your visitors, an undesired effect if you aren’t interested in site speed. This is also why Google only use a sample of your site visitors.

The default view for site speed groups all visitors together and splits the results by URL. This can give a misleading load time in the long run as traffic from slower devices such as mobile devices on 3G connection increases.

The table below shows the percantage of visitors using mobile devices to access some of the eCommerce websites that we manage.

Clearly if the percentage of all visitors accessing a site via 3G or slower increases by 0.5% each month, the average load time of your site is going to increase. A lot of mobile device usage could be over a wifi connection, however it makes sense to group your results by device type when monitoring your load speed over a significant time period.

In all, the site speed tool is useful for getting a sample of how fast a site loads for your visitors rather than the load speed for testing tools which generally use a fast internet connection. However for tracking speed improvements beware that the data is skewed by any change in the average connection speed of visitors and that it may be better to use a dedicated testing tools which uses the same connection each time you run a test.