Categories
Radio & Music

A question on the lifecycle of songs…

I’ve just posted this question to Ask Metafilter, but I thought I’d cross-post it here to see if anyone knows the answer:

When I was a kid, I remember hearing on the news about a study that had determined that there were a few specific life-cycles for the way a hypothetical person’s might react to any new pop-song. One type of song would get more popular the more times it had been heard and then would plummet in popularity when a person had heard it around fifteen times. Others took longer to get popular but would stay at the top longer. These studies were used to help radio networks determine what to play – how to make songs into hits and how often to play them once they had become hits. Does anyone know anything about these studies and where I might be able to find them?

If you know the answer to this question feel free to either post it on the thread (if you’re a Metafilter member) – What studies have been done on the lifecycle of pop songs and how people respond to them over time? – or below if not…

Categories
Radio & Music

On Reinventing Radio: Enhancing One-to-Many with Many-to-Many…

So our first presentation is over – much to my relief. I think it went fairly well – Webb was busy addressing people’s questions on IRC, and Biddulph, Hammond and I performed our little hearts out. There were some interesting questions afterwards which we all fielded and nothing went wrong. So probably all good stuff. Anyway – the paper is available for download as a PDF here: Reinventing Radio: Enhancing One-to-Many with Many-to-Many. I hear there’s probably going to be an incredibly embarrassing video or audio version circulating around the web in the next couple of days or so. Wow am I looking forward to seeing that!

Just to whet your appetites, here are a couple of screencaps from the presentation to give you a sense of the areas we talked around:

Only one more to go now – BBC Programme Information Pages. I’ll see you guys tomorrow for that!

Categories
Design Radio & Music Technology

On trying to get an image right…

A long time ago during all the Warchalking palaver, I got interested in the idea of trying to find imagery that might convey they concept of an available wifi network to people. Warchalking obviously had its utility – it was a higher level, cultish concept designed to celebrate some kind of Ur-hacker / Urban-tech-frontiersman aesthetic. But alongside that was clearly a need for something simpler that your average punter might be able to get their head around. And when I say average punter, I do – of course – mean me, since I never actually figured out what all the little figures and abbreviations were supposed to stand for. I’m a clumsy, technologically backward Luddite. Sue me.

Of course now there are lots of little icons and logos and buttons – mostly proprietorial – that advertise the presence of wifi, so there probably isn’t the need any more. But at the time I had in my head some kind of image like the RKO pictures logo, but instead of beaming out lightning or pulses – it would instead be firing off packets into some kind of surrounding network.

Anyway, forever and a day later I find myself trying to convey an image of broadcast radio sets engaging with some kind of networked future in a useful way for a presentation and I return to the same image, and after an extraordinary amount of fiddling and arsing around come up with something fairly mediocre in execution, but interesting to me in terms of imagery…

You can download a larger version of the image here: Radio / Network hybridisation. So now I was wondering if anyone had any sense of how maybe to push it forward as an image? Or whether there was someone out there more expert in illustration than I who might be able to turn it into some kind of logo or badge or button. And – of course – I thought maybe it might be a good time to actually see if it makes any sense to people at all.

This is completely throwaway, though. Please don’t think I’m taking this terribly seriously. I just knocked it up while trying to do something else and failing and thought that it might have more value being exposed in public than just sitting on my hard-drive forever.

Categories
Radio & Music

The BBC releases In Our Time in free-to-download MP3 format…

I was planning to post about this last week, but I got distracted with something. Hope you can forgive me. Anyway, a while ago BBC Radio and Music Interactive (where I hang out during the day for cash) released Radio 4’s Reith Lectures in DRM-free MP3 format for people to download. It was something that we were all terribly proud to be able to be associated with.

Well now the department has gone one better. There’s this show on Radio 4 called In Our Time that’s concerned with the history of ideas. Each week Melvyn Bragg brings together three guests (serious guests at the top of their fields) and they have a discussion around the major themes. It’s kind of awesome if you’re interested in science or history. Just to give you an example of the kind of things that they cover there have been programmes on:

  • The Origins of Life with Richard Dawkins, Richard Corfield and Linda Partridge
  • Cryptography with Simon Singh, Fred Piper and Lisa Jardine
  • Homer’s Odyssey with Simon Goldhill, Edith Hall and Oliver Taplin
  • Hysteria with Juliet Mitchell, Rachel Bowlby and Brett Kahr
  • Dreams with V S Ramachandran, Mark Solms and Martin Conway

And if that lot doesn’t whet your appetite, then nothing will. Now all of this stuff has been available online for people to listen to using the BBC RadioPlayer (you can launch it from here), but now it’s got even better. Starting from shortly after last week’s episode, now you can download and listen to the whole programme in non-DRM’d, easy to understand, iPod (and other media player) -compatible MP3 format! The latest episode (about the origins of Electricity, and featuring Simon Schaffer, Patricia Fara and Iwan Morus) is currently available for download here. And if you particularly enjoy it then you can explore the subject further with the BBC reading list.

How neat is that? You loving this as much as we are yet?

Categories
Radio & Music Technology

The New Musical Functionality: Portability and access

The other day I started this run of posts on the New Musical Functionality by arguing that the behaviour of an until-recently small group of digital music fans seemed to be now spreading into the mainstream. I also listed four areas that seemed to me to be where the most significant changes in consumption patterns were occurring – areas to which I believe that anyone building sites, services or hardware around music should be paying close attention. These four areas were (1) portability and access, (2) navigation, (3) self-presentation/social uses and (4) data use and privacy. Today I’m going to concentrate briefly on the trends towards portability and access.

This may seem like an obvious place to start, but I think it’s an important thing to get out in the open: the core difference between an iPod and a CD Walkman isn’t audio quality. That’s not to say that there isn’t a differences in the audio quality between the MP3/AAC file and CD ‘originals’ because – of course – there is and it is a significant one. However, in defiance of the normal path of technological achievements, the newer technology does not have the advantage in reproductive fidelity. In the future this may change (Apple’s lossless compression and increasingly cheap storage space are just two of the reasons why), but at the moment MP3s and AACs use lossy forms of compression and for this reason simply do not sound as good as their CD originals. It would probably be pushing it to say that this is the first significant change of popular audio format that actually made the sound quality worse (vinyl fans have been criticising the CD for that for years), but it does at least seem to be one of the first where claims of improved sound haven’t been a major selling point.

So why are these new formats and players starting to occupy the mainstream so effectively? What is it that means people want iPods so desperately even though they’re effectively purchasing a technology that will result in a decrease in audio quality? Again the answer is so obvious that it hardly bears repeating – particularly given that it’s on every single bloody advert that Apple produce. The reason that people are buying iPods is because they want 10,000 songs in their pockets. They want access to music wherever they are in the world. More still – they want access to all their music everywhere. Every last bit. Every last place.

As I’ve said, this sounds obvious but it is important. It’s important because once we understand the need that a product is filling, we can attempt to find other/better ways of filling it. The iPod’s current success has demonstrated that the need exists – and how – but I would argue that in the longer term it is by no means obvious that the need would be best served by small portable hard discs embedded in MP3 players.

It doesn’t take a lot of foresight to see the scope for development in this area. In the short-term, the trend seems fairly clear – storage capacity looks set to increase and/or devices look set to get smaller. This has been the trend of almost all computing technology over the last few decades (cf. Moore’s Law for the near-parallel phenomenon happening in processor speed). Given these fundamental developments, there aren’t an enormous numbers of directions that these devices can go.

The first two options for future product directions around this stuff are (1) larger capacities and (2) smaller form factors. We have already seen movements in both of these directions (iPod Mini / 60Gb iPod coming). However, there’s only so far that either of these trends can develop.

Increased capacity ceases to be interesting at the point where there is more capacity than data to fill it – hence the problem with saying that newer iPods can hold 10,000 songs. There are very few people in the world who would be capable, let alone interested, in sourcing that much music. After listening to my music exclusively through a computer for the last two or three years, I’ve still only got 8,000 MP3s. And I’m hardly representative. If we’re talking about significant subsequent increases in capacity then there are some pretty clear limits in place. 10,000 songs is about a month of solid listening. 100,000 songs would be getting on for a year. 1,000,000 songs a lifetime. Somewhere between a month and lifetime, the marginal utility of another song being on your iPod reaches zero (even assuming that physics lets you get to that size in the first place).

Of course when we talk about capacity in terms of songs we’re kind of missing the point. From this point on, advances in capacity are more likely to allow us to listen to higher quality audio than they are to increase the number of songs that people want to listen to. A tenfold increase in portable storage would mean that a future iPod could carry the same number of songs as a current iPod except in Apple Lossless formats that have all the sound quality of a CD. A parallel increase in bandwidth speeds could mean that the last few decades of work on compression could become fundamentally redundant – much like the techniques that meant programmers had to write whole applications to run with 8k of RAM are now pretty much irrelevant. So this is clearly a direction things are likely to move over the next few years. But even this has its limits. Once you’ve escalated disc size ten times there’s nowhere to go in terms of audio quality – or at least, nowhere that will make the slightest difference to most individual consumers. So again any subsequent growth in capacity will have to be sold in terms of an increased number of songs that could be held – and as such the gradual diminishing marginal utility problem comes in again. Increased capacity, therefore, has only so much of a shelf life – can only go so far before it collapses under its own weight.

The other potential obvious future direction – as I’ve said above – is to make the appliances themselves smaller. Here again there are limits to utility. There would seem to be a size under which a device ceases to be practical – that size being directly related to the size of interface elements, screens and buttons, which in turn relate directly to the size of fingers and thumbs and the limits of human vision. Now again, you can merge this in as a direction with the increased capacities and find a bottomed-out form factor and gradually increase the capacity on it – and no doubt this is the main approach that people like Apple will take over the next few years. At least that is until physics steps in or human interest (in having unlistenable amounts of music) begins to wane – both of which are probably a way off, but remain definite limits to future development in these directions.

Of course, there are certain conditions where an appliance may usefully shrink below the size of its interface, and that’s when it shares that interface with a number of other pieces of technology. This is the approach that the mobile phone manufacturers have taken – as the phones became almost unmanageably small, people’s attention moved instead to enhancing functionality and adding in cameras, PDAs, web-browsers, comms equipment, bluetooth and the like. This had the effect of keeping the form factors at manageable sizes while still allowing competition and product development to occur. There’s absolutely no doubt that this kind of hybridisation will be / is already a core part of the development of portable digital music players. Much of this hybridisation results in useful connections and possible new products emerging from music devices that are permanently network-enabled.

All of this previous stuff has been relatively uncontroversial – it’s no more than the immediate development along a couple of pre-existing axes of the products we have in our stores today. The incorporation of network-enabled devices has the capacity to change things a lot though. This is where alternative models for fulfilling a design for universal access and portability are likely to start emerging more strongly. We currently seem to be moving towards a world with greater and greater connectivity and one in which some kind of flat-rate, always-on broad-ish band internet access is likely to be integrated into pretty much all portable devices. This opens up other possibilities for having access to all of your music wherever you might be – and without actually carrying any of the files around with you. We could be looking towards a near future in which all of your media (and perhaps applications and information) can be held ‘in the sky’ and streamed/downloaded down to whatever appliance you like as and when required. Where this repository would live (with an ISP, with your home server, on your TV’s set top-box, on Apple’s iTunes Music store) is not immediately clear. But it’s conceivable that – given enough bandwidth and centralisation – massively redundant models like we have at the moment where everyone has their own copy of a music file could be replaced completely by centralised music-on-demand services. Personally, I’m not much convinced that particular extreme is likely – people still seem to like to own music and still think of it as an object rather than as a service – but that’s not particularly relevant. The important aspect is simply that the same user need can be met in different ways.

So will we move towards larger portable hard discs or towards connected repositories explorable through massive bandwidth? Probably the direction that we take here will depend on nothing more elegant and interesting than financial cost. If enormous storage options were to become enormously cheap and small, then carrying a significant hard disc is likely to remain the preference of individual music fans. On the other hand, if bandwidth became cheap, then we’ll probably find ourselves in a more service-driven and centralised streaming-based world. The model that’s most likely to dominate is likely to lie somewhere in between the two – in hybridised technologies that use hard disks as local copies of stashes of music held in more centralised locations – using the network to syncas and when appropriate (see note) as well as a mediator for various forms of engagement, navigation and data-mining around and in-between individual listeners. But more around that stuff in the next part of this sprawling rant around the New Musical Functionality: On trends in navigation…. (Coming Soon)

Note: Syncing becomes very important in a world with innumerable devices and limited connectivity. On a slight tangent – there are innumerable hybrid models where increases in portable data collide with the ability to access data at a distance. At the desktop level you can imagine computers running off the wired internet creating the impression of your ‘home’ computer wherever you sit, and on the portable level with large local storage being kept up-to-date perpetually via slower trickle-fed syncing protocols.

Categories
Radio & Music Technology

The New Musical Functionality…

Over the last few months webloggia has been full of discussions about the new musical functionality that’s starting to emerge around the web. I wasn’t immune from this trend – I wrote about MediaUnbound (On MediaUnbound and Recommendations Engines) and linked to the (currently pretty awful) Music Recommendation System for iTunes. Dan Hill has also been talking around the subject, talking about first Socialising mp3-based music listening and then about whether whether recommendations scale. And those minxes over at 2lmc linked and commented upon the views of people who are suggesting better ways that iTunes could handle transitions between songs. And of course the new version of iTunes and the iTunes Music Store also now has the user-generated iMix feature – standard web-native functionality which allows people (and now people in the UK, France and Germany rather than just the US) to put mix tapes on the web where other people can rate and/or buy them. And that’s just the tip of the iceberg…

Then of course there are the staples of this new musical functionality – from the rapidly-becoming-indispensible audioscrobbler (which uses the flexibility and granularity of net-enabled MP3 playing devices to create charts, lists and recommendations) through to the self-generating radio stations like last.fm and launchcast. And then there’s all the little hook-in tools like iChatStatus (publish current listening to iChat’s presence display) and Kung-Tunes (publish current listening to the web) that have slowly becoming integrated into my life without my really noticing how they all hook together, communicate, branch off and build upon each other.

All this new funtionality is emerging at the same time (or at least starting to be adopted at the same time) because we’re beginning to see a world in which a decent number of early adopters are now starting to do a substantial portion of their listening on digital devices. Obviously the iPod has been the major success story here – the definitive product that has been encouraging people to do the necessary work to transfer their music into more easily manipulatable digital files. But the increasing prevelance of broadband and wireless connectivity is helping too – becauase it’s the connection of these appliances to the internet that has created the explosion in interoperable, interconnected devices, applications and people. Clearly, the number of people listening to music through these channels is still tiny compared to the entire music-consuming public. There may be many people using iPods, but there’s still an adoption path for moving all your listening into digital jukeboxes and being perpetually connected to the internet (ubiquitous, always-on, non-computer-centric internet in the home is a bit of an obsession of mine at the moment).

But this small proportion looks like it is set to grow. One of the first questions you have to ask yourself in any organic R&D role (which is I think how I’d characterise what I do) is am I a freak or am I an early adopter? You have to have some sense of how much your instincts and excitements are in tune with real people in the world because otherwise you cannot possibly evaluate how those people might respond to the products, concepts or propositions that you think are exciting. In this case, it’s becoming fairly clear that people who are listening to digital music and in connected ways are very definitely more like early adopters than they are freaks. They’re pointing in roughly the right direction. And there are now enough of them that it’s becoming more and more worth people’s time to build little tools or widgets or applications or paradigms or appliances or business models around them. Which in turn appears to be making the whole area still more attractive, creating a feedback loop that is pulling more and more people towards new ways of listening. I don’t want to sound too cheesy but I’m afraid I can’t help myself – it’s pretty clear that we’ve reached a critical mass and that new musical functionality is about to explode. The only question now is what will be there when the smoke clears?

Over the next few days I’m going to write about some of the core trends that I’m seeing in people’s use of digital music, attempting to extrapolate from some current behaviours that we’re all observing around us – concentrating on how people wish to interact and use their music. I’m not going to spend too much time on the way some people may wish to legislate against these desires or build around them – because I believe for the most part that any attempt to do so will inevitably fail. Competing models that more adequately fulfil those needs will rise to take over in their place. The model that meets the most needs (while having the least obvious incumberences) will probably win in the really long-term, even if the market, commercial advantages or monopolist practices deform it in the short to medium term.

I’ll be talking about four major areas that seem to me to be indicative of the unevenly-distributed musical functionality of the future – (1) portability and access, (2) navigation, (3) self-presentation and social uses of music and (4) data use and privacy. These trends within these areas are – I believe – representative of much larger trends across the consumption of all text-based, audio-based and video-based media and so it might be possible to draw conclusions beyond the consumption of music. I am however not planning to do so. And I make no claims that these areas of enquiry are absolute or canonical, or that there are no other areas that I should also be investigating. All I’ll argue is that these four areas are core to the movements that we’re currently seeing and that they are each likely to play themselves out in the product designs, interface designs and business models of the near future.

Of course what comes after that remains to be seen…

Tomorrow: The New Musical Functionality, Portability and access

Categories
Design Net Culture Radio & Music

Developing a URL structure for broadcast radio sites…

One of the most common questions I’ve had about the Radio 3 redesign work that we’ve been doing has been about the URL structures that we have used to identify individual episodes of individual programmes. I’m really keen to address these questions with a full and maniacally over-detailed post because I think the issue of how we map broadcast programming to web URLs is a really interesting one, and because I think we’ve done some good work here that other people might find useful or interesting. Drew McLellan writes:

I see URLs like /radio3/showname/pip/randomcode which, as I understand it, would require a user to locate a particular show through the site’s navigational system. It looks like there’s no way of guessing a URL. Is that right? What’s ‘pip’? That makes no sense to me. My preference for date-based material is a path with the date in it – like /radio3/showname/2004/06/27/ Is there a reason why a URL format similar to this wasn’t chosen?

So the first thing to explain is that Radio 3’s new site is particularly interesting and ground-breaking because it doesn’t just have a page for every broadcast, it has a page for every episode. This is way cooler than having a page for every broadcast, but the full implications of it aren’t immediately easy to digest. Basically it means that there would only be one page for any documentary no matter how many times that documentary is repeated. That one specific page then becomes the definitive home for that episode of that documentary on the BBC and all subsequent information or supplementary material that is relevant to that episode can be stuck onto that page at any point in time. Imagine it as being a bit like having an entry in IMDB for that particular radio episode. It’s like creating the basis for an ever growing encyclopaedia of Radio 3 programming, and it should make it really easy to search for information about a programme without getting overwhelmed by dozens of versions of the same page, each containing little odds and sods of information, none of which are aware that they’re all talking about the same thing.

Having said all that, lots of programmes don’t ever get repeated on Radio 3. Let us take as an example, “Morning on 3”. This is basically the equivalent of the DJ-led shows that we’re all familiar with and which are common to radio networks the world over. These things are just broadcast live. That’s the whole point! It wouldn’t make any sense for it to be repeated. Some of the music on it will clearly be repeated – just like any popular music radio show, but the programme itself will not. For programmes like “Morning on 3” Drew’s URL structure (which is familiar to all of us who run weblogs) would work perfectly. You can imagine very easily getting to today’s episode of Morning on 3 via the URL bbc.co.uk/radio3/morningon3/2004/06/27/. That would be the perfect weblog-like kind of programme, where every individual entry/episode could only be connected to one moment in time.

But if wouldn’t work if they programme ever got repeated. By definition a programme that gets repeated has been broadcast on multiple occasions in time. Imagine a programme that was originally broadcast on June 27th 1985 and which is then repeated the following evening and then again nineteen years later (tonight). What would be the date-based URL for a programme like that? Well one approach would be to go for the date on which it was first broadcast. But what’s the experience of that for a user? They’ve gone to a schedule page for today (say) and they’ve clicked on the link to a programme that’s on this evening and found themselves with a URL from 1985. A plausible reaction would be to think that you’d got lost somewhere along the line and were on the wrong page. How did I end up here?. This situation gets worse when you consider that since we started capturing programmes on the 4th of June, any programme that was originally broadcast before that date would be assigned a URL based on a fairly meaningless broadcast date…

So, a date-based URL structure would work fine for programmes that never get repeated, but wouldn’t work very well for any programme that did get repeated. Immediately, we’ve got a problem then, because even though 99.9% of the time we know that “Morning on 3” won’t get repeated, we can’t exactly guarantee it. Just recently on the BBC we’ve had an unedited re-broadcasting of the live coverage of the 1979 General Election and the daily re-broadcasting in real-time of the Home Service’s commentary on the D-Day landings. So even those topical programmes we’ve talked about could quite easily be repeated.

But let’s pretend for a moment that isn’t too much of a problem. Let’s also pretend that we can easily distinguish between those programmes that almost certainly won’t get repeated on the one hand (and say they might work with a date-based URL structure) and those that very easily could or will get repeated on the other (say anything that’s pre-recorded before it goes out on air). What kind of URL structure should we use for the latter?

One obvious and simple answer is that we should use episode numbers. The Radio 3 show Composer of the Week is broadcast each weekday around lunchtime and then is repeated the following week at midnight. This means that there are two episodes broadcast on each day (another place where date-based URLs might get confusing or seem broken). If we used episode numbers, however, that wouldn’t be so much of a problem. So you can imagine the URL being something more like bbc.co.uk/radio3/cotw/episode/2345. This would allow you to predict sequence and order and would make the URL structure nice and hackable by users. Except then you have to think about what you should base that episode number on. Should you base it on the definitive numbers for that episode – ie. the ones that the makers of Composer of the Week use? How should you source that number? Do you trust that numbering scheme to be consistent and reliable? On the other hand should you start with an arbitrary number? And what happens if your system for determining repeats isn’t fool-proof and you accidentally assign the wrong number to an episode at some point? The worst eventuality would be that you end up with episode numbering schemes that start to wander out of sync with one another because someone pulls and episode or a schedule changes. And then you get gaps in your URL structure, or programmes out of order. Imagine a circumstance where after six months of perfect running you accidentally pick something up as being a repeat when it isn’t… Suddenly that episode has to be reinserted into the scheme somewhere by hand, or you have to change the URLs for any episodes that have been made into pages before you realised. The URLs break or what they point to change, and that whole part of the site stops being human hackable or readable and starts becoming institutionally and forever broken.

Or you could do it by subject for some of the URLs. Again – Composer of the Week is broken into five part weekly chunks. You could have a URL structure for programmes like this which highlighted those divisions: bbc.co.uk/radio3/mozart/part/4 or bbc.co.uk/radio3/mozart/4. Here the problems are potential URL length and namespace issues. And while they might remain human-readable, they’re not machine predictable in any way. So even this kind of URL structure has its problems.

I want to make something clear at this point – each one of these URL schemes could have worked very nicely for that particular kind of programming. But in the end that’s not enough. Because fundamentally as soon as you’ve decided to use different URL structures for different kinds of programming you’re immediately in trouble – because radio programming isn’t a static thing, it changes and evolves – an individual programme brand (say Choral Evensong) might change format, change frequency or be cancelled. Another programme might be created with the same name ten years later. And each week there will be a number of specials and one-offs and schedule fillers (this week on Radio 3 there were around seven one-offs, including tonights zeroPoints) as well as regular short-series or new brands. Suddenly there’s a time-consuming and fairly-skilled job that has to be undertaken every day – which URL structure should this new programme use… And you’re never going to be one hundred percent correct. And so pages are going to be moved and URLs break and all hell will break loose…

Which brings us to the URL structure that we went with in the end and the rationale for it. Our first principle was that in order to stop URLs breaking and to stop the possibilities of human error in assigning URL structures to brands incorrectly (and to deal with the possibility of random repeats et al) the URLs should all follow exactly the same structure. Fundamentally, this meant that date-based URLs had to go out of the window straight away because they weren’t suitable for every episode of every brand. The only URL structure that we could identify that didn’t actually break in any circumstances is one that’s based on an episode number or identifier of some kind. After careful consideration we decided that we didn’t want to give the impression of human readability or order or structure where that structure was inevitably likely to be broken or flawed or mismatched with other identifiers. And we decided that whatever additions to the URL that we made had to be short – it had to be able to be appended onto the end of a brand name without sprawling out of control. More importantly still, we decided that it shouldn’t break any naming conventions already used around the site or make the site harder to maintain.

Which is where ‘pip’ comes in. We’d already decided that we didn’t want to have the episodes sitting in the top directory of the brand. We’re in this for the long-term, and we wanted to make sure that we could guarantee that whatever future changes were made to the content management of the site, however many new things or features were added to it, we’d never have collisions between these features and the episode pages. We decided to place all episode pages into a subdirectory, and after much discussion of what that should be called (episodes – too long, not always an obvious term for a news programme / eps – too likely to already be used and too close to the name of a file format for us to be sure that it wouldn’t overwrite anything at any time in the future etc) we eventually decided to stake our claim on the directory name /pip/ meaning (if you really want to know) nothing more than ‘programme information page’. [PS. In a few weeks time, this directory should contain a list of all the episodes for each brand, meaning that you can hack back the directories and keep going up a level in the site heirarchy from individual episode to all episodes to brand to network to broadcaster.]

With the final part of the URL – the episode number itself – having taken into account all the problems that we might have with sourcing and guaranteeing the integrity of the ‘definitive’ numbers for any given series of programmes, and having considered the problems associated with any and all possible bugs that might emerge (what if two random programmes started to be considered as repeats of each other and had to be broken apart – what URLs to give them? What if the programmes were broadcast out of sequence oor we started running the site halfway through the broadcasting of a run and had to move around the episode numbers later etc) we came to the conclusion that the actual episode number should be a non-human readable short code. After much deliberation we came to the conclusion that a five-character alphanumeric hash would be short enough to not break URLs in e-mail and long enough to give us up to 60 million different identifiers. And of course we’ve kept it as a directory level URL to future proof the URLs against changes in the technology that we’ve used to build the site. (You’ll notice some index.shtml’s around the place, but we’re going to clear that up).

The alphanumeric short code that we’ve got now also opens up a whole range of new possibilities. Because these identifiers are unique across all of Radio 3, we suddenly have a way to point to (and potentially manipulate) every episode that’s broadcast on the network. We’re still looking into the various affordances that this identifier might provide us with and we’ll let you know what we come up with.

So – in summary – we have a URL structure that is eminently suitable for dealing with the breadth and wealth of programming that could come out of a radio network – a URL that will shortly be totally hackable to the extent that each and every level of the directory structure will contain content appropriate to its place in the site’s structural heirarchy ( broadcaster / network / programme brand / episode list / individual episode), and which is human readable as far down its length as is practical. Drew’s quite right – in order to guess the URL for an entry you do need to use the site’s inbuilt navigational systems. However, it’s almost impossible to be able to build URLs for radio programming that are completely human guessable and as reliable and stable as we’re determined to make them.

We’re thinking five to twenty-five years in advance here, making sure that the URLs of pages about radio programmes on Radio 3 could conceivably last as long as the web does. We’re in this for the long-haul…

Categories
Design Radio & Music

The new Radio 3 site launches!

Ladies and Gentlemen, it gives me great pleasure to direct your attention towards the new Radio 3 website, which I (along with a great number of other people from every discipline and from all across the BBC) have been working on for the last few months. The teams that created the site have been among the best I’ve ever worked with and if started naming names I’d be here all week.

But what’s so special about it, I hear you ask? Quite apart from the sterling design work from Paul Finn, we’ve been working with Radio 3’s team to make the site one of the most genuinely web-native sites I’ve ever seen – designed to effectively reflect the station’s programming online in a way that’ll be better for the site’s current users, for search engines and for anyone who would want to link to the site – including (but certainly not limited to) webloggers. Specifically the new site includes:

  • A web page with a stable long-term URL for each and every episode of each and every programme that is broadcast on Radio 3 – a page that will always have basic information upon it, but can also be supplemented with more content by the production teams that actually make the programmes. (Lebrecht.live, World Routes’ “Cairo Nights” etc.)
  • New schedule pages that are persistent and will remain on the site in perpetuity, each item upon which linking through to the specific episode page for that programme – allowing you to navigate to any episode of any show by the date and time it was broadcast upon (particularly useful for helping you to find out what was playing yesterday when you were listening to the radio in the car).
  • Better navigational aids, including the ability to easily see when the next (and last) episodes of your favourite programmes are on, the ability to navigate between episodes of a programme by date, and a full daily schedule on the front page of the site, linking through to every episode.
  • Improved URL structures, easily spiderable pages and nice content-related title tags that should make each page easier to bookmark and find through the BBC’s search engines and search engines across the web.

I could go on – I’m terribly proud of the work that everyone has done on the site and it’s only going to get better over the next few weeks. But good work be damned! The most important thing is that I think it’s going to serve the site’s users better – both existing, and (perhaps) people who’ve never listened to Radio 3 before and can now be exposed to its wealth of programming over the web more effectively than ever before.

PS. Hello to Leigh, Justin, Andrew, Gregory from Radio 3, Paul and Sarah from the Technology and Design team and everyone else who worked on the project: Zillah, Rija, Tim, Mike, Matt B, Paul C, Manjit, Ian, Jason, Tony, Clare, Dan, Webb, Chris K, Simon N and anyone else I might have forgotten about. And a special personal wave to Margaret Hanley and Gavin Bell for being the best creative partners and co-conspirators a boy could wish for. You all rock!

Categories
Radio & Music

On MediaUnbound and recommendations engines…

I’ve been playing with a demo over on MediaUnbound, which is a music discovery engine that runs in Flash and assembles pseudo-radio players that are designed to meet your every musical need. The concept isn’t particularly new, but I have to say I was impressed by the quality of the recommendations and – more importantly – by the process by which the recommendations were made.

Human beings have a tendency towards self-deception and care (to a greater or lesser extent) about the groups of people they are considered to be associated with. They care about how they are being compartmentalised or categorised by those around them and this – for the most part – is the way that most recommendations engines work: demographics, categorisation, association. In real life, people are reticent about revealing tastes that they’re slightly ashamed of and happy to own up to tastes that fit in with popular opinion or with the opinion of the subculture that they most heavily identify. Because of this, telling people what they might like is inherently a judgement by association – and if people aren’t comfortable with the way that the system has ‘judged’ them (either it seems clumsy and overly simple or it judges them to like music or books that are associated with cultures that they find tacky or crass) then they’re simply not going to be interested in hearing what it has to say. That’s as true online as it is when you recommend a song to a friend and they say that they don’t really like “that kind of music”, whether they’ve heard the song or not.

My experience with MediaUnbound has been better than with most other recommendations engines. Like the best LiveJournal quizzes the options you are provided with seem designed to make it a little more difficult to associate the choices you are given with ‘types of people’ you might or might not like. And the results give the impression of being satisfyingly varied between genres, cultures and styles allowing you to determine for yourself which recommended songs you think are central to your recommendations (ones you’re proud of or that you know you like or might find interesting) and which you can self-group as more peripheral (ones you’re ashamed of or don’t like). Add that to a generally pretty reasonable success rate and generally you can’t go that wrong… Here are a selection of some of the songs it thinks I’d like (I’m not going to tell you which ones are accurate or not – judge me as you see fit):

Sonic Youth: Silver Rocket
Porno for Pyros: Pets
David Bowie: Jean Genie
The Third Sex: At Least I Got Some Cool Clothes
7 Year Bitch: Dead Men Don’t Rape
The Pixies: Gouge Away
Spice Girls: Spice up Your Life
Eagle-Eye Cherry: Indecision
Weezer: Pink Triangle
Sleater-Kinney: I Wanna Be Your Joey Ramone
Cadallaca: Two Beers Later
The Breeders: Opened
L7: ‘Till the Wheels Fall Off
Hispana Tim: Sad and Lonely
Modest Mouse: Dramamine
Syrup USA: Vaporized
Tiffany: I Think We’re Alone Now
The Pixies: Silver
Tompot Blenny: Dr.Fitzpiers
Bruce Springsteen: Brilliant Disguise
The Breeders: Fortunately Gone
Confetti: Who’s Big And Clever Now
Razorcuts: Mary Day
Quasi: The Poisoned Well
Shop Assistants: All Of The Time
The Adverts: Bored Teenagers
Bedhead: Unpredictable Landlord
Britney Spears: Oops!…I Did It Again
Weezer: El Scorcho

Categories
Radio & Music

BBC releases Reith Lectures online as MP3s

For those of you who don’t know, basically my job at the moment is to be one-half of a rapid-prototyping and R&D unit with Matt Webb over at the part of the BBC that handles the interactive aspects of the BBC’s Radio and Music output. The department makes all the websites for the various Radio Networks as well as interactive TV stuff, stuff for mobile phones and – of course – the Radio Player. It’s a pretty cool place to work and I’m proud of the work that we’ve managed to get done there (more on that in the next few months, hopefully).

So at the moment I’m particularly proud of the work that the department is doing. Basically Radio 4 do a series of programmes each year called The Reith Lectures, in which they get a notable thinker to come in and – over a series of lectures – expound upon a particular scientific, political or social theme. This year Wole Soyinka, Nobel Prize-winning poet, is talking about Climate of Fear. Normally – like many BBC radio shows – you can listen to them again via the BBC Radio Player. But this year they’re doing something a bit different and I think pretty significant – they’re releasing all the lectures as DRM-free MP3 files for people to download. There’s more about this over at Dan Hill’s site and Matt Jones has written some commentary on it too (Free as in speech). Hopefully it’s the first open distribution of many programmes of this kind – enlightening, significant and weighty pieces of work that actually have the potential to make the world a better place – available for free from the BBC. Fingers crossed.