No hay notas en la diapositiva.
Hello and welcome to this half-day workshop on Modelling Structured Content (US vs UK). Glad you all could make it.Donuts. (REMEMBER TO BRING DONUTS)
Sorry its so early. Hope your brains are in gear for an advanced theoretical IA workshop. Hope mine is too. Im Mike Atherton – an IA. Work at Huddle as UX lead. Used to work at BBC, pioneers in content modelling for IA.Today is expansion on BTPB presentation done in 2011 – saw there was real appetite for this stuffMore recently content strategists have run with the idea- Sara woctor-betcha with Content Everywhere, other stuff coming from Cleve Gibbon and Rachel Lovinger.But really at its heart are old concepts – entity relationship modelling – taken from software developmentFor us, structured content and content modelling are the basis of content-centric experience design for our new device-agnostic, semantic, context-aware web. We’ve really only time to scratch the surface, but hopefully this morning will give you a taste of that.
What are we here to do?Look at what we mean when we say ‘structured content’Do some actual content modelling of our ownLook at the advantage of taking this approach to information architectureAnd hopefully learn some of the challenges you’re facing in your own organisations.The idea is to be practical and have tools to take away.Hopefully not just me talking – we’ll do some exercises where you’ll have the chance to make some models of your own.
I’m afraid it’s really tight, as there’s a lot for us to cover and we’ll need time to complete exercises. I completely expect these timings to fly out of the window. If we get to the end and you’d still like more Q&A time, we can perhaps adjourn to lunch or to the bar.
8.35amLet’s start with a story.Tom - real guy – used to be Product manager at the BBCTasked with building a product that reflected the BBC’s rich archive of natural history programmesYou’ve probably seen some amazing output – lions and tigers and bears.Product had some goalsBuild on BBC mission since 1922Had to be relatively cheap – lots of content already made, bought and paid for, so lets minimise new contentAlso cheap to manage – will result in big scale website, but can’t require a lot of ongoing editorial effortNeeds to be easy to navigate – work at scale for users, who probably don’t have very clear intent, and supports lots of browsing around, learning as you go.
Over 50 years of programmesProgrammes span multiple animals, locations, behaviours, time periodsSome are all about insects, or mammals. Some show the animals that live in different parts of the world, some cover different periods in earth’s evolution
So given all that content, how would you approach it? Is it about the programmes themselves, so a way of retrieving things you might have missed on TV?Is it about clips, so some kind of Youtube-alike for browsing video, if so how should that be structured?Or do you take a primary facet to hang navigation off, like geography or an evolutionary timeline?As designers, this is often how we think – in terms of the interface that will present our content…
… in fact, Tom took a step back, and didn’t think about interface at all.He first thought about what he wanted this thing to doyes, based on the footage but recombinedShowing the connections between the fauna, flora, geographic regions – all that stuff. In other words, create learning not just through the content itself but through its relationshipsTo show how the natural world joins up
Previously, another IA had taken a look at how to classify and connect the things in the natural world.Meet Swedish botanist Carl Linnaeus – often called the father of taxonomyMost often remembered today for the Linnean taxonomy…
Looks like this, or at least it did when first published in 1735.Its from Carl we get the division of animal kingdoms into mammals, insects, birds etc., and within that order, phylum and species.Bit hard to read though so here’s a simplified model…
Still looks a bit complex – and this is missing a bit of detail - but look at some of the things it tells us:Species – inhabits a – habitat (panda lives in broadleaf forest)Species has an adaptation (like being good at swimming)Also has a conservation status – in other words, how endangered is it.What we have here is a set of defined concepts within the subject domain of natural history, and the relationships – themselves defined- that connect them together. Because this is a content model.But a content model needs content…
Then came the hard part. Many hundreds of hours of footage from complete programmes chopped up – atomised – into model-based stuff.But with a model to work from, they knew what they were looking for, and how to classify it once they had it.And knew how it all connects together. But still not worrying too much about website structure. Why?
Because the relationships between the real-world things were expressed in the database, so express it any way you want.Earlier questions – timeline, map, clip-browsing – it can be any or all of these!And – this is coolest part for me – the learning, the value, isn’t just in the video clips. Where is it? Its in the links!I can know that a polar bear is a mammal, and lives in the Nearctic ecozone and is adapted to extreme temperature. Not through a handwritten essay, but because those concepts are linked together.And what’s even better is that once that model - with its things and relationships – is established, and populated with content, then the website can be thought of as a lightweight wrapper around it. So no one has to make all these pages by hand; they’re practically automated.
BBC loved it – maximises investment on high-quality content already producedGreat for reach – lots of pages, each about a single topic – so as findable, and linkable as WikipediaGreat for users and the brand; the principles of discovery and providing connections between subjects serves to inform, educate and entertain.They did it for natural history, for parts of science, for music, for food, for the world cup and the olympics, and soon a lot of subjects will be wrapped in an umbrella service called Knowledge and Learning.And K&L is really the advantage – for the BBC and for you - that structured content brings to the table.
8.45amThanks Wikipedia.Information or content – useful distinction actually. Sometimes we’re looking at honest-to-goodness content – video clips, reports, articles etc. Sometimes, and in addition, we might be looking at more abstract information, like the number of times a song has been played on the radio, or the conservation status of the snow leopard.Broken down – as we saw with Tom, to apply structure we really need to get inside the content itself; getting at the stuff that the content is really ‘about’. Atomic content in other words – some, like Sara call it molecular – breaking each piece of content down into a representative example of a single topic or concept or thingClassified – Some people when they talk about content modelling still refer to things that sound still sound like webpages; naming their things ‘article’ or ‘blog post’ – and perhaps if your subject is content itself, that’s appropriate. But what I want to cover today is a method that pretty much disregards content containers and instead studies real world things; things like soft-shell crabs, like wine, like rollercoasters – you know, real-world stuff.And classification also extends to relationships. In structured content we don’t just make broad category headings and dump stuff in different boxes - we create meaningful links between our defined things. That means the link itself has a definition. Connecting our Lion thing to our Savannah thing isn’t enough; we need to asset, at data level, that the Lion – lives in – the Savannah.Metadata – of course, we apply that classification at metadata level – the content about the content, if you like. We’re not going to go too deeply into metadata today, at least not technically, but inherent in modelling is the kind of metadata you’d work with your database developers to define in a schema.
I will say this though – an important facet of metadata here is to express relationships in a way that machines can read, not just humans.A page on Wikipedia has a lot of good stuff about a tiger. I can read that and learn a lot. But if I’m a robot, I need it broken down for me. So compare that hand-written description with this set of metadata statements.It’s telling me similar things, but a robot can store that away in its database and use it to connect the Tiger to other carnivores, other mammals, other things that live in the Savannah.Computers do the heavy lifting, we just have to feed them the information in the right way. BBC site couldn’t have been automated if the relationships only existed on the page – they have to exist in the database.
Why is structured content important? Whole bunch of reasons – off the top of my headContent at scale – if you’ve a ton of content you need a logical way of making sense of it so editorial teams can focus effort and pull in the same directionNavigation – you’re encouraging browsing by meaning, with connections based on real-world relationshipsLong-tail – All this linking is very democratic and can lead to surprising user journeys that connect users to content they might not otherwise have found.Reuse – if you’ve got atomised content assets, you may well want to refer to them as often as you can, across different contexts. Bridge across subject – We use subjects as suitable domain boundaries, but really all knowledge interconnects and we can expose natural pathways that link one subject to another.Improve findability – We end up creating lots of very focused resources – bit like Wikipedia – so lots of paths into your content.Social sharing – similarly, you can provide a direct link to things in your model which makes it much easier to share on Twitter.SEO – Lots of things affect SEO, but two important ones are relevance and link density; how focused on a topic is your page, and how interlinked is it to other pages on your site (internal) and linked to by others (external).Design for all devices – big one. We’re not tying our IA to the desktop, not mobile, not tablet – not anything. We’re not even thinking about pages at all when we start. Instead we’re thinking about how concepts within a subject interrelate, and that’s something we can ultimately preserve across all channels.Make robot-friendly – another big win. It’s one thing to take the Wikipedia approach and hand-write context around our links, and manually link concepts together. But really we want computers to do the heavy lifting. If we can make some assertions about concepts in a way that machines can read, they can connect things for us.
We’re not all the BBC, NPR, New York Times. That doesn’t matter. If you’re in the business of providing content, then that content needs structure and for all the reasons we’ve just covered, this is a great way to go.Aside from the specifics of the modelling approach, I think there’s an underlying principle driving this – and its to think of your content offering as representative, or at least contributing to, a subject domain.Movie showtimes site? You’re in the domain of cinema; with films, actors, awards, genresConcert tickets? Music, and specifically live music with artists, lineups, venues, setlistsInvestments? Maybe personal finance.When it comes to populating your model, you don’t have to fill all the gaps yourself. So abstract yourself away from your specific business proposition and don’t worry about your existing content inventory. First decide just what subject area your content lives within.
Even If I was doing a site for a small chain of restaurants, structured content helps. People probably care about the subject of food and fine dining more than they care about my restaurant.So we can talk about the cuisines, the dishes, the locally-sourced ingredients, recommended wines, our fantastic chefs, and our food that’s suitable for vegans or coeliacs. We can offer all of these interesting things as ways into our content and the means to connect it together.
8.55amSo we’re taking an approach that leaves all worries about user interface aside for the moment, and instead thinking more abstractly about the subject we want to represent. We still need a way of communicating that to our team and our stakeholders, but stuff like wireframes now isn’t that useful.This is where content models come in. A content model is a means of expressing the things and relationships in a diagram that anybody should be able to follow. It’s a mental map that will inform all design decisions.
Top-down is about broad classification; finding some reasonably wide common category under which to throw a bunch of stuff. Perhaps there are broader and narrower nested subcategories. I find in practice there can be issues:We combine the logical classification with the presentation of a menu. And maybe say things like, well there can’t be more than 7 +/- 2 category concepts because no one wants a menu that’s too long.We combine conceptual categories with containers. Maybe this is just bad IA, but you see it a lot – sections for videos, or photo galleries, even ‘news’ has problems in some ways. (after a few days its not news, its olds).Hacks like information scent.And really, the biggest issue is that we’re imposing a sometimes artificial rigidity to the structure, saying that all our content sits homogenously within categories and subcategories of similar specificity. And then saying that within any one of those boxes, there’s no explicit sideways relationships between the things within.Knowledge resists any formal hierarchical structure we try to impose on it. It’s wild and untamed and intertwined.
You might have seen this example from me before. I’m rather too fond of Disney theme parks.Disneyland exampleYou can see that this isn’t a hierarchy at all, but a graph.Pathways between concepts are really more wibbly-wobbly than a strict hierarchy would allow.Let’s redraw this more neatly.
And so here we are, a first cut of a content model to represent Disney theme parks – or indeed the subject of theme parks in general. My boxes represent the concepts inherent in the subject, but not the instances of those concepts – location here could refer to Anaheim, Tokyo or Paris, so this model is scalable to other parks. I could go further and label my relationship so I can make explicit assertions about exactly how two things are connected.After talking with friends about this model they said to me – hey what about those cruise ships that Disney do now are they theme parks? And don’t they have some water parks as well? How would you show those?Doh. Yes, I guess I missed those things out. Perhaps we need to build in something that covers types of park, or determine just how customers or Disney staff think of the cruise ships – are they connected to the theme parks in some way?But that’s fine. I don’t have to get it right first time.
So once again, if I’m modelling a subject I’m trying to pull out the important concepts – the things- that make up that subject.Couple more examples.
A content model also describes how two things connect, because those relationships have value. Quiz time!…We can see that things are connected through defined relationships, and those relationships might sometimes differ.
Content models can be as small or large as your subject demands. Here’s a more complex example covering scientific method.You can see how an experiment captures data, but an Analysis analyses that data.And how an Analysis can establish, validate, modify or even contradict a theory.And you can hopefully see that a model at this level is really trying to unpack a difficult subject; its really not worrying about webpages.
9.05amWe’ve said that we try to steer clear from thinking about webpages, or any documents at all, when we’re defining our model. Let’s take a brief look at why that is.
Who’s familiar with this painting?It’s calledThe Treachery of Images, painted in 1928by the Belgian surrealist Rene Magritte.Translates as “This is not a pipe”. Why not?Its not a pipe but a picture of a pipe.In fact this is a screen grab of a photograph of a painting of a pipe.
Forgive me if this all goes a bit Inception.As we’ve seen, content modelling focuses on real-world things – we try to disregard pages at the modelling stage.At some point, probably in our database, we’re going to have a definitive identifier that we use as a proxy for the real-world thing. We call this a resource. And when we’re describing the resource, we’re actually making statements about the real-world thing.These resources might then power many different representations, like a desktop webpage, a mobile-formatted page, an RSS feed, even a version in a different language that you still want to claim is the same resource, just a different representation of it.And the claims we make about our resources can be different to the claims about the documents that represent them. It’s a bit hard to explain, but let me show you what I mean.
Here’s a Wikipedia page for the Haunted Mansion, an attraction seen in Disneyland, and other Disney Parks. The text of this document tells us it opened in 1969, is located within NOS (a real place) and was created by these Imagineers.However this page – at this address – was created in 2003. Its related (loosely) to another Wikipedia page about NOS, and the page was created by a bunch of Wikipedia editors.So I’d have to be really careful about separating what I say about the document from what I say about the Haunted Mansion.
Does it really matter? As a human, I can read that Haunted Mansion page, and intuitively I can make the separation between the document and the thing it refers to. But give that page to Google or Wolfram Alpha and how would it know the difference?That’s where having our structured content is important. We’re making assertions – statements - about real-world things, and how they relate to other real-world things. Those assertions live in the database, so we can serve up representations that are more friendly to robots.So my human-friendly sentence can be broken down into a noun-verb-noun, and I can express that through metadata in a way that teaches the same fact to a robot.And by the way, the resources we use to identify things – we don’t always have to create them ourselves. There are third-party datasets available, and we can borrow where we need to from other content providers.
Which is great, because when different sources know about the same thing – are referring to the same resource - connections can be made even though you’re not holding all the cards.If the BBC wanted to make a page about, say, Billie Holliday then the BBC guys might have some interesting information, but don’t want to create all of it. They don’t have to.Other providers of data have defined resources that describe real-world things. That data can be queried from across the web and ultimately surfaced in the BBC webpage. Thanks internet, for doing our content strategy for us!
And there it is. A beautiful page on the BBC, with content pulled directly from BBC data, MusicBrainz and Dbpedia.
9.15amWho are you?What do you work on?What do you want to get out of today?
9.20amLike any good IA, content modelling starts with research. We’re dealing with subject domains, and we can’t be experts on everything. So we hold conversations with subject enthusiasts to help construct our model.
I say again. Forget about web pages. Forget about content inventory. Think first about the mental model of the subject.But any model, especially a mental model, is never really perfect. Like Luke Skywalker here, the model representation of a real thing can start out pretty rough at first, but get better with each pass.Sometimes its just a matter of opinion. I remember debates of the subject of History at the BBC; is there always such a thing as historical fact, or should we accommodate different accounts of events? Is history written by the victors? Can we truly say that one event ‘caused’ another, without inviting controversy? Ultimately your model is just the best take on a subject that you can manage.But don’t sweat it – you can test and iterate it, and while its boxes and arrows on paper, that’s very cheap to do.So armed with an understanding that we’re not asking anyone to help us design our website, or assess our content inventory, we can go explore the world of the subject expert.
Experts are great aren’t they? When you talk to someone who really knows their subject, their passion can be infectious. Buy them a drink. Get them talking.Get an overall picture of their world and ask as many questions as you can so that you have an understanding. Even take a notebook and start sketching a model with them if it helps. Your goal is to understand which things are important in their world, what those things are called, and how they relate to one another.If you get bamboozled with jargon, ask them to explain. Sometimes you find whole new concepts pop out. And try to work out where their field of expertise touches neighbouring subjects. Rare book collecting, for example, has close associations with bookbinding, but if we’re planning a model we don’t want to fall into the trap of straying into a different subject area.
I have a fragment here from a conversation with a rare book dealer.(read out first para) I’m having flashbacks to Clint Eastwood talking to a chair!We can see the different things start to fall out – edition, copy, printing, country, state, issue – even ‘best edition’, which I didn’t know was a thing. But these are the things that would go into our model, and our friendly expert has even taken the time to explain how they relate to each other.Use conversation in handouts as the exercise to draw terms from?
With our new-found knowledge of rare books we can now go talk to some prospective users. Regular people, but people who have a regular-person interest in the subject.We might find that they don’t know the difference between issue and state and printing, and perhaps they don’t care. They might call a ‘dust wrapper’ a ‘dust jacket’, or a ‘soft binding’ a ‘paperback’.On the other hand, they might have a different view of where their subject begins and ends. Perhaps our subject expert was a victim of organisational tunnel blindness and considers anything outside of his own department to be not worth mentioning.So find out what users care about. They’ll likely have lot less objectivity than experts, and you can use that to prioritise. Find out what terms they use, and favour it where you can. And uncover the boundaries of their own mental model.
The goal is to make a best fit understanding. Experts can give you the overall coverage, and users will tell you what’s important. Your model should strike a balance between having enough authority to please experts but enough accessibility to appeal to users.But don’t skimp too early. When you eventually build a product from your model, you’ll get a second pass at deciding how much complexity to expose to users. Aim for accuracy in modelling, even if that means more complexity than you’ll ultimately want to show.
Pro tip courtesy of Lou Rosenfeld, via his book on Search Analytics. If you have an existing site, then your internal search logs are probably filled with useful information. Search logs are telling you what users are looking for – and therefore what they’re most interested in. They’re also telling you the terms they use to describe those things. So go mine your search logs and see what treasures they yield!
The labels you use to describe your things and relationships go way beyond the model itself. This phrase ‘ubiquitous language’ comes from modelling in software development, but we’ll use it too. It means that the model’s language is used everywhere –from the names of the database tables, through to the names for CSS classes, and the labels used in the user interface.So from bottom to top, everyone is working from the same playbook and definitions don’t become misinterpreted.The content model should be easy enough for everyone on the team to understand, reproduce and work from.
9.30amLet’s talk a little bit about the edges of the model. When dealing with a subject its very easy to wander into related territory.
We’ve talked about how knowledge resists being constrained into hierarchical structure. It also resists staying within any single subject area.Take Mad Men. The show covers many of the themes of the 60s, like civil rights. It also references real people, real world events, and of course fabulously indulgent food and drink. It covers real-world advertising, which is a big subject in itself. And its great soundtrack includes music from people like Bob Dylan.Many subjects have natural connections to other subjects. This is good. We like exploring knowledge. We just need to be careful about deciding on the boundaries of any one subject, and finding ways to connect together what could be multiple different models.
Boundary objects, another term which we’ll steal and massively simplify for today’s purposes.Boundary objects are things that exist in different subjects, and sometime with different contexts. Like chicken, and chicken and chicken. There are lots of fun debates to be had to decide whether something is really the same thing as something else, and whether it should be included in a model.I remember some interesting questions about the BBC Lion page. People often tend to leap directly to the difficult examples, so a debate went on for a while as to whether the lion page should include Alsan, or other fictional lions. In the end they decided not.
But boundary objects are great for taking us seamlessly from one subject to the next. This Mad Men episode features a Bob Dylan track. And because track listings and artists were included in the TV shows model, and because Bob Dylan was also a known artist in the Music model, the robots worked their magic and made a user journey from one subject domain to the next.So don’t hesitate to include appropriate user journeys between domains. Don’t think twice, it’s alright!
This also means you don’t have to tackle all subjects at once. If you have multiple subjects consider them separately, and link when and where there are places to go to. Links can be exposed at any time. You don’t have to do everything at once.But in the meantime, if another provider has contextually relevant content, you can (and should) link beyond your own walls.
9.45amIt can really be any subject, but ideally something that at least one person in your group knows quite a lot about.At end: Who has at least 5 things? Who has 5-10 things? Any volunteers to come up and share their list?
10.00amNow its time for you to try your hand at creating a basic content model. You can base it on the exercise you’ve just done, or on any subject you feel passionately about. But we’ll have less than 30 minutes to do this, so choose wisely!Let’s look at the process.
We’ve chosen a subject we’d like to represent, and made a list of the important things that exist within that subject.Here’s my list. Anyone guess what I was trying to model?
My first step uses our old UX friend, the post-it note. I write each thing on a single note. On the back I might jot down some examples of that thing, just so I remember what I’m talking about. So for cuisine, I might write down Tex-Mex or Chinese. For Challenge Type I might put quantity or heat. (this is my take on the model!)
Then on a larger piece of paper or a whiteboard, I arrange them as best I can and start to sketch lines between them. The lines show which things connect to which.Here my chef connects to a restaurant and to a recipe but not to a dish. Because Ben of Ben’s Chilli Bowl in DC invented his own recipe for chilli, but he didn’t invent the dish of chilli con carne.I do want to make it clear though that Ben created his recipe, so the next step is to make that relationship explicit.
This can look scary, but not too bad when you get into it. We’re defining how these things connect.When your two things are real-world entities, then the relationship is more meaningful – we’re saying here that a chef works at a restaurant, not just visited there. Or that an ingredient is specifically used in a recipe.But sometimes, your entities are really more like properties to describe a real-world thing, like a recipe having a cuisine (like Tex-Mex or Japanese). In which case our label is just to state that our dish thing ‘has’ this property. It doesn’t have to be more meaningful than that.Sometimes you’ll see models that only define this relationship one-way, and that can be okay. It’s more thorough to label both ends.When this is eventually made into pages with links between each thing, you might want links to go in both directions – like linking on a recipe page to individual ingredients, and on the ingredient page linking to recipes that its used in.Some won’t be used in the eventual website, but that’s okay for now.
Finally, I’ll walk through some worked examples to test drive my model. This usually uncovers connections I haven’t made yet, or even new things that need to be added and hooked up. This is paper, so its pretty cheap to change things.
10.05amThink you’re ready to give it a try? This will run straight into the break, and we’ll do a review afterward. If you finish early feel free to break early – if you need more time, then maybe you don’t need a break?
10.30amMe too! I’m shaking with adrenaline and need to recharge for part 2.
10.45amWhat did you find challenging?
10.55amWe’ve talked about structuring content, modelling content, so let’s look at content itself. And as the old chestnut says, content is king. Though I think it should say…
Content is ***king hard.
Because good content is where it all begins. The best thing that the content strategists have done in the past few years is to have reminded us that content isn’t something that fills out our web designs. Its not something to be chased up from the client at the 11th hour. Content is the ball game. It’s the whole damn point of why we’re here.All our modeling isn’t worth a damn if we don’t have good content. This isn’t like some blackhat SEO trick to game the system and getting our crappy content to the top of Google.The best structure in the world won’t help if your content sucks.
Content is expensive to produce. All these text articles need researching and writing. Pictures need to be sourced and rights-cleared. And video production – astronomically expensive. You’d think it would help to be a major media organisation?But before content modeling, BBC fell into this trap. Never mind the fact that they made a lot of factual shows. When it came to the website, entirely new content – only for the website – would be created from scratch. Even worse, the BBC has a lot of different departments; Factual & Learning, Childrens, Regional affiliates, so often you’d get different teams producing very similar content from their own perspective. And of course, none of it was linked together – except maybe by Google – so hard to keep track of, even for editorial staff.It’s illustrated by an quote from the former BBC chief Mark Thompson, who when appointed had a mission to join up the BBC. He said “Today I'll do 1 interview for Ch4, 1 for Sky, and 40 for the BBC“.Woefully inefficient, and not helpful to users who don’t care about your internal siloed structure.
But we have a strategy to combat that, right? We now have a clearly defined model that our whole organisation should understand.This model determines what’s in and what’s out. If a thing isn’t expressed in the model, it shouldn’t be part of our offering. Period.If it is in the model, then each instance of that thing should be represented by one ‘page’ – with one URI to access it. If we have a bunch of stuff about Lions, it should all be available on our one Lion page – and aside from the links, the content on that page should only be about Lions.One page per thing with one thing per page.
One page per thing is efficient.When the BBC were using content modeling to represent their TV and radio shows, the project took a while to realise its value. In many ways the first release was a great leap forward – using the model to automate the creation of thousands of linked webpages, they managed to build a persistent location that referenced each of the 1500 shows that go out over TV and radio every day.But there wasn’t a whole lot on those pages. Bit of programme metadata – titles, synopses, airdates – but nothing really sexy.But all of a sudden the editorial teams realised they now had a million single points of light – a single place for each episode of each show that they could target with all the sexy multimedia they had to hand.First, the ability to watch the episode itselfplus clips, programme stills, lists of actors, list of music tracks played in the episode.Of course some shows – the more popular ones – got more of this stuff than others, but that’s okay. There’s no requirement to make each page equally rich, and every show has at least some baseline content.
11.05amIn applying this idea to your own content, you’ll first want to take a look at what assets you have to hand.
If you’ve done any content strategy work, you might be familiar with this – the content audit spreadsheet.Used to list out a complete inventory of all the content on a website, and classify it by author, approver, by quality assessment, by theme, or by other things like keywords or by popularity.It’s usually the first thing a content strategist gets their hands dirty with to assess the material they have to work with.
Well we’ve build a model that will drive our content strategy, so we’ll use that as the basis of any content auditing. Your spreadsheeting format – if you use a spreadsheet at all – is up to you, but here’s what you’re looking to achieve.Base your assessment framework around things in the model. Everything must connect back to this.For each piece of content – whether its already live or in Word documents, or in video or audio recordings – determine which thing or things it maps to. If it maps to multiple different things – well, we’ll talk about that in a bit.Through this process you’ll be able to determine where the gaps are. What things does your chosen subject area need to be represented, that your pile of content doesn’t include?Conversely, what doesn’t map to anything in the model? Can it be removed completely? Or maybe rewritten to make it a better fit? And if you have multiple pieces of content mapping to the same thing, is there value in both of them or is there an opportunity to merge them?There’s an adage floating around the content strategy world that says something like deleting 90% of your content will increase user satisfaction. If you’ve working on deep content sites for academic or government bodies, that sounds pretty good – both for your editorial team and your users.
In other words, do less.This passage is taken from the published design principles of one of the hottest design and content strategy startups in the world right now – the British Government. Who’dathunk it? And you thought they only had James Bond.For years their online services had suffered all the problems of siloed, fragmented deep content organisations. Repetitious content, and not knowing where to stop – even writing articles on bee keeping, apropos of I’m not sure what.But their amazing new team changed all that - they embraced a content-modeling approach and used it to radically simplify the content, making the stuff you really need easier to find and easier to digest.
Do what you do best, and link to the rest – a lesson from Jeff Jarvis in his book ‘What Would Google Do?’Live by this principle – Only do what you can do well. If someone else is doing it – like bee keeping articles - link to it rather than recreate it. Make the focus of your page clear rather than cramming everything onto one page. Focus your resources where they’ll do the most good, and concentrate on your irreducible core.This is considering content strategy at web-scale; seeing beyond the walls of our ivory tower and looking for opportunities to stitch our content into the wider fabric of the web.
But what if your problem isn’t too much content, but too little? After all you’ve sketched out this model of a subject area, and its quite possible the pile of website content doesn’t begin to cover all of it.Firstly, don’t’ worry. It doesn’t matter if you don’t have content for every thing in the model. Those things should still exist, and you probably want to make space for them in your data model, but all it means is that if you have things you can’t represent, then those things aren’t linked to.Here we see a list of credits for a BBC TV episode. In an ideal world, we’d link from each actors name to a page about that actor, which probably links in turn to every show they’ve appeared in. But they couldn’t build everything at once, and didn’t have the content or the infrastructure.But if you do want extra content, and you don’t want to create it fresh from your own budget, there are two ways you can go…
You can go on a treasure hunt around the business, finding content that hasn’t been surfaced before. Given that you have a robust content model in hand, you know exactly what you’re looking for. Content can come from unexpected places, and sometimes it isn’t really content at all.When BBC Music wanted to jazz up their new artist pages, they wanted to make them somehow more BBC-like, and thus more relevant to a BBC audience than, say, linking to a Wikipedia page. The web team went to the people who control the playout on the various BBC radio stations and found that those guys maintained a live database of every record that gets played on air. They need to do that to keep the music licencing people happy so that musicians get paid. Beyond that, no one had thought of doing anything else with that data.But it was a gift! A database that gives you the name of a record, the artist, when it was played, on which radio station by which DJ! Updated all the time and for free! So with some clever jiggery-pokery which we’ll gloss over, they managed to hook up this internal database to the website CMS, and infuse this data into the music artists page. Now if I look up my favourite band, I can see where I’m most likely to hear them on the BBC.And more than that, this kind of business data is great at what I call link glue. There’s lots of stuff there that can be made linkable, like the title of the radio show or the name of the DJ, so we’re boosting our link density and stitching our content ever tighter into the web.
A similar story emerged with BBC programmes. This is one of several pieces of paperwork a programme producer has to fill out during the making of a show – it gives details of the episode, of contributors, of music and archive footage used. Its used to make sure the correct licences are obtained and that everyone gets paid. Nothing to do with the website – this is just business as usual for TV production.The web team recognised this as a great source of metadata, but partway through the project they hit a problem. People weren’t filling out their paperwork! They saw it as just another bureaucratic form to fill out and these forms sat on producers’ desks waiting to be filled out.But then those same producers starting asking – why doesn’t the web page for my show look as good as the other guy’s? And the answer was – you didn’t fill out your paperwork! Not surprisingly, with an obvious incentive in place, a lot more forms got filled a lot faster.
Now if we were here all day we’d cover this in a lot more detail, but the other place to grab your content from is third-party sources of free data. Those long-haired beatnik lollygaggers are making it too easy.So more here from our Paul Simon artist page on the BBC Music site. Now even the mighty BBC don’t have armies of people to write bios for every artist, so they take a feed from Wikipedia! I was there when this was first proposed, and the BBC editorial policy people went crazy – Wikipedia’s full of lies, isn’t it? What if someone posts something libellous? Will we be sued!?Check out what it says at the bottom:
“Edit this article at Wikipedia” – don’t like it, fix it yourself! I can think of three reasons why that’s brilliant.First, that’s the point of Wikipedia, especially for all those who complain about its accuracy. If you don’t like an article, edit it yourself!And second, this is a great example of distributed content management. And the Wildlife site does the same thing for its descriptions of animals. Do some Wikipedia articles suck? Yes, so the BBC team goes in where needed and cleans them up – on Wikipedia, which doesn’t only benefit the BBC website, but everyone.Oh and third, I have to smile at what a big step this is for the BBC, who less than ten years ago were still providing interstitial pages with outbound links that said ‘You are now leaving the BBC – are you sure?’.
11.20amYour content needs to align to fit the things you’ve defined in your model – one page per thing, remember?But maybe your content doesn’t quite map to one page per thing. Perhaps its time to start chopping it into smaller atoms.
“Chunking” is something that technical writers have done for years. If you’ve ever prepared a client proposal, you’ve probably done it yourself – copying in a lot of boilerplate stuff and only using new material where necessary. Its another way of combating repetition in content, and getting the most out the content we already have.Smaller chunks of content are more useful, because we can link to them more often. If we have access to a passage of text that describes our store returns policy or a biography of our CEO, then we can reuse those assets in many different ways, rather than writing new versions. And every time we make an update to a chunk, those changes are reflected everywhere that its used.There are downsides to being overly granular though. Pages can end up feeling like they’ve been assembled at random; you can lose sense of narrative flow. It can also be overly taxing up front, especially if you’re not yet sure how often you’ll be using each chunk.So there’s a need to be realistic and only atomise your content as much as makes sense.
The BBC wildlife team went into an archive of complete finished TV episodes to find their content, using the content model to guide what they were looking for.
There were various levels of chunking they could have opted for. At one extreme, they could look for complete programmes that focused on a single animal or habitat. Rare, but possible. Would certainly have been less effort to just take complete programmes.At the other extreme, they could have picked out specific shots of animals and packaged them into new video clips. Very specific, but also lots of effort.In the end, they cherry-picked the best example scenes. The team didn’t need to use every available piece of footage, and certainly didn’t assemble together all the individual shots. So even if the same shot appeared in two different video clips, really that’s okay. They balanced the overall amount of content obtainable with the effort needed to obtain it.
As Groucho Marx once said, these are my principles – if you don’t like them, I have more.
11.25amThere’s just time to look briefly at content curation, something that brings an added human touch to the robot-assembled, content-modeled world.
Some people get a bit sniffy about using the word ‘curator’ in a web context, and it is often misused. Museum curators don’t simply classify stuff, or chuck a bunch of things in a room because they’re similar to each other. Instead they use artifacts to tell a story in a particular context, identifying and explaining the cultural, historical or scientific importance of those things.So doing ‘curation’ on the web got a bad rap, because it was all about the dreaded ‘related links’ syndrome – the terror of the right-hand column where we stick all the misc shit in the hope that someone will click there (no-one ever does). And related how, exactly? We never said. Perhaps we never knew, other than that there was some sense of similarity. Maybe.Now as seasoned content modelers, all of us in this room understand that we’re way beyond those old school related links. We can say exactly how our things fit together. But we can still learn from museum curators who hand-pick things from the overall inventory and showcase them through thematic collections.
These are a couple of the collections from the Wildlife Finder. One from the perspective of a famous British naturalist, another on an aspect of animal behaviour. They cherry pick example clips from the model and recontextualise them.This deals with one of the criticisms of content modeling – that its too democratic, and hard to make featured or otherwise editorialised choices. But these curated collections add new context, timeliness and promotion as a layer that sits on top of the structured content beneath.
Everything starts with good content
11.30amWhat kind of content do you work with?How might it be reshaped and atomised?Could other parts of your business hold useful content?
11.40amWho here gets involved in front-end design, at least at wireframing or protoyping level?
KarenMcGrane has talked a lot about this idea adaptive content – as far as I can see it’s what we’ve been talking about today; information resources that are separated from any particular platform-based representation, and connected by meaning using metadata. As we’ve seen that’s’ great for browsing by meaning, and learning through links, but it’s also great when it comes to offering different interfaces to your content across different devices. Whether its desktop, mobile, tablet, TV or things we haven’t thought of yet, its all driven by the same structured content – semantic meaning and relationships stored in the database and expressed through the interface. Karen talks about NPR as much as I talk about the BBC – they have this approach called COPE; Create Once Publish Everywhere – driving different experiences for each platform from the same structured content.
So now we’ll talk about how you take your model and expose it to page level. I’m going to say “page”, but I really mean bring it to the screen, or any device interface, or somehow put your stuff in front of people. Saying page is easier.We’re back to this principle of one page per thing, and the easiest reference for this is Wikipedia - 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.
I say one page per thing, but I don’t always mean it.Some things in your model aren’t all that interesting. It’s important that they are there, and useful to make distinctions in meaning, but they don’t necessarily justify having a page all to themselves.They don’t have to. Some things you can expose as transclusions – in other words, including them as detail to enhance a more important page.We should only publish complete pages where that page itself has value.
Here’s an example from the BBC. You can see that this page for a Parks and Rec episode includes when that episode is next on TV and when it’s previously been on TV. That broadcast concept is an important part of the model, but we really don’t need to have a separate page for every time the episode was shown on TV.So broadcast information is added instead to enhance the main programme page.So only make pages from your model where those pages will be useful, and remember, you don’t have to expose all of your model. Some things might not get represented at all, or at least not until you’re ready.
When it comes to considering the layout and structure of your page, content should always be front and center. But lets not lose the investment we’ve made in all this modelling. Add context to the content with supporting metadata.Metadata is the stuff people will use to navigate around and understand how the content they’re seeing relates to the subject as a whole, and maximises your opportunity for onward linking.
Blondie page here. Content – video and biography on the right. Some onward journeys driven by metadata over on the left.
With a whole bunch of model things to choose from, you can decide whether that should differ based on the device your content is viewed on. If a device can’t, for example, support video then it doesn’t need to be included. This comes down to good old fashioned progressive enhancement as a way of giving each device the experience it deserves.
We create one page per thing – where that page is justified – and link them through contextual metadata. But there’s other navigation to consider.
We talked at the start about the problems in imposing hierarchy in our website navigation, and why the natural, graph-like navigation that structured content offers are better aligned to the way that real-world knowledge is structured.But to be practical, its still a good idea to blend this horizontal navigation with some good old-fashioned main menus. We do it by pulling some major things out of the model and using them as jumping off points into the content.What we don’t do is to create new navigation classification paradigms from things that don’t exist in our model.
This is the content model for BBC Food – chef, ingredient, recipe, dish, technique and programme.
And this is the Chef page on the website. You see all the chefs to browse by, along with a count of their recipes.And along the top – why, it’s a main menu! And you see the sections of that menu are Recipes, Chefs, Ingredients – so we’re still working within the model, but providing some high-level ways of jumping in.And there’s even A-Z navigation for that really old-school browsing method.
You know this one.
We see the recipe itself – actually the video for the recipe – the metadata that describes it and provides context, and the Quick Recipe Finder, which is what this site is for.
Finally we get to Baltimore! I had a bet on that I could get a reference to The Wire in.New domain might have new top-down navigation, but horizontal navigation is the consistent glue
11.55amUsing the content model you’ve created, sketch a layout for a ‘thing’ page, for any device you choose – desktop or mobile.
12.25pmAll too quickly, our time together has come to a close.