The Stream of Consciousness.

I tend to use notepads to capture my stream of consciousness most days, scribbling todos, and things to write, but increasingly, i’ve been using my personal wiki to capture more detailed aspects of that. I’m not sure a blogging platform is right for these sort of abstract thoughts/comments/urls. Its not quite ma.gnolia’s role, nor tumblr either. Maybe i need to find a little IM+SMS twitter-esque tool for capturing personal thoughts, and putting them somewhere for later digestion.

here is an example of today’s stream:

* US Analogue TV shutoff in Feb 2009
* browser versioning (a list apart)
* wikileak
* gmail spam filtering failing
* scribd / embeddable doc sharing
* facebook analytics apps / adonomics, insights, develloper analytics
* facebook 5% drop in UK users in past three months (400K users)
* – new blogging/tumblr style platform
* – mobile publishing platform
* setup macmini + server at home

Starting over.

I’ve been thinking alot about, if i were to start a team from scratch again, what would i do differently. As I’ve been looking for a replacement for my role at de-construct, you ponder around these things, musing, trying to learn from your experience, and if given a blank slate – whilst there aren’t a huge amount of things i’d do totally different, there are certainly a number of approaches i’d take in the future from learnings over the past few years. One of the biggest – and this spans the entire agency – would be resourcing. We’re quite effective at having a number of developers working on a single project. We’re about to launch the Crafts Council site (check it out tomorrow at, and everyone on my team, at some point, and to differing levels of involvement, has had their hand in the code at some point. Its been a really great project. Having several developers working together means you get naturally occuring peer-review, and great iterative discussions moving the code forwards. It helps developers keep their work tidy (as there is nothing better to keep your code clear than thinking about what your collegue will say when they find your inelegant hacks), and its a fantastic way of learning.

Taking that a step further, what if you extend the model to work across your entire agency? All of the projects within the technology team are worked on by all of the team. Rather than Developer A being assigned to Project B, each project would be broken into its functionality elements, or user stories, and Developer A gets to choose which bits of work he wants to do across ALL of the projects in the studio – not just the ones he is pencilled in to work on.

Rather than having to worry about resourcing clashes (“Oh, but i need matthew to work on X all week”), your developer works on user stories of a manageable size in the time you can book him/her in for, and then the next chunk of their work may be on a totally different project. The project itself doesn’t really matter, its just delivering on the functionality which is key.

The benefits:

- All your developers will be aware of all of the projects (or thereabouts), so if someone falls ill, there isn’t a knowledge gap.
- Your developers get to work across a wider range of projects
- Your developers get to put their hand up and volunteer for pieces of functionality they’re interested in developing
- Reuse of functionality/code becomes more apparant
- If two developers are vying for the same piece of code, you might get a fight over who gets to do it. Isn’t that a good thing?
- All developers will have an interest in the overall architecture of the projects, and a consistant shared tone and approach to your code will naturally occur.
- No-one should end up getting ‘mop-up’ work, as the units of work should be discreet that a developer will always finish what they started (as well as testing it!)

I’ve seen this approach discussed before within the realms of scrum and agile – all work just get managed as a single project, and the entire workload is on the backlog, regardless of who the work is for, but i think it can exist in non agile situations also.

Google Analytics and Event Tracking

Google Analytics have released a new beta feature: Event Tracking, in order to better support RIA and Flash applications, or where ‘page views’ aren’t the only information you want to track.

The Google docs suggest this is useful for tracking: ‘any flash driven element, like a flash website or flash movie player, embedded ajax page elements, file downloads, [and] load times for data’.

Whilst we’ve been able to track things other than just page views using urchinTracker(‘/some/other/action’) for a long time now, enabling us to show how many people download a PDF, or leave the site via an external link, many of the actions which a user performs within a page we don’t want to track as part of the overall number of page views.

For instance, it is interesting for us to know how many people turn the sound off on our sites (it tells us whether the music is rubbish or annoying), or how many people stop a video halfway through playback (which also tells us whether the video is rubbish or annoying), but those figures can inaccurately inflate the ‘pageview’ count. It would be wrong to say we’d had 1 million page views if actually we were tracking the page view as one ‘hit’ and the ‘sound off’ as another.

Events allow us to seperate a pageview and an event.

To really understand this, lets get rid of (or redefine) the term ‘page view’, and call it ‘content view’. I define a ‘content view’ as any definable piece of content, so that might be an entire HTML page, or the user selected ‘next image’ within a flash gallery. If you think about when, if you had to build a flash site in html without javascript, a new page load actually occurs, thats a content view. In our example of the flash image gallery, the first content view is the gallery page itself (and perhaps image A). Pressing ‘next’ to load the image B doesn’t navigate you away from the ‘page’, but it does load in a new piece of content which is worthy of tracking. That would be two ‘pageviews’ – or the method _trackPageview()

Moving onto a more complex site, using a video gallery as an example, the first pageview is the gallery page, the next pageview is the user selecting a video, thats two hits (or two calls to _trackPageview()). The next step for the user is to press ‘play’. Now this is not a pageview or hit, but it is interesting from our point of view. Perhaps they press play, scrub around the video a few times, increase the volume, mute it, etc. That’s an event. Two content hits (gallery page, and then the selected video) and half a dozen events.

Within analytics, this then allows us to do two things: see how many people accessed that video, as well as how they interacted with it. Accurate number of ‘page views’, but far more granular data.

Google suggest you use an event to track a downloaded file. Personally, I would say that warrants being tracked as a page, rather than an event (consider my ‘contentview’ over ‘pageview’), as we want to track that they have accessed that download. That is why ‘pageview’ doesn’t cut the mustard. You can, however use events on top of pageviews. Track the download as a pageview AND an event of a certain type. So, perhaps your event object is ‘downloads’. _trackPageview(‘path/to/filename’) as your pageview, and the fact they’ve downloaded something as downloads._trackEvent(‘filename’). You can use the Event to then aggregate numbers of all events of that type (video interactions, downloads, external links) to get overall interaction trending – which has traditionally been difficult in Google analytics, having to some up ‘types’ of pageviews manually.

Currently, events are not related to pages. In theory, you could set up a uniquely named event for every item you’d like to track interaction on: movie_one._trackEvent(‘stop’), movie_two.trackEvent(‘stop’) or movies._trackEvent(‘movie-one-stop’), or even using labels: movies._trackEvent(‘stop’,’movie-one’), giving you a fair bit of control over how you can classify those events (you can also assign values to each event, perhaps monetary, download times, scrub-to positions etc.), but they’re then reported on entirely seperately to the page view itself. You would have to define a clear method of naming convention to ensure you can link all of the movies in Gallery A to the events you’ve tracked, as opposed to Gallery B. I hope the next step will be to attach (or nest) events to page views – for instance, get the count for all ‘stops’ under a certain content path. For now, we’ll need to use labels and values, but in any case its a great step forward for the already very nifty analytics suite.

Sunday Linkfest

First up, grand central station:

Google’s new Social Graph API:

I’m really looking forward to being able to spend some time with all the of new regularly released APIs for services like this when i leave decon, and give them my headspace to think about how they could be used.

Bird poops in mouth – the making of:

If you didn’t see the ‘original’, search on youtube, but here is the behind the scenes of the fake real fake original. ahem.

Matt Damon!

A picture is worth a thousand words

Lovely so simple idea:

Some great print ads

Nice selection of some amusing print ads

Sigma DP1

mmmm. want one

and finalyee