Category Web development

Entries 72 Total

The problem with breadcrumb trails

Feb 18, 10 9:00 AM

The other day I was chatting with some of the designers at work about secondary navigation and the subject of breadcrumb trails came up. Breadcrumb trails are those bits of navigation summed up by Jakob Nielsen as:

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
Comments (31)

Online information conference

Feb 1, 10 10:50 PM

I’ve really been neglecting this blog recently – apologies but my attention has been elsewhere recently. Anyway, while I get round to actually writing something here’s a presentation I gave at the Online Information Conference recently.

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

Leave a Comment

Lego, Wombles and Linked Data

Nov 20, 09 1:00 AM

As a child I loved Lego. I could let my imagination run riot, design and build cars, space stations, castles and airplanes.

Blue lego brick

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.

Comments (16)

There’s only metadata and URIs

Oct 11, 09 12:40 PM

On the web I reckon there’s only metadata and URIs or perhaps there’s no metadata and only data. Either way the metadata, data/content distinction isn’t helpful.

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

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.

Comments (9)

Humanity Connected

Jul 14, 09 2:50 PM

Digital Revolution, a new BBC TV programme, was launched last Friday. Due to be broadcast next year, the programme will be looking back over the first 20 years of the web and considering what the future might hold. The show will be considering how the web has changed society and the implications for things like security, privacy and the economy.

Tim Berners-Lee. Photograph by Documentally, some rights reserved.

Tim Berners-Lee. Photograph by Documentally, some rights reserved.

Unlike — well probably every other TV programme I’ve ever come across — each programme will be influenced and debated on the web during it’s production. Some of rushes and interviews will be made available on the web (under permissive terms) so that anyone can contribute to the debate, helping to shape the final programme.

To kick all this off the BBC hosted a debate chaired by Aleks Krotoski with Tim Berners-Lee, Bill Thompson, Susan Greenfield and Chris Anderson. The audience was almost as impressive as the folks up on stage a great mix of geeks and journalists, and luckily I managed to wangle an invite (probably because I’ve had a tiny, tiny role on the project).

Anyway… the presentations were very cool, and while I tweeted the best bits on the day I thought I would write up a short post summing it all up. You know, contributing to the debate and all that.

The thing that struck me most were the discussions and points made around the way in which the web has provided a platform for creativity, and the risks to it’s future because of governments’ failure to understand it (OK, the failure to understand it is my interpretation, not the view expressed by the speakers).

I’ve written previously about how the web’s generative nature has helped enable an eruption of creativity, spawning a new economy in it’s wake; and how governments have failed to grasp that it’s the people that use the medium that need policing not the medium itself. But as you might expect from such an illustrious bunch of people the panel managed to nail the point much better than I ever could.

To misquote TimBL: The web should be like paper. Government should be able to prosecute if you misuse it, but they shouldn’t limit what you are able to do with it. When you buy paper you aren’t limited in what can be written or drawn on it, the and like paper the Internet shouldn’t be set up in such a way as to constrain it’s use.

The reason this is important is because it helps to preserve the web’s generative nature. TimBL points out that people are creative, they simply need platform for that creativity, and if that platform is to be the Web then it needs to support everyone, anyone should be able to express that creativity and that means it needs to be open.

As an aside there was a discussion as to whether or not access to the Internet is a ‘human right’ — I’m not sure whether it is or not, but it’s worth considering whether or not if everyone had access to the Web whether it could be used to solve problems in the developing world. For example, by allowing communities to share information on how to dig wells and maintain irrigation systems, information on health care and generally providing educational material. It is very easy, for us in the West to think of the Web as synonymous with the content and services currently provided on it and whether they would be useful in developing countries. But the point really should be if anyone, anywhere in the world where able to create and share information what would they do with it? My hope would be that the services offered would reflect local needs — whether that be social networking in US colleges or water purification in East Africa.

Of course being open and free for all to use doesn’t mean that everything on the web will be wonderful, or indeed legal; no more so than paper ensures wonderful prose because it is open. Or as TimBL puts it:

Just because you can read everything out there doesn’t mean you should. If you found a piece of paper blowing in the wind you wouldn’t expect it to be edifying.

But what does open mean?

Personally I think that an open web is one that seeks to preserve it’s generative nature. But the discussion last Friday also focused on the implications for privacy and snooping.

Governments the world over, including to our shame the current UK Government, are seeking to limit the openness of the web; that is rather than addressing the specific activities that happen on the web, they are seeking to limit the very platform itself. ISPs around the world, at the behest of governments, are being asked to track and record what you do on the web, everything you do on the web. Elsewhere, content is being filtered, traffic shaped and sites blocked.

The sorts of information being collected can include your search terms (pinned to your IP address) and the sites you visit. Now for sure this might, sometime include a bunch of URIs that point to illegal and nefarious activity, but it might also include (indeed it’s more likely to include) URIs relating to a medical condition or legal advice or a hundred and one other, perfectly legal but equally personal bits of information.

Should a government, its agencies or an ISP be able to capture, store and analyses this data? Personally I think not. And should you think that I’m just being a scaremonger have a read of Bill’s post “The digital age of rights” about the French government’s HADOPI legislation.

On the day Bill Thompson (who, by the way, was on blinding form) summed up the reason why when he summed up his hopes for the web thus:

I hoped that the web would help us know our neighbours better, so that we didn’t go and kill them. That hasn’t happened but it does now mean it’s much harder to get away with it – the world will now know if you do kill them.

Governments know this, which is why some now try to lock down access to the Internet when there is civil unrest in their country. And it is also why the rest of the web tries to help them break though.

Few Western governments, would condone the activities of such Totalitarian states. But it is interesting to consider whether Western governments would support North Korea or Iran setting up the kinds of databases currently being debated in Europe and the States. Now they might point out that the comparison isn’t a fair one since they are nice, democratic governments not nasty oppressive ones. But isn’t that painfully myopic? How do they know who will be in power in the future? How do they know how future governments might seek to use the information they are gathering now?

Seeking to prevent snooping on the Internet aside there is another reason why the web should remain open, and it is the reason why it’s important to fight for One Web.

Susan Greenfield quite rightly pointed out that ‘Knowledge is to be found by creating context, links between facts; it’s the context that counts’. Although she was making the point in an attempt to take a swipe at the Web, trying to suggest that the web is no more than a collection of facts devoid of context, it seems to me that in fact the web is the ultimate context machine. (One sometimes wonders whether she has ever actually used any of the services she complains about, indeed I wonder if she uses the web at all).

The web is, as the name suggest, a set of interconnected links. Those URIs and the links between, as TimBL reminded us, are made by people, they are followed by people and as such you can legitimately think of the Web as humanity connected.

URIs are incredibly powerful, particularly when they are used to identify things in addition to documents. When they are used to identify things (dereferencing to the appropriate data or document format) they can lead to entirely new ways to access information. An example highlighted by TimBL is the impact they might have on TV channels and schedules.

He suggested that the concept of a TV channel was limited and that it would be replaced with complete random access. When anyone, anywhere in the world, can follow a URI to a persistent resource (note he didn’t say click on a link) then the TV channel as a means of discovery and recommendation will be replaced with a trust network. “My friends have watched this, most of them like it…” sort of thing.

Of course to get there we need to change the way we think about the web and the way in which we publish things. And here TimBL pointed to the history of the web, suggesting that the next digital revolution will operate in a similar fashion.

The web originally happened not because senior management thought it was a good idea – it happened because people who ‘got it’ thought it was cool, that it was the right thing and that they were lucky enough to have managers that didn’t get in the way. Indeed this is exactly what happened when TimBL wrote the first web server and client and then when the early web pioneers started publishing web pages. They didn’t do it because they were told to, they didn’t do it because there was any immediate benefit. They did it because they thought that by doing it it would enable cool things to happen. The last couple of years suggests that we are on the cusp of a similar revolution as people start to publish linked data which will in turn result in a new digital revolution.

Comments (4)
Follow

Get every new post delivered to your Inbox.

Join 819 other followers