The Scriptorium Content Ops Manifesto (podcast)
Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Amazon Music | Email | TuneIn | RSS
In episode 104 of The Content Strategy Experts podcast, Elizabeth Patterson and Sarah O’Keefe discuss the Scriptorium Content Ops Manifesto.
“The bigger your system is and the more content you have, the more expensive friction is, and the more you can and should invest in getting rid of it.”
– Sarah O’Keefe
Related links:
Twitter handles:
Transcript:
Elizabeth Patterson: Welcome to The Content Strategy Experts podcast brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way. In this episode, we talk about content ops and Scriptorium’s Content Ops Manifesto. Hi, I’m Elizabeth Patterson.
Sarah O’Keefe: And I’m Sarah O’Keefe.
EP: And so we’re just going to go ahead and dive right in. Sarah, let’s start off with a definition. What is content ops?
SO: There are lots of great definitions out there written by people smarter than me, but the one that I really like is pretty informal. Content ops is the engine that drives your content life cycle or your information life cycle. So that means the people, the processes and the technologies that make up your content world. How do you create, author, edit, review, approve, deliver, govern, archive, delete your content? That’s content ops.
EP: So Scriptorium recently published a Content Ops Manifesto. And in this manifesto, you describe the four basic principles of content ops. So what I want to do is just go through those one by one, and I will of course link the manifesto in the show notes. So the first one you have in the manifesto is, semantic content is the foundation. What exactly does that mean?
SO: I wanted in this manifesto to take a small step back from hands-on implementation advice, and the things that we tell people to do, you need to go through and build out your systems, and here’s how you make them efficient and focus instead on the principles of what that looks like without getting too much into the details. And so with that in mind, each of these principles is intended as a guidepost that would apply for any content operation that you’re trying to build out. Semantic content is information that is essentially knowledgeable and about itself, or self-describing. Now this could be as simple as a word processor file, where you have some paragraph tags that say, “Hello, I’m a heading one,” and “Hello, I’m a heading two,” and “Hello. I am a body tag,” that kind of thing. So you need to have tags, labels of some sort that describe for each, whether it’s a block or a little chunk or a string of text.
SO: What that text is. Is it a heading? Is it body text? Is it a list or part of a list? That kind of thing. So that’s tags. Now, there are lots and lots of ways to do tags across every tool that you could imagine, but you need some sort of semantic labeling. Second, we need metadata. So we need information about the information itself. Usually this is classification tags. So things like, “I am a beginner level task,” or even, “I am a task. I was last updated on this date. I belong to this product or this product family.” So metadata provides you some additional context about the information and describes it further, but it doesn’t really describe the information itself, but rather where the information belongs or who should be using it. Metadata is broadly… If you’re struggling with metadata, take a step back and think about, if I were searching for this information, what kind of labels or tags would I want to use to find what I’m looking for?
SO: And then we have hierarchy and sequencing. So hierarchy means that you’re looking at the structure of the content from the point of view of which things are subordinate to which. So let’s say that you have an installation procedure and there are six things you have to do in a specific order and each one of them is a task or a process of some sort. Well, you need to be able to say these six things are in a group. There’s the installation process, which consists of these six things, that’s hierarchy. And then sequencing is… And they have to be done in this order, right? You have to do one, then two, then three, then four. You can’t start with four and then do one or your installation won’t work. So there’s this process or this idea that you’re collecting up information. And when you do these bigger collections above and beyond a tiny little string, you need hierarchy and you need sequencing.
EP: So the second principle that you touch on in the manifesto is that friction is expensive. And when we’re talking about friction, in this sense, we’re referring to the process that you’re slowing down productivity. So what are some common points of friction and what are some things you can do to eliminate them?
SO: Yeah, so friction is any time you have really human intervention, right? Because computers are very, very fast at what they do and humans, well, we have other skills, but-
EP: We make mistakes.
SO: We do make mistakes, but we’re good at certain kinds of creative things. We’re good at saying these things go in this logical sequence, but what we’re not good at is applying the same formatting consistently over and over and over again. Right? So friction is any place in your process where there’s human intervention. So I’m going in and I’m hand formatting things, or I’m downloading a collection of files, zipping them up, sending them to somebody else who’s then uploading them into a different system and expanding them and reinstalling them there. Anytime you see a process that is driven manually and/or driven by paper, you probably have friction in your process.
SO: And we think these things have gone away, but there are a non-zero percentage of people out there who are doing reviews by the process of, “Let me print this thing out and go give it to you and have you write on the paper and then give me the paper back.” That introduces friction. The problem with friction is if it’s just you and me and we’re working on two or three pages of stuff, and we’re in the same location, not that big a deal. But as you scale, as you have more people and more documents and more languages and more variants, that manual process that used to be okay when we had 10 or 15 or 50 pages of content, becomes unworkable, right? Because it slows you down. So when we talk about friction in a content ops context, what we’re usually talking about is where are these points of manual inefficient intervention and how do we get rid of them?
SO: And when you start talking about eliminating friction, we fall back on things that you’ve heard previously in a non-content ops context, automated formatting, automated rendering across all the different formats that you’re looking for, reuse content instead of copying and pasting, connect systems together so that you can share content efficiently, review workflows that are not human dependent and not paper dependent, but rather roles. I need somebody with the role of approver to look at this thing. I don’t need it to be you personally, Elizabeth, and as it happens, you’re on vacation this week, right? So I don’t want to send it to you. And I certainly don’t want to send it to your email specifically. What I want is for the system to say, “Hey, this thing is due for a review and here are the three people that are authorized to do it.”
EP: So friction, I mean, it’s going to take time and effort to eliminate that friction, but it’s definitely worth it in the long run.
SO: The bigger your system is and the more content you have, the more expensive friction is, and the more you can and should invest in getting rid of it. Yeah.
EP: Definitely. So the third principle outlined in the Content Ops Manifesto is to emphasize availability. What exactly does that look like?
SO: So is content available? What that means is if I am your content consumer, and I need a particular piece of content, can I even access it or have you locked it behind a log-in that I don’t know about or that I don’t have credentials for. So literally, not available to me. The information exists, but I can’t get to it. So that’s question one is, have you made it available and in many cases, availability in that aspect of it is actually synonymous with, “If I Google, will I find it,” right? Because I don’t necessarily know where you’ve stashed it, but if I can find it, then it’s available to me. Now, there are outlier cases where you do need to put things behind log-ins for good and valid reasons and that’s fine provided that your end audience knows, “Oh right. I have these credentials. I’ve signed up for the subscription. That’s where I’m going to go look for the information.”
SO: That’s fine. So where do you put it? What are the rights to get to it, right? Do the right people have the right access and do they know about it to get to it? Now, the second factor with availability is actually accessibility. And here, I mean, in the technical sense of, can I consume this content successfully? So there are a bunch of aspects of accessibility which usually have to do with physical limitations. So we’re talking about things like, I’m colorblind. Did you design the content in a way that I can still use it, even if I have some vision limitations? Is the content consumable by screen readers so that if I have a vision impairment, I can use it? If we’re doing a podcast, is there a transcript so that somebody with a hearing impairment or somebody who’s deaf can read the transcript instead of needing to use hearing?
SO: So you get into this question of, have you provided ways for people to access the information that allows for the possibility that they have some a physical limitation? There’re some others around keyboard navigation, right? Can I tab through the buttons instead of having to click on them? Have you allowed for people that have tremor or issues with fine motor control so that asking them to specifically click on a tiny little button on a screen somewhere is maybe not an option. Is there a mobile option as opposed to a desktop? Maybe I’m accessing all your content from a mobile device and if you haven’t thought about that, then I’m going to have problems trying to read the teeny, teeny tiny print on my not so big phone screen, right.
EP: And we’ve probably all experienced that and it is frustrating.
SO: It’s so annoying. So when we talk about availability, we’re talking about literal availability, like where did you publish it? And do I have access? Talking about accessibility and all the various facets of accessibility, there are lots of useful guidelines on that out there that are more detailed. And then we also need to think about languages and localization. If I’m a non-native English speaker and my comprehension of your text is going to be much, much better in French, which by the way, I can assure you, is not the case for me, you have an obligation to provide that content in French, if you want to market to your primary French speaking audience, right?
EP: Absolutely.
SO: So you need to think about languages. Localization also ties into the question of, well, if I’m writing content for a particular locale, a particular location, you need to think a little bit about what that looks like.
SO: So to take a really basic example, if you’re marketing to somebody in Florida, you probably don’t need to sell them snow pants in October, right?
EP: Probably not.
SO: They are not buying snow pants in October. So that’s like a really basic localization principle that… You want to think about your market and how your market differs by geography or by locale. That gets tied in with language. But they’re not really the same thing, right? You’ve got geographic stuff, you’ve got regional things and you’ve got different regulatory schemes. So for example, to take the infamous example, any legal advice that you’re giving somebody always ends with “comma except in Louisiana.” So, oh, also don’t give anybody legal advice because we’re not qualified, right. But you have to think about those kinds of locales and the different regulatory schemes to make sure that you’re covered and you’re not giving people bad advice based on making the assumption that we all live in the same spot.
EP: Right. So the last principle in the Content Ops Manifesto is to plan for change, which is something that we touch on in a lot of the posts that we publish and the podcasts that we publish. So how do you plan for change?
SO: We really are annoying about change managment.
EP: It’s so important.
SO: It’s our favorite word, our favorite phrase, or actually it’s our second favorite phrase because our first favorite phrase is, “it depends.” But let’s say it this way. When you start thinking about content ops and building up these processes and these technologies and these systems that you’re going to use to drive your content engine, the number one thing that I would advise you to do when you do this is to think about your exit strategy. So in other words, I am buying product X and I’m going to put all my content into it, or I am implementing system Y and I’m going to put all my stuff into it and that’s going to drive what we’re doing. I want you on day one, when you’re going into this really cool system that you’ve decided is going to be the be all end all for at least the next couple of years, to be thinking about what if I’m wrong or what if things change?
SO: What if that company gets bought by a competitor and they discontinue the product? What if the system that you put in place doesn’t work or a new requirement comes along and your system can’t accommodate it. You need to be thinking on day one about, “Okay, well, I’m going to go in, but if I have to get out, do I have a way of getting out? What’s my exit strategy? What is the cost of exiting this particular system or process? What is the cost of changing tools and technologies?” Because I’m not saying you should have a foot out the door. It’s more that we know that change is going to happen.
SO: Change is totally inevitable and somebody is going to come along with a new requirement that we’ve never thought about before, and we’re going to have to meet the moment. And so we need to know A, what things am I picking and are they extensible? Can I add on, can I accommodate these new requirements inside the system I’ve built or selected? And if not, how expensive is it going to be to get out? Now, if the answer is, it’s going to be super expensive to get out, but this thing meets 100% of our requirements right now, it’s extensible in these 15 ways and I don’t see a reason that we would need to get out, that’s okay. That’s a decision that you’re making, but you need to do a strategic assessment of, what is my exit strategy and what are the implications of needing to exit from whatever it is that I’m about to pick?
EP: Right. And I think exit strategy is a good place to wrap things up. So thank you, Sarah.
SO: Thank you.
EP: And if you would like to read the Content Ops Manifesto that will be linked in our show notes. So thank you for listening to The Content Strategy Experts podcast brought to you by Scriptorium. For more information, visit scriptorium.com or check the show notes for relevant links.
About the author
