Now until recently I would have said “yes you do need both”, but recently I’ve been thinking that perhaps it’s not quite so black and white.

Before I get into why I think it probably makes sense to backtrack a little and explain the background to the question. After all for many people this question seems odd: why on earth would you need a URI for anything other than the web page, the document?

Library Parabola by Alex Watson, some rights reserved

In the real world we give all sorts of things identifiers: people have passports and National Insurance Numbers; buildings get Post Codes; books ISBNs etc. We do this because it’s useful to be able to unambiguously identify stuff. To be able to point, discuss and share information about things.

On the Internet we have email addresses and URIs on the Web. OpenID for example is predicated on the notion that a person can have an URI to identify themselves. And the Linked Data project gives URIs for not just people, but all sorts of things: people, places, animals, music, and through dbpedia the myriad of things described in Wikipedia.

Once you have an identifier for a thing you can make assertions about that thing. How big it is, where it is (in the real world), when it was created, who owns it, anything. You can also describe how those things relate to other things – this person is friends with this person and works for this company, which is at this address etc.

Now many people will tell you (indeed I probably will too) that you need to distinguish the statements you make about the thing in the real world from the statements about the document. For example, a URI for me might return a document with some information about me, but the creation date for that document and the creation date for me are two different things. And because you don’t want to get confused it’s better to have a URI for the thing and another one for the document making assertions about the thing. Make sense?

For those that are interested there are a couple of different ways of achieving this separation. For the purposes of this post it’s not important to know how to do this, but if you’re interested have a look at this paper by Richard.

But here’s the thing, many people will tell you that this is all too complex and frankly unnecessary, indeed you may well be thinking the same thing right about now.

Some people will tell you that the whole non-information resource thing isn’t necessary – we have a web of documents and we just don’t need to worry about URIs for non-information resources; others will claim that everything is a thing and so every URL is, in effect, a non-information resource.

Michael, however, recently made a very good point (as usual): all the interesting assertions are about real world things not documents. The only metadata, the only assertions people talk about when it comes to documents are relatively boring: author, publication date, copyright details etc.

If this is the case then perhaps we should focus on using RDF to describe real world things, and not the documents about those things.

On the Web there are a number of different ways of making an assertion about a thing (as identified via a URI): you can state how it relates to other things, you can link it to a piece of data (e.g. RDF literals) or you can link it to a document which makes some statements about the thing (e.g. a news article).

The question is: is there much utility in defining non-information resources in this third scenario: do you need URIs for the documents? Obviously they still need a URL so you can link to it and you should make that document available in a variety of representations but do you need a separate identifier for the non-information resource?

I think not.

This is how I’ve started to think about it: RDF is a great way of describing how (real world) things relate to each other and for this you need URIs for non-information resources. And because you’re dealing with real world things (I know documents are real world things too, but going down this path is how we ended up with the confusion we have today) you will hopefully have interesting and useful links to other things, useful chunks of data and links to useful documents about that thing. Those documents could be in any format – they could be an HTML document, a (Flash) movie, MP3 file, even a csv file. The point is the documents decorate the tree they are discoverable via the RDF graph but they don’t need to be published as RDF themselves.

An RDF graph of things is therefore a great way to: discover documents, to make assertions and share what we know about how those things. Or put another way RDF is a way of building a vocabulary to describe how web resources related to real world objects. I my however me wrong and I would be interested to hear what others think.

It’s the classic internet hourglass with signal carriers down the bottom, IP in the middle and applications up top. You can see the World Wide Web perched atop HTTP, one more technical layer in a technical layer cake.

It’s maybe because I’m not that technical but I’ve never really seen the web as a technical layer on top of the internet. In terms of technical design there’s not that much there. The design decisions of the web always seemed more political / ethical than pure technical. So at least in my opinion the web is a political / ethical layer above the internet.

As Ben Ward recently pointed out we tend to obsess on new standards OAuth, OpenID, Contacts, Connect, Geolocation, microformats, widgets, AJAX, HTML5, local storage, SPDY, ‘The Cloud’ and lose track of what the web is actually for. In Ben’s words articles and poems and pictures and movies and music, everywhere! How brilliant is that! Or put in my simple terms the point of the web is universal access to information. Everything else is just window dressing and mostly leads to restrictions. I think just about every blog post I’ve written includes this quote from Tim Berners-Lee. Now doesn’t seem like a good time to break that habit so:

The Web is designed as a universal space. Its universality is its most important facet. I spend many hours giving talks just to emphasize this point. The success of the Web stems from its universality as do most of the architectural constraints.

And that’s more important than any tech spec. The web isn’t politically / ethically neutral and wasn’t designed by people who are / were politically / ethically neutral. Which is why the most important design decision of the web was statelessness and the most important architectural style is REST. Statelessness means everyone has equal access to information regardless of age or gender or ethnic background or physical location or physical ability etc etc etc. Because the web doesn’t care about who you are, only what you asked for.

Which is also why accessibility really matters. Anything that restricts access to information to any one group is bad. Which means accessibility also means mobile views (because that’s the main access point for many people in “less developed” countries) and data views (because for some people the access they want is to the raw data).

And it’s why anything that attempts to impose state on top of the web is, in general, bad. It just adds friction and any friction reduces people’s access to information. So walled gardens, paywalls, anything that requires you to log in, anything that forces you to accept cookies, anything that needs to know something about you before it gives you information.

At the risk of descending properly into freetard territory the other great thing about the web is once you’ve found what you’re looking for nothing is locked down (other than a few clumsy attempts at DRM). More or less anything you find (text, images, a/v files) can be taken away and played with and recontextualised and republished and taken again…

Which sometimes is bad. Like when someone posts a picture of their friend pulling a silly face to flickr. And fails to understand licencing and makes it available for commercial use. And some company takes it, adds a demeaning strapline and posts it on billboards across Australia causing some degree of pain and distress…

But more often it’s a good thing. Because I could search for the TimBL quote above, find it, copy it and paste it in here. And when my daughter does her homework (actually she’s 4 so doesn’t really have any yet) she can go to the web and take a picture and paste it into the story she’s writing. And sometimes she’ll probably steal and sometimes probably give credit but in general what you can find you can borrow and take into your real life and reshape and recontextualise and make new meanings. And that’s good.

And there’s other ways it’s good. The election day Sun front page barely left the presses before pictures of it were winging round the web. And then people took that image, downloaded it (because the web makes that easy – it didn’t have to but it does), modified it and uploaded new versions. Which people commented on and talked about so more people made more versions and talked more about press bias and made jokes. And I think that’s healthy.

There have been occasional attempts to fragment the web. To create an academic space or a commercial space or a copyleft space or a ‘safe’ space. Apple’s shiny iThing app store model is just the latest attempt. Usually the motivations have been honourable. But the effect is always to create a something that’s less free than the open web; to take a public space and turn it into a policed enclosure. Or maybe like a public space in the same way a shopping mall might be thought to be a public space but is owned and controlled and often privately policed. Policing access is dangerous because it removes universality. And policing re-contextualisation is dangerous because it takes away the right to fair usage (my daughter’s homework…). But the people who really do want to steal will always find a way round any form of rights restriction that’s embodied in code and not in community norms. So you punish the “fair users” in an attempt to restrict the real “criminals” who get round the restrictions anyway. And end up building something that just frustrates.

So I really think the web (not the internet which is really just some pipes) is the greatest thing we’ve ever created. More than telly, more than radio, more than newspapers, more than books. Because it’s universal and because it’s open for reuse.

But there are problems. Anything that requires a computer and a phone line (or at least a web capable mobile) can’t quite be universal unless everyone has those things (or lives in a community with shared access to those things.) There’s a lot of talk about digital inclusion, about taxes to fund broadband and about universal access to the web. But it all misses the point. It was never just about having access to other people’s information. It was always about everybody, everywhere having the ability to add their thoughts, the things they know, to the web. Treating digital inclusion as a question of connecting pipes to homes is an easy mistake to make because it follows established patterns of water and gas and electricity and television aerials. But the web was never designed to be a broadcast / distribution mechanism. Digital inclusion doesn’t just mean everyone needs to have a receiver on their roof; it means they need access to a transmitter too. Without the ability to transmit, to publish, people just become passive consumers of other people’s information. And digital inclusion has to include the ability to produce as well as consume.

So physical access is only the first hurdle. Once you’re over that, the barrier to publishing is still too high. Owning your own publishing space means you have to start understanding domain names and DNS and server set ups and code installs and updates. Which for most people is just too difficult. It’s certainly too difficult for me which is why I end up publishing this here (wherever here turns out to be). Luckily “social media” sites arrived to fill the skills gap. But social media is a bit of a misnomer. The web was always supposed to be social and always meant to be open to contributions from everyone. The innovation of social media wasn’t really socialness. From Flickr to WordPress to Blogger to YouTube to Twitter the real innovation was the commoditisation of publishing technology. Now everyone could share what they knew. But at a price.

The most obvious price of commodity publishing is loss of control over your content. In almost all cases the hosting organisation will take a permissive licence on your content:

a worldwide, non-exclusive, royalty-free, transferable licence (with right to sub-licence) to use, reproduce, distribute, prepare derivative works of, display, and perform that User Submission in connection with the provision of the Services and otherwise in connection with the provision of the Website and YouTube’s business, including without limitation for promoting and redistributing part or all of the Website (and derivative works thereof) in any media formats and through any media channels

where for YouTube you can pretty much substitute any website with user submissions from Facebook to the BBC. It means you retain copyright but we we give ourselves so many rights your copyright is virtually useless. Content acquisition on the cheap. It’s a bigger problem than digital literacy because there’s no point educating people about the issues if they still can’t publish and avoid them.

The second major problem is privacy. You’d have had to be living life under stones to not notice that privacy has become the big issue of year. Facebook in particular have gotten regularly flamed for their ever decreasing privacy circle. Now they’re stepping outside the realms of knowing about your social network, your status and your photos and attempting to own the graph of what you like from elsewhere on the web. There are, as ever, arguments on both sides but the only one really worth reading is danah boyd‘s Privacy and Publicity in the Context of Big Data. There’s too much in there to really sum up in a one liner but my attempt would be: privacy issues aren’t about how much information you share; they’re about the gap between your perception of the context of sharing and the reality. Extrapolating from that, once you trust your personal information to “the cloud” you lose control over the context of use. Your data can be meshed with other data in ways you didn’t even begin to anticipate. And the rules around context can be nudged in whatever direction most benefits the cloud service.

It’s like building a giant Tesco loyalty card in the sky. Clive Humby (chairman of Dunnhumby (the people who run the real Tesco clubcard)) once said:

credit-card data tells you how they live generally, the supermarket data tells you their motivations, the media data tells you how to talk to them. If you have those three things, you’re in marketing nirvana

The social media “cloud” seems uncomfortably like Mr Humby’s dream web. And unlike Tesco it doesn’t even pay you for your data. Obviously there are worse fates than being the target of one of Clive’s targeted mail drops. Liberal democracies tend to assume they’ll always be liberal democracies. History seems to suggest otherwise. If the worst were to happen do you really want all that personal data out there outside your control? You might end up with more to worry about than whether your prospective boss sees you drunk on Facebook.

Is Clive’s web the one we really want to build? Or is there a fairer, more distributed solution that allows everyone to share the things they know on their terms? With the power to publish, redact, edit… I’m probably in danger of jumping on Steven Pemberton‘s bandwagon (who’s been saying this for several years now) but until everyone owns and controls their own publishing space we won’t really have built the web. And (with my day job hat on) until “the public” can “broadcast” without fear or favour we won’t really have built public service broadcasting.

I’ll leave with this:

It’s the original logo for the World Wide Web drawn by its co-creator Robert Cailliau. Until Dan Brickley pointed me at it I wasn’t even aware of its existence. The most important point is it doesn’t attempt to qualify the ‘us’; it just means everyone.

In my dream world everybody working with the web in any capacity would have this stapled above their desk. So when all the talk of product planning and sprint planning and deployment and test driven development and check ins and check outs and branded experience and user stories gets too tiring you can look up and remember why we’re doing this.

Well I don’t know about whether such a move by the BBC would have an impact on the market or not (although I agree with Martin, I think it was inevitable that the Trust has swould review the plans), but I do think the BBC could tackle the problem in a different, more open way.

There’s a lot of hype and hyperbole around mobile apps – and in some ways you can understand why, lots are downloaded and some folks are making money from them but I’m not so sure it’s going to last. I suspect that mobile apps are successful for a few reasons:

1. They are hooked into a big marketing push. Apple et al. are all publicising their stores on your handset on the telly, on posters and in papers.
2. The app stores are targeted and people know where to look, the Web could be The Store (as it’s been for other things) but that’s not how regular folks appear to see software nor do they want to dig about for what to install.
3. The Web (mostly) only works when you’re online, apps (mostly) work offline too.
4. Some stuff can only be built as a native app (rather than via the web), probably.

But as phones expose more of their API to the browser, as HTML 5 with its support for offline browsing and other goodies becomes adopted and, as libraries and support become available so the technical and user experience barriers start to become less relevant — it may once again be universally seen as sensible to develop web apps. Of course either the fear of being locked in or being locked out of the relationship with their customer might kick companies along a bit too.

So in the near future we should be able to build web apps every bit as good as mobile apps? Yes, but I would go further: for most of the things the BBC wants to do, the technology is already good enough. And with a web focused mind set you can start to invest in the sorts of things you can only do server side — just look at the sorts of things Google are building: word processors, voice communications, email clients, image recognition, maps etc. I think it’s better to embrace the future than play catch-up with the near past.

But what if I’m wrong and mobile apps are the future of content delivery? Well the BBC could still take a different approach – one where it licensed its content in such a way that others could build apps with its content. Of course, unless things changed, the app would need to be non-commercial and the use of the BBC logo and brand would be protected. Of course the non-commercial aspect might be reviewed under certain circumstances — indeed the BBC already licenses content to third parties both outside and inside the UK via its commercial arm BBC Worldwide, why not online? Although I can’t see any circumstance under which the BBC would allow use of its brand and logo since this is central to protecting its reputation, to avoid this sort of thing.

If the BBC did license its content in such as way as to allow others to build stuff then we might see all sorts of interesting innovation on all sorts of different devices and not just mobiles. Perhaps I’m missing something but I don’t see why the BBC needs to control the entire distribution chain, from encoding to eye balls, when distributing content over IP but not when broadcasting to your TV or radio. The BBC doesn’t make its own televisions nor radios instead it lets the market manage that bit, why not encourage the same sort of thing on the web?

When we started work on Wildlife Finder we designed the site around the core concepts that we knew people cared about and those that we had content about i.e. species, their habitats and adaptations, and we’ve been publishing resources about those concepts since last September. We’ve since published the model (Wildlife Ontology) describing how those concepts relate together. I’ve talked about this work as providing us with the Lego bricks because I also realised that we needed to use those Lego bricks to build stories, to help guide people through the content. Our first foray into online story telling with these Lego bricks are the Collections.

Collections allow us to curate a set of resources – to group and sequence clips and other resources to tell stories like the plight of the tiger or the years work of the BBC’s natural history unit. Silver Oliver has recently written about why he thinks this approach is important, why curation in a metadata driven information architecture – it’s a very good post — you should read it. But I thought I would share a bit about the intellectual framework behind how I think of this stuff. As with most of my ideas it’s not my ideas but one I’ve borrowed from someone brighter than me, in this case Nathan Shedroff who proposed a framework to think about how to build Lego bricks and then things with those bricks. A framework I’ve been using for few years now.

Wildlife Finder provides information by repackaging data from elsewhere – by organising programme clips, news stories etc. around natural history resources and concepts. This is good (I hope) because it provides useful additional context; but it’s not the whole story. In Shedroff’s model this process creates information — by adding context to data by presenting and organising it in a new, useful way. This is really what encyclopedias provide — structured information presented and organised in useful ways.  The next step is to take this information and build stories with it to build knowledge and facilitate conversations.

As I say, with Wildlife Finder, we have started to tell stories by localising the information into Collections, but of course, now we have a unified domain model (which links together programmes and concepts within the natural world) there are other ways in which we can add context and build knowledge on top these resources — in addition to collections. There are lots of ways we can create new experiences, but as you can see from the diagram above, we don’t hold a monopoly in terms of story telling — those that consume the information, our audiences and ‘users’ could also build stories. Although the BBC doesn’t really let people build their own stories other sites and organisations do, notably  Flickr who have a series of interesting approaches to let its users add context to photos through Groups, Galleries, Sets and Collections.

For my part I presented the work we’ve been doing on Wildlife Finder – how we’re starting to publish and consume data on the web. Ed Summers has a great write up of what we’re doing I’ve also published my slides here:

I also joined Paul Miller, Jeni Tennison, Ian Davis and Timo Hannay on a panel session discussing Linked Data in the enterprise.

In terms of Wildlife Finder there are a few things that I wanted to highlight:

1. If you’re interested in the RDF and how we’re modelling the data we’ve documented the wildlife ontology here. In addition to the ontology itself we’ve also included some background on why we modelled the information in the way we have.
2. If you want to get you’re hands on the RDF/XML then either add .rdf to the end of most of our URLs (more on this later) or configure your client to request RDF/XML – we’ve implemented content negotiation so you’ll just get the data.
3. But… we’ve not implemented everything just yet. Specifically the adaptations aren’t published as RDF – this is because we’re making a few changes to the structure of this information and I didn’t want to publish the data and then change it. Nor have we published information on the species conservation status that’s simply because we’ve not finish yet (sorry).
4. It’s not all RDF – we are also marking-up our taxa pages with the species microformat which gives more structure to the common and scientific names.

Anyway I hope you find this useful.

a single line of text to show a page’s location in the site hierarchy. While secondary, this navigation technique is increasingly beneficial to users.

and illustrated on Wikipedia by:

Home page > Section page > Subsection page

For reasons which will hopefully become clear the whole subject of breadcrumb trails vexes me and rather than shout into Twitter I thought I’d type up some thoughts so here goes.

Types of breadcrumb trail

There are 2 main types of breadcrumb trail:

• path based trails show the path the user has navigated through to arrive at the current page
• location based trails show where the page is located in the ‘website hierarchy’

Both of these are problematic so let’s deal with each in turn.

Path based breadcrumb trails

The first thought most people have when confronted by the concept of a breadcrumb trail is Hansel and Gretel. In the story the children were led into the forest and as they walked dropped a trail of bread crumbs. The intention was to retrace their steps out of the forest by following the trail of breadcrumbs (at least until the birds ate them).

The important point is that Hansel and Gretel weren’t conducting a topographical study of the forest. The trail they laid down was particular to their journey. If Alice and Bob had been wandering round the same forest on the same day they might have left a trail of cookie crumbs or even traced out their journey with string. The 2 journeys might have crossed or merged for a while but each trail would be individual to the trail maker(s).

The path based breadcrumb trail is the same principle but traced out in pages the user has taken to get to the page they’re on now. So what’s wrong with that?

If you’re a user experience person you’ve probably heard developers talking about REST and RESTful APIs and possibly thought REST was just techy stuff that doesn’t impact on UX. This would be wrong. From a developer point of view REST provides an architectural style for working with the grain of the web. And the grain of the web is HTTP and HTTP is stateless.

So what does that mean? It means when you ask for a page across the web the only data sent in the request is (HTTP) get me this resource and a tiny bit of incidental header information (what representation / format you want the resource in – desktop HTML, mobile HTML, RSS; which languages do you prefer etc). When the server receives the request it doesn’t know or need to know anything about the requester. In short HTTP does not know who you are, does not know ‘where’ you are, does not care where you’ve come from.

There are various reasons given for this design style; some of them technical, some of them ethical. As ever the ethical arguments are far more interesting so:

The Web is designed as a universal space. Its universality is its most important facet. I spend many hours giving talks just to emphasize this point. The success of the Web stems from its universality as do most of the architectural constraints.

is my favourite quote from Tim Berners-Lee. It’s the universality of the web that led to the design decision of stateless HTTP and the widespread adoption of REST as a way to work with that design. Put simply anybody with a PC and a web connection can request a page on the web and they’ll get the same content; regardless of geographic location, accessibility requirements, gender, ethnic background, relative poverty and all other external factors. And it’s the statelessness of HTTP that allows search bots to crawl (and index) pages just like any other user.

You can of course choose to work against the basic grain of the web and use cookies to track users and their journeys across your site. If you do choose that route then it’s possible to dynamically generate a path based breadcrumb trail unique to that user’s navigation path. But that functionality doesn’t come out of the box; you’re just giving yourself more code to write and maintain. And that code will just replicate functionality already built into the browser: the back button and browser history.

It’s possibly also worth pointing out that any navigation links designed to be seen by a single user are not, by definition, seen by any other user. This includes search bots which are to all intents and purposes just very dumb users. Any effort you put into creating links through user specific path based breadcrumbs will not be seen or followed by Google et al so will accrue no extra SEO juice and won’t make your content any more findable by other users. Besides which…

…it’s really not about where you’ve come from

One of my main bugbears with usability testing is the tendency to sit the user down in front of a browser already open at the homepage of the site to be tested. There’s an expectation that user experience is a matter of navigating hierarchies from homepage to section page to sub-section page to content page. If this were true then path based breadcrumb trails might make some sense.

But in reality how many of your journeys start at a site homepage? And how many start from a Google search or a blog post link or an RSS feed or a link shared by friends in Facebook or Twitter. You can easily find yourself deep inside a site structure without ever needing to navigate through that site structure. In which case a path based trail becomes meaningless.

In fairness Jakob Neilson points out pretty much the same thing in the ‘Hierarchy or History’ section of his post:

Offering users a Hansel-and-Gretel-style history trail is basically useless, because it simply duplicates functionality offered by the Back button, which is the Web’s second-most-used feature.

A history trail can also be confusing: users often wander in circles or go to the wrong site sections. Having each point in a confused progression at the top of the current page doesn’t offer much help.

Finally, a history trail is useless for users who arrive directly at a page deep within the site.

All this is true but it’s only part of the truth. The real point is that path based breadcrumb trails work against the most fundamental design decision of the web: universality through statelessness. By choosing to layer state behaviour over the top of HTTP you’re choosing to pick a fight with HTTP. As ever it’s best to pick your fights with care…

Location based breadcrumb trails

In the same post Jakob Neilson goes on to say:

breadcrumbs show their greatest usability benefit [for users arriving directly at a page deep within a site], but only if you implement them correctly – as a way to visualize the current page’s location in the site’s information architecture. Breadcrumbs should show the site hierarchy, not the user’s history.

But what’s meant by ‘site hierarchy’?

Hierarchy and ‘old’ media

Imagine you’re in proud possession of a set of box sets of Doctor Who series 1-4. Each box has 4, 5 or 6 DVDs. Each DVD has 2 or 3 episodes. Each episode has 10 or so chapters:

This structure is obviously mono-hierarchical; each thing has a single parent. So the chapter belongs to one episode, the episode is on one disc, the disc is in one box set. It’s the same pattern with tracks on CDs, chapters in books, sections in newspapers…

With ‘old’ media the physical constraints of the delivery mechanisms enforce a mono-hierarchical structure. Which makes it easy to signpost to users ‘where’ they are. An article in a newspaper can be in the news section or the comment section or the sport section or the culture section but it’s only ever found in one (physical) place (unless there’s a cock-up at the printing press). So it gets an appropriate section banner and a page number and a page position.

But how does this map to the web?

Files and folders, sections and subsections, identifiers and locations

The first point is people like to organise things. And they do this by categorising, sub-categorising and filing appropriately, dividing up the world into sets and sub-sets and sub-sub-sets… Many of the physical methods of categorisation have survived as metaphors into the digital world. So we have folders and files and inboxes and sent items and trash cans.

In the early days of the web the easiest way to publish pages was to stick a web server on a Unix box and point to the folder you wanted to expose. All the folders inside that folder and all the folders inside those folders and all the files in all the folders were suddenly exposed to the world via HTTP. And because of the basic configuration of web servers they were exposed according to the folder structure on the server. So a logo image filed in a folder called new, filed in a folder called branding, filed in a folder called images would get the URL /images/branding/new/logo.jpg. It was around this time that people started to talk about URLs (mapping resources to document locations on web servers) rather than HTTP URIs (file location independent identifiers for resources).

Obviously file and folder structures are also mono-hierarchical; it’s not possible for a file to be in 2 folders simultaneously. And the easiest and most obvious way to build site navigation was to follow this hierarchical pattern. So start at the home page, navigate to a section page, navigate to a sub-section page and navigate to a ‘content’ page; just as you navigate through folders and files on your local hard drive. Occasionally some sideways movement was permitted but mostly it was down, down, up, down….

Many of the early battles in Information Architecture were about warping the filing systems and hierarchies that made sense inside businesses into filing systems and hierarchies that made sense to users. But it was still about defining, exposing and navigating hierarchies of information / pages. In this context the location based breadcrumb trail made sense. As Neilson says the job of the location based breadcrumb trails is to show the site hierarchy and if you have a simple, well-defined hierarchy why not let users see where they are in it? So location based breadcrumb trails make sense for simple sites. The problem comes with…

Complex sites and breadcrumb trails

Most modern websites are no longer built by serving static files out of folders on web servers. Instead pages are assembled on the fly as and when users request them by pulling data out of a database and content out of a CMS, munging together with feeds from other places and gluing the whole lot together with some HTML and a dash of CSS. (Actually, when I say most I have no idea of the proportions of dynamic vs static websites but all the usual suspects (Amazon, Facebook, Twitter, Flickr etc) work dynamically.) Constructing a site dynamically makes it much easier to publish many, many pages; both aggregation pages and content pages. The end result is a flatter site with more complex polyhierarchical structures that don’t fit into the traditional IA discipline of categorisation and filing.

The problem is wholly contained sets within sets within sets are a bad way to model most things. Real things in real life just don’t lend themselves to being described as leafs in a mono-hierarchical taxonomy. It’s here that I part company with Neilson who, in the same post, goes on to say:

For non-hierarchical sites, breadcrumbs are useful only if you can find a way to show the current page’s relation to more abstract or general concepts. For example, if you allow users to winnow a large product database by specifying attributes (of relevance to users, of course), the breadcrumb trail can list the attributes that have been selected so far. A toy site might have breadcrumbs like these: Home > Girls > 5-6 years > Outdoor play

There’s an obvious problem here. In real life sets are fuzzy and things can be ‘filed’ into multiple categories. Let’s pretend the toy being described by Neilson is a garden swing that’s also perfectly suited to a 5-6 year old boy. In this case journeys to the swing product page might be ‘Home > Girls > 5-6 years > Outdoor play’ or ‘Home > Boys > 5-6 years > Outdoor play’. If there’s an aggregation of all outdoor playthings there might be journeys like ‘Home > Outdoor play > Girls > 5-6 years’ and ‘Home > Outdoor play > Boys > 5-6 years. If the swing goes on sale there might be additional journeys like ‘Home > Offers > Outdoor play’ etc.

Now it’s not clear from the quote whether Neilson is only talking about breadcrumb trails on pages you navigate through on your way to the product page or also including the product page itself. But the problem remains. If the garden swing can be filed under multiple categories in your ‘site structure’ which ‘location’ does the product page breadcrumb trail display? There are 4 possible ways to deal with this:

• drop the breadcrumb trail from your product pages. But the product pages are the most important pages on the website. They’re the pages you want to turn up in search results and be shared by users. I can’t imagine it was Neilson’s intent to show crumbtrails on aggregation pages but not on content pages so…
• make the breadcrumb trail reflect the journey / attribute selection of the current user. Unless I’m misreading / misunderstanding Neilson this seems to be what he’s suggesting by the breadcrumb trail can list the attributes that have been selected so far. Quite how this differs from a path based breadcrumb trail confuses me. Again you’re serving one page at one URI that changes state depending on where the user has ‘come from’. Again you’re choosing to fight the statelessness of HTTP. And again the whole thing fails if the user has not navigated to that page via your ‘site structure’ but instead arrived via Google or Bing or a Twitter link or a link in an email…
• Serve (almost) duplicate pages at every location the thing might be categorised under with the breadcrumb trail tweaked to reflect ‘location’. For all kinds of reasons (not least your Google juice and general sanity) serving duplicate pages is bad. It’s something you can do but really, really doesn’t come recommended.
• Serve a single page at a single RESTful URI and make a call about which of the many potential categories is the most appropriate.

The latter option can be seen in use on The Guardian website which attempts to replicate the linear content category sectioning which works so well in the print edition into an inherently non-linear web form. So the Chelsea stand by John Terry and insist he took no money article has a location breadcrumb trail of:

whereas the High court overturns superinjunction granted to England captain John Terry article has a location breadcrumb trail of:

At some point in the past it’s possible (probable?) that the superinjunction story was linked to from the homepage, the sport page, the Chelsea page, the John Terry page etc. But someone has made the call that although the article could be filed under Football or Chelsea or John Terry or Press freedom it’s actually ‘more’ a press freedom story than it is a John Terry story.

The point I’m trying to make is that breadcrumb design for a non-hierarchical site is tricky. It’s particularly tricky for news and sport where a single story might belong ‘inside’ many categories. But if you’re lucky…

It isn’t about ‘site structure’, it’s about ‘thing structure’

Traditional IA has been about structuring websites in a way that journeys through the pages of those sites make the most amount of sense to the most amount of users. The Linked Data approach moves away from that, giving URIs to real life things, shaping pages around those things and promoting journeys that mirror the real life connections between those things.

Two examples are BBC Programmes and BBC Wildlife Finder. Neither of these sites are hierarchical and the ontologies they follow aren’t hierarchical either. An episode of Doctor Who might be ‘filed’ under Series 2 or Drama or Science Fiction or programmes starring David Tennant or programmes featuring Daleks or programmes on BBC Three on the 4th February 2010. So again location based breadcrumb trails are tricky. But like The Guardian one of the many possible hierarchies is chosen to act as the breadcrumb trail:

which is echoed in the navigation box on the right of the page:

The same navigation box also allows journeys to previous and next episodes in the story arc:

The interesting point is that the breadcrumb links all point to pages about things in the ontology – not to category / aggregation pages. So it’s less about reflecting ‘site structure’ and more about reflecting the relationship between real world things. Which is far easier to map to a user’s mental models.

Wildlife finder is similar but subtly different. The location breadcrumb at the top of the page is a reflection of ‘site structure’. In the original Wildlife Finder it didn’t exist but initial user testing found that many people felt ‘lost’ in the site structure so it was added in. Subsequent user testing found that its addition solved the ‘lost’ problem. So in an input / output duality sense it’s primarily an output mechanism; it makes far more sense as a marker of where you are than a navigation device to take you elsewhere.

Much more interesting is the Scientific Classification box which reflects ‘thing structure’ (in this case the taxonomic rank of the Polar Bear), establishes the ‘location’ of the thing the page is about and allows navigation by relationships between things rather than via ‘site structure’:

In summary

• We need a new word for crumbtrails. Even seasoned UX professionals get misled by the Hansel and Gretel implications. Unfortunately ‘UX widgets that expose the location of the domain object in the ontology of things’ doesn’t quite cut it
• Secondary navigation is hard; signposting current ‘location’ to a user is particularly hard. IAs need to worry as much about ‘thing structure’ as ‘site structure’
• Building pages around things and building navigation around relationships between things makes life easier
• HTTP and REST are not techy / developer / geeky things. They’re the fundamental building blocks on top of which all design and user experience is built

Two best pieces of analysis, I’ve read, of the iPad and what it might mean for the future of our personal computers come from Jonathan Zittrain and Steve Frank. In the FT, Zitterain points out:

The openness on which Apple had built its original empire had been completely reversed.

[...]

The iPhone’s hybrid model of centrally controlled outside software is already moving beyond the smart phone. This is the significance of the iPad. It could have been built either like a small Apple Macintosh – open to any outside software – or as a big iPhone, controlled by Apple. Apple went with the latter. Attach a keyboard to it and it could replace a PC entirely – boasting plenty of new apps, but only as Apple deems them worthy.

But as s Steve Frank explains the significance of the iPad isn’t the iPad it’s what it means for future PCs.

[today's] computers are general purpose, do-it-all machines. They can do hundreds of thousands of different things, sometimes all at the same time. We buy them for pennies, load them up to the gills with whatever we feel like, and then we pay for it with instability, performance degradation, viruses, and steep learning curves.

But the iPad and the computer’s of tomorrow are:

… task-centric. We are reading email, browsing the web, playing a game, but not all at once. Applications are sandboxed, then moats dug around the sandboxes, and then barbed wire placed around the moats. As a direct result, New World computers do not need virus scanners, their batteries last longer, and they rarely crash, but their users have lost a degree of freedom. New World computers have unprecedented ease of use, and benefit from decades of research into human-computer interaction. They are immediately understandable, fast, stable, and laser-focused.

Steve Jobs claims that Apple took this approach with the iPhone because you don’t want your phone to crash as often as a PC, which is true – I don’t – and that he had allegedly banned Flash from the iPad because “most Mac crashes are due to Flash”. But there’s another, more likely reason, as Michael points out, it could also be:

Apple’s attempting to own / lock in other people’s customer relationship model [...] apple wanna own that relationship [because] it’s about owning the gateway to culture. Owning the point of sale is one thing; owning the point of subscription [is] quite another. Subscriptions map to habbits + hobbies + viewpoints.

Michael’s analysis certainly feels right – but that doesn’t mean that Apple will get away with it. If you look at most iPhone applications there’s really no reason why they need to be phone applications – there’s no reason why they couldn’t be web apps. And while that’s true now it will be even more true as HTML5 becomes more widely adopted. This isn’t anything particularly original, indeed Steve Jobs suggested the very same thing in 2007 when asked about the iPhone SDK – he suggested Safari.

The success of the Apple iPod store has proven that Steve’s view wasn’t held by most people – they wanted to build phone applications and people want to download them. I can understand why, from  a developers point of view the app store is a great market place and it allows you to monitise access to your app in a way that people don’t seem to tolerate on the web; and from an end users point of view it’s convenient and fits with most people’s expectations of what an application is.

But what was true for a phone now might not be true when it comes to the iPad, especially with HTML5′s APIs, including geo-location and offline storage capabilities (supported by Safari), tools such as jQTouch and the increasing awareness of web apps such as Google Docs, Latitude and Voice by the public at large.

It’s true we can’t build all apps as web apps — games in particular will need to remain native iPad/iPod apps and I’m sure those publishers wishing to employ DRM will stick with iBook or iTunes but for lots and lots of content and data centric applications the Web is the open platform we can all use without Apple’s permission.

The presentation is largely based upon the article Michael and I wrote for Nodalities this time last year.

My brother didn’t like Lego, instead preferring to play with Action Men and toy cars. These sorts of toys did nothing for me, and from the perspective of an adult I can understand why. I couldn’t modify them, I couldn’t create anything new. Perhaps I didn’t have a good enough imagination because I needed to make my ideas real. I wanted to build things, I still do.

Then the most exciting thing happened. My dad bought a BBC micro.

Obviously computers such as the BBC Micro were in many, many ways different from today’s Macs and if you must PCs. Obviously they were several orders of magnitude less powerful than today’s computers but, and importantly, they were designed to be programmed by the user, you were encouraged to do so. It was expected that that’s what you would do. So from a certain perspective they were more powerful.

BBC Micro’s didn’t come preloaded with word processors, spreadsheets and graphics editors and they certainly weren’t WIMPs.

What they did come with was BBC BASIC and Assembly Language.

They also came with two thick manuals. One telling you how to set the computer up; the other how to programme it.

This was all very exciting, I suddenly had something with which I could build incredibly complex things. I could, in theory at least, build something that was more complex than the planes, spaceships and cars which I modelled with Lego a few years before.

Like so many children of my age I cut my computing teeth on the BBC Micro. Learnt to programme computers, and played a lot of games!

Unfortunately all was not well. You see I wasn’t very good at programming my BBC micro. I could never actually build the things I had pictured in my mind’s eye, I just wasn’t talented enough.

You see Lego hit a sweet spot which those early computers on the one hand and Action Man on the other missed.

What Lego provided was reusable bits.

When Christmas or my birthdays came around I would start off by building everything suggested by the sets I was given. But I would then dismantle the models and reuse those bricks to build something new, whatever was in my head. By reusing bricks from lots of different sets I could build different models. The more sets I got given, the more things I could build.

Action men simply didn’t offer any of those opportunities, I couldn’t create anything new.

Early computers where certainly very capable of providing a creative platform; but they lacked the reusable bricks, it was more like being given an infinite supply of clay. And clay is harder to reuse than bricks.

Today, with the online world we are in a similar place but with digital bits and bytes rather than moulded plastic bits and bricks.

The Web allows people to create their own stories – it allows people to follow their nose to create threads through the information about the things that interest them, commenting, and discussing it on the way. But the Web also allows developers to reuse previously published information within new, different context to tell new stories.

But only if we build it right.

Most Lego bricks are designed to allow you to stick one brick to another. But not all bricks can be stuck to all others. Some can only be put at the top – these are the tiles and pointy bricks to build your spires, turrets and roofs. These bricks are important, but they can only be used at the end because you can’t build on top of them.

The same is true of the Web – we need to start by building the reusable bits, then the walls and only then the towers and spires and twiddly bits.

But this can be difficult – the shinny towers are seductive and the draw to start with the shiny towers can be strong; only to find out that you then need to knock it down and start again when you want to reuse the bits inside.

We often don’t give ourselves the best opportunity to womble with what we’ve got – to reuse what others make, to reuse what we make ourselves. Or to let others outside our organisations build with our stuff. If you want to take these opportunities then publish your data the webby way.

Linked Data allows you to bind HTTP URIs to an object and to information about that object. This is useful because it’s more useful to talk about real world things — things like people, places and events — the things that people think about. Despite this I have numerous conversations, and have done for years, about what ‘metadata’ to use to describe a document. Typically what this really means is: “what keywords to use so that some technomagical solution can use that ‘metadata’ to personalise/ recommend content”.

Self-portraiture + metadata by Saltatempo's. Some rights reserved

Beyond the obvious — keywords on their own are never going to achieve the sorts of solutions non-technical people imagine — it also forces an unhelpful schism. It makes people think about their content and your metadata, or that metadata is somehow outwith the content they are creating. The trouble is that one persons data is another persons metadata. Is the title of a story metadata or content? Is a news story content or metadata about a real world event? The answer depends on your perspective.

It seems to be that a more useful way to think about things is to have URIs to identify things and then have information/documents/data/metadata/whatever that make assertions about those things. Sometimes those bits of information will be simple data points, for example, for an album release they might include information/metadata about who performed or wrote the piece (obviously linking to URIs to identify the person who did perform or write it, with appropriate predicates) while other bits of metadata might be more verbose: reviews of the album or the lyrics etc. and then again some might be media things (recordings of the album etc.).

And of course because we’re talking about a graph of data, those documents making assertions about a thing can in turn also have metadata/data/documents which make assertions about them, for example, who wrote it, comments about it etc.

Imagine what might happen if a news website took this approach? You would mint a URI for the event (or reuse one that already existed) and then write news stories about it, each with their own URL, each making assertions about that event. It would create a news service which was truly native to the Web, rather than a facsimile of the printed press. Imagine then what it would be like if we could link-up all the news stories on the web which also made assertions about that event. As a user of such a site/ set of sites I could find everything about a given thing (a person, event or place).

Of course, as Dan Brickley, put it:

concepts and events are still social and technological artefacts, but they are designed to help interconnect descriptions of butterflies, documents (and data) about butterflies, and people with interest or expertise relating to butterflies.

In other words what matters is a way of identifying things, a way of interconnecting them and a way of describing them — subdividing those ways of describing them into ‘data’ and ‘metadata’ is unhelpful, or at the very least adds nothing useful.

It is however useful to separate our concept of something from our conception of it. As Stephen Pinkers puts it:

…if you look up William Shakespeare in a dictionary it says “English playwright, lived in the 17th century, wrote Romeo and Juliet and Hamlet, etc.” Is that what the name William Shakespeare means, and is that what the concept William Shakespeare is? That sounds plausible, but it turns out not to be true. If we were to learn that William Shakespeare didn’t write any of the plays attributed to him — let’s say that we learned he didn’t even live in Stratford, that there was a clerical error and he really lived in Warwick. He would still be William Shakespeare, and we wouldn’t posthumously dub the real author of Shakespeare’s plays William Shakespeare. We would just say we were mistaken about what we believed about William Shakespeare.

So what is the concept of William Shakespeare, the meaning of the word William Shakespeare? Basically, when Mr. and Mrs. Shakespeare christened their son William, and the name stuck, and then everyone who knew him, and then who knew someone else, who knew someone else, and passed it down to us — that unbroken chain of transmission of the name from the moment of first dubbing is what gives William Shakespeare its meaning. There’s a sense in which to have a concept necessarily means to be connected to the world through this chain of transmission of a name going back to the moment of first dubbing.

So while I don’t think it’s helpful to separate data from metadata it is helpful separate concept from conception.