Dealing with content beyond the webpage, DistilledLive discussion

By now, most of us are aware of the idea of responsive design and the sorts of tools you can use to make your website’s layout more mobile friendly. But how do we deal with content in this multi-screen world? In this video, London consultants Hannah Smith and Bridget Randolph talk you through how to move beyond simple responsive design, and distinguish between the layout of your site vs the content you choose to publish on it. How does your content fit into this design and how can you make it work more effectively for a more positive user experience?

You can read the full transcript, below.

If you want to learn more on the idea of responsive design and how to deal with your content beyond the webpage, we’ve just launched a new guide on that very subject. “Creating Your Mobile-Friendly Site: The Distilled Best Practice Guide’’ talks you through the process of making a website that’s mobile-ready, and discusses best practice considerations for each stage.

Head over to our training page to take a look through it now. We’d love to hear how you’re dealing with your content in the comments below.

DistilledLive| Dealing with Content Beyond the Webpage

Hannah: Hi. Welcome to DistilledLive. My name’s Hannah Smith and this is Bridget Randolph, and today we’re going to be talking about something called content everywhere, which is pertinent. Cisco just released some data saying that last year’s mobile traffic was nearly 12 times the size of the global Internet in 2000. Definitely there’s something to be said for device diversification; that’s hard to get your mouth around! So yeah, content everywhere is something that I’ve kind of heard about, but I’m not sure what it really is. Maybe you can explain it for us.

Bridget: Sure. I mean, most of us by now are aware of this idea of mobile design, responsive design, and all these sort of tools that we can use to make our websites more flexible, more mobile-friendly, more multi-channel. And that’s really fantastic. It’s really important. But, in a way, that’s only the first part of the solution, because as we begin to see more and more different types of devices, different ways of accessing our web pages, what we’re starting to realize is actually, there’s two parts to this. There’s the web page itself, which is sort of the layout that you see when you access it. There’s also the content on that web page. And they’re not actually the same thing.

Hannah: When you say content isn’t the same as a web page, those are things that are hard for us to distinguish, I think, given how we’re used to publishing right now. Could you give us some clarification on what you mean by that?

Bridget: Sure. I mean, I think just an easy example is a sidebar, right? A sidebar is a layout element. It’s an element of a webpage. But we could put all kinds of things in a sidebar. We could have a timeline. We could have a list of related topics. We could have a list of other posts by this author. We can even have our call to action button. So we can’t just say this is a sidebar. We also need to ask, ”Well, what’s the content that we’ve put in the sidebar?“ And that’s how you’re separating it out.

So getting back to the responsive design concept, the responsive design for the web page, we say, ”How do we deal with the sidebar?“ Content everywhere, which is sort of responsive design for content, would say, ”Actually, how do we deal with content if it’s a call to action? How do we deal with it if it’s a timeline? How do we deal with it if it’s related links?“ And so on.

Hannah: Do you have an example of that, perhaps, in the wild? So, perhaps, somebody who implemented responsive design, but perhaps has missed something?

Bridget: A great example of this would be, actually, Starbucks, who have made a beautiful website. It looks great on a desktop. They’ve made a beautiful responsive design, so when you look at it on your mobile, it looks great. But what they haven’t thought about is, in rearranging these elements on the page layout, they haven’t thought about how their content fits into that layout. And what they’ve done on the desktop is put their call to action, one of the most important elements of their product page, they’ve put that in the right-hand sidebar. Now, in the design, they’ve decided to move the sidebar, when it shrinks the screen width, to move that sidebar to the very bottom of the page. Fair enough. It’s a pretty standard thing to do in a responsive design. What they weren’t thinking about, though, is having a call to action in the sidebar means that when that page shifts, suddenly their ”Buy Now“ button is no longer visible.

Hannah: I think that’s a great example, not the least because they’ve kept all of their social sharing buttons at the top. So you can tweet about these coffee beans. You just can’t buy them on a mobile, unless you’re willing to scroll and scroll.

Bridget: And I think that highlights, as well, this problem of responsive design, because it’s limited to the layout, and so it’s not thinking about the purpose of a given page’s content. And I think, for instance, if it was a blog post, having those social links might be the most important thing. You might want people to be tweeting it. For a product page, it’s not so great. You want people to buy it. Those are the sort of things that you can get more granular with if you’re looking at it in terms of the content meaning, rather than just the page layout.

Hannah: We’re talking about identifying key elements. So purchase buttons, share buttons, author, whatever. How does that work in real terms? Like, what are we actually doing with that content?

Bridget: There’s sort of two parts to what you need to do to implement this type of system. First, you have to figure out what the content is, what it means, what you’re trying to achieve with it. And then you actually have to put it in a structure that is readable to the web browser or whatever else is rendering it. So you’re going to start by figuring out what you have. You do a content audit. If you have a lot of stuff on your site, that’s probably your first step. Then you’re going to take it and look at what the different pieces are. By that, I mean you might have a blog post. You might have a recipe. You might have a review. Those are all very different, and they’re going to serve different purposes. So you want to break those out, and those are sort of your types, your broad, top-level categories. Finally, you’re going to take each type and sort of do the same thing, and say, ”What are the building blocks? What are the basic elements that serve the different purposes in coming together to create this type of content?“

So an example, actually, to make it more concrete. If it’s a blog post, your type is blog post. Your elements would be title, author. You might have a teaser paragraph that you want to break away from the rest of the body, because you may want to use that on its own somewhere. So anything that you can see yourself wanting to separate out that is easy to divide from the other elements should be its own building block.

Hannah: How does that look to the people who are actually writing and creating this content?

Bridget: That’s a good question. It’s going to depend based on how you implement this technically. But generally speaking, I think what you’d be looking to do is customize whatever content management system you’re using in such a way that if the people writing it are not technical at all, you give them little fields. They can enter it all in separately. But behind that, what it will be doing is using markup, and there are sort of several markup languages that you can use. The one that we, as SEOs, are probably most familiar with would be Schema.org, but that is not all there is to markup. Simply put, markup is simply a way of describing the content that you have. So on a title, it might be a headline tag. It might be an author tag on your author byline. The reason you want to do that, rather than just formatting it as a headline, you want to tag it as a headline, because that way, when it goes out into the world, when it’s being displayed across platforms and shared across other sort of devices, that attribute of it being a headline will still be there, even if your pretty formatting isn’t.

Hannah: The simplest way is to maybe explain it as, like, rather than formatting your headline by, like, making it 20 point, making it bold, maybe italic if you’re that way inclined, go crazy, instead of doing that, you’re letting the CMS determine what size it should be dependent on the device. You’re just tagging it as a headline.

Bridget: Exactly. Yeah, that’s exactly right. And that will help, as well, when it comes time to rearrange it, because you’ll have rules in place that say, ”Oh, a headline is important. It needs to go at the top.“

Hannah: From an SEO perspective, what is it that we really need to do as SEOs? Because a lot of this, it seems to me like it’s a very technical solution, and I’m guessing that, for the most part, at least, it won’t necessarily be SEOs that are building these systems. But what is it we need to care about? What is it that we need to be particularly involved with in the process?

Bridget: As you say, we’re not going to do the technical implementation ourselves. I think it’s more useful to think in terms of how it can help us do our job better, because then we’ll know what to focus on when we’re in the stage of thinking about what’s important.

Hannah: Do you have, like, a concrete example of that in the wild? So maybe a publisher who has an awful lot of content, and they’ve maybe implemented something like content everywhere, and it enabled them to create richer pages as a result?

Bridget: I think a great example of this is actually BBC Food, which has all sorts of different groups of content. You might say they have pages about chefs, they have pages about their food programs, they have pages with recipes. And what they’ve done is linked it all up, because all of these different types of content actually share a common attribute, and that’s a dish. So they’ve ensured, by using this sort of method, that each of these pieces of content includes that element of dish. And what that means is that when you go to the BBC Food page and you click on any one of these things, you have this incredibly rich resource.

You might think, well, that’s great for user experience. Does it actually help with search? Well, the results that they saw indicate it does, because after implementing this, they saw 150,000 more visitors per week, just from search, and doubled their traffic overall.

Hannah: Beyond creating rich help pages, are there any other potential SEO benefits with content everywhere?

Bridget: I think absolutely, because as we’ve mentioned, it’s all about markup, and it’s all about structuring our data, and those are things that are very exciting for SEOs because it basically does our job for us. What our job is, really, is to make sure that web pages that we are working on are very clearly indicating what they do, and all this is doing is taking that to a new level. We’ve seen already a bit of that with Schema.org, for example, which we mentioned earlier. So what we can use this for, in a way, is doing that work for us. Instead of implementing Schema.org on every single page, we can actually just incorporate that when we’re customizing our CMS, so that as the content creator is putting the content into the editor of whatever kind, you can have content fields that map onto the Schema.org attributes that you want to include in the page and set it up so that it will generate that code for you. So I think that’s very exciting.

Hannah: And I guess, really, just to wrap up, what would you like people to do next? Like, what should people take away from this?

Bridget: I think, really, just go out and learn more about it, because it is a system. It’s not going to be your total strategy. But what it does do for us is enables us to sort of scale up all of the content work that we’re trying to do in a way that’s future-proofing it. So we’re not just chasing after the latest device or the latest new platform, but actually we can feel confident that our content will be ready no matter what comes out next, and that’s really important. So it might seem a bit intimidating or overwhelming, because implementing the whole thing would be a lot of work. But what you should remember is you don’t have to do everything at once. You can start by implementing it on a few pages. You can start by choosing a single type of content that you want to work on with. Any little bit that you can do to get started with this will help you in the future.

Hannah: Definitely. Cool. Well, thanks so much for joining us. We’ll see you soon.

Cheri Percy

Cheri Percy

Cheri joined Distilled as a community intern and now heads up the Marketing department in the London office. She has co-ordinated and project managed some of Distilled's biggest content pieces to date and has doubled its social media growth.  When...   read more

Get blog posts via email

4 Comments

  1. Many thanks for the interesting post Hannah and Bridget.

    I've seen quite a few responsive web designs lately that lose content, when the responsiveness of their website kicks in. More content gets lost when the viewing device get smaller.

    Some great things to think about.

    Thanks
    George

    reply >
    • Bridget Randolph

      Thanks George! Glad you found it interesting.

      Mobile is a tricky area, and responsive design has certainly been a great step in the right direction, but I do think we need to make sure we don't think of it as a complete solution. Hopefully we'll begin to see more and more people better integrate their content into the systems as the flaws of pure responsiveness become more apparent.

  2. Great article! Your training page is loaded with great information!

    reply >

Leave a Reply

Your email address will not be published. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>