Amazon, excess and the future of navigation…

Following a post from Anil (brought to my attention by new co-worker Simon Willison), I’ve been wandering around Amazon’s new tag implementation and my initial impressions are mixed. But I’m going to leave talking about that for another post. Instead I’m going to use Anil’s comments as a jumping-off point to talk about why tags are a good match for Amazon. I’m also going to try to use this post as a way of collecting together the various posts I’ve written on and around this subject.

Anil’s post seems a little suspicious of the Web 2.0 trend for functionality bandwagon-jumping. Or if it’s not suspicion, then maybe it’s just a slightly jaded wry exhaustion at seeing the same buzzwords manifesting across the internet. It’s a feeling that I share, but it’s a necessary side-effect of the way any new technology or approach gets interrogated and finally incorporated into the mainstream. To start off with you have a few trailblazers, then a period of enormous proliferation and clumsy re-implementation by people who didn’t understand the point in the first place, and then gradually powerful models emerge which reabsorb the concepts into the mainstream where they then seem ‘obvious’. Thinking back a few years, I can’t help thinking of the time when people started complaining about left-hand navigation systems. You wouldn’t dream of doing that now, and it’s not because people stopped using them, but because their use is pretty well understood and they’ve become pretty much invisible.

So the question remains – is there value in Amazon getting tags right? Anil thinks so, and so do I. And here’s why: Amazon really has two jobs: (1) helping people discover and navigate through an enormous number of products, and then (2) helping them buy those products. The latter is the more traditionally difficult, but that’s changing. At a certain point once you’ve got the price mechanics and delivery right, then the only place you can compete (and the place where a the internet really comes into its own) is in discovery and navigation.

Amazon knew this from the beginning – and attacked head-on the idea that people fundamentally want to buy the products that are right for them and that if you help them do that (by showing them peer reviews, ratings and as much data as a human can assimilate) then you’ll never go far wrong.

But this doesn’t simply hold true for Amazon – the future of media on demand, products, restaurants, places, holidays and pretty much everything else is one of excess. There’s an incredible, immense, almost impossible amount of information which people need help to explore and navigate. And people will pay for this navigational help – either in cash, or in terms of attention or even by sacrificing some of their privacy. After all, I derive enormous navigational utility from last.fm, and I pay for it with data about the music I listen to.

There’s significant value in navigation. There’s enormous value in discoverability. And anything you can do as an organisation to help people find what they’re after will bring you (or someone else) rewards. The big web search companies were the first to deal with this enormous excess and that puts them in a pretty good position for the next few decades. After that, who knows…

So you have products or programmes and you want to make them findable? The first job in making a service navigable is to identify the core component parts of the service and make them addressable. I’ve talked about that in my piece on Developing a URL structure for broadcast radio sites, and in my piece The Age of Point-at-Things. The next step is to work out some good semantic models of the objects you’re dealing with and how they inter-relate with each other. Once you’ve done that, then you need to start getting all the metadata you can find and glomming it onto the first order objects. There are all kinds of places you can get this stuff. For broadcast media (for example) you can collect information through:

1. The Production Chain – from metadata captured while recording, through to data captured during the editing process, through to data input around the edges by production people, through to the times and dates of the broadcasts themselves.
2. Direct (automated?) analysis of the media – from dynamic ranges of audio, text recognition, speech recognition or from taking first order production information and doing other stuff with it (like working out the average beats per minute or the genre and mood of songs that feature in a TV show
3. Working with your audience or users -looking at the pages they’re going to, how they’re rating shows, describing them, linking to them and the like.

I’ve written tons about this kind of stuff. The work we did on Phonetags was about finding a way to get user-generated metadata about music in a way that was useful for the individual, but would generate more navigational value for the collective in a pleasing virtuous circle. Another piece on How to build on bubble-up folksonomies concerned itself with what becomes possible when you combine metadata about a node with an understanding of the semantic relationships between the component parts. And of course, most recently, the work I talked about recently On the BBC Annotatable Audio project brought many of these component parts together – identifiers, component parts, semantic relationships, audio annotation and structured data.

Fundamentally though, it’s all just a question of understanding the parts, finding ways to collect as much data and metadata as you can get and then analysing and representing that data back to your users in terms of ways of moving through product-space, programme-space or information-space. Even the recent appearance of the API is just an extension of this process. The fact is, APIs have little to do with making it possible for people to get access to the data they’ve submitted to sites or services. What they’re for is to make the core product more useful and more valuable by making it possible for other people to generate new ways of using it. They make the product architectural to the internet, and when the core operation of your business is hosting photographs or selling products, then the API generates ways in which a wider community can create new ways for your users to navigate through your core assets. Everyone wins from such a relationship – users win because they can find what they’re looking for and site-owners win because their service is more usable and open for exploration than they could ever make it alone (and because at the end of every API is a photo they host, or a programme they want you to watch, or a thing they want to sell).

A massive explosion in trustworthy ways of exploring through your data is how you turn a business from a repository or a directory into a web native, 21st century operation. And tags are nothing more than an elegant, scaleable combination of metadata-collection mechanisms with a way of representing that metadata navigationally. It’s an ideal fit for Amazon, if they get the implementation right… Which leaves only one question: did they get it right? Hopefully I’ll write up my thoughts on that later in the day…