Category: Design

Double disclaimer time here – firstly I’m knackered and what follows is badly written and I will edit it later for clarity, punch and drama. The other thing is that – of course – the viewpoints represented here do not necessarily reflect those of my employers (the BBC) who may be much much more intelligent than I.

A few short months after iTunes installed a podcast directory and client comes Yahoo! podcasts, and frankly I think Yahoo are more on the money with this one. The current implementation is a bit clumsy, it’s true – there are loads of things wrong with it – but fundamentally they’ve got the idea that podcasts should be linkable, that social media navigation is fundamentally important and they’ve got that creating a platform for amateur creativity is going to be the thing that really demoncratises the medium and changes audio forever. In this – as in so many other things – they’ve taken a huge lesson from Odeo, which remains the best service on the net (and will blow people’s heads off when they launch their create tools please god sometime soon.

I wrote an enormous post about Odeo a while back, which I never published after a friend said it was ‘a little hyperbolic’. That post contained much of my thinking about the evolution of podcasting and why it was so important (and why Odeo had got it so right as far as it had got so far). I’ll dig that up later and try and get it up by the end of the day. But in the meantime, I thought I’d write a little bit about the design and implementation of podcasting on the Yahoo service (with occasional reference to some stuff that Odeo have done).

The big problem both services have is that they don’t own the audio clients that people will use to listen to (and probably download) podcasts. This unfortunately leaves iTunes with the most seamless (if truncated) experience. Odeo finds some ways around this. Yahoo! Podcasts doesn’t. The problem really is in the web interface elements. You want to be able to subscribe to a show with just one web-based click and have that be reflected with a download to your client-side audio player. Yahoo don’t even try to solve this problem, which brings us the first major problem with their product – the subscription process is a multi-stage horror of downloaded podcast files and double-clicking. It is, frankly, clumsy as all buggery. Odeo’s syncr app is a much more elegant solution – a small client through which you login to their site, and which then downloads your ‘queue’ of episodes. But Odeo’s app still has its problems – much of the great functionality of iTunes is concerned with deleting old episodes and with handling how many shows remain on your iPod. Odeo’s approach makes it harder to use that functionality.

What we really need, it seems to me, is some form of OPML-style file that a client can subscribe to that contains a collection of podcast feeds. The list of your subscriptions (in whatever appropriate format) could then be updated by web clients around the web and have that reflected in your podcast client next time it updated. I don’t know if anyone’s working on that kind of stuff. If you know anything, let me know…

So what else is going on with the Yahoo! podcasts service? Well can I just say to start off with how nice it is to see a Yahoo service that isn’t plain white! If this is a beginning of a trend for their more lifestyle / entertainment brands, then it’s something I’m in favour of. Obviously I’ve seen Yahoo Music before – but this seems to me to be a much more elegant solution – a simple top navigational structure that keeps the Yahoo brand but which could be colour-coded to represent different Yahoo products.

The rest of the page is a bit … busy … though. It’s the same problem I have with the Yahoo homepage actually – there’s just too much damn stuff on it. Or at least (in this case) there’s too lines and gaps and bits of black. It is – however – far from terrible and has take a lot of the lessons from Odeo’s implementation of subscribable programme blocks (complete with preview functionality). It’s just a bit inelegant, and doesn’t have the sheen of an iTunes or an Odeo. But generally, it’s far from sucky. Mostly well done!

One final thing I want to talk about is the implementation of tags. I think this is something that they’ve fouled up – although in this case slightly less than Odeo have. Both services allow users to add tags to describe shows, but neither builds in any impetus to do so other than pure, good-hearted altruism. The individual doesn’t bookmark or collect the shows in question, they just write stuff. There’s little or no (enlightened or otherwise) self-interest being met, and as a result I think it’ll probably fail.

The problem really comes in trying to derive value from the interactions of hundreds or thousands of people. The first rule is that the individual needs to see some value in what they’re doing (ideally personal value). It’s unclear what that value is in either Odeo or Yahoo’s implementation. But the second rule is that you should be able to aggregate individual interactions to create something bigger than the individual. Odeo gets this completely wrong – a show can be given a tag, but only one of any given tag. A bit of metadata that a thousand people think is useful is given the same conceptual weight as a bit of metadata that only one person thinks is useful. The end-result, an easily spammable system with no sense of weighting that could make searching or ranking results easier.

Yahoo tries to fix this by making it possible for a show to be tagged multiple times with the same term, but doesn’t give any clear explanation to people why they should tag a show with a word it has already been tagged by. And because there’s no obvious reason to retag something with a pre-existing word, and because there’s no value to the individual to undertake that tagging other than altruism, I can’t believe it’s going to be enormously successful.

What they need to do instead is think about a generic implementation of tagging (and a representative user interface widget) that a logged in Yahoo user can carry with them around all of their services, showing how an individual search result or review or news story or web page or podcast has been tagged by them personally (and making each tag a link off to browse their annotated collections of stuff), as well as showing the aggregate. That would make much more sense, and could be much more powerful.

[This post takes up some of the themes that Matt Webb, Paul Hammond, Matt Biddulph and I talked about in our paper at ETech 2005 on Reinventing Radio: Enhancing One-to-Many with Many-to-Many. A podcast of that talk is available.]

A few days ago I wrote about Phonetags, an experimental internal service that we’ve been running inside the BBC which allows you to bookmark, tag and rate songs you’ve heard on the radio with your mobile phone. Now I want to talk briefly a bit about one interesting way of using folksonomic tags that we developed conceptually while building the system.

The concept is really simple – there are concepts in the world that can be loosely described as being made up of aggregations of other smaller component concepts. In such systems, if you encourage the tagging of the smallest component parts, then you can aggregate those tags up through the whole system. You get – essentially – free metadata on a whole range of other concepts. Let me give you an example.

In Phonetags, we allow users to bookmark, rate and tag songs. They do so for a combination of personal gain and to add their voice to the collective. But music radio shows can be loosely understood as a collection of songs, and music radio networks can be equally understood as a collection of shows. So if ten songs that are well-rated and tagged with ‘alternative’ and ‘pop’ are played on one specific radio show, it’s quite plausible to argue that the show itself could be automatically understood as being tagged with ‘alternative’, ‘pop’ and that it should be considered well-rated. Similarly if all the shows are equally tagged with ‘alternative’, then it’s likely that you could describe the network that broadcasts them as an ‘alternative’ station.

How you handle the aggregation up the chain is an interesting question. My first instinct is that you would aggregate all the tags for a song, slice off the top ten or twenty and then throw away the rest and all the quantitative information. Then you do the same for all the other songs played in a show, and then reaggregate to see which tags have been played over the most songs. The alternative would be to simply add together all the tags that people sent in during that timeslot, but I think that would skew things towards the popular songs that people tagged a lot and wouldn’t necessarily reflect the character of the show itself. But that’s up for debate.

Another, and perhaps more intriguing, way of aggregating tags up through a conceptual chain would be to view albums as collections of songs and artists as a collection of albums/songs. This would mean that from the simple act of encouraging people to tag individual songs you were getting useful descriptive metadata on radio shows, radio networks, artists and albums:

The upshot of all of this is that you start getting a way of navigating between a whole range of different concepts based on these combinations of tags and ratings. The tags give you subject related metadata, the ratings give you qualitative metadata and from this you can start finding new ways to say, “If you liked this song, you may also like this album, network, album or artist“. You can start to generate journeys that move you from network to that networks most popular songs, through to the best albums on related themes (or which conjure similar moods or associations even if they’re by radically different artists) and so on.

And because you have a semantic understanding of the relationship between concepts like a ‘song’, an ‘album’ and an ‘artist’ you can allow people to drill-down or move up through various hierarchies of data and track the changes in an artist’s style over time. For me, this is a pretty compelling argument that understanding semantic relationships between concepts makes folksonomic tagging even more exciting, rather than less so, and may indicate a changing role for librarians towards owning formal conceptual relationships rather than descriptive, evocative metadata. But that’s a post for another time.

Are there other places where this kind of thing could be applied? Well, off the top of my head I can’t think of anything useful you could do with photographs, but I think folder structures on web-sites could prove an interesting challenge. I’d be fascinated to see if it would be possible to find well-structured websites with usefully nested folders and to aggregate tags from the individual pages up to section homepages and eventually to the site homepage. A little over a year ago I wrote about URL structure we developed for broadcast radio sites at the BBC built on the Programme Information Pages platform which you can see in action on the Radio 3 site. The URL structure mirrored a formal heirarchy much like the song / album / artist one – except for episode / programme brand and network. I’d be fascinated to know whether you could get a useful understanding of what Performance on 3 was about by aggregating all the tags from each of the episodes contained within its folder, and whether aggregating still further up to the frontpage of Radio 3 would give you a good description of the network’s philosophy and approach. One for Josh at del.icio.us, perhaps?

Now it’s over to you guys – can you think of any other heirarchies or places where we could encourage the tagging of the smallest practical component part and then derive value from aggregating up the semantic chain? Could the same thing work for non-heirarchic relationships? Anyone?