One of the nice things about running your own business is that you can occasionally decide to spend a bit of time doing a bit of research into stuff you find interesting. The Normalisr is an example of this - an application that I built to reflect some of my ideas on attention data and what could be measured in last.fm listening charts.

Hooray! It's live! Your all-new "Normalisr" experience can now boast the following improvements:

• A new URL - http://www.normalisr.com/
• A slick new design, including gig photographs
• Thumbnail views of artist and album charts
• The ability to manually find artists and albums that come from last.fm without a proper Musicbrainz ID - we're hoping that this will improve the accuracy of your charts
• Proper Unicode support (fingers crossed!)
• A graphical widget of your artist chart to add to your blog or last.fm profile

We hope you enjoy it. If you have any questions, feedback or issues to report, please use the feedback form.

After months of neglect, we've finally got round to working on an update to our last.fm normaliser application. We've decided to build the whole thing from the ground up using Python/Django, our new favourite toys. Version two will hopefully include the following improvements:

• Proper unicode support.
• The ability to find artists & albums that have a blank Musicbrainz ID in last.fm. This will involve users doing an additional search for each artist, but it should vastly improve most people's charts. We will try to make the search process as easy as possible (see screenshots below).
• A whizzy new design using gig photos from Flickr.
• Updated XML format to mirror v2 of last.fm's data feeds (we will keep the older XML versions available on the same URL).
• Hopefully, some form of export code that will allow charts to be shown on user blogs, etc.
• We're still scratching our heads trying to think of ways we can make a few quid out of all the work we're putting into this...

Anyway, some work in progress screenshots below.

Homepage

...you watch a video by the next big thing in pop music and concentrate on the gadget rather than the fetching young lady or the tune.

"When you blow something up by a factor of one hundred, it gets weaker by a factor of one hundred. If you try to build a cathedral that way, it just collapses into a pile of rubble." - Alan Kay

Having spent time as both a "Software Engineer" and a Structural Engineer, I am always interested when key industry figures start comparing the two disciplines. Alan Kay's insight into one of the fundamental problems with software reminded me of the arguments over the use of the word "Engineering" for software.

Our last.fm normaliser application recently celebrated its first birthday, and we're pretty pleased that not only has it lasted this long, but it still seems to be going strong. In that year, it has served up over a quarter of a million charts and now has over 215,000 albums in its cache.

It has been very interesting to compare usage with coverage - while most of our referrals come from last.fm itself, this article in Read Write Web, a link from Tom Coates and the launch of last.fm's directory of external applications all provided some welcome spikes in traffic.

Read Write Web has just published an interesting summary piece about the semantic web, that predicts the eventual demise of relational databases in favour of "structure on the fly" searching.

We've just knocked together a stats page for our last.fm normaliser application, that rejigs your charts based on an estimate of how long you have actually spent listening.

I have just published a little application that grabs the top 50 artists from your Last.fm profile and searches for the latests news about them from Google News. The results are produced in RSS format.

After much head-scratching and a few hairy moments with the database this afternoon, we have updated the Last.fm Normaliser to use median track length values in its calculations, rather than the arithmetic mean values used previously.

Hopefully, this should smooth out a lot of the issues people were reporting with a handful of extra-long or extra-short tracks skewing the figures for a particular artist or album.

I have just updated the normaliser application to add a few new features, including album charts and different time periods. Full update history here.

After grumbling about the way last.fm calculates artist rankings, I realised that in the age of open data it shouldn't be too much hassle to knock together a little application to apply the normalisation calculation I discussed.

The application takes a last.fm username and recalculates the ranking based on an estimate of the amount of time you have spent listening to an artist, rather than the number of tracks played. It uses the excellent MusicBrainz web services to calculate an artist's average track length. Why not give it a whirl.

Following last week's launch of Apple's Safari browser for windows, I've noticed the continuation of a pattern that I was hoping would stop with iTunes for Windows. Why on earth do Apple insist on using a non-standard window chrome design, making the buttons much smaller?

I'm a big fan of last.fm, a web application that records what music I listen to and can then find people with similar musical tastes as me. I have set up iTunes on my PC to automatically send data about what music I play, and I get all sorts of interesting information from it.

I have just written an article that goes through the various different applications and technologies used on this website and explains a bit about them.

What I thought would be a pretty quick exercise turned into a much longer task than I expected - who'd have thought that a little site like this could involve so many things? I was surprised, but its been good to remind myself of exactly what is involved in professional web development and what differentiates us from a lot of equivalently-sized suppliers.

I must say, I tend to agree with Google's attack on Enterprise CMS systems for being difficult to use and generally behind their consumer-focused counterparts.

The sad fact is that a lot of CMS interfaces are clunky and very confusing. These kinds of systems (similar to intranet applications) do not have the same competitive pressures - it is much more difficult and costly to move to a different CMS platform than it is to use a different search engine - and often the user interface suffers as a result.