Scriptorium

In episode 91 of The Content Strategy Experts podcast, Gretyl Kinsey and Simon Bate continue their discussion about using text strings and microcontent. This is part two of a two-part podcast.

“Make sure that their voice is heard. All groups that are using your strings need to have some input or have a way of communicating their needs to the organizations controlling those strings.”

– Simon Bate

Related links: 

Twitter handles: 

Transcript:

Gretyl Kinsey:                   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 continue our discussion around text strings and microcontent. This is part two of a two-part podcast.

GK:                   So then, yeah, we talked about all the considerations for content creation. What about content maintenance?

Simon Bate:                   Well, of course, in content maintenance, again, we get back to the same metadata that I keep harping on, and that is that having strings, having descriptions of the strings, help people perform maintenance tasks. So again, you may have particular reasons for saying things in a particular way, and it’s always good to pass along that knowledge. And not just as folklore within your company, but actually, is there something written down, and the closer to the thing that it’s describing the better. So if you’ve actually got a piece of metadata along with your string that says, “These are the considerations that we need to use when working on this string,” then that’s a good thing to do.

SB:                   Here’s another translation issue, and this is more a maintenance thing with translation. And that is, when you’re sending something off to translation, particularly when it’s individual strings that are just sort of individual pieces of information in isolation, you need to pass along information to the translators that say, “This is where this is going to get used.”

SB:                   And again, this gets back to what I was saying earlier, when you have a string in isolation, a word in isolation, like the word file, it could mean it could be a noun, or it could be a verb. The translator needs to know that piece of information.

SB:                   Along with maintenance comes sort of a management aspect to it. And that is, it’s always a good idea to identify a responsible individual or a group that is responsible for overseeing things, like the aging of content. At some point, somebody has got to go through all these strings and say, “Oh, this one’s no longer used. This is no longer necessary, and remove them from the database.” Also, what you’ll find, this is a classic reuse issue, is if you have a string and it’s reused in a number of devices, and then one device changes slightly which renders a string ambiguous or not meaningful anymore, you may need to decide, okay, it’s time to create a new version, a separate version of this string for use in this case. And so it’s always good to have some group to oversee or control how often strings get modified or how often they get forked into separate strings for separate uses.

GK:                   Yeah, absolutely. And having that kind of an individual or a small team in charge of that is especially important if you have multiple departments, or maybe even every content-producing department across the entire organization all coordinating and working together. You might have everybody in one repository or in separate, but connected, repositories and they’re all collaborating on the content, and they all need to make sure that there is kind of that one person or one group in charge that can make sure that one department isn’t just kind of going off the rails somewhere and making decisions that could affect all the rest.

SB:                   Yeah. And also, at the same time, it’s really good to make sure that people don’t feel left out of the process. So you also need to make sure that their voice is heard, for all groups that are using your strings, that they all have some input or have a way of communicating their needs to the organizations controlling those strings.

GK:                   Yeah. And I think this really gets back to what we talked about way earlier in the beginning, about how a lot of people, when they’re in the planning stage, they might start with that spreadsheet. And I think if that originated out of one department, it’s really important to make sure that any other groups who are going to be involved in the content are all aware of what’s in there. They maybe get a chance to come in and add their own ideas or their own requirements to that spreadsheet. Or if they’ve got a spreadsheet of their own, that it all gets consolidated. And that’s probably one of the best times in your project to choose who this responsible individual or group is going to be. And then that way they can take it smoothly or as smoothly as possible. It’s never perfectly smooth, but they can take it as smoothly as possible from that planning stage in something like a spreadsheet into your actual DITA environment.

SB:                   Yeah, that’s right.

GK:                   So now let’s talk about that third piece, which is content delivery. So what are some of the implications on the delivery end for microcontent and strings?

SB:                   Of course, the main idea about delivery is, you’ve got these strings and they’re in your repository in some form, and they have to be then output in a form that can be consumed by the device with the software that’s going to be using those strings. And of course, if you’re maintaining your content in DITA, good thing is, you can then use the DITA open toolkit to transform your strings in your CCMS into some delivery format. And the typical delivery formats that we see, there’s just plain text we’ve seen. Sometimes, there’s the need for comma separated values. But then also JSON is, nowadays, a very common format for encoding information. Many devices are set up to consume it.

SB:                   One of the real advantages of JSON is that in any number of languages now, the JSON files can be opened and consumed as a database almost immediately. JSON actually uses JavaScript syntax for marking it up. So you can actually take a JSON file and just plug it into JavaScript, and all the information is available using standard JavaScript selectors. For other languages, it’s only a little bit, only slightly, more difficult, but it’s a very flexible tool and a very effective way of saving information away.

SB:                   So of course, when you’re creating your output format, the software or the device that consumes those strings is going to have very specific expectations of those strings. It’s going to have expectations of the format of the strings, and expectations about the tagging. So how are each of those individual strings identified? In some cases, you don’t have much say over that. Sometimes the hardware department’s usually months ahead of you in terms of development and things, and by the time you deliver, everything’s on silicone and there’s nothing you can do. If you’re lucky, you can start early enough and start to negotiate, start to discuss with the hardware team, what might be necessary for supporting these strings. Are there things they haven’t thought about? And so then you can actually get some… Dialogue can occur between your groups about what they expect and what you can deliver.

GK:                   Yeah. And I think we’ve seen a few examples of this just in the way that some companies organize their departments. In a lot of cases, there’s a separate content department that does all of your technical documentation. Maybe there’s another one for your marketing, another one for your training. But we’ve also seen a few companies that do something more like, there’s each department for maybe a product line, and then they have their own, a writer or two, who kind of reports to that group or is ingrained there. And that’s really showing that that company values their content and is willing to kind of have that conversation earlier in the game. And I think that, even if you do have more of that sort of traditional structure where you have a content department, it’s still important to have people from that department going out and talking to your product developers, to your hardware team, and just coordinating earlier rather than kind of shoehorning either group into something.

SB:                   Yeah, absolutely. Communication among groups is essential.

GK:                   Yes.

SB:                   It’s essential for good product delivery.

GK:                   So what are some other considerations around JSON?

SB:                   Now, these are some considerations for JSON, but they may be applicable to other output formats. This is probably built in by the people consuming the JSON. But you do need to figure out, in JSON, a way of passing the JSON markup characters in your strings, and particularly the quote signs. So you have to have some way of encoding a quote. Then when they receive the quote, the quote sign, they can decode it.

SB:                   Now, the reason I call that out is, within JSON the quotation mark, double quotes, is used to delimit a string. So we have an open quote, close quote, but if you should actually need to use a quote in the middle of that string, you’ve got to do something so it’s not interpreted by JSON as being part of the JSON itself. That’s a syntax violation. Quotes need to be encoded, but also, it’s good to do the same thing for other JSON markup that may occur within your strings. For instance, square braces, curly braces, and semi-colon are also characters that are very important to the JSON syntax, and probably should be encoded.

SB:                   Another thing really worth considering is that strings in JSON, once you say, “Oh, this is a string,” that’s just all it is. It’s just a sequence of characters. And so if you’re thinking about something like DITA markup, within a DITA paragraph, you start a block object, a paragraph, and you can write characters, and then you can drop in, inline, DITA markup that does things to the characters. Like you could say, “Change to bold,” “Change to italic.” There’s a number of other things you can do for markup within a particular paragraph.

SB:                   If you take that paragraph and move it to JSON, all you’re going to have is the series of the characters in that paragraph with no markup, because there’s nothing within JSON for an individual string to have inline markup.

SB:                   Now, there are a couple of ways of dealing with it. And one is actually to have very complex JSON, but have the JSON understand that it’ll output individual objects for each piece of text in each individual format. So you might have an object that is just regular text, followed by an object which is italicized text, followed by another object which is normal text.

SB:                   Another way of dealing with this, and again, it’s based on the consuming system, if it can deal with this, you can actually drop something, an encoded form of markup, within your strings. So you might use a whole separate character set other than the JSON characters to say, okay, here’s regular text and here’s where italic text would start. And then here’s where italic text gets turned off again, and so on. But again, a lot of this is based on the consuming system. A lot of this gets back to our previous discussion about, you’ve got to be talking with the people designing the devices or consuming the content, and they have to know that inline text may be an issue, or they may say, “No, we’re not going to deal with inline text at all.”

SB:                   One final thing about just generally generating output, and this gets to all levels of things, and we see this a lot. And so it’s always good to sing it out. If the particular form of output needs to be in a different case, say all uppercase, or InitCap, or something like that, your sources don’t have to be in all uppercase, because that kind of character change can always be done by your output formatter. So as you’re transforming it in the DITA open toolkit, you can just say, “Oh, output this string, and while you’re outputting it, change the case to uppercase.” So it’s always good when your sources keep to minimum change of case within those sources.

GK:                   So now that we have talked through, we started off with content creation, went into maintenance, and wrapped up with delivery, I think one really good way to kind of tie all of this together is to talk about project management expectations. And we already touched on it a little bit. We talked about content governance and having that small team or an individual to sort of oversee everything, but what are some project management expectations that people need to keep in mind when it comes to working with text strings or microcontent?

SB:                   The main one, and it gets to sort of business common sense, you may have very high expectations about what you can do, the people who are taking in the content and they have high expectations about what they can do, but there may need to be, at some point, a middle road. There may need to be some compromise, a compromise of, what is the best you can do versus what is it that the device is capable of doing, or what is it that we are capable of delivering?

GK:                   Yeah.

SB:                   So there has to be a compromise.

GK:                   And I think a lot of what informs that compromise is cost and time. So you might have the technical capability of doing something, but if you don’t have the budget for it, if it doesn’t make financial sense, or if it’s going to really conflict with some of the time constraints you have, some of your deadlines, then it might be something to kind of consider for the future and slowly roll that out. But that’s one of those things where you can’t just have everything and you do have to make those compromises.

SB:                   Yeah, yeah. In my role of programmer, I often think, “Well, everything is possible. The question is, is there money to do it?” So I think the other thing to keep in mind with project management is that having strings, short text strings, microcontent, you can do a lot, it’s a good way of maintaining things, but it can’t necessarily solve all the issues that you may have. There may be need to go to other ways, like full-text strings, or other considerations for how you encode or transform this information.

GK:                   Yeah, absolutely. And I think that really is a consideration, not even just for strings or micro content, but for everything that… There’s no sort of one size fits all way to solve all of your problems. So it really does get back to what we talked about in the beginning, about planning your strategy and sort of figuring out how does the use of microcontent fit into your larger solution.

GK:                   Well, thank you so much, Simon.

SB:                   Absolutely.

GK:                   And 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.

The post Using text strings and microcontent (podcast, part 2) appeared first on Scriptorium.

In episode 90 of The Content Strategy Experts podcast, Gretyl Kinsey and Simon Bate talk about using text strings and microcontent. This is part one of a two-part podcast.

“They’re starting to get the idea of taxonomy and how important it is for all parts of their business to communicate using the exact same language. If this can be captured and put in one place, then those strings can be available to everybody.”

– Simon Bate

Related links: 

Twitter handles: 

Transcript:

Gretyl Kinsey:                   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 using text strings and microcontent. This is part one of a two-part podcast.

GK:                   Hello and welcome everyone. I’m Gretyl Kinsey.

Simon Bate:                   And I’m Simon Bate.

GK:                   And we’re going to be talking today about text strings and microcontent, so I think the best place to start is just by defining what each of those things are.

SB:                   Yeah. Well, text strings, it’s one of these things grew out of computer science, and all it really means is it’s just a sequence of text characters. Usually, it’s a paragraph or shorter. It’s more often just a sentence or just a snippet. It’s just, essentially, a series of individual characters.

SB:                   Microcontent is a little bit more specific and it has a number of definitions. The first one was about 1998, Jacob Nielsen coined it as a small group of words that can be skimmed to get a basic idea. And the idea here is something like a title or a headline or something like that, where you just look at it and you can see immediately what’s there. Since then, it transmogrified, and now it often refers to small information chunks that can be used alone or in a variety of contexts. And of course, one of the big contexts that people are really interested in using microcontent now are chat bots and voice response systems.

GK:                   Yeah, absolutely. And that gets into one of the next things I wanted to talk about, which is all the different ways that we’ve seen this concept of microcontent come up in our work with clients. We’ve had all kinds of different requests around using microcontent and use cases for it. So what are some examples of that?

SB:                   Oh, we’ll get things like, people say we need all our strings maintained in just one place, that then we can use those individual strings on a number of device interfaces. Sometimes people have a localization issue. They’ve got these strings and their devices, wherever their strings are used. And in this case, I’m talking about strings that are often used as part of an onboard device control system, so you get a small, little display panel and it pops up some words, some phrases or instructions about what someone’s supposed to do. Some of these are localized to many, many different languages, and so, it’s good to be able to have those strings all in one place and be able to localize them in a good, organized way.

SB:                   Other people will say they’ve got a new device coming online and it needs its strings in JSON format. And so, they need to know how to write and maintain the content and then export it so then it can be available in JSON.

GK:                   And just for context, for those who may be unfamiliar, what exactly is the JSON format?

SB:                   Yeah. JSON is a form that grew out of a JavaScript, actually. And it is a text way of simply describing a structure. You can think of it in many ways. It’s very much like XML, not in the way that it looks, but in the way that it’s organized. That essentially, within JSON, you have an idea of individual objects and those objects can be arranged in arrays, objects can contain objects, and so on. So it’s a way of labeling and structuring information.

SB:                   Sometimes we have requests, people just need company-wide consistency of terms. They’re starting to get the idea of taxonomy and how important it is for all parts of their business to communicate using the exact same language. If this can be captured and put in one place, then those strings can be available to everybody, and everybody, when they need them, they can say, okay, I need the string that describes this thing. And so, quite a lot of the time we hear that request.

SB:                   Another simple one we’ve just described earlier, they say, we’re implementing a chatbot. We need a way of creating and maintaining the strings. And of course, when you have a chatbot, of course, there’s loads of metadata that goes with those strings. So they have context and that has to accompany it. And sometimes, we get people, they’ve actually worked out a lot of these problems before, but they say our spread solution isn’t workable anymore. So essentially, they’ve got all these strings, but they’re maintaining it just as a spreadsheet and trying to add new columns when they add languages, or add new columns when they add additional uses of a term, and so on. But in some ways, they’ve actually got some of the issues worked out. They just need a good way, a good repository of storing the information.

GK:                   Yeah. And that really gets to some of the things we’ve talked about in some of our previous episodes around taxonomy and metadata, that planning things out in a spreadsheet is a really great starting point, but you do eventually hit this turning point where it’s not really going to be sustainable as you scale up. So that’s really a great point when you reach that to say, okay, maybe we do need to look at a different way to work with these strings.

SB:                   And that goes two directions too, because there’s the spreadsheet itself and the structure of the spreadsheet and trying to keep the information in it, and then there’s the whole management issue of who has the spreadsheet? What’s the latest spreadsheet? Now, of course, now with Microsoft Office online and tools like that, maybe the spreadsheet can be shared around, but there is often an issue when you’re maintaining things in a spreadsheet about who has control over it. And whereas, if you have a CCMS or something like that, then the control over the content is much more easily controlled.

GK:                   Yeah. You have a lot better control, like you said, over the content governance aspect, whereas when everything is just in a spreadsheet, you’re locked out in a way and it’s not as easy to disseminate that information to everybody. And this gets into the next thing that I wanted to discuss too, which is the idea of planning. because I think spreadsheets are a lot of times the starting point for that. So when people start to plan for the use of these text strings or microcontent, what are some of the factors that go into that?

SB:                   Well, there are really three angles to planning your text strings or microcontent and they are content creation, the maintenance of that information, and then delivery. And all of these factors inform your final design. And it’s a mistake to try to tackle these in order and say, Oh, let’s design the creation first and then handle maintenance and delivery. They all have to be developed all at the same time.

GK:                   Yeah, because all of them really play into each other in different ways. And when you are coming up with that strategy and figuring out that plan, you have to think across all three of those different angles. So let’s dive into each of those a little bit more and talk about, first, the aspect of creating content.

SB:                   Yeah. So often, when you’re creating the content, an XML solution or particularly DITA works very well for maintaining the content.

GK:                   And then, with one of the things that we see often with DITA is reuse, so how does that come into play?

SB:                   Well, it depends really how it’s going to be used, because there are two ways of looking at it or two ways of using reuse. One is you may be creating strings and those strings are output. And then, that output is reused across a number of individual devices. And then, there’s also the true DITA sense of reuse, in that you create these strings and you make them available for reuse across topics. You could actually need strings for both of those purposes, but in some ways, that’s going to inform your decision about how exactly you store the content in your storage solution.

GK:                   Yeah, absolutely. And we often see the need also for different forms of the same string. So, for example, a version of it that is abbreviated. So how is something like that identified?

SB:                   A lot of it’s, you have to know your content. Look at your content and know how it’s used. And this is a really big thing when you get to device strings, because there are times when the same string or the string with the same idea may need to be expressed in a number of different ways. You may need a short form of the string. It could be a phrase or a sentence or instruction, but there could be some applications where there’s not that much screen real estate, or they need a smaller number of characters to communicate the same thing. So you may actually need two different forms of the same string. You need a long form and a short form.

SB:                   And then, as we were talking about abbreviations, there are also times when you have a string or you have a term, and sometimes you just need to use that term abbreviated. You could actually be using these strings to kick out labels or something that go on a display panel or something like that. Sometimes those need to be abbreviated.

GK:                   Yeah, absolutely. I want to talk about some of the other considerations that go into this. And one of them that’s a really big one is metadata. So how does that come into play?

SB:                   Yeah. This is absolutely a big area of what you have to think through in planning your project. There are two main areas where metadata is going to come into play. And one is for your authors, because as they’re creating the content, they need to know what is the string for? What’s the final purpose of the string? Where is it going to be used? And that then informs also for the authors, what are the considerations they need to use when writing or maintaining it? You may need to leave an instruction behind or something to say, this can’t be any more than 50 characters, or I made a particular decision or corporate or legal has made a particular decision about what we can say here or what we can not say here. So that kind of information is really useful if it can be maintained in metadata, along with that string.

SB:                   Now also, there’s how the string itself is going to be used. So the consumer end, so there may be something like there’s an identifier associated with that string. Because when you create a GUI, from the GUI, for every component in the GUI you’ll have an identifier. And if you can use that identifier then to link to the string, you know which string is going to be used for which component in the GUI. And when I say GUI, of course, I mean, graphical user interface. And the others are things like keywords and things that might be used by a chatbot, or a voice response system.

SB:                   One good thing to know in metadata is there are emerging standards for some of the metadata. In particular, TCOM is building a metadata standard. It’s been out for a little while now. It’s called the IIRDS or intelligent information request and delivery standard. And it’s a standardized metadata vocabulary for describing technical content. It’s sensibly built because there are some things that are just fixed and standard pieces of metadata, but it’s also built to be expanded. You can add your own content to the metadata, because of course, every use, every application of these strings is going to have its own special needs, its own special considerations.

GK:                   So in addition to metadata, another big consideration is localization, right?

SB:                   Yeah. This is a number of considerations you have to apply if a localization is going to be one of the reasons why you’re creating these strings, or if your strings are going to be localized in the first place. Number one is there’s often a difference in length of strings for different languages. If you’re going to be localizing English text, say to German or Russian, there’s a great expansion of the length of the strings. Now, the people building the devices where your strings might be used will also have to know that the device itself is going to be marketed in other areas. They’re going to have to be able to accommodate these longer strings. This Eventually comes down to the creators and they have to know that within a particular language, the strings may have a maximum length. There may be of maximum screen interface. And again, that gets back to the metadata that describes the strings itself and what is that string for?

GK:                   So what about cases where people are trying to think about localization and they’re doing some shortcuts or work arounds and saying, Hey, we can just have this one piece in the middle of a sentence be a string, right?

SB:                   Yeah. Well that can work. And unfortunately, it works very well in English, but doesn’t necessarily work very well in other languages. And there’s a number of things to consider. And even in English, there are some issues if you’re just going to be substituting a single word. For instance, the definite articles a and an which depend on the following letter, is it a vowel or is it a consonant? So just trying to swap out a single word there is going to be problematic. It gets worse when you get into other languages, gendered languages. There’s a number of other considerations to take in mind there. So you just have to be careful, know your languages, set your expectations for what languages you’re going to go to.

SB:                   Another thing to consider, and this is not just for string substitution, but if you’re using short words, if you’re using individual words, again, English has this nice facility of we’ll have words like file that serve both as nouns and verbs. And so, you could write file and it’ll work very nicely in one use, but when it gets translated, there’s a question. Is this to be used as a noun, a label, file? Or is this actually an imperative, a verb denoting some action. Do you have to file? As you’re thinking about localization, again, it’s really important to keep these things in mind. And again, this is where the metadata describing what this string does.

GK:                   Yeah. This is something that we often caution people about when we know that localization is on the table or if they think it might be as they grow in scale. And that’s one of the reasons why some of the general advice that we tend to give is that if you are going to make a short phrase or a single word into a string that can be reused at different places, that you stick to something that’s going to be pretty safe, like a product name or a company name, something that is maybe not even going to be localized depending on how you do your branding, but something like that where the risk of the way the word is used is a lot less great than it is with just a normal word that’s part of your text. If it’s part of your brand and terminology, it’s likely to be a little bit safer when it comes to making it a string.

SB:                   Exactly. And so, yeah, sticking to product names and things, or just considering keeping it at the sentence-level. So your string should be the whole sentence. Even if that string has to get translated every time into a different language, in some ways that’s going to be a whole lot better, more predictable, get more predictable results than trying to do any of this swapping.

GK:                   Yeah, absolutely. So if you’re using DITA and you’re working with strings or microcontent, what are some of the possible models that you might use for that?

SB:                   There’s a number of ways you can look at it in DITA. And of course, a lot of this is informed by how your strings are going to be used. One approach, and some people might arrive at fairly quickly, is the idea of using keys. And there are some advantages there, but keys used directly may also run into some issues. They’re fine for single strings in isolation, but if the key itself needs to have any kind of DITA markup, you run into problems, mostly because of the DITA content model and what is allowed inside keyword, which is if you’re using keys for short pieces of texts and the keyword is the element you’re going to be using.

SB:                   Now, I say directly, because we can also use keys to identify glossary entries. And a glossary entry topic actually is something really worth considering to store these strings, because already the glossary entry topic has a number of elements for usage, different forms. It has already elements that identify acronyms or expanded forms. And DITA itself is set up to process these with the abbreviated form element. There’s a lot of good things in DITA. And you may want to consider maybe not using glossary entry straight, but actually specializing it. And of course, that always has the advantages that you’re going to be working with much more, much better semantics. If you specialize, you can actually identify for your users exactly what they’re going to be doing.

SB:                   Of course, you know, there is a downside to using the glossary entry. And that is just because it’s a great overhead. It essentially means for every string, you have to create a new topic. So this is potentially a vast number of topics you’ll have to create. So for some uses, that might be okay. For others, you may want to pull things together more. And so, you might consider creating topics, organize those topics with sections within topics, and then within those sections, you can either define individual words, strings. There’s a number of different ways you can do it. Again, you can do specialization. Several of the things we’ve done for people using strings, we’ve actually created specializations that help them manage the individual strings, the metadata that goes with those strings.

SB:                   Another thing we’ve seen is using tables. And tables themselves, of course, it gets back to the spreadsheet idea, but steer away from that for a moment. And nice idea about a table is you can have a string. You can have columns for the string itself. You can have a column with the ID. You can have a column with the description about where that’s going to be used. You can have abbreviated forms and so on. And of course, the advantage there, the differentiation with a spreadsheet is if you’re going to be translating, then the translation occurs at the topic level. And so, you’ll have a separate topic for every language, or a separate version of that same thing in each language.

GK:                   We are going to wrap things up here and continue our discussion in part two. 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.

The post Using text strings and microcontent (podcast, part 1) appeared first on Scriptorium.

In episode 89 of The Content Strategy Experts podcast, Gretyl Kinsey and Bill Swallow talk about strategies for avoiding the misuse of metadata and DITA XML-based content.

“The more you fine-tune how your content model needs to operate, the easier it’s going to be to move it forward over time. The more you start taking shortcuts and using metadata for purposes other than what it was intended for, the more problems you’re going to have.”

– Bill Swallow

Related links: 

Twitter handles: 

Transcript:

Gretyl Kinsey:                   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 strategies for avoiding the misuse of metadata and DITA XML-based content.

GK:                   Hello and welcome, I’m Gretyl Kinsey.

Bill Swallow:                   I’m Bill Swallow.

GK:                   And we are going to be talking about all the different ways that we have seen metadata get misused in DITA XML. Before we dive into that subject, Bill, what is metadata in the context of DITA? And how is it used just for anyone who may be unfamiliar?

BS:                   In the context of DITA, metadata is a series of elements and attributes that are applied to your DITA content in order to give it some meaningful purpose. A lot of times we see it as profiling metadata, so being able to set, for example, an audience on a topic to say, “This is only for beginner people.” This way, when you publish your output, you can turn on or off your beginner audience content and produce either a beginner guide or a more advanced guide without the beginner information in there. Metadata also allows you to do more interesting things with your content. One example that we see with metadata in the standard DITA implementation is around notes and warnings and cautions. They’re all the same root element of note, but you can use a type attribute to set whether it is a note, whether it is a caution, a tip, a warning, a danger flag or what have you. That’s an example of how metadata can influence the type of content that you have in DITA.

GK:                   Yeah, absolutely. It’s essentially we describe it as data about data. It’s all of the information in your DITA content that does not actually get printed or electronically distributed, I guess you could say, on the page. It’s everything that’s making it run kind of behind the scenes, but it’s not actually part of your published output. It can influence the way that it is produced as Bill described, the way it’s sorted and searched and delivered. But it’s not something that you actually see, like the words on the page. And I think that that can cause a lot of the confusion that makes it get misused because when people are coming into DITA from a mindset from desktop publishing, the way that metadata works there is quite a bit different. And I think that getting into that mindset of the proper use of metadata in DITA is a really big shift. I want to talk about some of the examples of misuse that we have commonly seen and fixed with a lot of different cases.

BS:                   I think probably one of the most common examples we’ve seen with regard to metadata misuse has been around using metadata or generic metadata buckets for very specific purposes. And one of these is the output class attribute that a lot of people end up using as formatting instruction within DITA. Which kind of breaks the rules of DITA itself because you generally are going to DITA so you can separate your content from its formatting. But here, we often see output class equals red or output class equals 16 points, where they’re adding instruction that wasn’t built into the transform itself in order to tell the transform how to render a piece of content. And it blows my mind, but it is one of the most common things we’ve seen.

GK:                   Yeah. And that just, again, it comes from that mindset of working in something like desktop publishing, where you do get to control all the little bits and pieces of the formatting at an individual level. And when you go into something like DITA, where your formatting is separated from the content and is automated, it can be really, really difficult to get your mind past that shift. And so then we see a lot of instances where people go, “Oh, I’m really limited. I can’t make this one piece of text bold anymore or I can’t turn this green anymore.” They just find the workaround of putting an output class on it. And what happens over time is that that misuse of the output class attribute ends up completely defeating the purpose of having automated formatting, because you’ve put all these overrides everywhere. And if you actually had a more legitimate use of output class, then that’s kind of ruined too by the fact that you have misused it in all of these places.

BS:                   Another bit of metadata misuse that we’ve seen is using one metadata element or attribute for another purpose, a purpose it wasn’t designed for. One example could be that you might be setting audience to let’s say a different country, which kind of makes sense if you want to be able to filter on certain types of content for certain geographies, but really that level of metadata should be held up in the xml:lang attribute where you’re describing which language and which country this content is aimed toward. If you’re labeling something for a German audience, regardless of whether it’s in English or in German, you really should be using the xml:lang attribute as opposed to profiling it for a German audience. Now, there are some differences that you can get into as to whether you want to include or omit certain types of information for a particular audience but in general, you have to be clear about which elements and which attributes you’re going to use for which specific purpose.

GK:                   Yeah. And audience is a really interesting one because I’ve seen a few different cases where if the audience that a company is delivering for is really complex and there are maybe a lot of different ways that they need to kind of parcel out the content for different chunks of that audience, that just the default metadata for audience in DITA isn’t really enough for them. And some of the workarounds that I’ve seen them do are they’ll use audience for kind of one facet of their total audience and then they’ll go in and pick another metadata element or attribute for another facet of their audience, when it’s really not designed for that. And so that points to the fact that if you’ve got complexity that’s not really built in, that you need to start looking at a more effective way to handle that than just shoving it into a metadata element where it doesn’t actually fit and where it’s not designed for it.

GK:                   Because then what happens down the road is if they actually did need to use a different metadata element that they had designated for a part of their audience and later they need to use that for its intended purpose then it’s already taken up with however they’ve described it for that piece of their audience. And then they have to do a lot of reworking. It really is important to kind of think about this. And I know we’ve talked about this in some of our other podcasts about planning out a taxonomy and thinking about your metadata as a whole before you go in and just start assigning it to the DITA elements and attributes.

BS:                   Right. And then even if you’re not misusing an attribute, a lot of times we do see cases where other meta is just used throughout an entire content set, where you’re essentially defining custom metadata, which is good, but you’re doing it in a very generic way that usually requires a lot of, well, it usually involves a lot of user error because everything is hand-typed at that point.

GK:                   Yeah. I’ve seen a lot of instances where that’s just kind of used as a catch all or a place to shove anything that doesn’t fit into all of the other existing metadata categories that there are. And then what happens is later when you need to organize that better, everything has just been shoved into other meta and there’s not really an easy way to kind of parse that back out and define it without doing a lot of work. It really is, like we said, helpful to plan this out ahead of time, think about all the different metadata that you’re going to need and figure out where and how it fits into DITA’s metadata structure.

BS:                   Absolutely. The more you fine-tune exactly how your content model needs to operate, the easier it’s going to be to move it forward over time. The more you start taking shortcuts at the beginning and using metadata for purposes other than what it was absolutely intended for, you’re going to have a lot of problems unwinding that as your content set grows, as your publication breadth grows. You’re just going to run into problem after problem after problem so it’s best to do it the right way. Rather than shoehorning a bunch of metadata into random elements and attributes and using other meta wherever you want to and output class and all these other things, probably want to talk about what might be a better approach?

GK:                   Sure. Of course one is specialization and that is the ability that DITA has to create custom elements and attributes based on the structure of existing ones. And this is absolutely something that you can and should do with metadata if you have that need. And this is really, I think one of the more common areas where we see specialization among our clients. That a lot of times the actual topic and map structure is fine, but there are metadata requirements that they have that just do not fit within what’s available by default in DITA. Coming up with some sort of a taxonomy before you start putting everything into those default DITA elements and attributes can help you see where, okay, maybe we might need a specialized element or set of elements or attributes for the specific type of metadata. And that really gives you a roadmap for how that might work.

GK:                   And I think one thing to look out for is if you do start with a kind of set metadata structure and then things change over time and you start noticing a pattern, that you may be are using other meta a lot or output class a lot for the same kind of thing over and over because it just doesn’t fit, that can oftentimes kind of be a little red flag to you that, hey, maybe we need to go back and take another look at this and think about specialization for that kind of information.

BS:                   Right. A lot of people are really hesitant to look at specialization because it means customizing the DITA model and really doing some very high tech and difficult things. And from a metadata perspective, it really is the best way to get in there and make the model work for your content and for your needs. And the beauty of the specialization approach is that once you’ve implemented it, it carries forward. You can update DITA from version to version, to version, to version and your specialized content will work. Your specialized elements and attributes will just work. It’s not divorced from the model. You’re not dealing with some FrankenDITA thing that’s never going to be able to be updated again. It’s really the ideal approach to wrestling with metadata and making sure that you have the right buckets for the right types of data about your data.

GK:                   Yeah, absolutely. I want to talk about another feature that can easily be misused but also it can be really helpful if it’s used correctly and that is subject scheme. And subject scheme is basically a special type of map that’s available in DITA that allows you to bind specific values or sets of values to attributes. And this can kind of work sometimes as an alternative to specialization if you don’t really have a compelling enough case for specialization yet, but you still need some sort of a custom set of values for your attributes.

GK:                   And some examples we’ve seen are again, if we go back to the example we talked about for audience and you want to define a list of different pieces of your audience that is kind of more complex than maybe something like beginner, intermediate, advanced, then you can set up that list in your subject scheme, you can set up hierarchical lists of values and it really just makes it a lot easier for your writers to avoid mistyping something because they have a pick list that comes from that subject scheme. But again, it’s also something that can really easily be misused.

BS:                   Absolutely. And the other piece about a subject scheme is that you can set it up so that you do have that finite list of values and you only have those values available. And that really allows you to only provide the values that you have handling built in for. If you are experimenting with different types of metadata and you don’t necessarily want them in a production mode, you can exclude those from some of the lists, depending on the authors that are working on it. You might have an experimental batch of authors that are working on the next latest and greatest batch of content, but for a lot of the content, that’s more in a maintenance mode or is using the existing publishing workflows that you have established.

BS:                   You can limit the metadata values to just what’s in the subject scheme, that’s all they have available so they don’t accidentally create something or mistype something that is not going to be handled. Because usually the publishing instruction will basically say, “I don’t understand this value. I’m just going to throw it away and just go with the content that’s there.” And that could be very detrimental if you’re publishing something that has metadata applied to it that says, “Do not publish this in this scenario,” in which case, then you get content that you didn’t intend in your output.

GK:                   Yeah. I think kind of one of the other ways I’ve seen people misuse subject scheme is that when they start to approach it as kind of a stop gap between having no specialization and eventually getting into specialization for their metadata, that over time, it starts to become really unwieldy and they’re trying to kind of shove, I think, too much complexity into some of those lists of values and really try to make it a substitute for specialization when really it’s not. And I think that’s another one of those things to look out for as kind of a red flag. Is that just like in your content, if you find that you are using output class excessively for the same thing, if you’re shoving into other meta too much, if you get into a subject scheme and you realize that it’s not actually helping with the complexity of everything that you need to capture, then that’s another one of those red flags that says, “Hey, we should look at specialization.”

BS:                   And likewise it hearkens right back to your taxonomy as well, because at the point where you’re using subject scheme, it should be reflecting what’s in your taxonomy. If there are additional things that you need to add that aren’t available in your pick list for the subject scheme, chances are they’re also missing from your taxonomy, which means you have some more thinking to do on exactly how you are categorizing your content.

GK:                   Absolutely. We’ve talked about taxonomy as kind of a way to make sure that you avoid that in this use of metadata. Another one I wanted to bring up is also not just to defining a taxonomy, but defining your formatting and your presentation needs as much as you can upfront as well, because that’s also going to play a role in where you might need some custom elements or attributes that can drive things a lot better than just using output class all over the place.

BS:                   That’s a good point. And I think the final thing that we want to mention is that you want to future-proof your content model as much as possible so that these needs are either expected or at least your model can grow as expectations grow from others of that content model. Being able to have specific metadata that’s specialized for your exact content is going to make it a lot easier to be able to introduce new values, to be able to constrain against specific values for that metadata and also having that mature taxonomy model as well will help you in that regard.

GK:                   Yeah. If you think about future-proofing and think about planning your taxonomy, planning, your publishing needs, planning your distribution around that, then that will really kind of help shape the way that you think about your metadata use and make sure that you allow for that growth and that scaling that should happen in your company if you’re going in a successful direction. Before you just start going into DITA and building the metadata, it really requires that level of forethought to make sure that you’re not going to misuse anything.

GK:                   And we’re going to wrap things up there. Thank you so much, Bill.

BS:                   Thank you.

GK:                   And 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.

The post The misuse of metadata (podcast) appeared first on Scriptorium.

In episode 88 of The Content Strategy Experts podcast, Alan Pringle and special guest Amber Swope of DITA Strategies talk about information architecture.

“Information architecture is a role, not necessarily a position, but by ignoring it, you end up without the discipline and the consistency that really enables great customer experiences.”

– Amber Swope

Related links: 

Twitter handles: 

Transcript:

Alan Pringle:                   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 information architecture with special guest, Amber Swope, of DITA Strategies. Hey everybody, I’m Alan Pringle, and today we have a guest on the podcast, Amber Swope, of DITA Strategies. Hey there, Amber?

Amber Swope:                   Hi there, Alan.

AP:                   So, let’s start with the basics here. Give me your definition of information architecture.

AS:                   Well, as you know there is no common definition of information architecture-

AP:                   No.

AS:                   … So rather than getting frustrated by that I chose that as an opportunity to own the version of it I want to have. So, I go with the Samantha Bailey definition that starts with information architecture is the art and science of organizing information so that it is find-able, manageable and useful. I really like that definition because it acknowledges that there’s art and science to this practice.

AP:                   Also, there’s not a whole lot of jargon in that definition, I appreciate that a lot too.

AS:                   Yeah. And particularly the science part is obvious to see. So for instance if you’re using an open standard DITA, then you could have five IAs, give them the same challenge, tell them which version of DITA they’re going to use, and they would probably come up with solutions that are 80% consistent. But that 20%, that art is where different information architects will bring to bear their experience and potentially give you something slightly different which is why it’s always great to have more than one information architect on a project.

AP:                   Sure. And there is absolutely an element of judgment call to it as you have said, it is not just a straightforward everybody’s going to do the same exact thing. There is no book basically that tells everyone how to do it exactly the same.

AS:                   And I also take this a step further and make a delineation between management information architecture and delivery information architecture. And I found that most information that is available for information architects is dedicated to delivery information architecture. That is the architecture, the structure, the metadata, et cetera, that is required to deliver information on a specific platform. So a mobile app, or a website, a portal, a working environment.

AS:                   And then there’s what I tend to do which is management information architecture. And the difference is that I’m tasked with creating an information architecture that can support omni-channel publishing to any of those platforms. I tend to work with companies that are trying to have a single source of truth that they manage in DITA but that serves different platforms, and each one of those platforms will have its own architecture because that architecture supports the display, usability, findability, et cetera, of that information.

AP:                   I think that is a very important distinction to make and it hearkens back to something that started in the late 1990s, the idea of single-sourcing, where you basically you have a source that is then output into a bunch of different formats and you’re not writing specifically for one format type.

AS:                   And that’s particularly powerful. And when you think about content that is to support learning, if you have content and you want to send it out to an LMS, you’re not going to structure it just for the LMS in the management architecture but the LMS, that experience is so important to learners that that architecture needs to be fully developed. And when you work in these larger projects the biggest challenge is first getting folks to acknowledge that they actually need information architecture as a separate discipline, and then next understanding that they need more than one. And understanding what those roles are and communicating which direction the requirements are going. And the reality is they’re both going both ways, and that leaves a lot of opportunity for some great collaboration but also an opportunity for some miscommunication.

AP:                   Sure. And I think this makes me want to ask the question, when should a group of content creators, a company, a department, whoever, when should they be thinking about information architecture? What’s kind of an inflection point where you say, “We really need to buckle down and think about this seriously?”

AS:                   Well, when I speak to a group of information developers or tech writers or whatever label you want to use for people who are creating content, I asked them, “How many of you are information architects?” And very rarely does anyone raise their hand. Then I ask, “Do you control the table of contents? Do you put in keywords or index words?” And everyone raises their hands. So, everyone’s doing information architecture as they create content in these organizations. I think the question really is when do you need to acknowledge it as a separate discipline? And I would say as soon as you have more than one deliverable. Because if you look at high-tech companies, one of the classic questions is, well, where does the troubleshooting information go? Does it go in the user guide? Does it go in a surfs guide? Where does that go?

AS:                   Well, that’s an architecture question. And if you have guidelines that indicate that user guides have this information, getting started guides have this information, administration guides have this other information, and it’s okay to have the same information in more than one deliverable or it’s not, that’s architecture. And I feel that it’s a disservice to not acknowledge that everyone’s doing it already. It’s a role, not necessarily a position, but by ignoring it you then end up not having the discipline and the consistency that really enables great customer experiences.

AP:                   I think that’s a very great point you just made. As people are creating content they are adding intelligence to it. They are categorizing that information oftentimes without even realizing that they’re doing it.

AS:                   And if you have more than one author then you have different people’s ideas and opinions and judgment calls. And I would argue that many of the style guides that teams have that allow folks to be more consistent, actually, most of the time incorporate a lot of the architecture. And that it might be helpful for teams to look at that information with a critical eye and say, if it’s about what information goes where, and what’s the structure of a specific deliverable, maybe it’s worth calling out into a separate section of the guide and acknowledging that this really is different than the words that you choose or how you format something.

AP:                   With IA, is it generally a project by itself or is there some trigger, some bigger corporate initiative that may make that happen or put attention toward it?

AS:                   I would love there to be projects where someone calls me up and says, “We just really want them have a great IA.” That never happens. Folks call up and say, “We are having this type of a business challenge. We understand that baking the structure of the content into the DTDs or baking it into the CMS structure, or completely ignoring the structures, the metadata that we need is causing us pain.” And then because IA is around the structure of the content and the metadata, and particularly if you’re working in XML, you don’t give people the raw XML, you always process it or render it with a transform. So it’s always going to be bound to additional work, you’re not going to go and change the IA and then not be able to generate the content. The simple answer is it’s always been part of a bigger project.

AS:                   When I look at projects like this I see the business question, what are we trying to achieve? And then I think of three dials or areas where we can control and make accommodations and improvements, architecture, technology, and process. And most challenges require some work in all three areas. What can the architecture do to give you more consistent, well-structured, more powerful content? What’s the technology that’s required to perhaps present that information in a better way to meet the user need? And then process, well, what processes need to change in order for us to produce the right content in a timely fashion?

AP:                   Those are really good ways to break it down. But if I’m talking to a C-level person, an executive, the person who has the money in their hand, how do you communicate to them about the importance of IA because I’m pretty sure telling them we’re going to get spiffy new tools is not the way to win that argument?

AS:                   Well, and it’s a challenge because everybody wants a simple answer, particularly in the U.S. where we get judged quarterly by our success or our failures. Most of these projects to make significant change or improvement take longer than a quarter, so the whole budget question is always difficult. The first challenge I think is for them to take a business challenge and understand when content is involved at all.

AP:                   Yes.

AS:                   Because once we say, “Oh, content is part of the solution,” then it immediately is, well, it’s not just the words but it’s also the structure, and at that point we can introduce the discussion around architecture, the role of architecture. And I’m actually working on a book with a coauthor about this exact challenge, is how should management understand when a business challenge involves content and when simply buying new software won’t be the answer because there’s always going to be some sales person out there offering them some sexy new software and telling them that it’ll fix everything.

AP:                   Indeed. And it usually doesn’t, says the narrator.

AS:                   Well, I would say it always doesn’t because the idea of buying software without understanding the inputs and outputs of it and the role of the people using it, that process, that’s how you end up with shelf-ware.

AP:                   Exactly. And I’ve seen that happen so many times I can’t even tell you, I’m sure you have too.

AS:                   Oh, yeah.

AP:                   Yeah. So there’s got to be some process here, some way to consider to map this out, especially to get that buy-in for the vision and then to implement it. Is there a loose process? Now, I realize this is a huge, huge leading question that we could talk about for hour upon hour. But is there’s some kind of a loose outline about how these projects go?

AS:                   Definitely. As with any challenge we want to start off with what the definition of success really is. Because we don’t want to make change, we want to make improvement and how will we know when we’re done if we don’t know what the goal is? And if you’re in a larger project, in larger organizations, a lot of times they’ll have a content strategist and the content strategist is usually the person who defines what success is. They work with the management team, understand what the challenge is and say, “Oh, okay, let’s talk about what success looks like from the contents point of view.”

AS:                   Then of course we want to understand the current status so we do some assessment to understand why is the current content, whether it’s its structure, its delivery, the actual words, it’s in the wrong language, where is the content falling short and what are we currently working with? For a lot of teams one of the biggest challenges is that they have multiple instances of the same content. And so it’s easy enough to write, but then when you go to update it’s like Pokemon, you have to go catch them all and you never do because you might be new, you might be busy or you might not even have access to the repository that has that fifth instance of that content. And that is why we really want to get to a single source of content in a management architecture so that when people need to update the content they simply do it once.

AS:                   After we know what we have, we want to look at the future state, what should the future state look like and understand taking the idea of success and making it concrete in a way that we can then start building toward. And then once we have this from the architectural point of view, I’m going to start looking at the deliverables, really looking at them and saying, “Okay, what’s this deliverable type? What’s its purpose? How should it be delivered? Is it for one or more audiences?” And when I mean deliverable, I mean a manual, an article, a course. If you’re a mobile app that has glossary quizzes, what is that thing that the end user consumes.

AS:                   And based upon the purpose and who it’s for then we can start looking at, well, what kind of content needs to be here to meet that purpose? And once we have the idea of what success looks like for the deliverable then we can look at the content types. In some organizations the content types are super basic. They have concept task, reference glossary, maybe some troubleshooting. If you’re in education you’re going to have learning objectives, you’re going to have questions, you’re going to have overviews, you’re going to have summaries. And the more specific your industry is, I have found the more content types you potentially have.

AP:                   Yeah. We’ve had that experience as well, I agree with that.

AS:                   When I say content type I’m not necessarily referring to an official topic type. For instance, you don’t have to specialize to get a content type. If the content structure is the same but you really want to identify the purpose of the content so that you can empower a more nuanced delivery. So for instance, if you have glossary terms, the glossary structure, for instance in DITA, but maybe you want to include that this is a vocabulary word versus this… And it’s for a specific industry or you want to say, “Oh no, this is a chemistry formula.” That’s a very specific purpose. And you don’t have to specialize, you can use the base topic, but then you are identifying for downstream systems what the content type really is.

AS:                   And when we know that then we can look at its structure. And what our goal is is for us to be super clear for the people creating the content what purpose is that they’re writing it, because creating smaller, modular, structured content is still a new concept to a lot of content authors. And even though it started way back with information mapping and has been used through multiple systems including DITA, the idea that you would write and store pieces of content for different purposes is still a big change for lots of authors.

AP:                   It is and if it were not we wouldn’t be employed, quite frankly.

AS:                   Indeed. And so once we have some idea about what the structure should be then we’re going to do some proof of concepts and try out some lightweight mock-ups and understand how things come together. And what I typically do is I start with what they do now and replicate it and then we start thinking about the art of the possible. Because, we’re not being brought in to ask them to recreate what they have now, because they have a business challenge that what they now doesn’t meet. Understanding what that change is, what’s that delta is really important from a structural point of view because we can’t help the authors make that journey to the new format and the new structure unless we fully understand it. So I’m a big fan of recreating doing a proof of concept, understanding with the stakeholders why what they have doesn’t work because me telling them that usually is not enough.

AP:                   No, but it does help that you’re a third party voice coming in there. And I’m actually very glad that you brought up proofs of concept because there is always on these kinds of projects a chicken and egg challenge with the tools and technologies. If you’re doing the information architecture and laying that all out, at that point you often don’t have the tools that will do the transformation, or the tools that they’ll be using for authoring. So how do you balance that lack of tools and doing these proofs of concept? How do you handle that chasm, for lack of a better word?

AS:                   Well, I start with what DITA gives us for free. Because it’s an open standard we have the open toolkit and a lot of the authoring vendors provide multiple transforms. And so I go with what I have available. Because it’s a proof of concept I don’t want to invest development time if I can help it and I see what I can get. So for instance, if I’m trying to show people how they can get different types of associations that can be represented as links in the output, I’ll just use a tripping helper, an HTML5, a transform, just to show them, hey, this is what you get. That’s particularly useful when you’re trying to explain to people why they will no longer have to manually manage and type the link text for all their links particularly if they’re hierarchical.

AP:                   Yeah. And I know having worked with you on some past projects, you’ve often even not even touched DITA tools to do proof of concept, for example, doing mock-ups of a table as they stand now and then doing a future state table using Excel or Word to show the differences and what’s possible without even actually having to touch DITA. Because you have that DITA knowledge, you can translate it in a way that’s very visual and help people understand without them even, or you really even having to touch the DITA code, I think that’s also very helpful.

AS:                   Well, that’s the thing and this is the chicken and egg part of it that you mentioned, Alan, which is, I’m trying to help folks understand what they can do with their content and they shouldn’t have to know DITA in order to be able to communicate their needs to me.

AP:                   Absolutely. Really, it is a situation where they need to bring their expertise and that is with the current state and with how process flow works and how information flow works. And it has to be basically combined with your expertise on DITA and whatever other model that may be, your case it is usually DITA. You’ve got to find a way to bring those two things together and have them sync for these projects to work, at least that’s my point of view.

AS:                   And I’m a big fan of using diagrams because first of all I’m very graphically-oriented, I love a good picture. And second, it allows me to help folks see past their words to see their structure. And the first version of the diagrams I do has no DITA in it, it literally, for instance if I were doing a diagram of a glossary unit and I wouldn’t even need to say the word topic, I’d say a glossary unit. It’s like, okay, we start off with the obvious, we have a term and a definition. Do we need abbreviations or some other alternate form? Okay, let’s talk about the alternate forms that you want. Do you need usage notes? What is it for instance, for the folks that did an application, a mobile app that tested glossaries, they’re basically digital flashcards.

AS:                   We had to say, “Oh, we need pronunciation here as well.” And that has nothing to do with the DITA elements I would use to support that, it’s helping the client communicate to me what does success look like, and like I said, I love using diagrams. I usually have two sets. I have a set for the structure and then I have a set that I then create that says, “Oh, here’s the DITA element,” and potentially the attributes I’m going to use to create and structure the information to meet the structure that they told me they needed.

AP:                   Yeah. And it’s almost baby steps, starting out simple and then adding another layer on top of it and that makes a great deal of sense to me.

AS:                   And I use the same ones over and over. I actually have a toolkit that I sell, that is the toolkit that I use with my clients. So not everybody has the opportunity to bring in a consultant but if you want the tools that I use you can get them.

AP:                   Absolutely. And before we wrap up, is there any one stumbling block that you can think of that really stands out based on your past experience where you can give a simple piece of advice to get around that stumbling block when you’re working on an IA project?

AS:                   I think that the biggest one is recognizing first that architecture is a separate discipline. And the second part of that is that you may have more than one architecture. Most companies I see have multiple ways that they are producing their content now and if we want to get into a management architecture we have to look at the input into that architecture and say, “How do we harmonize?” And I like the word harmonize because it allows me to express that we’re not making everything exactly the same, which when I say something like normalize it would imply massive change.

AS:                   Oh, no harmonize, I want everything to work together in one repository or repositories that they all have the same structure and then we can look at the downstream implications. So for instance if you’re doing a chatbot and you also have a self-guided troubleshooting and you have basic user manuals, you have FAQs, we should be able to structure the content and the management IA and empower it with the correct metadata so that you can deliver that content in the way that it needs to be delivered because for each of those platforms, which could be radically different if you think about the difference between an FAQ and a chatbot, that delivery IA is radically different.

AS:                   And most folks they’ve been thinking about it from the idea that, oh, we’re just going to push it out and it’s going to magically work on that platform and understanding that they will need to have two different IAs and take the effort to trace back from the delivery platform, back to the management IA to understand when metadata, specifically metadata gets assigned to which units. Is it one unit, is it a group of units, is it based on a map? Whatever that is, and recognize that there might be times when metadata never makes it back to the source, that it may need to be managed in different places. And so this idea about metadata being used to power the content needs to be discussed in the context of multiple architectures.

AS:                   And I find that that’s an evolving conversation that once we talk about it that way a light bulb goes on for people, but I wasn’t having that conversation two years ago with people. And I should have been, but it just became clear to me over the last couple of years that that is where I can really help folks understand how they can power their content in new and better ways. And maybe even using their existing content that they have and they just add a new delivery channel, whether or not they have to actually go back and touch their source, or whether there’s an opportunity to power it from a different place.

AP:                   That’s really good advice, I appreciate that. And I’ll be sure to include your website in the show notes so people can find you and continue this conversation with you. And with that, Amber, I want to thank you for your time, this has been a great conversation.

AS:                   Well, thank you, Alan. You’ve given me an opportunity to talk about one of my favorite subjects, I love talking about architecture.

AP:                   Well, we’re glad to do it, thanks again. 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.

The post Understanding information architecture (podcast) appeared first on Scriptorium.

In episode 87 of The Content Strategy Experts podcast, Sarah O’Keefe and special guest Nenad Furtula of Bluestream talk about finding the value when selling structure. Why do so many tech pubs departments fail to get support for structured content and what can we potentially do to change that?

Related links: 

Twitter handles:

Transcript:

Sarah O’Keefe:                   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 finding the value when selling structure with special guests, Nenad Furtula of Bluestream. Why do so many tech pubs departments fail to get support for structured content and what can we potentially do to change that? Hi everyone. I’m Sarah O’Keefe from Scriptorium and I’m here with Nenad. Nenad, you’re over there in sunny Canada?

Nenad Furtula:                   Thank you, Sarah. Always good to hear your voice and talk to you. I’m located in Vancouver, British Columbia.

SO:                   Nenad, tell us a little about yourself and Bluestream and what brings you to the structured content conversation?

NF:                   Of course. Yeah. My role at Bluestream is I guess I’m one of the two managing partners and I also manage all the business development and marketing activities when it comes to Bluestream. Bluestream has been around since 1997 and we initially were an XML database company and shortly after that, transitioned into content management. We’ve been doing content management for a very long time. Around that time that we got into this business, about 2005, DITA came about and so what we’ve done is we built a product called XDocs, which is a component content management system. For the past, I guess, 15 years, I’ve been soliciting the value proposition of our flagship product.

SO:                   Right. And you and I have had many conversations, at many conferences, with many drinks, about the industry and it’s always interesting to hear what you think about it. And so today I wanted to ask you specifically about what I think is yours and perhaps my number one business problem, which is why is it so hard to sell structured content at the executive level? When we go in and we’re selling to potential clients, why is that so hard with the execs?

NF:                   I guess the famous line is to catch a gopher you to think like a gopher, Bill Murray from Caddyshack. If you think about roles in an organization, executives have a role and predominantly they are concerned with growth, business growth and returning shareholder value, and sometimes stakeholders as well, right? Classical product documentation, when we talk about structures for example, is generally seen as a low-level cost center. That is necessary when you have to release a product, but it’s not really a forefront of the business thought. It does not generate revenue and it does not necessarily improve your organization’s image like marketing does, right? So that is a problem.

SO:                   And it doesn’t bring in new leads, right?

NF:                   Exactly, exactly. It’s a cost center, that’s the problem, right? It’s not a priority and it’s also a low-level cost center, meaning that there are expenses that are not overbearing essentially, right? Just to give an example is when you’re talking about, say Salesforce, they write that check every year no problem, right? Whereas when you’re talking about a component content management system, that becomes a bit of an issue.

SO:                   Basically, we have to show that this type of content, product and technical content, does in fact add value to the business, or I guess maybe more accurately, doing it better adds value to the business, right?

NF:                   Well, we have to show where it adds value. I think that’s key and we have to think about how it does that. Right? I think that I am guilty of this as I think many of us are in the beginning, let’s just say, let’s roll back 10 years ago or so, we were really focused on content reuse and how great it is for documentation lifecycle and proves the processes and reduces publish times and that these things are not really, executives don’t think about things like that. Right? The focus, really I think, has been in the last five years to really sell value of information and also show where it brings most value to the organization.

SO:                   Yeah. I’ve been warning people that focusing on cost avoidance is pretty much a straight train to the land of commoditization.

NF:                   Right.

SO:                   Which we don’t want actually.

NF:                   Right.

SO:                   What about DITA? Is there a different argument there or is it the same?

NF:                   Well, it’s sort of worse, right? If you think about it because, well, that’s the problem. Again, going back 10 years, we’re telling the world how great DITA is, right? I think it frightens some people too because it is great, it’s a wonderful standard. At the very essence of it, it’s just a technology that helps you deliver a structured content, right? Executives care even less about it. But where I’ve found the DITA argument, in particular, the standard argument helpful, is when you’re trying to mitigate risk. Right? Because the question inevitably comes up. We’re bringing this new tool and are we going to be vendor bound, right? Here we say well look, when you’re going with something like DITA which is a standard and not a proprietary schema, there’s a bunch of them out there, you are essentially mitigating risk. To me, that’s the most valid argument. You can talk about there’s a community, there’s thought share and all that wonderful stuff, but it really comes down to, can I switch to vendor? Should I need to? And yeah, you can because you’re working with the standard.

SO:                   Right, so you have a risk mitigation and then I’ve talked about it a little bit as an enabling layer in that there are things that you want to be able to do with your structured content and the people who built out DITA originally thought pretty carefully about what those things might be. There’s a lot of stuff in there that’s useful if you have the typical kind of structured content. Okay. We know that we can do some cost avoidance, some lower expenses, but we don’t really want to focus on that too much. What other kinds of things, what other kinds of value propositions do we have then?

NF:                   Well, when it comes to value proposition, I mean it depends on the organization and it depends on the industry. We’ll get into to the industry later on in this call but the true value proposition in my mind has to show an ROI, right? We get asked for this all the time. In particular, in my line of work, when I’m working with procurements, when I’m working with technical documentation managers trying to solicit value proposition internally, it’s all about all about the ROI. The number one, I think, point when it comes to ROI is, is this going to have an impact on my revenue, right? If you can show that a structure or going towards structure is going to impact your revenue, you have a pretty good argument. That’s a good starting point, right? And not everybody can show that. Not every industry is capable of showing that.

NF:                   Now of course, the second point is as you mentioned, is impact on expenses and reducing expenses. It is about lowering translation costs and making these departments more productive, if you would, right? That’s a big one. It’s really difficult to quantify a third point, pardon me, is that through documentation, you can enhance end user experience with your product. Okay. That’s a very interesting point to make because we’re no longer shipping 500 page PDFs. We’re shipping help centers. Give you an answer to your question, right? Talk about enhancing experience with the product that you were looking for an answer, it’s there, right? But then, like I said, it’s much more difficult to quantify.

SO:                   Yeah. I think you’re right. We’ve run into some other related things to what you’re talking about. I don’t know where you put this, but regulatory compliance and making it easier to deliver the right content that your regulatory body requires and doing it correctly the first time means fewer holdups in your regulatory experience, right? Fewer calls from the regulators saying, “Hey you didn’t do this,” or, “Hey we’re not going to approve your product unless you give us X, Y, and Z.” You give them exactly what is required and accurately the first time. You talked about risk earlier in a technology context. We talk a lot about risk mitigation as a value proposition that if you have a transparent, traceable, et cetera kind of process, you can reduce the number of mistakes you make in your content, right? And if you do make a mistake, you can fix it and be confident that it’ll get fixed everywhere, which reduces potentially your exposure from a product liability point of view, right? If you ship a possibly dangerous product, dangerous if used incorrectly and you don’t provide good instructions, you’ve got some exposure there, so that’s a concern.

NF:                   I agree. I agree.

SO:                   Yeah.

NF:                   That was the preamble to the question. The answer was it really depends on the industry.

SO:                   Mm-hmm (affirmative).

NF:                   That’s what we’ve seen. I’m sure you’ve seen the same thing. Adoption of structure, from these regulatory driven industries was much quicker, right? Pharma, they jumped on this early on. Medical device manufacturers, we’ve seen them adopt structure for that very reason early on.

SO:                   Right. To your point, risk mitigation. Yep.

NF:                   Risk mitigation. Exactly. I think that should have been a fourth point is industries driven by regulation. They just have to do it.

SO:                   Well and I guess they recognize the value, right? Because they know what the consequences are if they don’t do it right. For a lot of other people, the consequences are kind of squishy.

NF:                   They are. They are.

SO:                   I did want to ask you about cost centers because you mentioned them and I sort of twitched because we have seen a pattern, especially recently, where you have a technical publication or information development group that actually charges their services back to the in-house business units. If I’m tech pubs or whatever they’re called, then every time I produce a document for a particular product line, I charge back my time or the team’s time, to that business unit. Oh, we spent 30 hours, we spent 100 hours on your document so you owe us 100 hours times our internal magic bogus rate.

SO:                   What they’ve run into is that if they layer in something like structured content, or let’s say they’re sharing content, and so I write content for business unit A, but then I actually use that content again for business unit B. Well, business unit B pays eight minutes and business unit A pays three hours because that’s what it took me to write that piece of content, but then I reused it. If I have better efficiency, I charge back fewer hours which means the team gets less budget the following year and there’s no provision really to fund the infrastructure, to fund the build of structured content or the maintenance of the style sheets or anything like that. And this may be an unanswerable question, but I’m looking at this and saying, this doesn’t work. This cost center approach doesn’t work.

NF:                   Well it sort of works for certain organizations and not for others. We’ve certainly, especially in large organizations, this is the case, we have yet to run into, or I have yet to run into a case where the technical documentation department has become so efficient that they are getting their budgets cut. That’s just my experience. I personally haven’t seen it. The other reason too is because just the demand for information is growing as well. There is more information, there are more product lines. Maybe that’s why I haven’t necessarily seen that myself, but certainly it could be a problem.

SO:                   Yeah. It’s not common, but we’ve seen it a few times and we keep saying, well you have to account for the shared infrastructure somehow. I think the challenge is when you move to structure, there’s more shared infrastructure and less hourly billing back, and that’s what you want because more reuse equals more lower translation costs and all the rest of it. You mentioned different industries have different arguments for structure and we kind of touched on regulatory and risk management and what that looks like. What are some of the other examples of that where a different industry or a different vertical might care about different things when they’re looking at structured content?

NF:                   Yeah. I’m actually glad that we went through regulatory first because the two examples that I had in mind, I’m comparing say a classic software vendor to say someone like a heavy equipment manufacturer, right? Their arguments for structure are going to be different, we found anyway. When you’re producing software manuals and say you have a software product like we do and you need user manuals and such, basically it is a straight up cost to business to develop that. Okay? For example, just to start with, ignore the fact that your processes are going to be better while using structure and you’re going to be more efficient and all that, and your localization costs are going to lower.

NF:                   What you really need to do is you need to focus on information flow and you need to figure out which recipients of that information have the most value or are getting the most value. In an example of a software company, quite often we see these delivery platforms emerging, and that’s the argument, right? The argument is we need to go into structure so that we can have a better delivery mechanism of our documentation so that for example, we can reduce the burden on our support organization. Okay? And voila, here is your delivery platform, right? What’s interesting about that argument, what we’ve seen there is we’ve seen a lot of people, a lot of software companies actually, sell structure successfully to management and of course, now they’re working debt, because they can’t get money for a tool and get budget for it, for a tool like a CCMS.

NF:                   But then, it’ll be much easier for them to sell a delivery platform because it’s outward facing. Right. And the whole argument there is, well information flow is, hey, look at my end user. They’re interacting with this documentation, with our product. Again, you’re enhancing the end-user experience with the product and you’re reducing the burden on support. Right? And that works very well for say a software manufacturer or software vendor, for example. Whereas if we take a look at someone like heavy equipment manufacturing and Bluestream has really niched into that vertical quite a bit, over the years, they have a completely different requirement and their requirement is much more sophisticated when it comes to delivering information for the use of this equipment. Right?

NF:                   Well, first of all, the equipment has a long lifespan, right? And this equipment needs to be serviced and a big portion of a company’s revenue or some fair portion of a company’s revenue is associated with servicing that equipment, and as well as selling spare parts, if you would, right? So when you look at that information flow, when you think about, well, who are the recipients of this information that really matter? Well, they become this service personnel, either third-party or internal, who have to service these machines for many, many years. And of course, they have to sell parts. And so those parts and that service, or those aftermarket parts I should say, and this service become a big part of the revenue, right? The revenue story, company’s revenue story. And so when you’re going into a situation like that, what you’re going to talk about is increasing the sale of spare parts, and that has all the attention of management.

NF:                   So I’ll give you an example. We’re dealing with a very large train manufacturer, they’re actually worldwide. And I was looking at their business case that they presented, and we’ve been dealing with this customer for about four years, but I remember their case that they presented to management, it was 95% of the business case was focused on increasing the sale of spare parts. Whereas 5% of the business case focused on basically increasing productivity of some 70 plus technical writers. Okay. And that says it all, right? Where’s the focus? Well the focus is in fulfillment, in that particular case. Right? So very different than what we see in the example that I gave earlier, like a software industry. Right? And so the focus has to really be adjusted to the industry that you’re selling into or the industry that you’re in essentially.

SO:                   Yeah, that’s interesting. And I think we’ve seen that as well, that on the software side, with some exceptions, but in general, on the software side, the focus is on cost savings and also on velocity, time to market. Because software gets distributed electronically. This sounds dumb, but some of us are old enough to remember the literal, we have a contract and our client is required to get this piece of software by close of business on December 1st. And if you miss the FedEx 9:00 PM deliverable, or sorry, you miss the 5:00 PM pickup at the office, that means you have a 9:00 PM cutoff at the airport. And if you miss that, you’re putting somebody on a plane at 6:00 AM to fly them to California, holding a CD in their lap so that they can walk into this business and deliver the software on time. Right?

SO:                   That’s how it works the olden days. And now you obviously distribute it via a patch or an electronic download or whatever, and that entire shipping process went away. And it took content a long time to catch up to that distribution mechanism. Eventually, we had PDF and we could electronically distribute. But at first it was kind of a big problem. And so software is interested in speed, velocity, time to market, cost savings. And then as you said, manufacturing really has this, it’s more like a two part sale, right? You sell the core product, but then there’s this long lifespan of maintenance and updates and service and spare parts. It’s just a much, much different chain. We’re also seeing an awful lot of companies getting into the fleet management and service management.

NF:                   That’s right.

SO:                   So they actually go from being a product like a manufacturing company to being also a software company, because they’ve got the database of all of the equipment that they’ve sold you and think of airlines, when is it due? When is this plane due for maintenance? Keeping track of that is actually a service. So now this distinction between product and service is starting to blend.

NF:                   Well you know who defined that actually initially? Believe it or not, it was Xerox. Xerox is a big partner of ours and they were for many years and Xerox actually, everybody thought the Xerox was about copiers, right? Yeah, sure, they sold copiers, but a bulk of their revenue came from servicing these copiers. Xerox actually is not a products company, it’s a services company. Right? So it’s true.

SO:                   Then what about organizations where the content is in fact the product?

NF:                   Yeah. So those guys have, we see a lot of folks generating learning content, training content in particular. We have a number of customers in those fields and they actually, interestingly enough, they’ve caught on to XML, I should say, early, early on. Okay? And at the time, I say early on, probably about 15 to 20 years ago. Right? And so they’ve paid attention to this stuff and they, for the most part, built their own systems. That’s what we’re seeing. A lot of proprietary systems, a lot of proprietary XML. And so for them, getting into structure was much easier, is much easier I should say. And for them, embracing something like DITA makes sense. The challenge of course becomes how easy is it to use? How easy is it to author?

NF:                   And this is where DITA, maybe did a disservice to some of us because it’s been presented, it’s so powerful and yet so complex. In fact, I just had a conversation last week with someone that said, “Gosh, we can’t do this. It’s too complicated. We’re going to go with something different.” Right? And so anyhow, I know there’s a discussion around DITA Light and all that wonderful stuff. But those organizations who sell content as their primary business, they’re embracing this and they really are coming on board. The other one is insurance. Sarah, we’re seeing insurance companies. I mean, it makes a lot of sense for insurance, structure makes a lot of sense for insurance. We’re seeing airlines embrace this. Of course, that’s a regulatory industry. We really are seeing an uptake in structured content. There’s no question about it. Last few years have been, in my mind, changing.

SO:                   Yeah, which sounds like some good news for all of us. So well thank you. I appreciate this because I think there’s a lot of food for thought in here and obviously you’ve not just thought about this, but had to think about this in the course of your business. And I think it’s helpful to me to chew through all these things and contemplate what they’re like. I’m going to, with that, wrap this one up. Thank you, Nenad. I appreciate it as always.

NF:                   And thank you, Sarah. Thank you for having us on. Like I said, this topic is near and dear to us and should anyone want to discuss further, I’m sure they can reach us at www.bluestream.com.

SO:                   Yep. And we will drop that in the show notes, along with some other contact information so that you know where to find everybody. Thank you to our audience 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 the relevant links.

The post Finding the value when selling structure (podcast) appeared first on Scriptorium.

In episode 86 of The Content Strategy Experts podcast, Gretyl Kinsey and Bill Swallow continue their discussion about the steps to structure, how to move from unstructured content to structure, and what each level of maturity looks like.

“Step five is when you’re  thinking even your structure is structured. You’re really thinking about how to take this to the highest possible level, how to get the most out of your automation, and how to make sure that the way you’re delivering your content is maximum efficiency.”

– Gretyl Kinsey

Related links: 

Twitter handles:

Transcript:

GK:                   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 the steps to structure, how to move from unstructured content to structure and what each level of maturity looks like. This is part two of a two-part podcast. Hello, and welcome. I’m Gretyl Kinsey.

BS:                   And I’m Bill Swallow.

GK:                   And today we’re continuing our discussion about the steps to structure. So we previously covered steps one and two, which are unstructured phase, and step three, which is getting to structure. There’s step four, which is customized or specialized structure. So could you tell us a little bit about what that means compared to just sort of the baseline structure?

BS:                   Sure. So once you have everything in your structured format, chances are you’re going to start finding little bits of differences or dissonance between the type of content that you’re producing and what the structure will allow you to use. You may say, “Well, we have this very specific type of paragraph, or this very specific block of content that doesn’t really fit into the structure in its own native form.” We want to be able to handle it, and we want to call it something unique. We want to be able to structure it uniquely as well, yet still use it within the framework of everything else we’re doing. So this act of specialization or customization is kind of the next step because now you’re looking at the structure and saying, “This is great, but we can do more with this.” So you’re fine tuning and tailoring things a bit more so that you can label your content more appropriate to your needs and be able to handle that content specifically for the types of uses for that content.

GK:                   Yeah. Absolutely. And I think this is an area where we start to really see a lot more work on the kind of metadata and taxonomy side of things because that’s when you start thinking, “Okay. Now that everything actually is structured, now we can think about how this content needs to be organized, how it needs to be sorted and filtered, how both our authors and our customers need to be able to search for the particular information that they need within this content set, how we might need to do something like personalized delivery.” So once you kind of have that foundation laid down with just the basics of structure, that’s where you really kind of start to think about: Okay, how do we want to customize our metadata? And how do we want to build out some sort of a taxonomy that we can support with metadata so that the content is not just tagged in structure, but it’s also organized? And there is information about the content itself being captured in a way that makes it a lot more flexible.

BS:                   Right. And what’s really driving a lot of this is not only the different types of content that a company might produce, but it’s also starting to hit that personalization note with people and being able to drive content dynamically to them that is of their immediate interest, rather than generic content that might be suitable for any audience.

GK:                   Yeah. So this is where, if you’ve got that structure in place and you’ve started to do those customizations, that you can do some kind of dynamic delivery. So your users might sign into a portal, and it can pick off information about that user based on their login, and then feed them the content that they need without them having to kind of dig through and search for it. So that really kind of takes your use of content to a higher level than you were able to do before, even though this is still a structured step, but it’s just really kind of enhancing it and taking it to the next level.

BS:                   Yep. And that next level beyond that would be something that uses, or that next step, so step five. Once you have everything in step four done, which is all of your customization, step five is kind of building upon that even further and implementing a lot more additional dynamic capabilities to your content.

GK:                   Yeah. So step five, we’re kind of thinking of this as even your structure is structured, so you’re really thinking about how to take this to the highest possible level, how to get the most out of your automation, how to really make sure that the way you’re delivering your content is maximum efficiency. And this is kind of what I think of as the differentiating factor between just simply moving to structure versus true digital transformation of content. I know that’s something that we’ve talked about in some of other webcasts and podcasts and posts is this idea of digital transformation has kind of been an industry discussion as well. But this is where we tend to think of truly transformed content is content that is a lot more personalized, where you’re really making the most out of your automation and your efficiencies. And the content itself is kind of not just one single digital delivery, but it’s something that a user can customize, mix and match, and it can be really, truly personalized.

GK:                   So this is where you’re really, really looking at: What is the most that we can do with structured content beyond even steps three and four? How can we really continue to take it to the next level and make sure that it keeps on scaling as the company grows?

BS:                   Yep. Step five tends to be incredibly specific from implementation to implementation, so one company will be doing things one way in a structured environment. Another company might be using the same exact underlying structured framework, but be organizing their content and doing completely different things with it. This is where essentially every single case that we’re seeing of companies that are at or looking to move to a stage five in their structured progress, it’s a unique engagement. It’s a unique way of looking at content based on what that company specifically wants to do with their content.

GK:                   Yeah. And this is really where if you’ve got most of your content problems solved with structure, but then you just have a few of these edge cases and unique requirements, where some additional customization would really take it to that next level, that’s kind of what we consider for that step five. And as you said, it is unique from company to company. But it’s something that’s also important to consider when you’re still in stages three or four, thinking about what your future requirements might be, and making sure that you kind of don’t lock yourself out of that. So if you are, let’s say you just get to stage three, you’ve just moved to structure, and you sort of know what your five year plan is, maybe not necessarily specifically, but you have some ideas of things you want to be able to do with content in the future, it’s always important to keep that on your roadmap and keep an eye on it because you don’t want to build something in a way that when you do get to that maturity point of being at the step five, that you’ve done something with your structure earlier that then requires a massive amount of cleanup or lots of tedious fixes here and there to get to that point.

GK:                   And I know we’ve talked about this on at least one of our other episodes about how it’s really important to plan, to be very careful, and to spend a lot of time on that planning. I think especially when you’re kind of going from step three to step four, and you’re thinking more about your metadata and your taxonomy, that has a lot of implications when you get to something like step five as well, when you’re really maximizing your content potential and your efficiency. Just that when you are building those structures and when you’re thinking about a taxonomy and how you want to organize your content, that you don’t lock yourself out of those future requirements.

BS:                   Yeah. You always want to keep some options open there because things will continue to shift and change, especially as your requirements change, or if you acquire another company, or acquired by another company. You want that nimbleness still built in and room for improvement, or room for change still available, and not just nail everything down and call it done.

GK:                   Absolutely. So on that note, what are some tips for moving to structure? If you are kind of at maybe a step one or a step two, how do you eventually get all the way to step five or close to it? And how do you do that as efficiently as possible?

BS:                   The first step is to kind of wrap your head around the strategy for your content and where it’s going to go, how you’re going to author content, what your future state looks like. So a lot of the things that we’ve been talking about, not just in this episode, but in many of our podcasts, but building that content strategy that gets you from where you are to where you want to be, and make sure that you have some kind of roadmap or framework for each of those steps that you want to take, so that you understand the scope of work that is going to be required to move from one step to the next, and to have some criteria so that you can measure what done looks like, and whether you’ve accomplished things that you wanted to get done in that stage. So not just: Are you done, but is it working?

GK:                   Yeah. And I think that’s also really important when you are coming up with that strategy to build in some kind of backup or contingency plans for when things don’t always go the way you think they will. And that’s why it’s really important to kind of look further out toward the future, so if you’re kind of at a stage one or two right now, that go ahead and make your ideal plan for stage five, but know that there’s going to have to be some flexibility in how you might get there. So you may want to have a few backup options of things that you would achieve in stages three and four before you get to that ultimate goal.

GK:                   Another tip that I want to bring up is just, like we said, when you go from that second step to the third, where you are cutting over from unstructured to structured, it’s really important to come up with a conversion strategy because that’s where you are going to be getting all of your content out of one format into another and migrating it into whatever kind of tools or systems are going to be managing that content. And that’s why we really emphasize having a step two and not just kind of skipping from step one to step three because that really I think helps improve that conversion strategy. And things to think about at that stage are one, how much content cleanup has to get done on the front end versus the back end, so pre versus post conversion.

GK:                   And what can you do to minimize the amount of kind of human intervention or manual cleanup that you’ll have to do? Because the more content you have, the more time it’s going to take to convert everything, and so the better off you’ll be if you can automate it. And that’s why having a clean content set as much as possible really helps with that conversion strategy. So just before you convert everything, it’s really important to think about what’s highest priority. What state is your content in? And what kind of clean up you’re going to have to do on either end of that conversion.

BS:                   Yep. And once you get to that stage three, you no longer really have a conversion path that you need to worry about, but you need an exit strategy going forward no matter if you’re at stage three or step five. You need to have an exit strategy for your content if you do need to change tools again, so keep a lot of that in mind when you’re selecting things. It’s not necessarily that one’s going to be bad and another one’s going to be better from an exit strategy point of view. But you need to understand how these new tools and new systems work with your content so that if you do need to move from tool A to tool B, you know how you can export the content, what certain handling capabilities from the old tool need to be redone, or somehow otherwise implemented in tool B. And have that in mind going forward. Moving to structure generally allows you to have some degree of portability with your content. But again, your mileage may vary depending on the tool choices you make and the types of structure you’re looking at.

GK:                   Like you said, having an exit strategy is so important because as we’ve mentioned in a lot of our other discussion on this episode, things do change. When you go through all of these updates to your content process over time, things change. And when you are kind of moving through those structured steps, so going from step three to step five, a lot of your decisions are going to be driven by the changes that happen in your organization, and the new requirements and the new demands that you’re going to face over time. So you have to think about how your processes need to scale up to meet all of the changes that are going to come, and just sort of use that as your guide. Update the roadmap that you come up with at the beginning as you get new information, and just kind of constantly keep your eye on that so that you can ultimately sort of move through from step three, to four, to five over time, just based on what’s happening at your company.

BS:                   And also keep in mind, jumping from one step to the next, any given step to the next, you need to make sure that you have a clear understanding of the benefits that you are going to get by making these improvements in order to get buy in, not only from people who have the money that you will need to purchase new tools, or to provide training to your team, but also to get your team to buy in to the idea of, we’re going to work differently, and this is why it’s going to help you going forward.

GK:                   Yeah. That benefit is important because you don’t want to just kind of move from let’s say step four to step five without a good reason for it. You have to be able to explain, here’s why we’re doing this, and here is how it’s going to improve content production going forward. And with that, I think we can go ahead and wrap up. So thank you so much, Bill.

BS:                   Thank you.

GK:                   And 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.

The post Steps to structured content (podcast, part 2) appeared first on Scriptorium.

In episode 85 of The Content Strategy Experts podcast, Gretyl Kinsey and Bill Swallow talk about the steps to structure, how to move from unstructured content to structure, and what each level of maturity looks like.

“It’s important to keep in mind when you move from step two to step three that your authoring tools may change. The writers might have gotten used to working with one set of tools in steps one and two. But as you move to structure, the tools that you’re using for unstructured content may not support the underlying framework for the structure that you’re moving forward with.”

– Bill Swallow

Related links: 

Twitter handles:

Transcript:

Gretyl Kinsey:                  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 the steps to structure, how to move from unstructured content to structure, and what each level of maturity looks like. This is part one of a two-part podcast.

GK:                  Hello and welcome everyone. I am Gretyl Kinsey.

Bill Swallow:                   And I’m Bill Swallow.

GK:                  Today we’re going to be talking about structured content and all the different steps it takes to get there. Let’s just go ahead and dive right into what is the first step or the baseline when we’re talking about moving from unstructured content to structured.

BS:                   Well, I guess the very first step that you’re on is that you have content.

GK:                  Yes.

BS:                   Congratulations. You have content. It exists. It’s probably written well. It is probably being authored by a bunch of different people or authored by people using a variety of different tools. Basically there’s no general rhyme or reason as to how the content is being produced, but it looks good, it serves its purpose, it’s published, it’s out there, people are reading it, but there’s generally no underlying structure. You might be using Microsoft Word and various other tools, no actual templates involved, all the formatting is kind of ad hoc and all hand produced.

GK:                  Yes. I think this is what we consider as the baseline or the bare minimum when it comes to content. It’s there, it’s well-written, it’s usable and you have it and it’s working, but you’re not really able to leverage it necessarily and do a lot more sophisticated things with it, and so you may have some limitations if you’re at step one. For example, with how you publish your content if everything is very manual in the process of creating it, then that’s probably true on the publishing side as well. So you’re not really getting mass automation there. You may also be limited in your ability to share content across maybe different departments, different types of documents. A lot of times when we see companies who are in what we would consider the step one, they tend to be in silos with unstructured content, and so you’ve got sort of different types of unstructured content all over the place and none of it is really connected or working together.

BS:                   Right. With regard to being able to share the content, there’s also that issue of copy paste that we ended up seeing a lot. This happens a lot in this first step where if you need to share content or you need to reproduce the same content in multiple formats, or in multiple documents, there’s a copy and paste going on, which then just adds to the whole snowballing effect of being able to manage to your content. If you need to make an update, you then have to find where you’ve copied and pasted that information throughout all of the documents and deliverables that you’ve produced.

GK:                  Yeah, and sometimes this can really have a snowball effect where if you do have different departments that produce content and let’s say maybe you don’t have as much of a problem with separate silos, but you do have this issue where there’s no connectivity. So let’s say you’ve got some folks over in training and they need to reference information from the official technical documentation and their training materials, and they go over and don’t necessarily grab the latest and greatest version, but they copy and paste some of the documentation from somewhere and then that gets into the training materials. And so there’s not really any sense of version control. There’s not really a sort of enterprise level sense of how the content is being used and maintained. That can really become a big maintenance issue over time as you need to grow and scale.

BS:                   Yep. With regard to growing and scaling and with regard to leaving this first step behind, what is, I guess, the next level that we’re going to; step two?

GK:                  Step two is when you’re using templates and a consistent style in your content. This is where for example, if you are working in something like Microsoft Word, Framemaker, InDesign, you actually have templates set up. So you’re not just kind of ad hoc creating different styles all over the place. You’ve got something that can not necessarily enforce that style, but at least give you a guideline to work within and some parameters to use as a starting point. That can really help improve that consistency of your content, can make sure that everything follows a more not exactly structured, but approaching structured pattern. This is something that I tend to refer to as implied structure because it’s not actual enforced structure on your content yet, but it’s kind of that intermediate step to getting there.

BS:                   With that implied structure, there’s also usually a style guide that will go along with it that will further help people follow the same structural composition when they’re authoring. So it’s not just the templates that are in place that they always use heading one for the first level heading in a document or use a particular note style if they need to produce a note in their documentation, but there is also a style guide that says, this is how the content should be arranged. Not only going through and saying these are what all the different styles afford, but this is generally how you approach building documentation. This is the type of content that you want to put in this type of section in whatever you’re writing.

GK:                  Yeah, absolutely. I’ve seen some company style guides also address things like branding consistency. So if you do have a lot of different departments creating content, there is something that says here is the logo you always use, here is the official way that you refer to the company, here are the official list of product names, that sort of thing so that there’s not an inconsistency there that just makes your company look unprofessional. We also can see it sometimes if your company is doing any kind of localization, if your content is being translated and there are particular things to avoid or ways that you want to phrase things that help make translation easier, that can be included in a style guide as well.

BS:                   Yep. Really, it also comes down to that level of organization of content within the documents you’re putting together. So if you’re putting together training materials or some kind of repair guide or something that’s very procedural, you generally want to have a section that says, “Okay, we’re going to start with a heading. We’re going to introduce the topic using these types of paragraphs. Then we’re going to break into a subheading and perhaps give a list of all the parts required, if you’re doing some maintenance or all of the things you need in order to complete a particular procedure. And then jump into the procedure itself, perhaps with another heading or with some other section delineation there.”

BS:                   That way the style guide allows the writers to understand when they’re going to write something for a particular audience, that they have this structure in place that they can follow. Again, it’s an implied structure. There are no set rules against it, other than the style guide and whoever enforces that coming down on the writers and saying, “No, you must do it this way.” It at least gives you a starting point to be able to start making your content look and feel the same, regardless of who’s authoring it, regardless of what tools they’re using to do it.

GK:                  I think that’s a really important foundation to get in place before you move on to step three. What is step three in this process?

BS:                   Step three is actually using structure. So being able to identify that there is a need for this level of consistency and these level of rules and adopting a framework that builds those controls in. So structure, we’re talking something like XML or DITA, which is a flavor of XML, SGML, that’s an old school one that’s still around to some degree, but it’s essentially a technological framework that says, “Here are all of the types of content that you have, and this is how they all play together. This is where they’re allowed. This is where they’re not allowed, and this is how they all flow together as well.”

GK:                  Yeah. So this going from step two to step three is really the break point between unstructured content and structured content or between that implied structure we talked about and an actual structure. I think that’s why it’s so important that if you are going to move out of your unstructured content and get into true structure, that you do have that intermediary step one to step two, because if you try to go straight from step one into step three it’s probably not going to be a very clean migration over into structure. So if you’ve already laid that groundwork and you have that implied structure in place in step two, it puts you in a much better position to go on to step three.

BS:                   Yep. Not only do you have the content aligned so that you can convert it to some kind of structured format, it makes that conversion process a lot easier. If you have step two in place and you have these solid templates that you use, and you have this consistent writing format that you’re using, you can automate that process to some degree, or if not completely to get it to a structured format. But it’s also important to not skip step two, because you want your authors to be able to acclimate to now writing in a structured format. If they’re used to just doing whatever they would like as long as the end product looks good and reads well, they’re not going to come around to the idea of authoring in a structured environment very willingly.

GK:                  Yeah. This is, I think the biggest challenge that we do see when a company goes from unstructured content to structured content, is that big mind shift that has to happen. That’s why I think it’s important to have that step two, so that people get accustomed to working in something that’s like a structure, even if it’s not a programmatically enforced actual structure that that mind shift does not have to be as big, because that is where you see a lot of resistance to change that can just really get in the way of your progress.

BS:                   Yep. It’s important to keep in mind when you move from step two to step three, that your tools may change, your authoring tools. The writers might have gotten used to working with one set of tools in steps one and two, where they were unstructured but perhaps following a style guide, perhaps using different templates, but as you move to structure, the tools that you’re using for unstructured content may not support the underlying framework for the structure that you’re moving forward with.

BS:                   Often we see a little bit of reluctance among the authors to move towards structure because the tool set is going to change. And what they’ve been accustomed to using perhaps for many years, they need to abandon, and they need to adopt a new tool with a new user interface, with a new underlying file format that they are just not accustomed to. Things may look a little strange, especially when you’re moving to structure using XML or so forth, that doesn’t have formatting necessarily applied to the content itself. They’re not accustomed to seeing a different representation of what they’re authoring than what will be delivered to the other people. So what they’re authoring in and what it looks like to them is not what it’s going to look like to the person who’s reading the finished produced deliverable.

BS:                   That’s a little jarring for some people. A lot of care needs to go into making sure your team is aware of these changes and that they have the training and the support necessary to make that leap.

GK:                  Yeah, absolutely. I think it’s a really intimidating thing because suddenly you’re going from, like you said, something where you can actually see what the finished product will look like as you’re working to something where you really have no idea. If you are moving to structure for the purpose of automating your publishing processes, for example, then you’re going to have one tool for authorizing, you’re going to most likely have some other tool or suite of tools for content management and then another tool or suite of tools for publishing, and all of those pieces are separate. So if you are used to everything all being in one tool together where you write everything, you review everything and then you just export it directly to publish from that same tool, and then suddenly you’re in this very different framework, it is a shift in not only the tools themselves, but how you work.

GK:                  It’s really, really important to make sure that nobody feels like their concerns fall by the wayside or that they’re getting left behind, but that instead they are supported because really there are a lot of benefits to this. I think that’s the main thing is just you convincing people here is how your life will be so much easier if you’re not dealing with all of those problems. We talked about earlier with copying and pasting, and not knowing where your content lives and not knowing what version is up to date. Going to structure can really help fix all of that. But it is that big change that you have to get people over that hurdle.

BS:                   Right. If they’re accustomed to producing multiple different types of deliverables, for example, a PDF and some HTML from a particular content source, it’s going to make their lives a lot easier on the publishing side, because that can be done automatically. At that point, you’re really removing the writer from the process of publishing, and their job is to make sure the content is structured appropriately and written correctly. At that point then automation takes it to the publishing stage.

GK:                  Yeah. Another thing that you get at this stage that I think it’s important to call out is that you get to leverage smart reuse. So instead of copying and pasting information, instead of finding workarounds to share it, you can actually have a single source of content that gets used in multiple places. That again is another shift in mindset, right? But that’s also a major benefit that you get out of going to structure. That’s something again, that should be a major part of training for writers.

GK:                  On a lot of the client projects I’ve worked on, we end up doing a split where we start with basic structured authoring training, and then we usually do a separate training session or series of sessions specifically on reuse for each company because each organization is going to have its own reuse strategy and its own reuse requirements. Being able to leverage that finally is a really powerful thing, and it’s important to have that as part of the training that you do to support the authors.

BS:                   And of course, once you hit the structured stage, there’s nowhere else to go. Step three is the final step, right?

GK:                  Oh no. There’s much more. We will be covering that in part two of this podcast. For now, thank you so much, Bill.

BS:                   Thank you.

GK:                  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.

The post Steps to structured content (podcast, part 1) appeared first on Scriptorium.

In episode 84 of The Content Strategy Experts podcast, Sarah O’Keefe talks with Val Swisher of Content Rules about why companies fail and how to succeed at delivering personalized experiences at scale.

“It all has to be completely standardized in order to be successful. There have to be small, individual, standardized chunks of content that are devoid of format that can be mixed and matched. Then the output can be personalized to the person who asked for it and sent to them at that moment in time.”

—Val Swisher

Related links: 

Twitter handles:

Transcript:

Sarah O’Keefe:                   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 with special guest Val Swisher of Content Rules about why companies fail, which seems terrifying, and also how to succeed at delivering personalized experiences at scale. And I imagine you’re going to tell us those two things are related, like do one to avoid the other.

SO:                   So, hi, my name is Sarah O’Keefe and I’m here with my special guest Val Swisher, who is the CEO of Content Rules. Val and I have some common affinities for a variety of causes and some needlework and some other fun stuff like that. And we run similar businesses so we actually talk quite often. Today, we’re going to attempt to distill that into a useful podcast for you. So wish us luck. Val, hi.

Val Swisher:                   Hey Sarah, how are you?

SO:                   I’m good. How are you doing over there?

VS:                   I am doing just fine here.

SO:                   Excellent.

VS:                   It’s a new day.

SO:                   It is a new day. For context, we are recording this on November 9th?

VS:                   9th.

SO:                   9th in 2020 so you can take that away for whatever you want. But Val, tell us a little bit about Content Rules and what you do over there.

VS:                   Well, we do a lot of similar things to Scriptorium, don’t we? Since you and I are in similar businesses. So as you said, I’m the CEO of Content Rules and I started the company in 1994 and we do a variety of things that are all related to content. So we develop content with contract writers and editors and course developers and all those kinds of folks. We do a lot of content strategy work, helping customers move from an, unstructured environment to a structured environment or helping customers with their global content strategy and how to go global, what they need to do to go global. And we also help customers optimize their content using special software that will allow them to program in their style guides and terminology, and make sure that their content is as good as it can be. So those are all of our different service lines.

SO:                   Yeah. And you’re right, there is a good bit of overlap. Although the funny thing I think is that we don’t actually see that much customer overlap, which is probably why we manage to get along, which is helpful.

VS:                   Undoubtedly. It is interesting though.

SO:                   Do, you have a book you’re working on?

VS:                   I do. I do. I am working on my fourth book. This book is titled The Personalization Paradox: Why Companies Fail and How to Succeed at Delivering Personalized Experiences at Scale.

SO:                   Okay, so let’s start with failure. It’s 2020 so I feel like that’s where we need to start. Why are companies failing at this?

VS:                   Okay. So there are a few reasons that companies are failing. The first thing is that they focus on the wrong place. Companies have spent years focusing on the delivery of personalized experiences, the delivery mechanisms of content. They’ve spent a lot of time, a lot of money, all around how they’re going to deliver content. And that’s the wrong place to start, they need to start with the content. And when you start at the end, rather than the beginning, you’re kind of setting yourself up to fail. So that’s one reason.

SO:                   So you’re saying they should start at the very beginning and that’s a very good place to start?

VS:                   Indeed. I could break into song right now.

SO:                   Okay.

VS:                   Yes. So starting with the content is the most important thing you can do. It doesn’t matter what delivery mechanisms you have, if you don’t have your content set up to deliver personalized experiences, it’s not going to work. So that’s the first problem.

VS:                   The second reason companies fail is that they are into the new, great, bright, shiny object. So they keep buying tools and they don’t think about it before they buy tools. They’re just like, “Oh, let’s buy this tool. This’ll do it. Oh, let’s buy that tool. That’ll do it.” And my new saying, I have a new saying, if you take the same crappy content and put it into your new expensive tool, you will end up with expensive crappy content.

SO:                   That seems accurate.

VS:                   So once again, we are starting at the content. And then the third reason is the same old silos that we’ve always had. I mean, we’ve been talking about silos for decades and decades, and if you really want to deliver personalized experiences at scale, you’re really going to need to play well with each other. This silo thing gets more and more difficult. So those are the reasons.

SO:                   So those are the three. Okay, so what are we talking about here? When we talk about personalization, what does that mean? What is a personalized experience?

VS:                   So personalization is when we deliver the right content to the right person at the right time on the right device in the language of their choice. So some people refer to it, we start referring to it as the Amazon experience. When I log into Amazon, boy, they know me really well. They show me everything I want to buy right now. They’re like in my brain, “Oh, Val, she likes shoes, we’re going to show her these boots,” this sort of thing.

VS:                   More and more, we’re coming to expect the content that we receive from a company to match what we need rather than having to go hunt for it. In fact, I was talking to someone over the weekend about this and they were telling me how frustrating it is for them when they go out to a particular financial site that actually has all their information. And rather than just showing them what they need, they know what funds they have and all this, they make him just search for stuff nonstop. And he’s like, “They know all about me, why am I putting this information in? Why can’t they just show me what I need?”

SO:                   That would be nice. I actually saw an example of this that I thought was fantastic and it was a credit card company believe it or not. And this was so stunning because they did the right thing. My mind was blown. So what happened was, now this was of course in the before times, I had bought a plane ticket because I was going somewhere and I went on to the credit card website to do something and was looking at my list of transactions and there was the charge for the airline, right? And underneath it, it said, essentially, “Hey, you’re traveling overseas. Would you like to set up a travel alert?” And I thought, well, that’s pretty good.

SO:                   Now, I’ve since seen a different version of this, where I actually got an email that said, “Hey, we noticed you bought a plane ticket and so we automatically set the travel alert for the place you’re going,” which was actually even better. But I was stunned because it was so unusual. Normally you have to dig through 18,000 menus to find the travel notification. Okay, in the olden days, children, we used to this thing called getting on airplanes and we would go places, we would leave our house and go to this big building and then we would get on the small tube in the sky and go places, yes. So, anyway, sorry, bad example right now. So personalization really just means deliver reasonable information, right? I mean, is it fair to say, you’re not really talking about, it doesn’t have to be that personalized, it doesn’t have to be, “Hey Val, here’s your stuff.”

VS:                   It’s a really, really good point. It’s very interesting you should even talk about that. When we’re figuring out how to talk to the customer, we need to be super careful about how we do that. It is so contrived, dear blank, and then they use the wrong name or it says dear [first name], because something’s screwed up. It really just means, give me what I need. Honestly, I don’t care if you know my name, as long as you give me what I need.

VS:                   We’ve been working on making it easy to find content for hundreds and hundreds of years literally. In fact, I was doing some research and back in the 1500s, there was a man named Pliny the Elder, not to be confused with the beer from the Russian River Brewing Company called Pliny the Elder. There was a guy called Pliny the Elder and he wrote a 37 volume, it was like an encyclopedia at the time, of the natural world. And book one was an index to the other 36 books. This was in the 1500s.

VS:                   So we’ve tried everything as we’ve gotten more and more technologically advanced. We have the card catalog for libraries and we’ve had indexes and table of contents and lists of figures and lists of tables, navigation on a website, navigation in any type of app or training or whatever.

VS:                   We’re at the point where people don’t want to have to pull that information. All of those ways of searching, ways of finding content is pulling that content. The onus is on the person looking for the information. We don’t want that anymore. We want it pushed to us automatically, just push what I need right now. I don’t have time to look in book one to see that what I want is in book 28. We’re out of that kind of time. The expectations are really different. So it’s not new.

SO:                   No, but we seem to be sort of bad at this. I mean, there’s the creepy version, right? Or there’s the failure, dear first name, which is terrible. And then, I mean, you mentioned Amazon, but my experience with Amazon is like, “You bought a washing machine, you’re obviously starting a laundromat. Let me sell you some more washing machines,” right? They seem to have kind of lost the chain there between somebody bought a washing machine, maybe I should sell them detergent. And so they’re not quite there yet, but you buy these big appliances and they immediately assume you want more like that. And so there’s something not quite right with that algorithm, but setting aside that example and thinking more about the business content that you and I mostly deal with, why are people so bad at delivering relevant content?

VS:                   Well, again, I think it’s because they’re focused on the wrong things. For a very long time, we were focused on trying to figure out enough information about you that we could go get the content for you. And even 10 years ago, 12 years ago, there were companies focused on that problem, how are we going to get enough information about you so that we know what to target our ads, so we know what to advertise to you? And now it would be we know what content to deliver.

VS:                   That problem has been solved. I mean, big data is here. We have more of a problem with controlling all the information they know about us than gathering. We know that, we see it every day. It’s the creepy, creepy and on the one hand, it’s uncomfortable. And on the other hand, if you want only the content that you want to see delivered to you, then I’ve got to know a whole bunch of stuff about you. So it’s time to start focusing on the ways that we create, manage, publish, and deliver the content.

SO:                   And so you talked about content and you talked about, I mean, there are certainly tools that can help with this, but they won’t help unless you do the content first. What about the silo issue? What are the problems there? What are the failures there?

VS:                   Where do you begin? I mean I once saw you do this fantastic presentation at a conference where you brought up a manual and it had nothing to do with the marketing content, it was just like, this happens all the time, you see companies’ marketing messages and examples and illustrations and positioning and their terminology and the way they talk about the product and then you move over to the knowledge base, or you move over to training courses or technical documentation and we have four different descriptions of the same widget when really we need to be sharing one description of the widget. So the more content that we each make in our own silo, the worse the problem is because now we have too much content, it all is kind of sort of the same, but not really, we cannot reuse it across silos, we’re restricted in terms of what we can deliver. We can only deliver that which we create. It’s expensive, it’s inefficient, it’s often inconsistent. There’s nothing good about it. So silos get more and more exacerbated when we try to deliver personalized experiences at scale. Same problems, just maybe exponentiated a tad.

SO:                   So what does that mean? I mean, are we talking about one monster piece of software to rule them all?

VS:                   Well, so I would say we actually need to step back from the software and really focus on the content because how people store and manage and publish the content is definitely a challenge to solve, but we need to teach people how to create the content. And you know this as well as I do, the only way to deliver a personalized experience at scale is to write your content in very small units, call it a component, call it a chunk, call it a topic, call it whatever you want, but a very small unit that’s self-contained, that can be mixed and matched with other small units, devoid of format so the format comes in at the end and have this library, searchable, tagged, find-able units of content that at the point of delivery can be mixed and matched so that an output is built, a format is applied and publishing happens on the right device at the right time, etc.

SO:                   Yep. And I’m totally there with you, but all the non-tech writers just ran screaming from the room.

VS:                   I know they did. I know they did. They ran, they’re hyperventilating, but it gets worse for them. It gets worse for that. Actually.

SO:                   Tell us more.

VS:                   It does, sorry.

SO:                   It’s 2020. Tell us more.

VS:                   Well, so here’s the paradox. The paradox is that in order to be successful with this, in order to be successful mixing and matching these little components so that they create a thing that’s specific for you or specific for Tom or Sally or whatever, each one of those components needs to be standardized at every level. The terminology needs to be standardized, the grammar needs to be standardized, the style needs to be standardized, the tone of voice needs to be standardized. It all needs to be standardized to create an experience that is not disjointed, that at best kind of reads funny or looks funny because we’re not calling a widget a widget, we’re calling it 20 different things and at worst completely confuses the person you’re delivering it to.

VS:                   It all has to be completely standardized in order to be successful with this. So they have got to be small, individual standardized chunks of content, devoid of format that can be mixed and matched so that at the point of publishing, that output is personalized to the person who asked for it and sent to them at that moment in time. So yes, everybody’s now screaming. “You’ve taken away my creativity, danger Will Robinson! Creativity, creativity.”

SO:                   And I’m really sad right now that this video will not be captured on podcast. Excellent robot impersonation.

VS:                   You can see me with my hands like robot. Yes, sir.

SO:                   Okay. So having covered all the 2020 buzzwords, COVID travel, etc. What about artificial intelligence? Is that going to help us with this mess?

VS:                   So it will, it’s going to fundamentally change the way all of this happens. So with today’s technology, we have some constraints. One of the constraints is that we have to tag each piece of content with enough metadata that is appropriate, that systems can locate each chunk of content that needs to be delivered for your personalized experience. So that’s the first constraint that AI is going to pretty much mitigate. In an AI engine when they become ubiquitous, that cognitive system itself sets up its own matrices that we don’t tell an AI system, “Here are your tags,” it sets it up. And we tell it, “Here are the things that go together,” we train it, “Here are the things that go together,” and we train it with a whole bunch of information, and then it continues to figure it out on its own. So the locating of the content is going to be much easier.

VS:                   Also, AI systems can look through any kind of content. It doesn’t have to be a structured content. It can look through emails and social posts and all kinds of other content in order to grab what it is you need at that moment in time. And it does it really fast and it learns over time what’s correct and what’s not correct. So the whole process of locating that information and grabbing it, and the whole percentage accuracy goes up, right? The longer it goes on, it’s more likely to be accurate. So that’s one way.

VS:                   The second way is right now, we are constrained by output types. We really do have to define the output type. In the AI world, we won’t need to, it will just send you information. It will be able to on the fly know, “Oh, this is what you need, I’m going to take all these different pieces and I’m just going to send it to you.” We won’t need to define in advance what it’s going to look like. It will be able to do that on its own. We’re not there yet, we’re definitely a few years away minimum, probably… I mean, you and I have plenty of customers that aren’t even at the point of being in structure yet, right? They’re just getting there. So I think there’ll be companies that can leap frog right to it once AI systems are all over the place, but for now we are constrained and AI will take those constraints away.

SO:                   So that’ll be fun and hopefully not at all troubling. All right so it sounds as though we’re going to need this book. So is it out yet? Where can we get it? When can we get it?

VS:                   Any minute now. So the book is not out yet. It’s November 9th. It was supposed to be out at the end of October, but it’s 2020 and nothing happened on time in 2020. It will be out in the very beginning of 2021. You’ll be able to get it on Amazon, or you’ll be able to order it from XML Press. And again, the title is The Personalization Paradox: Why Companies Fail and How to Succeed at Delivering Personalized Experiences at Scale. And I should mention that I do have a coauthor, her name is Regina Lynn Preciado. Regina and I have worked together for, we got to 15 years and it just got blurry beyond that because we’re old, we’ve worked together for a very, very long time. She’s a phenomenal content strategist, I’m really a happy to have collaborated with her on the book.

SO:                   Awesome. So we’ll add all of that information to the show notes and hopefully with any luck XML Press or Amazon or somebody has a pre-order page up.

VS:                   XML Press does and the Content Rules website also does.

SO:                   Okay, great. So we’ll add some version of those. And I think with that, Val, thank you so much, I’m going to wrap this up. This has been the most fun I’ve had today by a long shot actually.

VS:                   Oh, goodie. That’s cause you like my robot impersonation. Danger, danger.

SO:                   The robot was very helpful. So thanks again, and hopefully I will see you in person at some point in 2021 and not just on a screen because I’m kind of over the screen thing, but we’re lucky that we get to work at home, but…

VS:                   We are. And thank you so much for inviting me on and it’s always fun to talk to you.

SO:                   You too. So with that, 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.

The post The personalization paradox (podcast) appeared first on Scriptorium.

In episode 83 of The Content Strategy Experts podcast, Gretyl Kinsey and Jake Campbell talk about the next generation of DITA. What happens when you need to update your existing DITA structure?

“When you’re building everything out the first time around, you can do as much user acceptance testing as you want—but the best user acceptance testing is going to be live testing.”

—Jake Campbell

Related links: 

Twitter handles:

Transcript:

GK:                   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 the next generation of DITA, what happens when you need to update your existing DITA structure? Hello everyone and welcome. I’m Gretyl Kinsey.

JC:                    And I’m Jake Campbell.

GK:                   And we’re going to be talking about updating your DITA content structure today so I think we want to start by just briefly talking about DITA itself and the kind of different generations or versions that it goes through for those who are unfamiliar. Jake, can you just give us a little overview of that?

JC:                    The earliest version of DITA that I’m familiar working with actually started back in 2006, DITA 1.1, and that lacked a lot of the modern conveniences that we’ve become accustomed to in DITA today, particularly when it comes to actually customizing the DITA structure. You weren’t able to do things like specialize attributes, some reuse capabilities I think we’re kind of limited. And now we’ve got a lot of very specialized topic types. We have a broad suite of specializations available out of the box for some purpose built usage, things like the troubleshooting domain or some of the more specialized element, like hazard statement for when a standard note won’t do.

GK:                   Right. And I think a lot of these kind of differences between each version of DITA because we’ve gone, as you said, from that earliest 1.1 to 1.2 and the now we’re in 1.3, and I think one of the big driving forces behind that has just been this idea of seeing how people use DITA, how people need to use DITA and what changes sort of needs to be made to that out of the box content model to kind of help make sure that all those features are available. There’s definitely been, I think, kind of a few major evolutions that we’ve seen.

JC:                    Yeah, definitely. And a lot of what’s available now is kind of in response to what people have needed. And we’ve actually seen with some clients who need to move their content model from DITA 1.2 to DITA 1.3 or in some cases DITA 1.1. to DITA 1.3, there are some things that they had specialized or that they had built specific semantic structures around that are now actually part of the base DITA model as of 1.3.

GK:                   That’s actually a really good segue into the next question I wanted to ask, which is what are some of the reasons that you might want to update your DITA content model? And I think you already kind of touched on that with the idea of being able to include features that you couldn’t before and then suddenly those start to become available in the latest version of DITA.

JC:                    Yeah. And the kind of most sweeping way that you kind of realize that’s happening when you move into a new version of DITA is some of topic types that become available. I remember when the DITA 1.3 specification was just starting to come out and there were some rumblings about it being released, there was some discussion around the troubleshooting topic type, which is a further specialization of the task type. And there were a lot of people talking about how that was really important because there were semantic structures in that that specifically said, “These are the problems you’re seeing. This is what could cause these problems. This is a way to solve that problem.” Whereas before you would have had to specialize a task structure or create specific semantic structures using out of the box components in order to contain that kind of information previously.

GK:                   Yeah. If you have a case where you need to support some kind of structures and then you see that those are becoming available in the next version of DITA, that’s a really good time to kind of evaluate what you’ve got now and think about when it’s going to be the best time to make this move over into the new version and kind of clean up some things that had to be specialized before. Because I think one thing that we try to recommend is to only specialize as much as you need to and to use the out of the box features. Keeping an eye on what becomes available out of the box over time is a really smart thing to do and can definitely be the case for making some tweaks and updates to your existing DITA structure.

GK:                   Another thing that can kind of guide you along that path is if you get into a situation where you start to change your technology, so maybe you’re looking at a different content management system, you’re looking at maybe some different publishing outputs, you’re looking at new authoring tools, any or all of the above. And you have developed your existing DITA content model in ways that sort of aligned with the current tool set you have now. But now that you’re looking to change, then that’s a place to start evaluating is there anything in the DITA model that needs to change too, as we start to change software and technology?

JC:                    Yeah, I’m sure we’ve touched on this on the podcast in the past, but once you start looking at a proprietary tool, they probably handle things in a very specific way in order to achieve their goals. And that usually means that there may be some compromises or accommodations that need to be made in order to actually make that work. Some CCMSs we’ll use more of a database model for containing all of the different information that you want to have there. It kind of treats these individual elements and files as objects within a database. There may be something on the CCMS side that is equating with the ID attribute that you need on your DITA topics, but isn’t actually using that ID attribute that’s on those DITA topics. You may need to take a look and see if that might be something that’s locking you into that particular technology depending on what kind of move you want to make from there.

GK:                   Yeah, absolutely. And I think, especially if you did some sort of a specialization, if you did some sort of workarounds on your content model that were designed to sort of accommodate the current authoring workflow and content management and publishing workflow that you have and you realized that that has created a little bit of lock in with your current tools and you need to change, then I think that really presents a good opportunity to say, “Well, if we are going to make this change anyway, we really need to look at the DITA itself and figure out how that has to change too.” And then whether the latest and greatest version of DITA that’s out there, if you’re currently in 1.1 or 1.2, if going to 1.3 can kind of help make that change easier.

JC:                    Yeah. And when you’re looking at moving your content model over as well, you might want to take a look at, do you have any customized output, any custom DITA transforms that you’ve built around your particular specialization or any changes you’ve made to your content at the same time?

GK:                   Definitely. And there’s one other thing I want to touch on here too, which is that if you have any sort of new requirements that come up, so let’s say you have a new product that you need content to support or let’s say that you are extending something about the particular information or metadata that you capture around your existing products and you need to extend your DITA content model, especially if you have specialized it, then that can also be kind of a driving force to look at well, does the current version of DITA that we’re in support that? Or should we also just look at moving to the latest and greatest? Looking at going to DITA 1.3 at the same time? Will that help make anything easier if we’re kind of touching up an existing specialization?

JC:                    Yeah. And when you’re thinking about that as well, it’s important to identify what kind of gaps you’re currently seeing when you’re thinking about making that kind of move, because you should always start with this kind of gap analysis for want of a better phrase, to say, “What needs do we have that aren’t being served? And how can we rectify that? Can we make any of those kinds of changes of what we have now? Or do we need to move somewhere else?” And I feel like that’s really going to be a driving factor in, do we make this kind of big jump into a new version?

GK:                   Absolutely. What are some things to consider when you’re approaching a DITA remodel?

JC:                    I’ve always kind of said that when you’re building everything out the first time around, you can do as much user acceptance testing as you want, but the best user acceptance testing is going to be live testing. Even when you’re in production and you’re happy with what you’ve got and it’s working and it’s not posing a significant problem, it’s still a good idea to kind of keep taking the temperature on these things, to see, do we have any content authors who are running into problems? Are we running into any weird corner case issues with some of our broader content now that we’re actually out in production with this? Definitely, see if you aren’t being served by your content and what can you do to make sure that you’re getting everything that you need out of your content?

GK:                   Yeah, absolutely. I think that leads into a lot of the steps that we try to take with our clients when they come to us and say, “We need to restructure our DITA. We know that our content model isn’t working, but we’re not quite sure how to go about making that change.” One thing that we do and it kind of really helps to have those metrics, Jake, that you were talking about is, suggesting that the company evaluate which parts of the DITA structure still work? What should you keep? Which parts of the model are still going to be functional for you after you change? And then which parts are not serving you so well? And then you have the roadmap you need to start making a plan for how you’re going to change those things that aren’t working. And when you know that, that sort of makes it manageable because you’re not just kind of going, “Oh my gosh, we have to change everything.” You have a really specific plan for how you’re going to tackle that.

JC:                    Yeah. It’s not that unusual to kind of look back on the initial development process that you did with your specialized content or with the current model that you have and just kind of compare it to what you’re actually getting out of it. If you’ve been through this once before, you probably already have some sort of roadmap that says, “This is what we have done in the past,” and you can kind of use that to measure up your current state with where you thought you would have been.

GK:                   Yeah, absolutely. I think it is really important to learn from those lessons of the past if you have been through this before, because if you’re in DITA now, you did initially go through some path to get there, whether it was just starting in DITA or going from some sort of unstructured content to DITA. You do understand kind of what it takes to develop a content model in DITA, what it takes to understand the structural needs that you have and then how to take that forward. It does give you a baseline of lessons learned for what to do when you do this remodel.

GK:                   And I think one thing to really think about and be cautious about, which is something, Jake, that you touched on a little bit earlier is when we’re talking about designing specializations and content models around your tools, around your content development workflow, it’s really important to be careful about doing any sort of work arounds or specializations that are specific to a particular tool, because that does lead to a certain degree of lock-in and that’s something I think that you could avoid going forward if you’ve already done that once.

JC:                    And it’s also important to try and think about where some of this information is being stored. I know that metadata is kind of a weird squishy concept because metadata is information about data. It doesn’t have a lot of inherent meaning sometimes. It can be kind of hard to think about and it’s not unusual for some parts of metadata to be stored within the CCMS rather than stored within the source. Trying to think about what are you trying to do with your metadata structure when you build it out? Where are you going to store it? And how is it going to be used? And where is it going to be available? Is all really important when you’re thinking about tool selection and when you’re thinking about how to model your content.

GK:                   Yeah, absolutely. And I think I’ve seen in many instances with clients I’ve worked with that there’s kind of a hybrid where there will be some metadata that’s stored in the DITA content itself and other metadata that is managed and stored by the CCMS and by the tools. And so there’s kind of that balance there that you have to think about. And if you are doing a DITA remodel, that gives you an opportunity to revisit your taxonomy and to think about metadata beyond just what’s in the content itself? But how it’s used overall. And that’s where, we get back to this idea of gathering those metrics from your customers about how they’re using your content. You gather metrics from your authors about how they’re creating content and what are some of the roadblocks that metadata can help solve? And that can give you a lot of good information about how to approach metadata and how you might want to remodel that as part of your overall DITA restructure.

GK:                   Another thing to think about is the migration process. How is content going to be migrated from the current DITA structure you’re in to your new one? And are there any concerns around scripting and automation that can be addressed on the content model side to make that easier when you’re having to go through and rework the way that all of your DITA content is tagged?

JC:                    Yeah, it’s tricky when you’re looking at migrating into a newer version of DITA from an older version. By default, DITA is backwards compatible. Theoretically speaking, you could open up any file that was created in DITA 1.1 in something that’s using that DITA 1.3 definitions and it should open up just fine. And it most likely will. It just won’t be as fully featured. When you’re looking at moving from an older version of DITA to a newer version, just the baseline, the biggest thing you should be looking at is, what are we looking to get out of this migration? Is it just to get us to a new starting point so that moving forward, our content can be richer and take advantage of the features that are afforded by this new environment? Or are we looking to try and leverage some of those new features in existing content? In which case you really need to do an analysis of the why you’re moving and put together a plan for how you can fill those gaps.

GK:                   Yeah. And I think that’s especially important if you have done any sort of specialization that may not carry over so well to the latest version of DITA, or if it needs to be kind of completely reconfigured or restructured because DITA 1.3, for example, supports something that you build a specialization for before when that didn’t exist in DITA by default. That’s something to build into your analysis and into your plan, not just thinking about what does the new structure look like? But how are we going to move our content over? And sort of what are the priorities? What content needs to be re-tagged and restructured first?

JC:                    Yeah. And to bring it back just for a second to, we’ve specialized and we’re moving, did the newer version of DITA actually implement the thing you specialized already? We’ve actually seen in the past instances where there has been specialization and in migration to a new version of DITA found that not only did that new structure exist, it was also named the same. You need to kind of take a look at that and make sure if there is something new that exists that fills the role that you wanted to fill, would it be better to keep what you already have with your specialization? Or migrate your existing content over to that newer specialization?

GK:                   Yeah, absolutely. When you are developing your very first DITA content model, what are some safeguards that you can build in to avoid headaches if you do have to update it in the future? I know some companies are able to kind of stay with the same content model for a long time, but I do think it does become sort of inevitable that after years and years, you will probably need to or at least want to switch to whatever the latest and greatest DITA version is. And so, how can you set up your very first, your initial DITA content model to make that as smooth as possible and to kind of future proof it for later versions?

JC:                    The best advice that I could give is kind of what I’ve been hitting on as we’ve been going throughout is figuring out why you need to get this set up. And if you have a really good understanding of why you’re doing something, you’ll be able to better define what you can use out of the box or to identify the places where you’ll need to specialize. And if you have a really good understanding of the reasons that you’re doing this, you will most likely have an easier time of reacting if that needs to change later.

GK:                   Yeah, absolutely. There’s something that we’ve said in many of our podcasts before, but the more upfront planning that you do and the more you kind of analyze your specific needs around why your content model should be a certain way, that will really, really help make sure that you make the right decisions and that you kind of avoid things that will become pain points down the road. And I think in particular, when you’re looking at sort of broader information architecture decisions, things like your taxonomy and metadata, things like how your content is organized, how it’s structured, how it’s broken up into the different DITA topics and maps that you have, how reuse is set up, all of that. The more planning that you do upfront, the less chance that you’ll probably have of having to do major reorganization on that in addition to just updating your DITA version.

JC:                    Yeah. And also I kind of just to get into the specifics of it real quick, I deal a lot with actual DITA transformations, taking your DITA and turning it into something different. And the most compelling reason that I’ve found for specialization kind of boils on that side of things, boils down to two sides. It’s we need to make sure that our content gets treated in a specific way once it gets turned into a PDF or into HTML or whatever, you need a specific semantic structure to key off of in the transform so that it gets treated a particular way. Or, oh no, our SEO is bad. We need to make sure that our metadata is being handled properly. It’s not only knowing what you want out of your content model, but how your content model is going to deliver that for you once you actually start generating your content with it.

GK:                   Yeah. And that actually brings up a couple of points too that are sort of general advice. They may not apply to every company, but they are things that we tend to advise people to consider at least when it comes to sort of designing your content model. When you’re talking about the concerns around your output, one thing that we do really stress is to focus on semantic based tagging and not on tagging that is going to kind of help you get a lot of specific formatting based edge cases into your outputs. And again, that’s just because the entire point of DITA is to have your formatting separated from your content itself. Building things into the actual structure, building a bunch of specializations that are there just to address formatting concerns is generally not the greatest idea, especially if you think about how in the future things with your outputs may need to change alongside of your DITA version itself. That’s one thing that we really caution people about.

GK:                   And another thing is with regard to specialization itself, we tend to advise sticking to the DITA standard out of the box, as much as you can and only specializing when necessary. And again, that’s just because when you do specialize, if you need to make a change later, that’s always a little bit more difficult than just going kind of from an out of the box structure to another out of the box structure. That’s kind of just a little bit of advice we tend to give. Of course, there are always going to be exceptions. There are always going to be some companies that really do need heavy specialization, but we just advise that you try to keep that to semantic reasons rather than just doing it because you can or because you have some concerns around formatting.

JC:                    Yeah. When you’re looking at specializing like that, you really want it to be about making sure that your content is semantically rich. If you have a product that’s italicized because your style guide says, “Product names are italicized.” You don’t want to be wrapping that in just an i-tag, because that just means it’s italics. It doesn’t mean it’s that kind of content. And you want to try and find ways to enrich your content, not just make the content fit a guide.

GK:                   Yeah, absolutely. I think the biggest things to remember are just put semantics first, put structure first and do as much of that upfront planning as you can around the semantic needs that you have so that one day when you do have to go into the next generation of DITA, that can be done as seamlessly as possible. With that I think we’re going to wrap things up. Thank you so much, Jake.

JC:                    Yeah. Thanks for having me. It’s great to be here with you.

GK:                   And 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.

The post DITA: The next generation (podcast) appeared first on Scriptorium.

In episode 82 of The Content Strategy Experts podcast, Elizabeth Patterson and Bill Swallow talk about taking a phased approach to content strategy when you have limited resources and how you can prioritize that approach.

“It’s really easy to allow your scope to expand. Try to keep it finite. Try to keep the phases small.”

—Elizabeth Patterson

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 look at taking a phased approach to content strategy when you have limited resources and how you can prioritize that approach. Hi, I’m Elizabeth Patterson.

Bill Swallow:                   And I’m Bill Swallow.

EP:                   And today we’re going to talk about taking a phased approach to your content strategy. So the first thing that we’re going to hit on is why exactly companies take that phased approach, which is something that we are seeing more and more frequently with the companies that we’re working with. And the number one reason for that is going to be limited funding, and limited resources. So when you are moving forward with a content strategy or an enterprise level content strategy, oftentimes the price tag on that is going to be pretty steep, and when you try to pitch that to upper management, it can be really difficult to get that approved. So breaking your approach to your content strategy up into phases can make those smaller price tags more appealing to upper management, and therefore it’s easier to get it approved.

BS:                   Also, what we’re seeing a lot now are more enterprise level implementations of a content strategy, and it is almost impossible to completely scope out accurately that entire implementation from start to finish. So it’s much easier to break it up into chunks and that way you have a clearer idea of what needs to happen. And usually these implementations take months, if not years. So taking a phased approach kind of keeps you on task.

EP:                   Right, and when you’re sitting down thinking about an enterprise level content strategy, and you’re coming up with a list of all of the things that you need to accomplish, that gets to be a really long list and sometimes things change, and so having those phases helps you to better prepare for those changes so that you don’t have this huge plan mapped out and then all of a sudden it’s completely different by the end of it.

BS:                   Right. Some of these phases could be as small as evaluating a new tool set, or it could be doing a content analysis to see what needs to change in either how you’re writing or how you’re managing the authoring process. It could be larger like implementing a tool set and running a bit of content through it. But by having these phases, you have a very finite start and finish. You know what your starting point is, you know where your end goal is. You can roughly scope out the amount of time that it’s going to take to get the work done. You kind of know how many resources you’re going to need, or you’re able to adjust a timeline based on the number of resources you have. And you know the rough costs that you’re looking at, to say this quarter, we’re going to focus on buying and implementing the software. Great. So your primary cost aside from a little bit of resource time is going to be the cost of the tools that you purchase.

EP:                   Right, and this approach, taking the phased approach, is going to look different for different companies because you have different needs. So what we’re talking about now might not look exactly like it’s going to look for your company. This is just sort of a general outline.

BS:                   Exactly. Some companies focus more on localization improvements, other ones focus on more authoring improvements, or they focus on systems integrations. There’s a wide variety of reasons why people would adopt a content strategy, and the phases that are involved are going to vary from case to case.

EP:                   Something that you might want to consider, if you do have these limited resources, and not just with limited funding, it can be valuable without that as well, but is a proof of concept. So completing a small project that can then show your upper management, show your company, that this is going to be worthwhile.

BS:                   Right. Especially if you’re doing something completely new from what you’ve done in the past. You want to be able to have something to say, here, I’ve proven that this can work.

EP:                   So I want to talk a little bit about prioritizing a phased approach, because I think that this is sometimes a question that we get. Really the first thing that you’re going to need to do is to clarify the problems that you’re trying to solve. That can take the form of an assessment. So you could have a content strategy assessment done by a consultant that’s going to help you to identify your gaps and then make recommendations for those gaps. And you’ve got to be able to pinpoint those things before you can get any further. Trying to decide where you’re going to go, what tools you’re going to use, before you even know what problems you’re trying to solve is a big mistake.

BS:                   Right, and it’s not to say that you can’t do it internally either, but getting some kind of an outside view, even if it’s just to look over what you’ve put together, as far as the assessment work that you’ve done, getting a third-party to go in and say, yes, this makes sense. Or did you think about this? Or what about this over here? It kind of brings a bit of clarity to what it is you’re trying to do before you actually start spending a lot of money on new tools, on training, on migrating your content, or what have you.

EP:                   You also want to try to get everyone on the same page. So starting with this assessment and really identifying those problems and helping other people at your organization to understand what the goal is, can be very helpful because company politics can be pretty nasty, and pretty difficult to work with. So you want to have everyone get as close to an understanding as possible to where you’re going with this project, because if you all have different goals in mind, that can make it very difficult to prioritize as well. Because everybody’s going to have an agenda. You want to have that end goal in mind and have everybody understand that, so that you can work together to accomplish that.

BS:                   It’s not to say that the actual focus or the actual approach isn’t going to change either. So while some people might have some reservations, they may not be able to fully articulate it. But if they at least know what the end goal is, they’re more inclined to kind of go along with the early stages, and usually at that point, once you start getting a couple of phases in, you really start seeing how everything is going to start coming together, or not. And you’re able to make those fine adjustments or you’re able to stop and redirect before things get too far off the rails, and that usually helps people see where things are, see where the end goal is, and then start understanding where they fit in within the full scope of the strategy.

EP:                   That can be really helpful, too, with this phased approach is, okay, you stop and you think, this is something that we need to tackle from a different direction. And because you’re moving through that phased approach, you’re able to do that. There’s nothing worse than making a decision quickly because you have to, and then regretting that decision later, which we see very often.

BS:                   Measure twice, cut once.

EP:                   Absolutely. So I do want to talk a little bit about some of the things that you really need to watch out for when you are taking a phased approach, and that kind of goes into what we were just talking about. You have to be patient sometimes. So you’re moving through this in phases, funding at your organization may be coming through slowly and in chunks, but you want to do it right. By doing it in phases, you’re giving yourself that opportunity to catch things as they happen. But sometimes you’re going to have people on your team that just want to get it done. They just want to go full throttle. With a phased approach, you have to be a little bit more patient with that.

BS:                   Right, and I will put this out there right now. Your first phase, or even probably your first two or three phases really should be more analytical in nature. Being able to get your arms around things. It depends on, obviously, the size and scope of what you’re trying to get done. But if you are approaching a new content strategy and you jump in phase one with let’s pick some tools, you’re doing it wrong. You’re doing it wrong. The goal is not to use new shiny tools, although it’s always fun to get new stuff and play with it and be able to do new and interesting things. But you want to make sure that those new and interesting things kind of fit where you need to go, and not losing track of all the other contingencies on your content that’s still need to be met. So you might be able to hit the highest priority on your end goal, but all of the subsequent needs are left hanging. That’s somewhere that you definitely don’t want to be, especially after you spend a significant sum of money on new software and new tools.

EP:                   I think we’ve said this until we are blue in the face. It’s in so many different blog posts and podcasts, is that tools should definitely not be the first thing that you choose. You’ve got to identify the problems you’re trying to solve first.

BS:                   And it still needs to be said because it’s still a knee jerk reaction that… You can’t help it because it’s a very tangible thing that you can implement and say, look, new, shiny. It’s going to work. But it’s really one of the last things that you want to do. You want to get all your planning done upfront, then focus on the tool sets that best match what you discovered during the planning phases that help you achieve your goals. Then toward the final end of the phases, you then have the implementation work, which is usually extremely substantial, and then your training and maintenance going on forward.

EP:                   Another thing to keep in mind is that it’s really easy to allow your scope to expand. So try to keep it finite, try to keep these phases small so that…. Don’t use those knee-jerk reactions and pick a tool set before you’re ready. Just know that the phased approaches do give you more flexibility when it comes to scope.

BS:                   If you have a pilot project, you also want to keep that scope small. Use a very small content set. Make sure that you have something defined from start to finish. So your pilot should involve a bit of authoring, should involve a bit of review, should involve a bit of publishing, and then seeing what that looks like, so that you have something tangible to poke at. The greater you increase that scope, so if you’re going from, let’s say 10 documents, to a thousand or even a hundred, you’re increasing the level of effort and the complexity of getting that proof of concept done. The point is not to get your stuff through in that proof of concept. It’s just to say, see, this is possible. Now we can expand the scope and we could take a look at it in a bit wider stance.

BS:                   It’s not to say that, also, you want to jump from one phase where you have a very finite, very controlled proof of concept to “let’s do everything now.” You want to break it off into pieces, so if you have multiple product lines, if you have multiple companies under your corporate umbrella, you don’t want to throw them all in at once. You want to take one through and see how it works, see if anything else needs to be adapted. So going back to some of the analysis work that you did and make sure that nothing has changed there and also check your horizon and make sure nothing is changing out there, and then you can proceed with the next phase.

EP:                   And let the phases do their job. Avoid those quick fixes, even if you feel like it’s something that you have to do. We did a podcast a couple months back on quick fixes, which I will link in the show notes, but that can end up costing you a lot more money in the long run, and if you already have limited funding, this can be disastrous.

BS:                   Exactly.

EP:                   Also, the phase that makes the most sense to start might not be the phase that’s going to seal the deal with your stakeholders. You need to set those crystal clear expectations upfront, and, again, have everyone on your team sit down and understand the project. Talk about it, get people on the same page, because without having those expectations in place, you’re going to have problems along the way.

BS:                   Not everyone is going to be able to play in every single sandbox along the way. You’re going to have to bring a few people in at a time, when it’s relevant for them to be involved, and make sure that that phase addresses the concerns that they have around the goals that you’re trying to meet in that phase as best possible. Then bring another crew in later for a subsequent phase. If you try bringing everyone in at once, and you try to tackle everyone’s needs at the exact same time, the scope is just going to expand exponentially because now you’re starting to really bring in all of the dependencies and discrepancies with how people work, and rather than trying to focus on making sure that they’re all being addressed, you’re spending the time mitigating a lot of conflict between the groups saying, well, mine should take priority because X, Y, and Z. You have two, three, four people saying that and suddenly nothing gets done because everyone’s bickering.

EP:                   So I know we were just kind of talking about some things that can be really intimidating, but overall taking a phased approach to your content strategy has a lot of benefits to it, and a major benefit is that you are biting off small chunks. So you’re going to address problems as they come up, rather than having really big surprises later on when you’ve already made it so far in the project, and then you have these unexpected expenses. Now, sometimes those things can still happen, but you’re really reducing the risk for that, which is important, especially if you have limited funding.

BS:                   You’re basically taking a lessons learned approach as you go. So you can scope things out. You can hit your target, even if you’re a hundred percent successful, you’re probably going to have some takeaways that are going to adjust how you move going forward. So taking that phased approach really does allow you to really stop and pivot along the way until you get to exactly where you need to be.

EP:                   So I think that that is a good place to wrap up. Thank you so much, Bill.

BS:                   And thank you.

EP:                   And 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.

The post Taking a phased approach to your content strategy (podcast) appeared first on Scriptorium.