Email
Like
Liked ×
Save
Private Content
Embed
Loading embed code…
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.
Loading

+ Follow

Beyond the Polar Bear

by Mike Atherton

32,313 views

Accessibility

View text version

Upload Details

Uploaded via SlideShare as Microsoft PowerPoint

Usage Rights

File a copyright complaint

76 Embeds 3,616

http://reduxd.com	893
http://www.ide-smith.co.uk	320
http://ebiinterfaces.wordpress.com	276
http://www.reduxd.com	253
http://biodiversitydata.blogspot.com	231
http://lanyrd.com	227
http://storify.com	167
http://library.iasummit.org	152
http://www.scoop.it	134
http://www.linkedin.com	131
http://thatssodigital.tumblr.com	108
http://paper.li	101
http://www.byrichardpowell.co.uk	100
http://biodiversitydata.blogspot.fr	67
http://webexpo.cz	63
http://webexpo.net	40
http://understandinggroup.com	36
http://dannydenhard.com	28
http://jmorse.posterous.com	27
http://feeds.feedburner.com	20
http://eventifier.co	15
http://twitter.com	13
http://biodiversitydata.blogspot.co.uk	11
http://rocketscience.brookellingwood.com	11
http://www.techgig.com	11
http://blackboard.du.edu	10
http://www.finditshareit.com	10
http://dianas.tumblr.com	9
http://biodiversitydata.blogspot.ru	8
https://p.yammer.com	8
http://s1m0neresources.tumblr.com	8
http://naturalsolutionswp.wordpress.com	8
url_unknown	7
http://a0.twimg.com	7
http://linkeddata.uriburner.com	7
http://www.slideshare.net	7
https://twitter.com	6
http://www.mongodb.org	6
http://biodiversitydata.blogspot.ca	6
https://abs.twimg.com	5
http://stud.inf.ucv.ro	5
http://biodiversitydata.blogspot.com.au	4
http://biodiversitydata.blogspot.com.ar	4
http://notdespairing.wordpress.com	4
http://christineharmel.bo.lt	3
http://safe.tumblr.com	3
http://www.onlydoo.com	3
http://biodiversitydata.blogspot.in	3
http://sprmario.posterous.com	3
http://biodiversitydata.blogspot.it	2
http://www.petrobras.com.br	2

More...

Statistics

Likes: 159
Downloads: 0
Comments: 17
Embed Views: 3,616
Views on SlideShare: 28,697
Total Views: 32,313

1–10 of 17 previous next Post a comment

Takanobu Shuji, Infomation architect at Selfemployed Thank you very much for sharing great material!! For your instance, I reached ere from the link below. http://ux.stackexchange.com/questions/17124/domain-strategy-from-a-ux-perspective 1 month ago
Are you sure you want to
Jamie Hanratty These were great slides to read, despite not hearing/seeing the talk. Thank you. 2 months ago
Are you sure you want to
Moira McGregor at Fopp Despite currently being taught from the Polar Bear book (whoops!), your talk given yesterday in Brighton made a lot of sense and helps to make the bridge between ideal world of text books to the real world of unwieldy content.

Cheers

Moira 1 year ago
Are you sure you want to
Fredric Landqvist, Researcher at Dept. Applied IT, Gothenburg University / Chalmers A very well set-up journey beyond the famous Polar Bear book we all use daily. Pragmatic and detailed, with great illustrations that match up. Would love to listen to the talk as well.... 1 year ago
Are you sure you want to
Tim Holden, Copywriter at TBWA\MAL Thank you for the talk. Loved seeing the Mythology engine stuff up there. Is there any news on its progress? I mentioned it a few days ago when I was looking at the beta BBC homepage.

http://nothingelseis.com/articles/bbchomepage/ 1 year ago
Are you sure you want to
Dan Brickley, Other at FOAF project, SpyPixel Ltd., misc. I'm at ESWC SemWeb summer school and this has just been recommended - so while I'm here I'll also plug http://www.bbc.co.uk/blogs/radiolabs/2009/01/how_we_make_websites.shtml which is close in topic and well worth a look too. 2 years ago
Are you sure you want to
jhourcle I thought this was the best talk at the IA Summit ... but this was also one of the few that was specifically IA (information architectore), and not UX (user experience), project management, or some other related topic.

It was the only talk (at least that I attended) that specifically talked about how better structuring of the information lead to improved findability, even though the techniques went against what most SEO folks are going (eg, URL stuffing). 2 years ago
Are you sure you want to
ajniemin For an UX presentation the text in the slides should be more readable. More contrast and bigger font sizes needed there imo.

Awesome presentation otherwise. Thanks! 2 years ago
Are you sure you want to
rowolo Great thoughts and insights! Thanks. 2 years ago
Are you sure you want to
jonweber I wish this was 'downloadable' for ease of reading it offline... 2 years ago
Are you sure you want to

1–10 of 17 previous next

1.1. For the past thirteen years, “the polar bear” book by Lou Rosenfeld and Peter Morville has been an invaluable constitution for our industry. Maybe today we’ll be drafting a few amendments to that constitution.
You see, a lot has happened in that time. Google happened. Facebook and Twitter happened. Smartphones happened. IPTV happened. The paths to content have splintered, and the way we access information has become more organic and ubiquitous.
Today we’ll look at how the BBC now makes websites that better represent their core business,better fit how the web is today, and deliver on the mission they’ve had since 1922 to inform, educate and entertain. My colleague Michael Smethurst can’t be with us today, but he’s here in spirit; when we get to the science bits, it’s all him and his team. We’ll go on to discuss how you too can apply these principles, and if there’s time I’ll include the customary IA Summit rant about how you’re all doing it wrong.
And on that note, I should say that any implied frustrations with UX practices, whether intentional or incidental, are entirely my own.
2.1. As the polar bear teaches us, information is hard to categorise. We have a raft of tools and techniques to help us, from card sorts to use cases to content inventories, but at the end of the day, when we draw our taxonomical site map we know we’re making a series of compromises and workarounds to ‘best fit’ the limitations of that structure. In many ways, taxonomical site design hasn’t really moved on from the traditional library science approach where a physical book has to go on one physical shelf. In the last few years we’ve done things like tagging to expose more subtle facets of information and thus unlock more user journeys, but still information architects are largely limited to saying that one thing is more or less specific than another thing. So we do our card sorts and we label our boxes and we cross our fingers that our homepage superordinate categories will give some clue as to the goodies within, then get frustrated in user testing sessions when people demonstrate that they don’t visit our homepage at all, but deep link to our content from Google.
2.2. At the BBC no-one knows whether to refer to website singular or websites plural. In theory, our website is bbc.co.uk, but the reality is that small BBC web presences popped up over the years like tents on a hillside, and still in user research we hear people refer to…
...the news site, or the iPlayer site, or the CBeebies site.
The BBC publish a massive amount of content, 1500 programmes across its 8 national TV channels, 10 national radio stations and over 40 local radio stations every day. Over the years its been difficult therefore for a large organisation to represent its offering online, and there have been political, cultural and technical hurdles to overcome, and consequently they ended up building a web presence in just about the most expensive and inefficient way possible: teams working in silos, hand-cranking out pages all over the place. For years the BBC site or sites just weren’t very joined-up, have suffered from repetition of content (which is a curse of such a large and fragmented corporation), pages that aren’t linked to so have terrible SEO…
…pages that get mothballed (whatever that means) because the programme they supported isn’t on anymore, or removed completely throwing 404 errors…
…and most recently a government-appeasing diktat to reduce the number of “top-level directories” by half. Weird, for something that’s supposed to be one website, and all a bit embarrassing for a broadcaster regarded as the best in the world. Recently, as part of a strategic review, the BBC has pledged to cut its spending online by 25%, which will lead to a major loss of resource and so force a new, more efficient way of publishing content.
2.3. At the BBC, and arguably even beyond, the grey squirrel of user experience design is gnawing the legs off the red squirrel of information architecture. The focus is now squarely on the presentational and interaction elements of UX, and service design projects that start with beautiful, but largely imaginary page mockups. In a great metropolitan company right now, a senior executive is being seduced by a Photoshop comp that may or may not be buildable.
The perception is that rapid prototyping, by which I mean faked-up prototypes, are cheaper and easier to develop than anyone getting their hands dirty with code. So these things get incubated in a vacuum, which come to think of it isn’t healthy for anyone. UX design and prototyping commits a lot of product decisions, sometimes unwittingly, before anything gets in front of a real user, or before software developers are consulted about the art of the possible.
LINK TO NEXT BIT: So at the BBC, this whole web thing needed a bit of a rethink, and some rebel forces, striking from a hidden base, won their first victory against the evils of siloed thinking. They recognised the power of the semantic web; and how it could be used to build better bridges between content, extend user journeys and stitch all of the BBC’s offering into a single, extensible framework. Its a process that allows great things to be done quickly with real, not mocked-up content, and brings UX, software development, product management and users as equal partners to the process.
3.1. Usually when we’re doing some heavy IA, we’re trying to think about how our subject breaks down, and at the same time, how the website should be organised. We’re like librarians, finding the right boxes to place our stuff in, so we might do a card sort, and then we might end up with a box for photos, another for videos and a third for news. Two problems here; first is, that as we know, web documents don’t fit neatly into prescribed categories. The relationships between bits of knowledge are much richer and graph-like than just ‘broader and narrower’. The second problem is that when we think about our favourite subject, we’re not thinking of documents at all; we’re thinking about things.
Things. Real-world things. Last time at this conference I spoke about Disney theme parks. Disney World is a real place, in a real location. It has some theme parks in it. Each park is divided into lands, and as Disney fans know have an iconic weenie. The lands have attractions, each of which were created by someone, and might be based on, say, a movie. Then there’s the hotels, that have restaurants. Oh, the lands have restaurants too. The restaurants have meals, which might be associated with a character. And that character could be also be based on some prior art.
3.2. So in looking to represent a subject online, we think first about the things in that subject, long, long before we ever think about web pages. At the BBC the book Domain Driven Design has become the new bible. It proposes not a taxonomic, but an ontological model for modelling subject domains, called, appropriately enough, a domain model. It’s really just an attempt to accurately capture a user’s mental model about a subject; identifying the most important things in that subject, and the sometimes complex relationships between them. Domain modelling is now the first step for building new web products at the BBC, and is the key to an approach that has seen us move away from a process that starts with wireframes and Photoshop comps, to one that starts with a logical model of the subject we’re covering and working upward from there.
3.3. This is a simple domain model for music. In fact there are various ways to present a domain model. Sometimes its a simple diagram, other times a more complex entity relationship diagram, but always the point of it is to define the most important things and connect the dots between them. A recording artist creates several tracks, and a track might be released in more than one place; a single, an album, or greatest hits. We define release types to cover these kinds of releases, each of which has a date of release associated with them and a record label they were released under. You can start to see how describing this process through a simple hierarchy would be difficult.
3.4. The first step in building a domain model is to speak to people who really know their onions. Let’s call them domain experts. They don’t need to know anything about web design, just their specialist subject. Maybe you have some in your company, or if you’re freelance, its a great way to give clients direct influence over product design before you start to hate them. Get your expert to describe, or better yet, sketch their world to you. Ask lots of questions and uncover the hidden complexities. When we talk about a soccer match, how is that organised? Do matches exist in isolation, or are they part of a bigger competition? Soon you’ll find out what the experts think are the most important things and the relationships between them.
3.5. But we’re all about user-centred design, so your next conversation is with end users. After talking to the experts you’ll have at least a prototype understanding of the subject, but you may find users have a simpler or just different view of the world. It’s more important to get the model, and specifically the language, right for users. After all they are the ones who’ll be searching on Google and hoping to access your content according to their own mental model.
Again, sketch their world back to them. Identify the key things and figure out the relationships between them. Remember this isn’t yet about web pages, just modelling the subject itself.
3.6. Now we know from all those card sorting exercises we’ve done over the years that labelling things is hard. And defining conceptual differences is even harder. I like Wuthering Heights. But what do I mean by that? That I like the book? Or maybe I like the movie? Or maybe even the Kate Bush song. If it’s the book, am I thinking of a specific edition of the book, because all of these are different things. Or maybe its the overall concept of Wuthering Heights that I like, distinct from any specific manifestation; the creative work, if you will. In mapping a mental model you find that some things are harder to quantify than others. Outside of domain experts, people may find it hard to name things appropriately, even if they can appreciate the inherent differences between, say, The Beatles’ album Rubber Soul and all the other things that could also be said to be the same thing.
3.7. But defining the damn things is vital if you want to be able to point at them. To take our Wuthering Heights example, I expect most people wanting to buy a copy of the novel are thinking in general terms; not of a specific edition. Yet Amazon have no concept of a ‘cultural work’, so to them two different editions of Wuthering Heights are really as different as a copy of Wuthering Heights and a copy of Pride and Prejudice. When you Google Wuthering Heights you get a bunch of different Amazon results, which isn’t so great for their Googlejuice as one ‘master’ Wuthering Heights aggregation page would be. Plus they’ve had to put hacks in place to merge reviews together, so often you’ll find, say, complaints about the quality of a DVD version of a movie on the product page for the Blu-Ray. So we think about the basic level at which people are searching for things, and try to first represent a ‘canonical’ version of that concept.
3.8. Actually this touches on some cognitive science, if you know your Lakoff. Basic-level categories are the level at which we most readily identify things. They are the simple names we give things as kids; Dog, not Husky or Mammal. Car, not vehicle or Mustang. Tree, not Oak or plant, and we somehow see them as more important, or ‘cognitively real’ than higher or lower-order categories. Not only that, but that within a category there are what’s called ‘prototypical examples’; so if I asked you to name some furniture you might say chair or table, and even within chairs, there are probably things you’d think of as more chair-like. If we were playing Family Feud and I said name a type of bird, you’d probably say robin before you’d say ostrich.
In domain-driven design your goals is to get a ubiquitous language; an agreed lexicon used by everyone on the project team, which means in turn that the same terminology is used all down the stack from database tables to CSS classes to menu options. This way everyone on the project has a shared understanding and things don’t get lost in translation.
3.9. So where you stop? What are the limits of your domain? When creating your domain model, you may find that some things, like people or places branch into whole other subjects. This could mean a link between your model and someone else’s. Often the BBC domain models link into the FOAF (Friend of a Friend) ontology, which has been created to describe the relationships between people. The BBC music site makes extensive use of MusicBrainz, which describes all the releases made by recording artists. It may even be that other parts of your website deal with some of your domain objects, in which case its okay to link out to these pages. The point is not to replicate content unnecessarily, and don’t reinvent where someone else has already done the thinking.
3.10. But the good news is that you don’t have to get it right first time. As we’ll go on to see, the domain-driven process is heavy on iteration, right down to this fundamental level. Things change all the time; either new requirements come in mid-way through a project, or once your site has launched you’ll find that the things you thought were important aren’t proving so popular. The chances of you getting the model right first time are slim.
LINK TO NEXT BIT: Domain modelling is a big deal; bigger than we can cover in this quick run-through. The Domain Driven Design book is a coffee table read. Heck, it could be a coffee table. Hopefully this gives you some idea of the process that the BBC has put into practice. Let’s look at that practice now; first with how the BBC Programmes team met a long-held ambition: a way to make a permanent page for every one of the 1000 programmes the BBC puts out across TV and radio every day.
4.1. TV is a messy business, and was never designed to be put into much order. Sometimes one-off shows become the pilot for a series. Sometimes, the schedulers will decide that a 2-part story is like a mini-series within a series. Our general sense of a ‘show’, like Glee or The Wire or Silent Witness is what in the BBC they call a brand. It’s a different thing to a particular series (or season) of that show. Silent Witness, unusually, has sub-series within it, and of course individual episodes. And different versions of episodes, most commonly the version that goes out with sign-language.
Sherlock was a popular show recently, but it only had three episodes. What does that make it? Can we even answer that until we know its future? For now, Sherlock is a brand with some episodes, and it has an associated channel – BBC One – that it aired on.
But if there are more episodes of Sherlock made, how would that change? Maybe it would become a full series, or more likely, the new episodes would become series 2, which means we’d then have to define a series 1, which changes the current hierarchy of things. It could also switch to another channel. It’s problems like this that the Programmes team have to make sense of.
4.2. By talking to programme schedulers, the Programmes team came up with a domain model that describes the main objects within the domain, and the relationships between them. The brand is the highest level object. This is, if you like, the overall ‘cultural work’; something like Doctor Who. Well, Doctor Who has a number of series, though any fans will know that even that gets complex depending on whether you started counting in 1963 or 2005. Each series has some episodes, each episode may exist in different versions, and all of these have either been broadcast at some time, or available on-demand at some time. Collectively we call these things ‘programmes’, and they go out on (and in the possessive world of media, sometimes want to be associated with) ‘services’, which was an attempt to find a word that grouped TV ‘channels’ and radio ‘networks’.
4.3. That was the basic model, but it’s not much use without data. There’s tons of business data available about programmes; episode titles and synopses, broadcast dates, that kind of thing, perfect for populating this model. Only really not perfect, because was built for production staff to use around things like compliance and rights management, wasn’t consistent, and was never intended to be user facing. It took a lot of work and workarounds for the web team to whip this data into the right shape. And that’s an important lesson in itself; just as you know better than to replicate your company’s org chart in your site structure, don’t be a slave to the inherited data model, because often it just won’t be right, or at least complete.
4.4. With the model now populated, only then did the team start to work on anything resembling web pages. Because of the things and relationships already put in place, outputting a ton of linked webpages became relatively straightforward and for the first time in web history, a broadcaster had represented all its output accurately, persistently and scalably on the web. The approach generated one single web page for each ‘thing’. One page per programme, with one URL to locate that programme. Why is this important?
Just look at the success of Wikipedia, which has many thousands of single pages, each discussing a single topic.
Having a single URL makes it easy to point at that thing, which makes it easy to link to, and so easy to blog about and tweet about and generally share. Internally, it means content teams know exactly where to put their multimedia niceties to enhance that one page. And it focuses Googlejuice squarely on a single location, making it easier for people to find.
4.5. URI design is an important, though often overlooked part of the user experience. We use some guiding principles in making nice web addresses: they should be persistent (in other words, always reliably there), hackable (so people can chop them back at the slashes as a means of navigation), and preferably human-readable (since that’s just nice). Balancing those things can be tough, but as the hierarchy of needs shows, the most important one is persistence…
…after all as Tim Berners-Lee says, “Cool URIs don’t change”. Your web address is an implicit contract with the people who link to or bookmark your site.
But how do we maintain persistence with content that is subject to change? What do we need to look at. First let’s get rid of the extension - no-one cares about the technology, and one day we might change technology anyway. Is keeping the series part okay? Well as with Sherlock, that could change, so let’s take that out too. BBC One is the network, but one day this show might move to another network. The name Sherlock is unlikely to change, but across dozens of TV and Radio stations it might not be the only show with that name, so let’s lose that too. Which leaves just episode1, and that doesn’t make much sense at all.
So in fact, the URL format used leaves just about the only thing we know for sure; it’s a programme. The unique ID lets us pinpoint that programme. It leaves a URL that is only partly human-readable, but we’ve at least made pretty sure it’s going to be persistent.
4.6. So the Programmes site launched with a whimper, quietly giving people URLs to link to when referring to any BBC programme…
…from the worthy and educational ones that make good use of our public funding…
…to the ones people actually enjoy watching. No longer would only the popular ‘brands’ get a web presence. Did it set the web alight? Not at first, at least not to people outside the IA community. Because while the modelling was a major technical feat, content really is still king and beyond having episode details and air dates, the Programme pages were light on delight. They called it a skeleton in need of muscles and skin. Pretty soon though, programme content teams took a pride in having their own pages to embellish, and things got a lot richer.
First by embedding the programme itself onto the page (pretty cool, thanks to iPlayer - the BBC’s equivalent of Hulu) and then production stills, behind-the-scenes clips…
…even track listings for the music used - which got very cool when the team made those things clickable and linked to the Music domain.
4.7. Programme pages have become the standard for representing programme content on the site. Gone are the days of siloed teams making siloed microsites that were full of glory while the TV show was hot and then left to wither when it was not. Instead there is a completely scalable ecosystem that comprehensively represents the BBC’s massive output. Still, people do quite like those programme microsites, so content teams have been given the tools to make branded support sites using Programme pages. And of course you still need URLs you can put on the side of a bus, but thanks to some polite web redirects our on-air announcers don’t need to say “just go to www.bbc.co.uk/programmes/b006ml0g”. The experience is a lot like the old microsites (maybe losing the downloadablewallpapers and Flash games - though you could even have those if you really wanted) but instead of being siloed, they’re stitched into the wider fabric.
We’ve even started to explore modelling things within the content of a programme like characters, locations and plot events, with a view to recontextualising stories beyond the confines of the episode.
LINK TO NEXT BIT: But modelling programmes was only the start of the story. On a business and content stack largely built around AV content, once you can point to programmes, and even to individual bits of them, you’ve unlocked a ton of content you can then use to make more products.
5.1. The BBC Food site was always doing okay, but never that great. Its a recipe database, a bit like Epicurious, and justified by the fact that the BBC make a lot of cooking shows, and people needed to go somewhere to get the recipe. Well I don’t know about you, but if I want the recipe for apple crumble, there’s only one place I go first - and that’s Google. I’ll get back a ton of recipes and I’ll probably pick one from the first couple of results. SEO therefore is hugely important in the totally saturated recipes market, and frankly the SEO wasn’t great.
They had apple crumble alright; too many of them which splintered our Googlejuice. How then could SEO be improved, and more value from the content be unlocked?
5.2. The Food team went back to consider the things people think about, and in this case the things that people are searching for. In my modern, sensitive view of the world, men think about Nigella while women think about chocolate. When he thinks Nigella, he thinks chocolate cake. Meanwhile she’s thinking of a show she saw this morning that had a chocolate cake recipe on it. Great minds think alike.
This is how that looks as a simplified domain model. At it’s heart is the recipe, which is written by a chef, and has some ingredients – and sometimes, recipes, like chicken stock or corned beef, can make something then used as an ingredient in another recipe. It might have an associated technique, such as how to knead dough or scoop out lobster brains, and because this is the BBC, the recipe has come from a programme. Then there’s the all-important dish, which we’ll come back to.
Now think about the content of a recipe; a lot of this data is in there, but usually its baked-in as static, unexploitable text. Through applying domain modelling, the Food team were make each ingredient and even some techniques into a pointable thing, and so able to move the site from ‘sauces’ to ‘resources’. Oh yes.
By modelling around the structure of a recipe, they unlocked new ways of exploring food and cookery. “Show me all of Nigella’s cupcake recipes”. “Show me what I can do with this zucchini”.
5.3. Most important was the concept of the ‘dish’; another example of having a master canonical ‘work’ - a mental image of Spaghetti Bolognese if you will, from which individual recipes could be hung. The dish gave something for people to point at, consolidating all the Googlejuice toward a single URL. It gave a more stable structure too; recipes are more rights-protected than you might think, but even when a specific spaghetti recipe had to be removed, the canonical dish stood firm.
The recipes were carefully selected and named by studying the search analytics. We used to have the oh-so-fancy name Vichyssoise, until we found out people were searching for plain old leek and potato soup. All the photographic love and fancyness was quickly migrated to Leek and Potato soup.
5.4. So this focus on unlocking many new and interwoven routes to content, along with a big push on SEO-friendly language massively boosted both internal link density and external linking. Traffic to the Food site has doubled. BBC Food now has 20% of the UK recipes market. 150,000 extra search users each week. Let’s look at those users for a minute and ponder something else.
Last year the site saw a 20% rise in access from mobile devices…
70% of traffic comes directly to recipe pages from Google; far more than from the BBC Food homepage, and I’ll bet those referral figures are similar for a lot of other sites too.
So which is the real BBC Food homepage? Web, Mobile or Google? The old rhetoric that your homepage is your most important page is no longer true. According to the traffic, at best 30% of effort should be on the homepage, and 70% on your thing pages.
LINK TO NEXT BIT: Finally, let’s look at what is perhaps the standard bearer for domain-driven design at the BBC. A site whose subject could be said to inherit a domain model, and needs more data than even the BBC can provide.
6.1. Wildlife Finder is a showcase for natural history footage, something the BBC has a reputation for of being the best in the world. But far more than being a simple video gallery, it presents these clips in a new and useful way, attempting to show how the natural world joins up.
Educational, informative and entertaining clips have been pulled from thousands of hours of archive footage.
Specific clips from more general programmes have been extracted to focus on individual animals.
The learning is not just in the clips themselves, but in how the species, adaptations and behaviours, habitats and ecozonesof the natural world are connected.
What does the Polar Bear have in common with…
…the Barn Owl?
Both are polygynous; where one male mates with multiple females, but each female mates with only one male. What else is polygynous?
Maybe the Hippo, which is herbivorous, lives in flooded grassland and is - uh oh – on the vulnerable list. You could lose yourself for hours in these user journeys, but unlike sites with randomly related content, each onward link is teaching you something new.
6.2. As you can imagine, the domain model is rich, and based part on the Linnaean taxonomy for biological classification. The natural world is of course a huge subject, and while we have a natural history archive stretching back 50 years, that only provides the video clips. There aren’t teams of elves working away to attach the written descriptions needed for every creature in the animal kingdom. Oh wait, there are.
It’s just that they do it on Wikipedia. Yes, the Wildlife team are fans of using the whole web as their content management system. Need a description? Pull it in automatically from Wikipedia. Do some Wikipedia entries suck? Yes, so edit them directly on Wikipedia so that everyone benefits.
The clips in Wildlife Finder are defined as being segments of programmes, so link to the BBC Programmes domain. Similarly, the conservation status of animals is maintained, not by the BBC, but by the University of Michigan. While the distribution data comes from the WWF.
This hints at the power of using linked data; treating the whole web as your database from which you can draw bits and pieces of content to plug the gaps in your own offering.
6.3. Once again, these thing pages are the canonical work that gathers the Googlejuice and gives people a place to point to and talk about when they want to reference lions, tigers and bears.
But it doesn’t end there. Because really, these pages are a collection of a whole bunch of individual audio and video resources, each of which can be accessed individually. The Wildlife team have made it easy for developers to access this content and add it to their own meshup applications…
…right down to using the same URL format as Wikipedia. By using a known URL scheme and by being able to serve content in HTML, RDF and the species microformat, the Wildlife Finder site is also its own API. If you’re a data-hacker, go dream up the next big thing.
6.4. And in fact the Wildlife team continue to build next big things, using the resources and thing pages as Lego bricks. The big addition is curation, addressing one of the main criticisms of the domain-driven approach; namely how to add some editorial voice, a human touch if you will, to the order laid down by the data model. Curation is a layer on top of the resources. It collects together hand-picked examples and uses them to tell a particular story. The first example was to get the naturalist David Attenborough to pick his favourite wildlife moments, and since then there have been light-hearted collections like Wildlife Wind-Ups to ones to promote events like Year of the Tiger. Collections add new context, timeliness and promotion; an alternative view through the eyes of presenters and film makers. This kind of curation enhances the experience without undermining the structure.
LINK TO NEXT BIT: The success of these projects has changed the way we make websites at the BBC. From Music to the Solar System to the Olympics and World Cup and soon to History. The domain driven design means everything not just links to, but seamlessly integrates with everything else. Let’s recap the approach.
7.1. First develop your domain model by exploring the subject and talking to domain experts and end-users. List the things they talk about and sketch the relationships between things. This can be done with as simple or as complex a diagram as you deem appropriate. Define the most important things, and develop a ubiquitous language used throughout the technology and user interface. The objective is to map a mental model that works for both casual users and subject experts. Think only at this stage about representing the subject, not about creating webpages.
7.2. Develop data model and populate. Working in collaboration with a software engineer, translate your domain model into a database schema. Check to see what data is available within your organisation and if any holes may be plugged by data available from external providers (either through commercial licencing or for free) and user community data (via the Twitter API, that sort of thing). Reshape data as appropriate to be able to pipe into your domain-model-based schema. Don’t just expose your internal data models as-is. Consider latency issues, sadly still a problem for using web data in general. Data availability decisions will iterate the domain and data models. Remember you have the option to expose only parts of the domain model based on available data.
7.3. Design URIs for all the individual resources and aggregations you’re going to offer. The URI scheme should follow your domain model, and follow as far as possible principles of persistence, hackability and readability. Please don’t expose your technology in the URL. It isn’t necessary, it isn’t pretty, and it’s a problem for URI persistence should you change your technology platform down the line. Maintain a policy of one URI per thing, one thing per URI. Don’t worry about building taxonomic hierarchy into your URLs; those garden swingsets in your product catalog could equally appear in the boys and girls sections. Get extra credit for using web-scale identifiers if possible to make it easier for outside developers to meshup your content: remember it’s in your interest to give your content as much possibility for reach as you can. Make your URIs human-readable if you can but avoid including anything that could change over time. If content must move, do it nicely: Use 301 redirects for permanent redirection, 302 redirects for temporary redirection.
7.4. Define all the data you’ll need for all representations, not just HTML. Start with stub pages with H1 titles that represent your domain objects. Take note - it’s only at this point in the process that we’re starting to think about making actual webpages! For your HTML pages, think about document design before applying any layout. HTML document design is another one of those often-forgotten parts of user experience. How does your page look with all the stylesheets and Javascript niceties turned off? Is the most pertinent information highest in the document, or are you including a whole bunch of links before getting to the good stuff? It’s not just screen readers that will see it that way, Google will too and mobile browsers may also get a limited rendering. Speaking of rendering, think about speed. Slow sites equal bad UX, so considering the balance between too much and too little caching really is a UX issue.
7.5. Apply layout and decor CSS. I want to appeal to you now to take the plunge. Consider leaving behind the Axure and the Omnigraffle and the pages and pages of wireframes. Think of the power you could wield if you were wireframing directly in the web browser using CSS to draw boxes, and a domain model to point the arrows. Layout CSS is where you position elements on the webpage; like wireframing, only this time you’re working with live content for a far more realistic experience. It’s bold, I know. Decor CSS is still probably the domain of your visual design colleagues; it’s where the visual niceties of styling are added. In all of this, design with your least able user or device in mind, not just the desktop web. Use a responsive design approach, with media queries that govern which elements get displayed and how. Certainly you should progressively enhance with Javascript and AJAX as appropriate for complex interactions and general wow factor, but never require those things for your site to work.
7.6. Test and iterate. Actually you should be doing this at every step. This whole approach is about getting to real code, real data, real content and real users as soon as you can, not generating lots of interim, well-meaning, but ultimately fake deliverables. From sketching domain models back to users to verify understanding, to putting real people and not personas in front of your basic layout pages, to testing again once the pages are prettified. Test understanding of the conceptual model, not just of the interaction. The advantage over top-down design is that your product is far more malleable and able to adapt to new requirements – you haven’t painted yourself into any corners. For every development cycle, test and iterate again.
8.1. Understand that user experience goes far deeper than presentation. It reaches down through all the layers of this software trifle, and as an IA or UX designer you have responsibility to get your hands dirty throughout. Business logic, SEO, pointability, document design, URI design, even server load and caching; all these things have a profound effect on the experience your users will have when interacting with your content. And all of them are facets of information architecture. The approach practiced at the BBC puts IA at the heart of an end-to-end service design, not just interaction or presentation. With great power comes great responsibility.
8.2. Think about your content in terms of things, not documents. The standards exist to allow you to add semantic meaning, allowing you to model complexities in knowledge and make links between things represent a specific - and actually machine-readable - relationship, as we’ve seen with the Wildlife Finder. Adding semantics involves two things: allowing documents to contain machine-readable information, and allowing links to be createdwith relationship values. When computers can read our stuff properly, we can use them to do the heavy-lifting we’d otherwise do by hand, like saying “show me all the Blu-ray players under $70 from suppliers who offer overnight shipping” or “where in Denver can I get a hair appointment for 3pm tomorrow?” - all of those things could be built fairly trivially today if only the suppliers and the hair salons published their data in the right format.Understand the business you’re trying to represent, and understand the most important things - both to the experts and to the customers. You might be thinking that domain modelling is all very well for an enormous content provider like the BBC, but even if your project is a site for your local restaurant the main principles apply. What would diners care about? Dishes? Cuisines? Local producers? Paired wines? How do these things connect?
8.3. Think about the web as a whole, and how your contribution can make it a better place. The World Wide Web didn’t evolve by chance. It was designed by a man, who said “The Web is designed as a universal space. Its universality is its most important facet.” We are supposed to use this space to share information, not to build ourselves ivory towers. Make your stuff easy to point at, and easy to share, and convince your bosses of the value of the increased reach this gives you. Design using web-scale identifiers where you can. And reap the benefits of shared information; enhance your own content with linked open data. DBpedia is a great place to start - it’s an open database with all the information from Wikipedia and it’s free to use.
8.4. Bottom-up everywhere. Don’t begin your design process by thinking about web page wireframes. Instead start designing from the domain model and data model upwards. Put most of your effort into your core content pages - thing pages - rather than the home page. Most of your traffic will be from deep links into your content. Google is your front door. Design for your least-able user first. This isn’t just about accessibility for screen-readers; I pretend to care about that kind of accessibility as much as the next guy. The Googlebot is your least able reader, but could be your best friend. Mobile users too; Mobile traffic to the BBC Food site is up 20% from last year, so this isn’t about throwing a bone to fringe users, it’s about maximising reach.
8.5. Make friends with a software engineer. In the advertising industry, great work is done by pairing and art director with a copywriter. Just think what a dynamic duo an IA and a coder could be. Be agile and iterate often. Prototyping is fine, but the real rapid prototyping tools are not things like Axure or Flash, they’re things like Ruby, PHP, CSS. How much more effective will your prototypes be if they’re powered by real data, real code, so they can be put in front of real users, real fast. Doing it for real isn’t really more expensive than creating tons of UX documentation, but it does takes some new skills - and that investment is far outweighed by the benefits. I really do think as a community we need to move on from the kitsch user story comics and persona posters if we want to be taken more seriously. Heartbreaking I know, because I enjoy making those things too.
8.6. More than anything, accept that the web has changed since the Polar Bear book first came out, and that some of our practices need to change with it. Of course, we’re still about creating the shortest route to content, making it easier for people to find what they’re looking for. We’re still about defining, and to some extent classifying information. But the emphasis is no longer on using taxonomic library science to build a series of private libraries. Access to information is perhaps more ubiquitous and fractured than ever before. Consider the whole web as your canvas, and make your content mesh seamlessly into it. Design for a world where Google is your homepage, Wikipedia is your CMS, and humans, software developers and machines are your users.
LINK TO NEXT BIT: In closing then, have we gone beyond the polar bear? How do we keep up with a changing web? Here comes the ranty bit.
9.1. Yes, the web has changed from documents to things. People, Locations, Things, verbs can have URIs associated with them to form the basic of semantic assertions. Google may not be a fully realised semantic search engine yet, but that’s largely because it doesn’t have your metadata to work with. In some ways the web is going back to its roots; away from corporate silos and toward a shared, open network of information. Today, the public at large are doing your information architecture for you, by bookmarking, tagging and socially curating your content. Half of all social media traffic to websites comes from Facebook. Can people easily point to your content from there? The polar bear asks ‘Does your site need search?’. The BBC has a site search, yet 70% of traffic to Food is coming from Google. So probably not, because Google is your search. Hell, Google is pretty much your information architecture.
9.2. Modelling the complexities of knowledge with all its semantic subtleties turns IA from largely taxonomic to ontological; from boxes and arrows to wibbly-wobbly lines. Many of the practices outlined by the polar bear still hold true; finding the right labels for your things is still vital (and still hard), you need to consider the many and varied facets of your content, and know the value of metadata; although we’re not talking here about tagging your webpages after the fact, but designing with metadata from the ground up. But the polar bear’s main message is one of managing broader and narrower categories, be they uniform or polyhierarchical. And as the book acknowledges, that has never been a particularly accurate fit for modelling information. Things have properties, and those properties inter-relate with other things.With an ontological structure the definition of the links between things becomes as important as the things themselves.
9.3. I believe there’s an elephant in the room, and it’s getting bigger. Information Architecture, like Rodney Dangerfield, “can’t get no respect”. It’s struggled for years to define itself and, as a result I think, sold its soul to the Technicolor religion of user experience design. We’ve become known for the quality of our documentation, and talk introspectively in conferences about abstract processes rather than the actual projects we’ve delivered. We’re getting squeezed by interaction designers on one side and software architects on the other. Some places I’ve been, the IA team meetings are held in clandestine priest-holes, with that team often bitching about how they’re seen as irrelevant in a culture that favours design led by flashy conceptual prototypes, or overtly technical engineer-led solutions. But I wonder if its just a skills gap to be closed. In a web of semantic information, is it less about detached deliverables like Axure, paper wireframes and persona design, and more about learning to wrangle information - data - at its source? The UX niceties like curation, seductive interactions and, God help me, gamification, can be layered on top, but we have the power to tame the roots and branches of knowledge itself. There are rich social graphs to mine, appetites for infographics and data journalism, growing repositories of free data to exploit and the hot topic of user-owned social data and identity. And if architecting information isn’t a job for an IA I don’t know what is.
Thank you for listening.

159 Likes

Takanobu Shuji, Infomation architect at Selfemployed 1 month ago
amubalt 1 month ago
gemmapetrie 1 month ago
Xuan Truong Vu, IT Student at UTC 1 month ago
emchateau 2 months ago
Sam Scott 3 months ago
Jose Emilio Labra Gayo, Teacher at University of Oviedo 3 months ago
shinichi3 3 months ago
levent güneş 4 months ago
Michaël Piron 4 months ago

Beyond the Polar Bear Presentation Transcript

Beyond the Polar Bear
Mike Atherton @mikeatherton
BBC / RedUXD
www.reduxd.com
New routes to content
“inform, educate and entertain”
2. The Problem Space
Information Isn’t Neat
The BBC: ONE SITE OR MANY?
Sections or Separate Sites?
Broadcasting over 1000 Programmes Every Day
Pages mothballed or Removed
Deep Cuts Across The Online Division
The BBC has made a commitment to halve the number of ‘top level directories’ on its site
In 2011 it will reduce its online spend by 25%
Controversy has arisen over a recent announcement that legacy content will be removed from the web
UX emphasis on the top layers
‘User experience design’ has put considerable emphasis on front-end presentation and interaction design
Yet the elements that contribute to a user’s experience go much deeper
In ‘tearing down the wall’, many IAs have leaned toward interaction design and away from software design
CSS / Javascript
HTML
Controller
Business Logic
Data Model
Fake ARTIFACTS
Projects usually begin with extensive front-end prototyping tested against user stories and personas, not actual users
The belief is that ‘real’ technical prototypes are too expensive to develop
3. Domain modelling
Avoiding Sorting by Document Type
A Web of Connected Things
A way of representing the important ‘things’ within as subject, and the relationships between those things
A way of using the subject knowledge of users and experts to influence software design
The first stage in the BBC’s process of designing new websites, and one of the few tangible artefacts
Inspired by Eric Evans’s ‘Domain-Driven Design’ book
What is domain modelling?
What a domain model looks like
ALBUM
LIVE
artists
release types
SINGLE
COMPILATION
releases
release events
tracks
labels
Talking to experts
Domain experts need not be technical, they just need to know their subject
They will help you understand the important and complex things
Break out the pencils and sketch their world back to them
Talking to users
round
competition
Use their language; learn how they speak, what they consider important and how they search
Users may understand the subtle differences between concepts, but can struggle to label them
Your aim is to capture their mental model
stadium
match
team
goal
player
stadium
competition
team
match
round
goal
player
Sketching a model to define Relationships
The differences between things
The canonical thing
Novel editions
Film adaptations
How about something like
bbc.co.uk/works/wuthering_heights
?
Wuthering Heights
The ‘Master Work’
Has a general sense of wutheringheightness.
Musical adaptations
Basic-Level categories and Prototypical Examples
car
dog
tree
Name a type of chair…
Name a type of bird…
Creating a ubiquitous language
Defines a common lexicon used by all members of the team, at all levels of the design
Labels for things can be informed by thinking about basic-level categories
Specific priority of things can be informed by thinking about prototypical examples
domain model
CSS classes
user labels
Don’t reinvent, link
In defining your subject, define the boundaries of your domain
Where objects touch existing models, use them instead of replicating them
If canonical content pages already exist on your website for domain objects, link to them
Don’t have more than one page covering the same topic
Test Understanding and iterate
Verify the model with experts and users as soon as possible
Check against business requirements and available content
It’s not too late to change, even after you’ve started building
Shared Model
+
Shared Language
+
Shared Understanding
=
Consistent USER EXPERIENCE
4. BBC Programmes
The complex world of Television Shows
brand
series 14
episode
“Part 1”
version(sign language)
sub-series “The Prodigal”
brand
Episode 1
Episode 2
Episode 3
Sherlock
SHERLOCK BRAND
SHERLOCK SERIES 2
Series 1
Episode 1
Episode 2
Episode 3
Episode 1
Episode 2
Episode 3
Sherlock’s Future?
BBC Programmes domain model
brands
formats
genres
series
programmes
episodes
services
versions
broadcasts
on demands
Getting the data right
Massive amounts of content, so metadata needs to be captured during business as usual
Many data systems were built for production purposes, not for users
Quality of data capture and labels used varies across departments
Data needs to be reshaped to best fit the domain model
pages for Brands, Series and Episodes
Wikipedia
CAPTURING SOCIAL BUZZ
Principles of URI Design
Cool URIs should be
Hackable
Human-Readable
Persistent
Cool URIs don’t change.
Choosing a Nice URL design Pattern
http://www.bbc.co.uk/bbcone/sherlock/series1/episode1.shtml
Don’t expose your technology. No-one cares and it might change anyway.
http://www.bbc.co.uk/bbcone/sherlock/series1/episode1
Is it really series 1 until there’s a series 2? Will it be the same overseas?
http://www.bbc.co.uk/bbcone/sherlock/episode1
What if this show moves to BBC TWO or another network later?
http://www.bbc.co.uk/sherlock/episode1
What if Radio 4 decide to do a programme called ‘Sherlock’ in the future?
http://www.bbc.co.uk/episode1
Hmm, well now that doesn’t make much sense at all!
The resultant URL
http://www.bbc.co.uk/programmes/b00t8wp0
The only thing we know for sure is that it’s a programme that can be uniquely identified
Using a unique ID isn’t human-readable, but is an acceptable compromise to get persistence
301 redirects can be used for a more marketing-friendly URL
A Page For Every Programme
From THE EDUCATIONAL…
…To The POPULAR.
Media rich page
Embedded video of the programme itself
Episode synopsis
Additional programme clips
Production stills
Contributors list
Web links
List of broadcasts
Track listings
Links Across to Other Subject Domains
PROGRAMME PAGE WITH TRACKLISTING
BBC MUSIC ARTIST PAGE
Making microsites
Model allows for fully-skinned and even restructured pages
Additional material can be associated at brand, series or episode level
Marketing URLs are redirected to the Programmes space
User experience is enhanced without undermining the structure
Telling the Stories within Stories
5. BBC Food
A crowded MArketplace
HOW Google SAW THE SITE
What do we think about?
programme
ingredient
recipe
chef
dish
BBC Food domain model*
chef
ingredient
technique
recipe
programme
dish
*simplified version
Recipes: A rich source of Data
Roasted lobster with champagne souffle
Ingredients
1 cooked lobster
30g/1oz butter
30g/1oz plain flour
150ml/ 1/4 pint champagne
150ml/ 1/4 pint milk
1 tbsp Dijon mustard
1 free-range egg, separated
salt and black pepper
Unlocking new ways to Explore
The Dish as a Canonical Work
SEARCH QUERY
DISH PAGE
SPECIFIC RECIPES
Enhancing pages based on Popularity
Results
NetPromoter improved post-relaunch (58)
150,000 extra users each week from search engines alone
~20% share of UK recipes market
1.3m
650,000
OLD SITE
(weekly)
NEW SITE
(weekly)
Desktop TRAFFIC vs. mobile
89%
10%
1%
Of the top 2500 search queries November 2010 saw over 20% of searchers arriving via smartphones alone - an increase of 20% since October.
Source: Google Webmaster Tools
Where does Food traffic come from?
70%
30%
other
Most visitors arrive into the middle of a site, via a deep link, not via the homepage.
Source: Google Webmaster Tools
SO Which is the real FOOD homepage?
DESKTOP
MOBILE
GOOGLE
6. BBC Wildlife
Showing How the Natural World Joins Up
Showcasing the BBC Natural History archive
Unlocking the value contained in complete programmes
Presenting content in new and useful ways
Unlocking New Ways to Explore
What does the Polar bear share with…
The Barn owl?
Both are polygynous
Hippopotamus
BBC Wildlife Domain Model
location
event
has location
individual
bio_event
participates in
is composed of
participates in
ecozones
cohort
features in
displays learnt behaviour
is aggregation of
is aggregation of
ecoregions
species
adaptation
has adaptation
is composed of
lives in
inhabits
is endangered
habitat
domicile
con_status
Using the Web as a CMS
Linking to Other Sources of Data
CLIPS FROM BBC PROGRAMMES DOMAIN
CONSERVATION STATUS FROM ANIMAL DIVERSITY WEB
DISTRIBUTION FROM WWF WILDFINDER
The Linked data Cloud
Canonical Objects
Aggregations and Resources
bbc.co.uk/nature/life/Giant_Panda/news
bbc.co.uk/nature/life/Giant_Panda/sounds
bbc.co.uk/nature/life/Giant_Panda
bbc.co.uk/programmes/p00chptr
Same URI scheme as Wikipedia
bbc.co.uk/nature/life/Giant_Panda
en.wikipedia.org/wiki/Giant_Panda
Curation to Add Context and Trust
7. How we make websites
Develop a domain model
Talk to experts and end-users
List the important things and sketch relationships
Develop a ubiquitous language
Think only about the mental model, not webpages
Populate your data model
Work with a developer to translate your domain model to a data model
Look at your business data and reshape if necessary
Identify sources of linked data to enhance your product
Don’t reinvent where someone else has done the thinking
Design URIs
Design for persistence, hackability and human-readability
Maintain one URI only per thing
Don’t expose your technology in the URI
Don’t include taxonomy or other things that may change over time
Use web-scale identifiers where you can
Build pages
Start with simple stub pages for all your objects
Think about all representations, not just HTML
Design your document to put the most important things at the top
Consider requirements for caching and load-balancing
Apply layout and décor CSS
Layout your wireframe pages directly in the browser using CSS
Design for your least-able user first
Practice responsive design and use media queries
Progressively enhance using Javascript and AJAX, but don’t make them mandatory
Test and iterate
Test at every stage, from the domain model upward
Test not just interaction, but the conceptual model itself
Test with real people, not against personas or user stories
8. What can you do now?
UX Thinking All the Way Down
User experience goes far deeper than presentation and interaction
Consider things like business logic, SEO, document design and URI design
Take your rightful place at the heart of service design
Think Things not documents
Design your content for a semantic web, modelling things and relationships
Understand the business you want to represent
Consider the domain modelling approach for projects of all sizes
Think of the Web as a Single Shared Space
The web was designed to be universal
Design your content to be pointable, sharable and used to plug gaps in the Web
Use the data published by others, and publish data of your own
Think Bottom-up everywhere
Don’t start from wireframes, but from the information itself
Put 70% of your effort into your ‘thing’ pages; your homepage is less important
Design for your least-able user first (that’s probably the Googlebot)
CSS / Javascript
HTML
Controller
Business Logic
Data Model
Team with a developer
Design in the browser, using CSS frameworks and code that references real data
Be agile and iterate often, putting your prototypes in front of users
Focus your personal development to meet the skills gap between IA and software engineering
Standards-based CSS framework
Standards-based web editor
Design in the absence of content is not design, it’s decoration.
Jeffrey Zeldman
Living, breathing wireframes!
Think How the web has changed
It’s still about making the shortest route to well-organised content
Primary routes to content have shifted from silos to aggregators
Design for a world where Google is your homepage, Wikipedia is your CMS, and humans, software developers and machines are your users
9. In closing
The new Information Architect…
Thinks about real-world things
Thinks ‘user-experience’ from the ground up
Designs for mobile first
Designs for search and social media
Wrestles data from around the web, and publishes their own data back out
Beyond the Boxes and Arrows
The complexities of knowledge call for ontological structures
Relationship values attached to connections teach us how the world joins up
Reusing content and linked data across domains greatly unlocks value and maximises investment
Playing nice with The Other KIds
Has IA turned into UX?
Has this put the focus on interaction and presentation?
Can we make a more direct contribution to the building of web services?
What skills will that require?
Photo by Oliver Klink
The way to get started is to stop talking and start doing.Walt Disney
Thanks to
Michael Smethurst@fantasticlife
Silver Oliver @silveroliver
Chris Sizemore @onpause
Chris Thorne @songschris
Tom Scott @derivadow
Paul Rissen@r4isstatic
Patrick Sinclair @metade
Further Reading
‘How we make websites’ by Michael Smethurst
bbc.co.uk/blogs/radiolabs/2009/01/
‘How does the emergence of the semantic web change the way we think about information architecture?’ by Silver Oliverblockslabpillar.com/2010/09/18/
‘Some thoughts on curation – adding context and telling stories’ by Tom Scott
derivadow.com/2010/03/11/
This presentation appearing soon at
slideshare.net/reduxd
Picture Credits
THANKS TO
flickr.com/photos/
cobalt/4330261604
dtaylor28/4369801559
debbcollins/4620829591
notm/1499506651
krustysplodge/1297721427
fcam/2476027735
peadar/2487923494
joncandy/3931662699
smaira/3721669619
phes999/1180686827
peterbecker/233071629
andertoons-cartoons/2517000136
benmcleod/11391970
89142790@N00/3212373419
danbri/2415237566
rapettif/4399201987
jjay69/4050882410
rwr/281039209
philip_d/2559996327
photos/saariy/2612208165
- “Linking Open Data cloud diagram, by Richard Cyganiak and AnjaJentzsch. http://lod-cloud.net/”

Beyond the Polar Bear

by Mike Atherton

Accessibility

Categories

Upload Details

Usage Rights

76 Embeds 3,616

Statistics

Beyond the Polar Bear Presentation Transcript