Scriptorium

In episode 81 of The Content Strategy Experts podcast, Gretyl Kinsey and Alan Pringle discuss document ownership and the role it plays in content development workflows and governance.

“You’ve got to quit the focus on the tools. The tools are not going to solve mindset problems. Those are two distinct different things. You’re talking about technology, and you’re talking about culture. Culture is a lot harder to change.”

—Alan Pringle

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 document ownership and the role it plays in content development workflows and governance.

GK:                   Hello, and Welcome to the Content Strategy Experts podcast. I’m Gretyl Kinsey.

AP:                   And I am Alan Pringle.

GK:                   I want to start off this discussion about document ownership with just asking a very basic question. What is it? What is document ownership?

AP:                   Document ownership means answering the question, who is responsible for the creation of this content, for the review of this content, approval of it, any other things that you do around content? So who is responsible for basically the parts of that life cycle?

GK:                   Absolutely. I think it’s important to point out too, that those responsibilities for all those different aspects of the content and that development workflow are different from one organization to the next, and it depends on things like the size of your content team, the resources that you have available, the kinds of content you’re creating. We’ve seen some organizations where there’s just a really small team in charge of creating content, and so you might have one person who kind of owns the entire document life cycle from its creation all the way to its approval and release, and then in other cases, things are a little more segmented. You might have some folks who are in charge of writing, some who are in charge of editing, some who give the final approval. So, it really kind of depends on the organization, but there is a tendency, I think, for there to be some kind of an ownership model in place so that all those responsibilities are laid out and everyone knows what has to happen to get that content out the door.

AP:                   There’s another kind of side angle to this, another kind of ownership, and what happens if your company is acquired? What happens if there is a merger? Then you’ve got these two corporate cultures and what they perceive as the correct document ownership process. Then you’ve got to figure out how to integrate those two together, so it’s like ownership on top of ownership and that can be quite the challenge.

GK:                   Oh yes, absolutely. I want to talk a little bit about that challenge and how it kind of feeds into some other challenges that we see a lot around document ownership. One, of course, is just how document ownership differs when you look at an unstructured versus a structured content workflow. When you’ve got an unstructured workflow, then I think we more frequently see cases where documents tend to truly be owned by a specific person, a specific group, someone who’s responsible for the document from end to end, whereas in a structured workflow, since the content is more modular and you tend to have things like components or topics, the content is broken up into smaller chunks. Then, the ownership is not necessarily of an entire published document, but over the kind of pieces and parts that go into that document. So, when you’ve got a workflow where you can mix and match and reuse topics and your final published documents have more flexibility, then that changes the way you have to think about ownership.

AP:                   Right. It really has to. What you’re talking about is basically more of a printed book model, where you’ve got one monolithic thing at the end and it made sense. Okay, I’m going to own this or this author is going to own this, but when you were starting to take a more modular route and a bunch of pieces and parts are coming together to create a document, a deliverable, a book, a help set, whatever it is, it does require a really kind of big flip in your mentality about ownership.

GK:                   Yeah, absolutely, and so you kind of think about how are we going to approach ownership in a structured workflow? Instead of it being based on documents themselves, it might be something like a particular subject matter or a product line. A person or a group might own one product family or product suite instead of an individual document, and you may also have people in charge of whatever subject matter that they are experts in. So you may have some folks over here who are in charge of, let’s say engineering, and you may have a set of folks over here who are in charge of something else. So, you’ve got these different, more subject-based types of ownership roles than looking at really just who owns a document from its inception to its publication.

AP:                   This in some ways parallels the agile software development, that whole change in mindset from the more waterfall development to agile development. I’m not going to get into that because I know it can be contentious and people use those words a little more differently, but the same idea is still there, breaking things down into smaller parts. I think that very much applies to what you’re talking about here.

GK:                   Absolutely, and then you have to think about a few other things that are more on the management and workflow and governance side as well. So, instead of just saying who’s responsible for a document or who’s responsible for a subject within a document, you have to think about things like reuse and linking strategy, taxonomy and metadata personalization requirements, all of those sorts of things. It’s really important to have some sort of an ownership model for those aspects as well, because if you are just thinking about it from more of a document point of view, then those aspects that reach across documents won’t have any sort of person in charge of them or group in charge of them, so that’s something that you have to consider for your ownership model if you were in a structured workflow.

AP:                   Another aspect of this too, sometimes you can take ownership possibly a little too far and try to recreate a wheel if you’re inside a company, and, for example, you have a strong web presence marketing group. I’m going to assume there is some kind of taxonomy in place in regard to products, possibly how they’re organized on the website, things like that. So, there is some kind of hierarchy there to describe your products, your services. If you were writing for another department, for example, let’s just say the product documentation team, the product content people, you need to get that existing taxonomy and then add your two cents to it. Don’t redo the whole thing. So yes, you need to get your part in there, but don’t assume that ownership of that means it is yours. This could be more of a company enterprise level thing, and you need to bolt your part onto that.

GK:                   Yeah, absolutely. I think this really gets into the idea of how working with structured content actually opens doors to scaling up and addressing content across your entire organization, really getting it in at that enterprise level and making things consistent across the entire organization. So it is really important not to have this kind of siloed or segmented ownership, regardless of whether it’s at the document level or at some other kind of organizational level. It’s really important to think about, “Okay, we’re in structure, so obviously this model of a document-based ownership isn’t going to work. So how do we take our ownership across the organization, collaborate with other departments, use what they’ve already done and they can use what you’ve already done?” That way, it eliminates a lot of wasting time, as you said, reinventing the wheel.

AP:                   Yeah, and something you just said, talking about silos there, it just occurred to me. When you own an entire book, and yes, I know that’s kind of 20th century, but I’m going to use that word anyways, when you own a book, if you think about it, that is a silo right there on its own in a lot of cases.

GK:                   Absolutely.

AP:                   So it’s basically breaking that book up into pieces and parts, and there’s a parallel there to what you were just talking about, more of an enterprise approach to thing. Yes, there is organization, there is a method to the madness, but when you get down to it, it is a bunch of pieces and parts that are shared, and that’s the bottom line from my point of view.

GK:                   Yes, absolutely. It’s about that modularity, that granularity, and having those flexible and shareable pieces. That kind of brings me to the next question I want to ask, which is about the shift in mindset. So we talked about how it really is a very different mentality between the way that you would own documents versus own these modules or parts. So, when a company shifts from an unstructured to a structured content development workflow, how can they make that transition easier with that document ownership mindset?

AP:                   Well, first thing, you’ve got to quit the focus on the tools. The tools are not going to solve mindset problems. Those are two distinct different things. You’re talking about technology, and you’re talking about culture, and guess what? Culture is a lot harder to change.

GK:                   Yes.

AP:                   You can train someone how to use a tool proficiently. That is not the problem. It is getting them to buy in to using that tool that is the huge problem. So you have to realize, merely buying the tool, that is not going to solve your problem. You have to address culture and change management through good communication training. I sound like a broken record. I think I’ve spoken about this a zillion times on this podcast, so I’m not going to dig into that again, but basically culture, culture, culture. That is very important. The tools are not going to take care of that for you.

GK:                   Right, and I want to reiterate, training is important, but it is only one piece of it. As Alan said, it’s about thinking about that culture and not just providing the baseline training, but the true support that people need to make that shift and to understand it is going to be a major change in the way they work. It’s going to be a major change in the way they think, and so it’s really important, I think, to really show them the value of what moving to structure is going to buy them. So, as a content creator, it might do things like eliminate a lot of manual processes and inefficiencies and it might help things be more accurate, so it’s really important to show them that and help them understand, even though, yes, I know this is a big change, here’s what you’re going to get out of that change, and make sure that they don’t feel like they’re left behind and just left in the dust. They need to be supported and to be brought along so that that really big mindset shift does not cause problems.

AP:                   There are a few ways you can approach this from a mindset point of view. Number one, people are going to be learning new skills that make them more marketable. Now, if you don’t want to lose your best people, that can be kind of a hard sell, but you are giving people new skills that make them more marketable in the world, in the professional world, and that’s something that is not a bad thing to let people know. When we are making this change, you are getting new skills. So, that’s a great thing too. Once again, we come back to the whole idea of silos. You’ve got silos among departments, you’ve got silos among publications.

AP:                   Well, I think what I’m kind of headed to, you can have a silo of your own brain and experience, thinking, “This is the way things have to be. This is why they are. This is what works for me.” Well, unfortunately, you are a part of a bigger corporation, just like a content module is something that is part of a bigger group of documents, customer experiences, whatever. You were one part in this, and you’ve got to figure out basically how what you’re creating fits into the bigger picture, this giant puzzle.

GK:                   Yeah, absolutely.

AP:                   So, it’s a huge, huge shift in how you think, and it can be very daunting. I am not going to say it is an easy thing, because it absolutely is not easy for the authors, the content creators, the reviewers, and it is not easy for the people who are trying to manage and wrangle all of the expectations, the cultural shifts, and so on.

GK:                   Yeah, and I think that brings up an important point about content governance and why it’s really important to have that as part of your strategy and to have resources available for that, because that is going to help provide some of that continuity and that support for all the people who are actually creating the content and managing and publishing it. If you’ve got a strategy in place and someone who is dedicated to all of the governance around content, making sure that this shift from unstructured to structured actually goes through and actually works correctly, then that’s really going to, I think, help to smooth things over because as you said, it really is difficult. It’s a big adjustment and it’s important to think about that as part of your strategy and not leave it out and make sure that you do have those resources available for it.

AP:                   Yeah. To me, the most important thing I think I can end with is it is not just about switching tools. It is not. It is about culture and making that shift in mindset, and that is critically important. If you don’t take care of that, you have just flushed away thousands or millions of dollars. It is that simple.

GK:                   Absolutely. So one other question I want to ask based on this too, is that I think we’ve seen several instances of this happen, where you’ve got this mind shift happening, people are struggling to adjust, and one of the excuses that sometimes gets brought forward is we don’t actually own the documents, the customers do. That’s something I think that people put out there as an excuse not to change, and so I want to ask how you should approach that kind of situation when things are being deflected off onto the customers as the document owners.

AP:                   The customer’s experience is very important. You know, that is true. However, they are one stakeholder in this content experience. They are not the only ones who have a say in this. At the end of the day, while your customers are buying from your company, they are not the one directly paying your salary and I think it would behoove people to think about that. Yes, you advocate for your customers and do right by them, but you realize they’re not the only people who are involved in a change like this.

GK:                   Absolutely, and I think it’s also important to consider when you say that the customers are the ones who own your content, is the content actually serving them? Because in a lot of cases, too, one of the reasons companies move to a structured workflow is because customers are having trouble finding the content they need at the time they need it. So, if you really are truly concerned about your customers using that content and owning, it in a sense, then your first priority should be to think about, “How do I need to make the content findable, usable, and really serve the customer’s needs?” At the end of the day, the customer, even if they own the content, in a way, they don’t own the processes. That’s on you and your organization. So it’s really important to think about the bigger picture, again and in that sense, and ask yourself, “Am I really trying to serve the customer or am I just using this as a front to avoid change?”

AP:                   Absolutely. Is it real or is it deflection? That’s a great question to ask yourself.

GK:                   So I think really the main point we want to make about all of this when it comes to document ownership is again, as we’ve said, it is about that mindset, and when you change your processes, it’s really important to be adaptable and to understand that the way you may have owned a document in the past may not always work and it’s just really important to be flexible and to understand, document ownership can mean a lot of different things. Content ownership can mean a lot of different things, and what’s really most important at the end of the day is what kind of ownership model is going to be the most efficient and most effective for the company.

AP:                   To me, that’s the most important thing that you’ve said toward the end, for the company, not for you, yourself, not for just your department, but for the company.

GK:                   Yes, and I think that’s a good place to wrap things up. So, thank you so much, Alan.

AP:                   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 Document ownership in your content development workflows (podcast) appeared first on Scriptorium.

In episode 80 of The Content Strategy Experts podcast, Gretyl Kinsey and Sarah O’Keefe discuss information architecture in DITA XML and other forms.

“You have to look at information architecture in metadata starting from a taxonomy point of view. This means you are looking at the structure of the content as well as the organization of the data that’s used for search and filtering.”

—Gretyl Kinsey

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 discuss information architecture in DITA XML and other forms.

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

Sarah O’Keefe:                   And I’m Sarah O’Keefe.

GK:                   Today, we’re going to be talking about information architecture. So I think the best place to start is just defining broadly what information architecture is.

SO:                   And that sounds so simple and yet we’re going to hit our first snag, because if you go look at this, you’ll discover that everybody in content across all the different aspects of it has an opinion about what constitutes information architecture. I think probably the easiest place to start is to say that if you’re looking at a website, then the way that that website is organized and structured and how the content is hierarchical, you start at the top, you go to the about page, you drill down to the team or the company history, that’s information architecture.

GK:                   Right. And that can extend not just to the way a website is organized, but whatever your delivery method is. So the same thing, if you’ve got a print-based piece of content, it’s that hierarchy, it’s how is it organized into maybe chapters or parts, and that really can apply across all different types of content. I think this is a good place to mention that it is really important to know your terminology and define it, because when you’ve got lots of different types of content that you might be working with, you might get some confusion going on if you don’t really clearly define what IA means.

SO:                   Right. Exactly. And we’ve had some kind of hilarious run ins with this, where we’re sitting in a meeting and we’re talking about information architecture and what we mean is how things are encoded in the DITA files, which we’ll get to in a minute, and it turns out that our counterparts in let’s say content design or UX or something like that are thinking much more about the website delivery layer and nobody is thinking about the print, right? So we have to really be careful about this and be careful to make sure that when we say IA, that we know which one we’re talking about and at which level.

GK:                   Absolutely. You did mention DITA, so I want to talk about that next. So what is the difference when you’re talking about DITA-specific IA? How would you define that?

SO:                   So in DITA, when we talk about information architecture, what we’re usually referring to is how exactly are we structuring the content and marking it up in DITA. So which topic types are you using and what goes into each kind of a topic? Let’s say you have a bunch of reference information. Well, the decision to, for example, put all your terms and definitions into the DITA glossary is, I mean, extremely sensible, right? But that’s a decision and sometimes you might discover that you need a reference topic that the out of the box reference topic doesn’t really help with, so you go down the road of specializing. And then I think, Gretyl, you’ve run into some stuff with DITA metadata as well.

GK:                   Absolutely. And that’s an area where it’s kind of its own thing. You have to look at information architecture in metadata starting from a taxonomy point of view. So it gets into not just what is the structure of the content, but what is the organization of the data about your content that’s used for search and filtering and organizing it and making sure that everybody can find it. So that’s something I think even before you start building out the content structure itself, it’s really important to think about that piece of it, because in DITA, you can have specialized metadata structures as well. So if that’s something that you’re going to need, it’s really important to plan that out and think about it and make sure that’s part of your IA.

SO:                   Right. We talk about DITA information architecture, and of course, whatever it is that we do in coding, the DITA files is going to feed into the information architecture on the delivery side, whether that’s website or print or app or it could be any number of other things.

GK:                   Absolutely. So I want to talk about some situations where you might need to deal with both a DITA information architecture alongside other types of information architectures. I think we kind of touched on at the beginning that you might actually have IA coming from different approaches and you have to have that conversation to make sure everybody is on the same page. So one scenario that I can think of right top off my head that lots of our clients have dealt with is just when you have different departments that are in different content workflows but they need some way to connect their content.

GK:                   And maybe they’re not necessarily all going to work in the same information architecture, they’re not all going to be in DITA, but each department still has their own IA for their content and they need a way to make it play nicely together, and there can definitely be some challenges and things to figure out when that’s the case.

SO:                   Yeah. DITA versus DITA is one thing, and that can be a challenge. But perhaps that’s actually the biggest challenge, because you also see a DITA versus not DITA content. So there’s a merger and the company has five departments and eight different authoring tools, and you think I’m exaggerating, but I’m not, right? So you have all these different groups, they have all these different authoring tools, they’re delivering to all these different places, and at some point you have to step back and say, “Well, wait a minute. What about the poor customers that are looking at all this stuff together? How are they going to access this information successfully and what do we need to do to make it consistent such that they can actually have some sort of a fighting chance of finding what they’re looking for?”

GK:                   Yeah, absolutely. And when that sort of thing happens, when you’ve got something like a merger, or even whether it’s a true merger of companies or just sort of a merger of departments within a company, you’re looking at maybe DITA in one place and then maybe things like Word, FrameMaker, InDesign, all manner of other things and other places. And it’s really important especially when you can’t necessarily get rid of one of those sort of non-XML flavors of content production, where you actually need something like InDesign for example, it’s important to think about the implied structure of that content and the enforced structure of your DITA content and how to make sure that when all of that content is packaged up and published for delivery, that it all works nicely together.

GK:                   Again, back to what I mentioned earlier about taxonomy and searchability, making sure that everything is organized in some way that the customers are not going to get confused, they’re not going to start complaining to support that they can’t find what they need. It’s really important to think about, “Okay, if this content is developed in different work streams and different ways but it still needs to be coordinated and shared, how do we make sure that those different information architectures work well together?”

SO:                   Yeah. Then there’s a similar but different use case, right? Which is the, we have all this DITA content, which typically is going to be some sort of technical documentation, technical product content, that kind of thing, that forms a corner of the website. So you have what most of our customers call the dot-com. It’s company.com. It’s the main website with all the marketing information. And somewhere on that website, there is a button or a link or something that says documentation or support or additional information or technical literature, literature library. I’ve seen all these kinds of names.

SO:                   And the information that lives in that technical documentation corner of the dot-com is coming out of DITA with its own information architecture, but then the overall website has a, I guess, big picture IA. So one of our pretty common jobs is to try and bring those two things together so that we can feed the DITA based technical information into this corner of the dot-com and make sure that the people accessing it, accessing the website in general, get consistent information, they get consistent user experience, customer experience, on the information that they’re trying to access even though the website was built by one team, probably, and the tech docs were built by a completely different team using a different technology stack, different systems, different everything, but it’s still possible to make them consistent.

GK:                   Absolutely. One area that I’m starting to see more and more is the idea of delivering content through dynamic delivery portals. So that’s another layer that you have to think about. Some of the companies I’ve worked with that are doing this have to think about information architecture on both the backend, so how are they actually structuring the content itself? And then also the front-end, how is that getting delivered through a dynamic portal? How does it have to be tagged and structured to work with the way that the portal actually gathers the content up and delivers it to the customer?

GK:                   Then if you’ve got a portal for a portion of your content, so like you were saying, Sarah, if it’s for documentation or for online help or training or something like that and it sits in a corner of the website, then you have to think about how does that fit in with everything else and are there other departments that are also serving up their content dynamically as well? How can you make that play nicely together? So it really is a lot to think about and to plan.

GK:                   I think one thing I’ve seen that’s helped a lot is just having dedicated content resources or content team that sits above all these different departments and looks at how the pieces of the puzzle come together and can say, okay, “This group over here has one information architecture, this group has another. Here are maybe some tweaks or changes that have to be made to make sure that’s going to work with how you’re publishing your content through a portal onto the website.”

SO:                   Yeah. I think that’s a really good point. And your distinction between back end and front end, I think, can be very helpful to talk about backend information architecture. How are you encoding the DITA files? How are you encoding the source files, whatever those may be? And then the front end IA, which is essentially how are you presenting them? How do your end users experience this information? Now, what’s interesting is that you probably want to have some consistency between those two things. I mean, it can be a little challenging if you have a back end information architecture that in no way represents what you’re trying to do on the front-end.

SO:                   That’s probably not going to end so well. But when you start looking at this from a development and a skillset point of view, I think it is actually very helpful to think about, “Okay, we’ve got to do some back end encoding for DITA and we’ve got to do some front end encoding for user experience and we need to make sure that those two things are in fact compatible.”

GK:                   Absolutely. I want to, for the rest of this discussion, focus on that back end specifically and what happens when you’ve got some scenarios where you are sort of merging or bringing different types of content together. One instance that I’ve seen is when you’ve got to take content from other sources into a DITA based single-source of truth. This is something that we’ve seen a lot where you may have a lot of Legacy content, you may have content in different types of documents. So you may have a lot of Word files, you may have a lot of FrameMaker files, things that are not working together well when it comes to getting your content all searchable and in one place and reusable.

GK:                   In those cases, people sometimes make the decision, “Let’s bring it all into DITA and really get that maximized reuse that we don’t have right now.” So one big challenge I’ve seen is how do you make that decision of how you’re going to take the content from those other sources and make them work with whatever DITA information architecture you’re going to have. I think this hits a lot into the process of conversion and making those decisions. What content are you going to keep from your Legacy content? What content are you going to throw out? Then of course once you’ve decided what’s your important content that you have to deliver, then you look at that implied structure that I mentioned previously, that any content even if it’s in something like Word, FrameMaker, InDesign, even if it doesn’t have an enforced tag-based structure, it’s still going to have an implied structure hopefully.

GK:                   Hopefully it’s not just no style guide and complete chaos all over the place. But typically it does have some sort of an implied structure. You see patterns in the types of headings that you have, the types of content that you’ve got. You may have lots of reference information like you were saying earlier, Sarah, or you may have a lot of task-based information. So looking at that implied structure and seeing how it fits into the information architecture structures that DITA offers by default is a good starting point, and that helps you make those determinations that we were talking about upfront of, do you need specialization? How are you going to organize your metadata? All of those kinds of questions. That’s sort of the starting point, is what’s that implied structure and how does that kind of carry over into an enforced structure?

SO:                   Yeah, I think that’s right. In addition, if you think back to the wonderful days of printer technology, there’s this concept of the gamut when you print, which is the range of colors that you can produce on a given printing press with a given set of inks, right? And there are certain colors that you simply cannot produce. So for example, if you want something to look metallic, you usually have to put in a special metallic ink to make that happen. You can’t get metallic out of the traditional four-color CMYK; cyan, magenta, yellow, and black. So the gamut is helpful to think about because… I mean, you mentioned FrameMaker.

SO:                   There’s specific things that you can do in FrameMaker where you can get a little creative with the stuff that you’re putting in your files that is really, really difficult to reproduce in another tool or another content model such as DITA, and vice versa. There’s things you can do in DITA that aren’t necessarily supported in your Legacy tools. So you run into this gamut issue where because you’ve never thought about doing a thing because you couldn’t, because it was impossible in your current tool set, you have to really think carefully about, do I want to implement that now as I move forward into the new tool set? Does it add value? And as you said, this is relatively easier if you’re starting from, “I have all this unstructured content in Word and I want to move it to structure.”

SO:                   That is actually relatively easier because you have a wide open sort of blue sky make some decisions situation. It gets really, really interesting if you have a, let’s say an existing DITA set of content, and now let’s say that your organization buys another company and they have Microsoft Word files and you’re going to move the Word files into DITA. Well, now you have a structure. Like, you’ve made some decisions about your content model, do you extend your structure to support what the other company did? Do you say, “Nope, you have to jam your content into the content model we created because we feel like that’s the best approach.” That starts to get really, really squeaky from a technical point of view and it’s also very political, right?

SO:                   Because you just acquired this company and they may or may not be happy about the acquisition and they may or may not be happy about reporting to you because you’re now leading this project, and so you might make some compromises that aren’t the best technical solution but that will keep the peace in these new organizations that you’re bringing together.

GK:                   Yeah, absolutely. I’ve definitely seen examples of that happen where I think a lot of the judgment calls that were made were not so much about what’s the value of the content and what’s worth keeping and what’s worth putting into a different structure and what structure are we going to use? It was more made based on those kinds of political decisions and keeping things running smoothly. And then what ends up happening down the road once you kind of get over that hurdle of a merger happening and things do settle out, then sometimes you might have an opportunity to look at things and go, “Okay, our content processes are still not as aligned as they should be and we need to start thinking about ways that we can make that happen.”

GK:                   And maybe then down the road you can start making decisions that are a little bit more logical and a little bit more based in the content itself. But yeah, when you first start to make that choice and you’ve got a situation where there’s an existing DITA structure and then there’s unstructured content coming in, that’s definitely a place where there can be a big clash over change resistance and coming into a new process that you’re unfamiliar with. So it’s really important to think about the balance of those things.

SO:                   Yeah. And I think that a lot of times, for me or for us, we’re so deep in the technology that we like to hide in the technology and look at that and say, “Well, this is just a pure technical decision.” But nothing is ever purely technical, there are always politics there and there are always considerations of, how is this going to affect the people that are working on the content if we choose a content model that looks like this and then the conversion is going to be super difficult because we chose this really complicated content model? Well, who takes on that pain and that expense of doing the conversion? Are we inflicting that on the newly arrived merged company employees? Because that will almost certainly make them cranky.

SO:                   So there are those kinds of considerations which are really interesting to me that go above and beyond the hard enough already question of, what’s the best information architecture for this content from a markup point of view?

GK:                   Definitely. So do you have any other final thoughts, final advice for how to make an information architecture development process go as smoothly as possible especially in a situation where you might be combining DITA and non-DITA content?

SO:                   Oh, sure. Yeah. I mean, is that all? I would say that, define your terms, make sure that when you talk about information architecture everybody is talking about the same thing, or you agree that, “For this meeting, we’re talking about this kind of IA,” that sort of thing. But, define your terms, and I think it’s useful and important to get the entire team up to speed on what that entire IA piece looks like from DITA markup into storage, into rendering and delivery, and whatever else might be happening downstream so that we’re not all just looking at it through our own little lens or our own little peep hole and only focused on our piece of it. If you’re a backend IA person, the better your understanding of the front-end IA, the easier it’s going to be or the better your results will be when you bring those into alignment.

GK:                   Yeah. And I think just to add to that, my advice would be that you can never do enough planning, and so… especially if you do not have major deadline pressure, which I know that’s not the case for most of us. But if you’ve got time to plan, take advantage of it and definitely do as much of that planning that you can even in and around your other deadlines and your other work before you ever start actually encoding and that will save a lot of trouble and a lot of headaches down the road.

SO:                   Yeah. That’s excellent advice, and I’m afraid hard-earned.

GK:                   I think at this point we’ll go ahead and wrap things up. So thank you so much, Sarah.

SO:                   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 Information architecture in DITA XML (podcast) appeared first on Scriptorium.

In episode 79 of The Content Strategy Experts podcast, Gretyl Kinsey and Bill Swallow continue their discussion and talk about solutions to quick fixes.

“A big part of your content strategy should be how requests come in, how the timelines are built, and what you’re responding to and how you’re responding to them in the first place.”

—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’ll be continuing our discussion on quick fixes, this time focusing on solutions. How can you undo quick fixes or better yet avoid them in the first place? This is part two of a two-part podcast. Hello and welcome everyone. I’m Gretyl Kinsey.

Bill Swallow:     Hi, and I’m Bill Swallow.

GK:     And today we’re going to be revisiting our previous discussion on quick fixes, but this time with a bit more of a positive spin. Just to recap a little bit from last time, what we mean when we talk about quick fixes are when you take a one off or bandaid approach to your content strategy, you do some sort of a work around to get content out the door, usually on a tight deadline or under a constrained budget, and then that later can cascade into lots of problems down the road if you have done a quick fix instead of planning and doing things the right way. And where I want to start things off today, talking about how you can undo or avoid quick fixes, if your company decided to use a quick fix in the past, what are some reasons that you might need to change that now?

BS:     Well, I think one of the first things that you should be looking at is the amount of time your team is spending on overall tasks and to see exactly how much time is being spent fighting with, or otherwise futsing with their content development tools. Are they going in and constantly having to reformat things? Are they constantly having to retag things? Are they fighting with the tool to get it to work the way they need it to? And looking at these types of things to figure out, do I have a problem with quick fixes? Did we implement things correctly? Are we using the tool the way we should be using the tool, and is the tool right in the first place?

GK:     Yeah, absolutely. And I think this kind of touches on the flip side of the scenario that we talked about in the previous episode, where we mentioned things like template abuse and tag abuse, and people going outside those parameters that you have defined in your structure or in your template and doing these one off quick fixes for formatting. So if you realize that you’re spending a whole lot of time on those kinds of things, then suddenly that’s not really a quick fix. That’s a very time consuming fix when you put all of those little individual quick fixes together. So if you realize that you’ve got a lot of writers doing that, then that can lead to something like a limitation down the road. If you realize, for example, “Hey, we really need to streamline templates that we have, or we need to introduce a new template or a new publishing output that is a lot more sleek and efficient than what we’ve already got,” and you’ve got writers all over the place breaking the existing templates, then suddenly they’re imposing a limitation unnecessarily on the tools that you have.

BS:     Yep. And we’ve been hearing a lot over the past several years about companies going through digital transformations and being able to essentially modernize their entire content set. And I want to say just putting it online because that’s not what digital transformation is all about. Yes, it’s a component. But one of the things that a lot of these companies are struggling with is that they’re looking to move to a more digital foothold on their content and where they need their content to go. And they’re taking a look at their entire legacy content set, and they’re finding out that they have millions of different Word files that are all using different formatting, different templates, if they’re using templates at all, several different content tools in play. They might have Word. They might have FrameMaker. They might have InDesign for some more higher designed outputs that they were producing.

BS:     They might have both RoboHelp and Flare in the mix because there were two different divisions of the company at the time and each one decided on their own tools to use, and they have different styles and templates and even different approaches to how they develop the content in the first place. So you start seeing all of these things where you have all of these different documents using a wide variety of conventions, and suddenly you need to be able to standardize this stuff so that you can start doing more intelligent things with your content and it makes it incredibly difficult to take that leap if everything’s a mess at the starting gate.

GK:     Yeah, of course. Absolutely. And that is a massive problem I think that I’ve seen in probably the majority of the projects I’ve worked on here at Scriptorium that… Especially when it’s factors outside of maybe the company’s overall control, if there has been something like a merger in the past, and you’ve had lots of disparate teams that suddenly are working together and they’ve all had their processes, then suddenly any of those teams who have employed a quick fix solution, that’s going to be multiplied when you’ve got all these different teams and all of their past histories of quick fixes working together. That’s when it becomes really important to look at what all these different teams are doing and streamline their processes and come up with a content strategy that brings everything together as it should be.

GK:     And I think that gets into the issue, not only of streamlining, but of scalability as well, if you need to scale your processes to a larger target audience, a larger market, or as you mentioned earlier, Bill, if you need to undergo a digital transformation and you need to deliver more intelligent content, content that is not only available online, but that is interactive or that’s personalized, then if you are hindered by all of these one off quick fixes that people have taken, it can be almost impossible to scale. And that’s when you’re looking at maybe a complete content overhaul at that point.

BS:     Yeah, and I do remember one client a while ago who decided that after looking at all the numbers and taking into account all the different documents they had in play, they needed to go ahead and rebrand, they renamed their company and had new logo, new look, new feel to all their content. They did a lot of upfront analysis and came to the conclusion that it would be a lot easier to just fix it all, to basically press the pause button, fix it all, move it to… In this case, they moved to DITA, but move it to a single content format and then apply all of their branding changes using automated formatting. It was a lot cheaper and a lot less time to do that than it would have been to go into every single document and update it by hand. And that speaks volumes.

GK:      And I’ve seen a few clients take a similar, but maybe not quite as quick approach where if they couldn’t press the pause button on everything, they at least did that one department at a time. So start in one place with DITA and then pull the next department in when they were ready and then so on and so forth. So kind of depending on the size of your company, your budget, your deadlines for different products and different content that comes from different departments, then that approach in phases or with a small starting point that expands outward might be a good idea to make it manageable as well. But it really all depends on how interconnected things are when you start, how interconnected they need to be by the end, and how that all interacts with your product release schedule.

BS:     And another consideration there is also if you happen to be merging teams or bringing on new teams, or if your team is growing, you’re bringing on new hires, it is very difficult for someone to figure out not only a new job or a new role, but also to figure out how to produce things when everything is formatted differently, when everything uses a different convention, when you have to know all these little details about how a particular deliverable comes together, because nothing is consistent in everything is done ad hoc. It becomes very difficult to get new people up and running in that environment.

GK:     Yeah. And that gets into some of the things we talked about on the previous episode with training and how I think that one of the things that we talked about is that a lack of training or a lack of documented knowledge can lead to this problem of these one off quick fixes just growing and growing. And then that perpetuates itself into this problem that any time a new hire comes on, it is very difficult to keep them trained if it was a lack of training that led to people making these mistakes before. So that’s where it becomes really imperative when you bring on new teams, whether it’s from a merger or whether it’s just expanding and hiring that you get all of your content systems streamlined and aligned across the organization and provide adequate training and ongoing training to prevent those ad hoc solutions that people were using before.

BS:     That’s great, and brings up another question here, which is types of approaches that you might take to start getting these quick fixes out of the way and start streamlining things.

GK:     Yeah, absolutely. One thing that you can do is just revisit your original content strategy if you had one, which hopefully you did. If you didn’t, then it’s time to start one. But if you had some content strategy and things maybe went off the rails, maybe there was some sort of major deadline pressure that prevented you from putting the solution in place that you really needed to, and you used a quick fix instead. Then once you get over that deadline, a question you can ask yourself is, “Okay, well now that we’re six months out or a year out from when we originally started planning and things went a different direction, which of our goals from back then are still relevant now, and how are these quick fix bandaid approaches that we took to get through this deadline impeding those original goals that we had?” And that can start to give you a path out of the weeds that you got yourself into.

BS:     Yeah, you definitely want to catch yourself before you start running too far in one direction and constantly look back and realign yourself with the goals of not only your content, but are they meeting business goals as well? Was this one off thing that you, or this screaming deadline that you were responding to, does it feed into those goals? And if it does, take a step back and see, “Okay, we had to do all of these quick fixes to get it out the door. Why did we have to make these changes? Were the decisions that we made when we started on this strategy sound and do we need to revisit those as well?”

GK:     Yeah, absolutely. Another thing that you can do is look at the situation that you’re in now and do some evaluation and come up with an estimate for the effort it’s going to take to get out of the situation that you’re in with these quick fixes. So you’ll ask yourself questions like, “How much editing is it going to involve? Are we going to have to go in and make changes to a whole lot of documents? Are we going to need to do maybe an automated process to refactor them if it’s too much to do manually? Are there solutions that can make that process a little bit more efficient and more streamlined?” Because that’s the danger of going that quick fix route is a lot of times those fixes are introduced through manual processes. It’s through a single person making a one off judgment call here and there, and then those all add up.

GK:     So it’s really important to look at what people have done and where that’s left your content now, and then how big of a mess is it to clean up. And that can help you make some of the decisions that you need to make in terms of, do we need to focus more on some a programmatic solution and getting an expert involved who can write a cleanup script to help with a lot of this, or is it going to be more worth our time and money to invest in actual human resources to clean this up? People who are going to go in and clean up every document. So that’s another thing that you can ask yourself to make sure that you get out of that mess as effectively as possible.

BS:     And it’s also a good opportunity to take time to reassess just how widespread these quick fixes have become and how necessary a lot of the documents are to fix going forward. So if you have a case where you’ve been copying and pasting information all over the place, how many of these deliverables use the same content in a different way? And do you need to fix all of them? Let’s say you’re migrating to a different tool set. Do you need to migrate every single one of them? Or can you migrate one or a small handful of them and rebuild a lot of the other deliverables that stem from that content automatically.

GK:     Another thing that is really important to do while you’re evaluating the mess that you might’ve made with your content with these quick fixes is also look at what it’s going to take to get you into the solution or solutions that you should be using. So that might be things like new content development tools. It might just be improved processes with your existing tools. It might be some combination. And it’s important to look at that aspect and then everything that goes with it. So for example, what kind of training is going to be involved to make sure that you keep up those new processes and you don’t fall into the same traps that you fell into before with the quick fixes? There’s going to be a change management aspect to that as well, which I think goes hand in hand with training. Looking at why did people go to these quick fixes? What was it about that temptation or what was it about the necessity that may have led them down that path? And how do we put some kind of checks and balances in place and content governance in place to make sure that we don’t do that again?

BS:     So after all this evaluation and all this investigation, the next thing you want to do is plan, plan, plan, and make sure you get things nailed down that are causing the problems that lead to quick fixes, not just resolving the quick fixes themselves. A big part of your content strategy should be how requests come in, how the timelines are built, and what you’re responding to and how you’re responding to them in the first place. If a lot of your quick fixes are a result of someone in the organization coming to you with a screaming need, then that is something that needs to be addressed by your content strategy, even if the strategy basically is to get management involved and coming to some agreement on how those requests for content come in. The more you get your arms around how requests for content come in and how the content flows out, the better control you’re going to have over the content creation process itself.

GK:     Yeah, absolutely. And I think this is an interesting thing to me because a lot of the content strategies that we end up doing are the result of these quick fixes, and we get brought in to solve whatever those problems were that led to those quick fixes in the first place. So the silver lining to having done these quick fixes and gotten into a mess is that it really helps you see where you went wrong and where you need to go right when you’re going forward. You get a little bit of a template or a roadmap for avoiding those mistakes once you have made them. So it’s really important to take advantage of that and not to make those mistakes again.

BS:     Right. If you have the ability to collect any metrics on exactly how much time is spent dealing with quick fixes in your content workflows, that will go a long way also to helping you formulate a solution that will stick, because then you can get firm numbers to present to management to be able to enact some real change.

GK:     Yeah, exactly. We talked before in the previous episode about how much these quick fixes can really rack up costs over time. And if you collect the information and have the numbers to actually prove that that’s what’s happening, then there’s a much greater chance that somebody higher up in management or at the C level will realize that it’s a problem and do what needs to be done to stop it.

BS:     Right. I mean, if a lot of your time is spent essentially on churning rather than actually producing, then that is a productivity problem, and you can believe me that managers are very keen on identifying and solving productivity problems. And you want to make sure that those problems are solved the correct way, which is mitigating the need for these one off documents, mitigating the need for these last minute requests and being able to then focus on creating your content in a more structured way, whether you’re using structured authoring or not. So being able to use templates correctly, being able to use a proper workflow from content creation to review to publishing and so forth, and be able to use the tools the way you ideally need to use them.

GK:     Absolutely. So if you’re just starting out with a new content system or new content process, and you have not yet had the chance to fall into this pattern of using quick fixes, how do you avoid that?

BS:     Well, first I would take into account everything that was said before. And make sure that you have things documented, make sure the pain points are documented, make sure that even things that you aren’t currently doing incorrectly, make sure that you identify what not to do in a content plan as well. All of this information really does need to be funneled up to the managers or executives who are essentially owning this entire content development process.

GK:     Yeah, absolutely. And it’s really important to help people at that level who are not creating content and are not in the weeds of it, but they are the ones controlling your budget. They need to understand just how many problems these quick fixes can cause. How much cost it incurs over time, how many messes it creates that have to be cleaned up later. And they need to know that information so that they can weigh it against things your deadlines and your schedules because it’s all too tempting, I think, even for people at that management or executive level, since they aren’t the content creators, they can be easily swayed into saying, “Yeah, go ahead and do whatever needs to be done to get it out the door.”

GK:     But if you’ve made them understand that taking that approach is going to get you into a mess later, then they might be more likely to say, “No, let’s actually make sure we do this the right way, and if that means that I need to shift somebody’s responsibilities for a little while, so that you’ve got more resources for your content for this deadline, or that means if I need to bring in someone to help with training and get you up to speed to do things the right way, then that’s going to be worth putting those things in place.” So it’s just really important to make sure that the people who are in charge of the budget truly understand how it’s being spent so that they can help everybody else avoid those quick fix approaches.

BS:     Yep. And if they’re in charge of the budget, chances are they’re also in charge of a lot of the workflow within the higher level of the organization. So it might be that a lot of these screaming needs that come in at the last minute that are creating some of these ad hoc practices in your content development process, it might be that a lot of these deliverables were known high up at a very early stage, but for whatever reason, the information did not get down to the content development teams until someone from either sales or from tech support or someone else came running down saying, “Hey, we need this thing tomorrow. Can you stop what you’re doing and work on it? This is a high priority item.” So it’s to your advantage to make sure that you have management informed of not only where the quick fixes are happening and the problems that they’re causing, but also to discuss a lot of the workflow around them to clear the… Essentially be a linebacker and clear the path for you so you can hit the goal when you need to hit it.

GK:     Yeah, absolutely. Another thing that you can do to avoid these quick fixes, and we’ve touched on this a lot in this episode and the previous one, but provide adequate training. Don’t let your writers, your reviewers, anybody involved in content development to get behind, because that ends up breeding resentment. And if you are introducing some sort of very different and very new content development process to your team, there is going to be a learning curve and there’s definitely a chance that people will be resistant to that learning curve, that they will say, “Why does my working life suddenly have to change so much and have to be so stressful?”

GK:     So support them through that learning curve. Make sure that they have the resources they need. That they don’t just have a one and done training session, but that they’ve got somebody they can continue to ask questions to whether it’s a consultant, whether it’s a dedicated resource in your organization, whether it is someone that works for the software vendor that makes your content tools. They need to have that open channel of communication where they can say, “I’ve been trained on this, but maybe I still don’t quite understand this one aspect or I’ve been through initial training but I think I need a little bit more robust training on this particular aspect of what I’m doing.” And make sure that they don’t fall through the cracks because that’s what’s going to lead them to say, “I don’t know how to do this, but I have to do this thing to get the document out the door, so I’m just going to use a quick fix.”

BS:     Yep. And it’s really important to make sure that this training is also targeted toward the type of work they’ll be doing and uses content that they’ll be developing. A lot of times we see teams that say, “Oh yeah, we were trained on using this particular tool.” And it turns out they’ve just gone through generic tool training. And as we all know, you can use, for example, Microsoft Word to produce anything. You can use it to produce a letter to a full blown manual and everything in between. It doesn’t necessarily help you if you’re only providing tool level training. You have to be able to provide contextual content related training. So something that is tailored to the exact type of content that they’re going to be developing, perhaps even using their existing content in the training class so that they know exactly how they should be writing and when and where things should be applied a certain way. Which styles do you use in which instances? How do you structure a document? Which tags do you use in which cases? How does the publishing workflow work? Why don’t we select this one particular button or select this one particular option when we’re going to print something out or to convert it to HTML? It’s really important to have that targeted training, so it’s not just about the tool, but it’s actually relevant to the work they’ll be doing.

GK:     Yeah, absolutely. And I think it’s important too, along that same road, to think about are there going to eventually be content features or aspects of content development that you won’t use until later? So it’s important to think about training at different points in the content development journey that your writers are going through. So one example I can think of is that one of the clients I worked with did basic authorizing training when they first made their move to DITA, and they had not introduced any reusable content yet. They were still doing a lot of writing. They had not fully written out their documentation, but then as they went along and as they wrote that documentation, they had more and more content that they needed to reuse.

GK:     So they realized they needed additional training on DITA reuse mechanisms a couple of years down the road. We had gone through basics of things like what is a conref, what is a key, how do you set up reuse? But it’s a very different ball game to go through that generically and just touch on the highlights of it at an early stage where there’s no context for it, then it is to talk about down the road, “Okay, we have these pieces of content that we need to reuse in this way. How do we do it?” And that’s why it’s really important that you make your training ongoing and open to addressing new needs that pop up.

BS:     And that right there really speaks to how you roll out a content strategy or how you approach developing content with a content strategy in place. You want to have things staged, because you don’t want to try doing everything at once out of the gate because you’re going to get things wrong. You’re going to implement things incorrectly. You’re going to discover that what sounded like a good idea at the time doesn’t really work well. So you’re going to have to refactor a lot as you’re going along, and it really helps to have things buttoned up and streamlined so you can make these shifts as you hit these different milestones in your content strategy implementation, to be able to say, “Okay, we tried X, Y, and Z. X and Y worked great. Z was a catastrophic failure. We can’t allow that to happen again. Let’s stop, reassess, and let’s change things.”

BS:     And if your documents and your workflows are void of any ad hoc bandaid approaches, then it’s a lot easier to make that shift. If the content needs to be refactored, chances are you can probably do it programmatically at that point. If it turns out a particular tool isn’t working well, then it’s probably going to be a lot easier to up and move your content to a different tool or to implement a new tool in the tool chain that you have for publishing if everything is done consistently up to that tool’s point. The more you can get your arms around all of the pieces that go into your content creation and address each piece systematically in the process of implementing your content strategy, the easier it’s going to be to make these pivot points when you need to, when you find that a piece of the strategy just isn’t working.

GK:     Yeah, absolutely. And that’s why I think it’s really important when you are developing that strategy to, as you said, pace it out, have it in phases, have it in stages and think about your short term versus your long term goals and realize that those long term goals might change over time, and almost certainly will change over time. I mean, you may have your overarching business goal stay the same, which is bring in more revenue, deliver content more quickly, and better quality content to your customers, but the way you actually achieve that will almost certainly shift over time. And that’s because a lot of times there are unexpected things that happen. Emergencies, challenges, things that come up that you were not planning for, so that’s why building in that flexibility into your strategy, saying here’s what we want to do in the short term, here’s what we want to do in the long term, the road to get there. We’ll probably take these steps, but it needs to be flexible, because you don’t know what kinds of things might come in and disrupt all of the plans that you had.

BS:     And let’s be honest, you’re going to have a need that is going to go outside of your established process. It’s almost a given that something’s going to come in, it’s going to be a high priority need in a very short period of time and you’re just going to need to get it done. At that point, you need to pivot. Don’t abandon your strategy, but take that one piece out and plan to take it out of that stage and have a plan to put it back into whatever content workflow you have in place. So don’t just introduce ad hoc formatting and just assume that it’s going to be a one off need, but actually plan for it to be an ad hoc process to get something out the door, and then there is a plan for bringing it into the fold. Whether it’s six months out out from delivery, whether it’s two years out from delivery, or whether it’s tomorrow, depending on how big of a need this is. But have that plan to essentially take a detour around the strategy while all the other content continues to follow the correct workflow.

GK:     Yeah, absolutely. And I think, to tie everything together, we we’ve made this point with all of our other ones, but it’s really important to plan for those unexpected things, but also still keep all of your goals and your content life cycle in mind as you execute the strategy step by step. And that’s again, why it’s so important to take this well paced or well phased approach, start maybe really small, maybe start with a proof of concept, a pilot project, something that’s low stakes to prove that what you are planning to do actually works and then expand outward from there. That’s going to help you build in a lot more room for things to change and a lot more adaptability to those changes when they come up, if you keep things well paced, instead of trying to do a whole bunch of things at once.

GK:     And I think that, that aspect of biting off more than you can chew and trying to just go all the way into a new strategy with all of your content all at once can actually lead to more of those quick fixes because you may get in the middle of transferring all of your content over from one system to another, or trying to scale way too quickly and realizing that you can’t do it on the deadlines that you have set and then just falling right back into that trap of quick fixes. So I think keeping that entire cycle of your content mind and keeping that entire path of your strategy in mind, and really pacing it well, taking each step at a time is a good way to not only avoid needing a quick fix, but if something unexpected does come up and you do have to have a quick fix, it does make it easier to address that and not let it get out of hand and bring it back into the fold of your content strategy without too many interruptions.

BS:     Yep. Slow and steady wins the race.

GK:     Absolutely. Well, I think we’re going to go ahead and wrap things up here, 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 The true cost of quick fixes (podcast, part 2) appeared first on Scriptorium.

In episode 78 of The Content Strategy Experts podcast, Gretyl Kinsey and Bill Swallow talk about the true cost of quick fixes in your content strategy.

“Even if a quick fix might save you some time or a little bit of upfront cost or upfront effort on planning, it’s almost always going to add costs in the long run.”

—Gretyl Kinsey

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’ll be talking about the true cost of quick fixes and common issues that might lead an organization to taking this kind of bandaid approach to content strategy. This is part one of a two-part podcast.

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

Bill Swallow:     Hi, I’m Bill Swallow.

GK:     And we’re going to be talking about quick fixes in your content strategy today, and how that can lead to all kinds of issues down the road. So I think the place to start is just talking about what we mean by quick fixes.

BS:     And that can be pretty much anything that doesn’t fit the greater plan. Doing things that kind of make things fit or responding to an immediate need with an ad-hoc approach to getting something done.

GK:     Yeah, absolutely. And I think we’ve both seen plenty of examples of this happen. Even if you’ve gotten a really solid plan together for your content strategy, there are oftentimes things that just pop up that do go outside of that plan. And so then it’s often really tempting to sort of apply this quick fix to get you through it. So what are some examples that you’ve seen of these kinds of quick fixes?

BS:     One that jumps right out is formatting abuse. So whether you’re working in structured content or not, ignoring any styles or any elements or whatever you’re using, and just kind of using whatever feels right to you in order to make things look or behave a certain way rather than following what the styles should be.

GK:     Right. And I’ve seen this, like you said, both in structured and unstructured content. And so from the structured side of things, that’s usually going to be a situation where you’ve got some sort of separation between your content itself and your formatting. But if you are used to working where you’ve got that control over the formatting, and then you suddenly don’t have that anymore when you go to structure, I’ve seen people do this tag abuse thing where they will use a tag in a way that is technically legal within the structure, but it is trying to control formatting. And then that can have all kinds of unintended consequences across your actual transformation processes that produce your output. But that’s just a very common thing that people will say, “Oh, I need a page break here, or I need a table to look like this here.” And they do something that’s just a tag abuse thing to get it out the door.

GK:     And from the unstructured point of view too, I’ve seen people do what I would call template abuse. And so that would be things like, for example, in InDesign, instead of all of the predetermined styles, maybe applying one but then making a little tweak to it, like making the text italic or something, or making it a slightly different size, or not connecting text frames together when they should be connected together just because you’re trying to get something to lay out and look right on a page, but you’re actually making the whole document break. And same thing in FrameMaker as well, similar to what you might do in an InDesign template. If you’re an unstructured FrameMaker, I’ve seen people do that same thing where they’re ignoring the formatting that was built into that template and overriding it with lots of little formatting tweaks here and there just to get one page perfect. But then later, if somebody makes an update and it blows away all of these little formatting tweaks, then that person would have to go back and make them again. And so that’s when a quick fix doesn’t become so quick.

BS:     Oh yeah. And there’s nothing quite like opening up a Word document and seeing everything being tagged with normal asterisk. Especially when you’re trying to do a quick rebranding job and you realize that your four page document is going to take you about eight hours to change. Especially if you’re changing fonts and sizes, colors, that type of thing. Once you start introducing a lot of these ad-hoc quick fixes, the more work you’re creating for yourself down the road.

GK:     Yeah, absolutely. Another thing that this is kind of more specific to structured content, and I think particularly to DITA, is something that we at Scriptorium call spaghetti reuse. And that is basically when instead of coming up with a reuse plan and putting all of your reusable content into warehouse topics and putting them all in one place where people know where to get them, instead what people will do is maybe conref in a piece of information ad-hoc from another topic. And then you suddenly get this tangled web of reuse that’s impossible to track. And that’s done as a quick fix because if you know that you should be reusing content, but you haven’t made a plan for it, and suddenly you need to get this content out, that might be a tempting thing to do, but then it’s, just like with the tag and template abuse, it’s just going to create a lot more problems later when somebody comes in and needs to fix it.

BS:     Oh yeah. If you’re working, especially creating new maps for new deliverables and you’re bringing topics in to build your map out and to build your document or your help system or whatever you’re producing out of DITA, once you start pulling those maps in, you’re going to find that you have all of these missing links all throughout your content to other topics that you didn’t want to include in your map file. And now you’re stuck either having to stop what you’re doing and create these warehouse topics so that you can do it correctly, or what I’ve also seen is that people just grab the topic that they need, dump it in the map and set it to resource only, just so they can resolve that conflict in a hurry. And that creates another issue down the road with more spaghetti reuse.

GK:     Absolutely. So that again, points to this idea that it’s always better to go ahead and build in that time up front to make that plan, instead of just going the quick fix route, because it’s not quick later when you have to go back and clean up the mess you’ve made. Something else that can also cause a problem like this, and this is more for if you’re working in an unstructured environment, but heavy use of copy and paste, and then if you do get into structure and you do have reuse capability, but you are in the habit of heavy use and copy and paste, still going ahead and doing that can be a real problem. That’s even worse than the spaghetti reuse if you’re in a structured content environment, like DITA, but you’re still copying and pasting everywhere and you’re not making use of that reuse potential that you now have.

BS:     Yep. And copying and pasting really creates two really fundamental and horrible problems. One is if you need to update that content, god knows how many places you’re going to have to go looking to fix that content. Even though it’s exactly the same in all places, you’re going to have to make the fix in all places. Likewise, on a localization angle, you’re just throwing money out the window if you constantly have stuff copied and pasted all around, especially if people are then modifying what’s been copied and pasted because they don’t particularly like the wording in this certain instance or they forgot to update it in one place. Then you start getting all of these fuzzy matches going into your localization workflow, and you’re throwing money at a problem that shouldn’t be there in the first place.

GK:     Absolutely. Another example of a quick fix is having multiple variants of the same output type to satisfy immediate needs. So for example, if you are generating PDF output, let’s say, from a collection of DITA topic files, maybe you realize, “Oh, I need a PDF with this particular cover variant and I need another PDF over here with this one for different audiences.” There are ways in your PDF transform to build things in where there’s a switch based on your audience or based on the product that that content goes with or what have you. But instead, maybe you decide that the quicker fix is to just basically copy over that transform and make that one little adjustment when you could have just had it all working in one single transform. And we’ve definitely seen that come up as an issue as well, and the problem there is that you are just kind of creating this ballooning effect of your outputs. So instead of having one output transformation that can do a variety of things, you’ve got multiple transforms for all these different variants when you didn’t really need it.

BS:     Oh yeah. And the same goes for on the unstructured side, especially with an InDesign and FrameMaker and other applications that allow you to use … Well, I’m going to use a FrameMaker term, but to use master pages for your layout.

GK:     Yes.

BS:     A lot of times I’ve seen people create multiple templates just to satisfy either different page sizes or different cover pages, as you mentioned Gretyl, and they ended up having to apply these templates over and over again to their files just to generate new output when they could go in and just select a different master page and allow the document to reflow into whatever that new layout needs to be.

GK:     Yeah. And again, this is just one of those things where a little bit of planning upfront could have gone a long way and saved you all of that trouble, and all of that ballooning effect of having all these different ways to produce your output when you could have gone with something much more efficient. And if you realized that that’s a problem and you need to clean it up, it’s kind of like all of these other quick fix examples, that you’ve made a mess that could have been avoidable, and now someone has to put in the time and the effort to go back in and clean that up.

BS:     Well now that we talked about some of these quick fixes that are out there, what are some common issues that might lead a company to implement a quick fix rather than do it the right way?

GK:     So one of the most common, and I think most obvious issues that we run into, is just pressure from deadlines and release schedules and things like that. You’ve got a product that has to go out the door by a certain date, or you’ve got an update to your product that has to go out by a certain date, you’ve got content that has to go out with that product. If you are localizing, you’ve got those deadlines too. So that is a big source of why people cave to the pressure of these quick fixes. Because if you are looking at a limited window of time where you’ve got a choice between, “Do I do things the right way or do I do things in a way that works, maybe not ideally, but still gets my product out the door on time?” Then that’s the one they’re going to pick. So it’s a tough situation. And again, it gets back to this idea of planning more up front, but sometimes there are scenarios where you just don’t have the time to do that properly. And so what generally will happen is a company will say, “Okay, well, it’s going to be just strictly from a cost benefit analysis perspective, better to do what we have to do to get it out the door and then go back and fix it later when we’re not under that deadline pressure.”

BS:     And you always have that extra time after a project to go back and rework and do it the right way, right?

GK:     Oh yeah, of course. No you don’t. That’s one of the pitfalls of this is that you think, once we get over this one hurdle of this deadline, then we can go back and fix it, but there are usually other deadlines coming up, and even if you’ve got long cycles between your releases, if you’re not on that typical two week sprint schedule that a lot of companies have, you still may have something unexpected that pops up. You may have somebody in a different department say, “Hey, we’re going to introduce a new project over here. And guess what all that time you thought you had to fix your mistake, your quick fix, that’s all gone. And so, this is really a tough problem that there’s not always a great solution to, but I think if you’ve got the time to plan up front, that that’s really the best way to get around this, because once you kind of get in that quick fix mindset, it becomes a perpetuating cycle that’s very hard to break out of.

BS:     Yeah. And it snowballs to a point where once you do have to do something different with your content, whether it’s a rebranding effort, whether you’re switching tools, whether you’re doing whatever. If there’s something large scale that you need to change in your content, the more quick fixes that you have in there the tougher it’s going to be to work around them to get anything done on that larger effort.

GK:     Yeah. The tougher and the more expensive, because if you’re doing something like converting your content from one format to another, or rebranding or making some sort of large scale terminology update, anything like that that affects basically all of your content set, then the more consistent your content is, and the less full of these kinds of little quick fix tweaks that it has, then it’s going to be a lot more of a smooth process to convert it or change it, update it, whatever. If you are faced with deadline pressure and it’s absolutely imperative that you have to change the content or convert it or whatever, then you’re looking at a pretty big price tag because you’re not only making a lot of major updates and kind of getting all of those consequences of your quick fixes out of there. But you’re also having to do that under a tight deadline, which is probably what got you in the quick fix boat in the first place. So that’s something to keep in mind is that there is going to be … Doing anything on a quick deadline, that usually means there’s going to be a bigger cost for that turnaround.

BS:     Absolutely. And speaking of cost and cost comes down to two things, time and money. Either you don’t have the time personnel wise to get something done right the first time, or you just don’t have the funding to either go back and revisit, or you don’t have the funding to pick up, let’s say you’re doing something ad-hoc in a tool that is not really well designed for your needs, and you don’t have the funding to actually buy the tool that you do need that would satisfy all this rework that you’re doing constantly. It can be difficult to be able to either get that budget or be able to secure that time to do things in a more efficient manner.

GK:     Yeah, absolutely. So if you do have that limited funding or limited resources to really build out the ideal solution that you want, it makes it kind of hard to think about your planning. And I think this is an issue that I’ve seen with a few clients, or maybe more than a few, where one of the challenges they ran into was just a lack of longterm planning or the ability to do longterm planning.

GK:     Whenever we’ve come in to help companies develop a strategy. One of the things we do is to encourage them to not just focus on the present, but also the future and think about what are your goals for right now versus what are your goals for two, three, five, 10 years down the line? But if they are working with really limited budget, really limited resources and even kind of an unpredictability factor in how much budget they’re going to get from year to year, that can make it really difficult to ask and answer that question of where might you be five years down the road, and what are your ultimate business goals?

GK:     So I think it’s important to be flexible in that area and still plan for it as best you can so that you can avoid falling into this rabbit hole of making quick fixes and just having that become your only strategy. But it does kind of become understandable when you look at this problem of limited funding and limited resources, why so many companies end up taking that quick fix route.

BS:     Another area we can get a lot of quick fixes creeping in are if your writers aren’t properly trained to use the tools that they need to use to get the job done, or if they are not well trained in the types of publishing that need to happen from those tools.

GK:     Yeah, absolutely. And I think, in some cases, it’s not always just a lack of training, but it can sometimes be an active avoidance of a steep learning curve, and that’s where I think it’s really important. And we’ve talked about this in some of our other podcasts and blog posts, but it is so important to customize your training to what your writers and other content creators need to make sure that nobody is getting left behind, to make sure that people are not feeling resentful about the changes that are now in their kind of day-to-day working life, because that is a really big concern, and when you’ve got this whole different way of creating content, it can be very difficult to learn.

GK:     So if you want to avoid people coming up with quick fixes with work arounds, with some sort of way of doing things that they find easy but that isn’t necessarily correct, then it’s really important to make sure that they get not just a one size fits all training, but custom training, maybe ongoing training or support to make sure that they can do their jobs correctly.

BS:     And in addition to that, if you find that either after training or if there are enough writers that refuse to do it the right way for whatever reason, or that cannot do it the right way for whatever reason, you probably picked the wrong tools. In which case, then you’re going to have to go back. That also speaks to the longterm planning. You chose a tool based on its capabilities and not necessarily the wants or needs of your staff.

GK:     Yeah. And that’s something as well that I’ve seen, that even the tool selection itself can sometimes have a quick fix approach that gets you in trouble later, and that has a lot of consequences down the road. So that’s where it is really important, kind of like we talked about previously without that longterm planning, whatever limitations that you may have with budget resources, it is still really important to think about your future needs and to make sure that your tools and your strategy are going to truly serve your company’s business goals and make the actual work that your writers and content creators are doing more efficient.

GK:     And one other area that kind of ties into this idea of training and knowledge is that we’ve seen some people, specifically in DITA workflows, apply quick fixes just because they didn’t know about a DITA feature that would have let you avoid it. There is a lot of very particular weird twisty stuff out there in DITA that is kind of considered more advanced, and a lot of times if you just have that basic level of training in DITA, you wouldn’t know about it. And in particular, I think there are some of the reuse mechanisms that are available, that a lot of times people have come up with some sort of a workaround just because they didn’t know it existed. Things like conref push for instance, and in some cases, even just the use of keys or the use of conkeyrefs. People will come up with some sort of quick fix to solve a problem that there was already a DITA mechanism in place that would have just automatically solved it. And so again, that’s where getting into not just training, but looking at what kinds of things you need to do with your content, talking those through and making sure that you haven’t overlooked some aspect of DITA that could solve that problem can help you avoid those quick fixes.

BS:     Oh yeah. I’ve seen a lot of cases where people even use tables for formatting in DITA in a specific way, which gives it a completely non-semantic markup, whereas they probably would have wanted to use maybe a definition list or maybe they’d use a glossentry or something like that that gives it a little bit more meaning as to the context of what your content is rather than just slapping it in a table and removing all borders.

GK:     Yeah. And that’s kind of a holdover, I think, from folks who have been trained in more desktop publishing oriented content development processes. Then they get into DITA, and they don’t realize that there are all of these features of structure that would let them accomplish something that previously they would have had to use maybe a table or some other kind of weird formatting to achieve, that now they don’t have to do it that way, but they may just not know. And they may be kind of … going back to things that they are familiar with if they haven’t gotten that proper training.

GK:     So I think to wrap up, we’ve already touched a little bit on this, but I want to talk about the consequences of relying on quick fixes. And I think the two major ones that we’ve touched on a few different times throughout this podcast, one is that it makes a huge mess, and eventually when there’s some sort of pressing need to have things set up the right way, then you have to go back in and clean up that mess if you have relied on quick fixes.

BS:     Oh yeah. And that can take ages depending on how much content you have.

GK:     Absolutely. And then of course, the other big consequence that we’ve mentioned as well is that it adds cost in the long run. So even if a quick fix might save you some time or might save you a little bit of upfront cost or upfront effort on planning, it’s almost always going to add costs in the long run to do a quick fix. Because even if you just start with one small, quick fix now, as that gets expanded and propagated across all of your content over time, that is going to just really blow up that one small, quick fix into an expansion of quick fixes everywhere. And so then if you have to clean that up later, that cost is going to be huge, and it’s something that could have been avoided upfront if you had not gone that quick fix route.

BS:     Absolutely. And to add one more thing in here, you could be doing everything right, you could be planning for the long term, you could have carefully chosen your tools, trained your team, everyone’s following exactly how they need to be working, and then a request comes in for a one off document or a one off deliverable that’s never going to be used again. And you decide to throw caution to the wind and just get it done quick and dirty. And then suddenly that one off document becomes something that you carry forward with you for years and years and years updating and so forth. And if you do it wrong the first time, or if you make those quick fixes and do some ad-hoc formatting or whatever else, you then have to carry that forward. And it becomes more and more difficult to get that one off document that somehow has turned into a sustained need, which they usually do. It’s harder to bring that back into the fold of the other things that you might be doing the way you need to.

GK:     Yeah, absolutely. And that problem can become even more of a headache when that one document that you have done as a one off not only has to be carried forward, but maybe they decide that that’s going to be the basis for how you want to do a whole lot of other documents. You develop new products and they go, “Oh, this document structure worked really well. Let’s take that to five, six, 10 different products.” And so now a mistake that you’ve made has just really blown up, and it’s become the standard. And so to get that mistake out is going to just really be a nightmare.

BS:     Or, “Oh, they’re just release notes. Don’t worry about it.”

GK:     So we’re going to wrap this up here. This is going to be a two-part podcast, and the next one is going to focus on the solutions to quick fixes. Because in this one, I think we’ve talked a lot about the problems, but in the next one we want to focus more on the positive side of how you can avoid these in the first place. And if you do end up doing them, how you can solve those with hopefully as little of a headache as possible. So thank you, Bill for joining me today.

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 true cost of quick fixes (podcast, part 1) appeared first on Scriptorium.

In episode 77 of The Content Strategy Experts podcast, Alan Pringle talks with Chris Hill of DCL about content reuse and what it looks like across different industries.

“You really have to start seeing content creation as a collaboration and build trust between the people who create content.”

—Chris Hill

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 take a look at content reuse with special guest Chris Hill of DCL. Hi everybody. I am Alan Pringle. And today we have a guest on the podcast. It’s Chris Hill from DCL. Hi Chris.

Chris Hill:     Hi Alan, good to talk to you.

AP:     Yeah, it’s good to talk to you as well. Today, we are going to talk about content reuse and what that looks like across different industries. And the first thing I want to ask you, Chris, is why should people even care about reuse from say the executive who has departments that create and distribute content to the content creators themselves?

CH:     Yeah, that’s a good question. And it’s one that’s evolved quite a lot over the last 20 years as we’ve moved more and more content to formats that support reuse really the critical things about content is there’s a cost to managing content regardless of how you do it and every piece of content you can think of as an expense. As you build up more and more content, the expense rises because you have more cost to manage it, to find it, to dig through it, to decide what’s relevant. And it slowly will build up to the point where it becomes daunting to deal with larger and larger volumes of content. So content reuse really came about to help control that.

CH:     And when we see documentation that maybe has similar procedures or similar warnings or similar boiler plate text, whether it’s a copyright statement, you need to keep these things consistent. And so your users, your consumers of your content, benefits from reuse in that you create a consistency in the content that’s reliable, and that will not lead to confusion about what you’re trying to say. The creator themselves is often responsible for trying to deliver that quality consistent content to the users. And so a reuse oriented approach lends a great deal to be able to control and make sure that content is consistent and is accurate.

CH:     If you have a lot of duplicated content and I find out that there’s a problem with that piece of content, or maybe something needs to be updated in that content. I suddenly am faced with a huge search task of digging through everything, to find where that content was used. If I’m using a real reuse strategy, that content should only appear once in the content. And so if I need to update it, it can be done so accurately by just going to the single source and knowing that it’s reflected in all of the places where that content might appear. So that’s from like a user and maybe a creator level. Now, sometimes management might say to themselves, well, I don’t really care. I’ll pay someone to do that work. It costs a lot maybe to move my content to a content management system. Why should I do that? I’ll just hire another person to do searches. And that is an approach that a lot of people take.

AP:     But that’s almost like it’s the inverse of death of a thousand cuts. It’s this cumulative effect of all of this layer, upon layer, upon layer that you just keep throwing people at something where maybe technology might be a better solution.

CH:     Exactly. And it might be fine to throw people at it for the first few years, but if you become successful or your product family grows, if you’re a product company or if you’re offering a service, maybe you expand your services. It’s slowly, like you said, that death by a thousand cuts, it slowly builds to this level where suddenly you’re overwhelmed with any kind of content update. And you can usually see that in organizations, because what you’ll find is that if the content is proving a drag on the agility of your organization, so if you say, okay, we’re going to release a new product or a new version of our product, but when will the user guide be updated? And if you’re finding that, that’s always way down the line or always a drag, there’s a good chance that there’s some things going wrong in there that reuse might be a part of the solution for.

AP:     You mentioned the word control a little bit earlier, and that kind of stuck in my head because I have heard in the past from content creators, something along the lines of, “Well, my version of this stuff is better. So I’m just going to use my stuff.” How do you deal with that kind of mindset when you’re talking about a bigger picture reuse strategy?

CH:     Yeah. That’s always a challenge. I think just about anyone who has a lot of pride in their work, whether you’re a writer or a programmer, I used to be a programmer and when somebody would say somebodies already written this piece of code, my initial instinct was, “Well, I don’t know how that code is. I think I’ll rewrite it.” Right?

AP:     Exactly. Yeah, exactly.

CH:     And I think content creators have similar pride in their work. And what’s important I think there is, you’ve got a couple of things that you have to address at the organizational level. You really have to start seeing content creation as a collaboration and build trust between the people who create content and make sure that they understand each other and what they can do for each other, because really rewriting a piece of content that’s perfectly acceptable really doesn’t benefit the user in a meaningful way a lot of times we might think we wrote it better the second time, but wouldn’t it be an even better solution if there is a problem with the existing content, if I rewrote that existing content or updated that existing content so that all of the documents and all of the content that I produce could reflect that improvement? Rewriting it myself for my own manual might make my own manual a little better than someone else’s if I’m writing manuals, but at the end of the day, really, it pays from a organizational perspective to make sure that everything is written to the best level we can.

AP:     Sure. Now I know DCL works with a lot of different industries. Do you see kind of similar or different pain point struggles that organizations have based on a particular industry type when it comes to reuse?

CH:     It’s really a lot of it overlaps. I look at a lot of different industries content and the errors are all the same in a general sense. For example, one of my customers makes a conveyor belts, right? For baggage handling. And I don’t know, stuff like that. And when I look at their manuals, I don’t know what half of it’s about, but I do see the same exact errors and the same exact inconsistencies in their content as say, somebody who’s writing a journal, maybe a medical journal or something, you’ll see inconsistent phrases. You’ll see maybe somebody refers to their product in a certain way. And another writer refers to it in a slightly different way. Both of those ways may be valid, but could lead to confusion on the part of the user when those pieces come together, whether that’s a product name or whether that’s a disease, I’ve seen that where medical journals refer to a disease with two different names in the same articles sometimes. You wonder about that and those things are things you need to look for because their areas where somebody less knowledgeable about the topic might be confused.

AP:     Yeah, regardless of industry or content type, consistency, I’m assuming is something you really want to strive for regardless of where the content is coming from.

CH:     Yeah, it’s all about clarity to the end user and whoever consumes the content, we always have to think, the person reading my content is not going to be generally as knowledgeable about me or as me about the subject. So as I write that, I have to really think in terms of somebody who’s just coming to this content or this subject for the first time, they need that consistency to help remove some of those hurdles in mastering the information. If you have a lot of inconsistency in the way you talk about or refer to things, I think that’s just one more hurdle in the way of me really understanding what you’re trying to tell me.

AP:     And I think your point about thinking about the person who’s consuming, this content also addresses some of the ownership issues we were talking about earlier I don’t know if selfishness is the right word, but this idea, this content is mine. It’s really not yours. It’s the people who are reading it.

CH:     That’s a great attitude to take. I think it’s a tough one sometimes.

AP:     Oh absolutely, I agree.

CH:     But it’s a great attitude. If you can get your organization there it’s really so much the better. I used to work in some more content creation jobs and one of the things I always tried to do in a meeting when we’d have a disagreement over content or how to write something or what to write about, I always tried to focus the discussion on the users, if you keep your focus there, I think that should be your North star as you’re trying to work through these issues.

AP:     Sure and I can see it can also diffuse some tension when you’re talking about content that will eventually be shared or should be shared?

CH:     True. That can sort of be the bridge between you and somebody that you may have some disagreements with.

AP:     Well, speaking of disagreements, what are some of the horror stories you can share about reuse and going into an organization that you don’t have to name names of course, but what are some of the really kind of horrifying things that you’ve seen that you were able to help your clients fix?

CH:     It’s really interesting when you go look at a lot of content and especially I think because I often am coming into it with not a great deal of subject matter expertise, because again, we work with so many different industries.

AP:     Sure.

CH:     I mean, what do I know about luggage conveyor belts? Or what do I know about medical procedures? Not a lot is the answer. But when I look at their content, I can really see things that oftentimes they’ll miss. They’re often surprised I will come in and I’ll look and I’ll say, “Well, you obviously copied this manual from this manual and then to this manual.” Because I can almost tell from the changes that, that’s, how they’re operating. And that’s often the case you’ll see, especially in a lot of manufacturing type companies is they do a lot of, we’re going to start by copying an existing close thing and then we’re just going to edit the parts we need to edit.

AP:     I hear that all the time, all the time.

CH:     Yeah, it seems to be an easy way to work I totally understand why you want to do that.

AP:     Sure.

CH:     And in the old days, that’s all you could do. I mean, you didn’t have a lot of reuse options back in the eighties and nineties, unless you were IBM or something.

AP:     Right.

CH:     So it’s totally understandable that, that’s how you’ll work. And also that’s how we learned to work in our personal lives. None of us have set up content management systems in our home, as far as I know.

AP:     I hope not.

CH:     I don’t have my IT department downstairs, maintaining my files for me. So how do I work? Well, that’s literally how I work. I mean, I’m a reuse person and yet in my personal life, I’m not afraid to say that I will take a document that I’ve already written and revise it a little bit for some other purpose.

AP:     Sure.

CH:     But what happens if you do that at an organization level, is that those two duplicates then have their own life of their own. They’re really a split in the road and so if we find out there’s a problem with the content, most of the content you and I deal with personally, it doesn’t matter too much. If it’s out of sync a little bit, it’s like, “Okay, well, we’ll get over it.” But if I’m writing a space shuttle manual, or even a luggage conveyor belt manual, there are safety issues that come in. If I find out that there’s a safety problem and I’ve got to revise part of the documentation, if that documentation has been duplicated in dozens of places that I don’t know about, and I’m not very good at doing an exhaustive search, I may continue to expose my users to those incorrect or inconsistent pieces of information that could become a real liability.

AP:     A legal, costly, financial liability.

CH:     Absolutely. The other area a lot of times that this will come and I don’t know if this is a horror story, but is translation. So companies will start maybe in the U.S. or if there sometimes a Canadian company will start in a couple of languages like French and English, but they’ll start with a very narrow band of their user base. And if they achieve success, their user base expands. So if I take my company global, all of a sudden, I’ve got all kinds of other issues about my content and even if the content is in the product, any documentation I provide, there are laws in every country about how that gets delivered and what languages it gets delivered in.

CH:     So I might be perfectly content using my copy and paste and starting from an existing document for my English speaking content, but suddenly I move into France and I have to add French to the mix, or I move into Germany and now Germany’s on the table and German language is on the table. And as I keep doing this, I think it quickly becomes evident that you can’t hope to manage not only copies of content, but then also the language variations of content very easily using that copying process as you go.

AP:     Sure. Because once again, you have layers that are just exponentially increasing every time you do buy a new version of whatever you add a new language to the mix. So very rapidly, I can see it getting out of control.

CH:     Yeah, it does. And that’s a big horror story in a lot of companies, a lot of companies will come to us to talk reuse because they are going international or they have gone international. And suddenly they’ve got this nightmare of stuff. As far as translation goes, it’s very expensive to do translation. And so if I have a manual, the first time I get it translated, there’s just kind of a fixed cost. I mean, all those words have to be turned into German or whatever. The next time I go back to that manual, if I have a way of doing reuse, I can break that manual up into parts and just keep track of what parts have changed instead of retranslating the whole manual a second time.

CH:     And that can have a really dramatic effect on the cost and the velocity with which you can produce content internationally. If you can track and have a reuse strategy where only the reused components that get changed have to be retranslated that can often be very significant to an organization. So this is where the management starts to perk their ears up because they’ll start saying, how much money can we save on translation? Or how much faster can we get those translation done if we use this approach? And those are the areas that are often the real big pain points that an organization will come to us with.

AP:     I know from past experience doing copying and pasting of my own, yes, I have done it it’s been a long time, but I have done it. That it’s easy to get content where they are sort of like near matches. It’s almost the same content, but a word or two is different. So from a reuse point of view, I mean, what kind of different matches are there? Because there’s got to be some variety in how you can identify and track them all the way from absolutely identical to fuzzy kind of the same.

CH:     Yeah and that’s really where it gets very complicated if you are using that copy paste strategy. So if I take an existing manual and maybe I don’t like just the order of some of the phrases in the introduction, so I might move a couple of sentences around. Maybe I’m not really changing the meaning I haven’t really changed it much. I’m just aesthetically making some modifications because I like it better that way.

AP:     Right.

CH:     Well, suddenly it’s very hard to do searches to find that stuff. If there was an error in say a paragraph and I need to go look for that paragraph everywhere that it’s been duplicated, it can be incredibly difficult to find that stuff. And so fuzzy matching is something that is very hard to do in a traditional tool. You can do wildcard searches, say in Windows, if you’re looking at a shared directory or in most content management systems, but they really have a hard time if maybe the meanings mostly the same, and maybe a lot of the words are the same, but they might be in different orders. It’s almost impossible for a regular person to write at an… You have to really get into regular expression writing. And even the experts on that can’t really address those fuzzy matches very well because there’s just so many variations.

AP:     Right. And the people you’re talking about a lot of the time are content creators. They are not programmers.

AP:     So they may not have that in depth knowledge of how to do regular expressions and other kinds of searches to really find that stuff.

CH:     Yeah. And a lot of times what you see then to go back to our horror stories is… I’m amazed at how many organizations rely on, I always say one old guy, but it could be one person who is just intimately familiar with everything and that people go to and go, “We have to fix this.” And they’ll go, “Oh, this is in this, this and this manual.” And, “Oh, did you look there? Because it’s probably in there.” And that kind of reliance is very dangerous to an organization.

AP:     I have seen exactly what you were talking about in a manufacturing firm in particular. Yes. I know exactly the type of person you’re talking about. He or she has been there forever knows where everything is, it’s this huge, fast domain knowledge that they’ve got tucked away in their heads, but they are usually approaching a retirement age. Very dangerous, indeed.

CH:     Yep.

AP:     So let’s kind of move beyond, we know the horror stories, we’ve got some ideas of how to fix them, but once you know that you’ve got reuse and you’ve identified it, what kind of things do you have to do to really get a return on investment? Because merely a dent, just identifying that reuse is probably not enough.

CH:     Right. So the steps that follow generally, you’re going to have to find a framework or a platform on which to build a reuse strategy. So it generally is not possible or sufficient to just say, “I’m going to try to make reusable components on a file system.” There’s just too many limitations. So that’s when you start to get into the area of content management. And we’re kind of lucky today compared to say 15 years ago in that there are lots and lots of content management solutions out there that can support reuse and they’re better than they’ve been ever and there’s more options than ever. Some of them are cloud based and you can just get into them at a pretty reasonable monthly fee to start with and then build your way up if you need to. Or some of them are deployed content management systems that you bring into your organization and your IT department can manage if that’s your approach.

CH:     But usually once you’ve identified the need for reuse, that’s the next stage of the conversation. And really the reason why you need to do the reuse analysis first, generally is these content management systems are not free. Some of them are quite expensive and depending on your needs, it may be worth making an investment like that. But to make that case, you really have to look at all of the ways it’s going to improve the organization. And at the heart of that tends to be reuse in a lot of the work I run into. So to able to go to your management and say, “I want this much a month in licenses.” Or, “I want this much to deploy some software solution.” To do that, you really have to come with some metrics. And one of the things, knowing where all the duplication is in your existing content that can really help you put together those metrics.

CH:     You can put some estimated hourly or dollar figure costs on each piece of content and the changes you can talk about the time it took you to produce the next version of a manual or an updated version of a manual, sort of come up with some ballpark figures to work with as far as cost savings and efficiency improvements that these tools might have.

AP:      I think that’s very important what you’ve pointed out, you are not going to have a lot of luck going up the management chain saying, “I need this.” Without showing ROI, you’ve got to have something that shows how that system is going to be paid for, it may be over a period of time, but you have to show how your return on investment is going to pay for this new technology. Otherwise, what’s the point?

CH:     Exactly. Yeah. Yeah, I find that I’ve seen teams and I’ve been part of teams where we went to the management to ask for something and the only real thing we had at the end of the day, if you summed up our argument was it’ll make our lives easier. And I learned very early in my career, management doesn’t always care about making my life easier. They might even say, “I’d rather just give you a raise, than make your life easier.” Or “I’ll hire you some help.” Or whatever, because it can seem daunting these content management systems. And it’s like, why should we change everything that we’ve been doing for the last 40 years? We’ve been doing it this way I don’t understand why we need to change it, we’ll just get you some help. So making that bigger case and talking about some of these reuse issues and talking about content cost and velocity, those are all things you can start to put those numbers on so that you’re not just going to management with make my life easier.

CH:    Right. You’ve got something fairly objective instead of all about you and how it will make your life easier.

AP:     Yep. Yep. So for people who were thinking about reuse, are there some common places to start to look for duplicated information kind of low hanging fruit, if you will?

CH:     Well, I mean, almost always you have copyright statements, right? And how many times do you find a copyright statement that’s out of date or inconsistent? It’s a lot and I can look at those usually and very quickly see, okay, there’s a reuse issue here. You may have, depending on what industry you’re in. We see a lot of background information, introductory paragraphs, those kinds of things often have a lot of overlapping subject matter. And it’s, again, you’re not looking for exact duplication all the time oftentimes you’re looking for the same objective for the piece of content. So maybe this content is to familiarize you with some process that our equipment performs. And so the background information might show up in several places and those are areas where that’s really easy to find.

CH:     Another thing that’s easy to find is if you have product variations, you might have in the example of the conveyor belt company, there’s a straight conveyor belt, there’s a curved conveyor belt. There’s a conveyor belt that moves at a different speed. Those may have a lot of the same parts. They might almost be exactly the same, but they have different manuals. Usually, you know from your products where those things occur.

CH:     One of the things we did, and this is really my role at DCL is I was hired on as product manager for one of the products we actually sell that looks for duplicated content. And it wasn’t originally a product so well before I joined, it was a part of the conversion process. When someone would come to DCL and say, we need to move our content out of word or out of Framemaker or out of whatever tool we’re using into this format, say DITA or XML that our content management system can use. One of the first steps is to say, “Well, where are those reusable pieces?” And we used to do that analysis by hand and throw armies at people at it.

AP:     Wow.

CH:     But nowadays over time they evolved a product to do that and that’s the product we call Harmonizer that I manage and that product has improved over the years because of all the breakthroughs in natural language processing and artificial intelligence and machine learning, all those fields have given us a lot of algorithms and a lot of approaches to find fuzzy matches, those near matches or even kind of matches of content that you’d never find by hand that a person would never see. I constantly see when we run a bunch of documents through this tool, it’ll find things where people have rearranged entire phrases into different orders and move the sentences around and it still picks it up as a near match to something else.

CH:     And when you first look at it, if you were just scanning the page, you’d miss it because it doesn’t look anything like it at first glance and then when you read it, you’re like, “Oh, those are the same.” Somebody really rewrote this in maybe a better way, but didn’t rewrite the original one. So that’s where there are some tools now emerging that can help you do some of this stuff.

AP:     Well, I think those sound very helpful and we’ll be sure and include a link in the show notes to the Harmonizer tool so people can learn more about it. And I think with those recommendations, we’re going to leave it at that. So, Chris, thank you very much. This was a great conversation.

CH:     Yeah, I really enjoyed it. Thanks Alan.

AP:     Thank you. 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 Content reuse: different industries, same problems (podcast) appeared first on Scriptorium.

In episode 76 of The Content Strategy Experts podcast, Elizabeth Patterson and Alan Pringle talk about expectations versus realities of tools when moving to smart structured content.

“You can have different people using different tools and still pour all of the content into the single content management system. People connect to it differently based on the authoring tool that they prefer, and what works best for them.”

—Alan Pringle

Related links: 

Twitter handles:

Transcript:

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

EP:     In this episode, we talk about expectations versus realities of tools when moving to smart structured content. Hi, I’m Elizabeth Patterson.

AP:     And I’m Alan Pringle.

EP:     And I want to get things started by just having a brief definition of what structured content is.

AP:     Smarter structured content is a content workflow that lets you define and enforce a very specific, consistent organization of your content. And it also captures some intelligence about your content. For example, what the audience is, for what product it is, you can embed that intelligence inside the structure for that content.

EP:     Okay, great. So when you decide to make that move to smart structured content, what are some questions that you need to ask yourself before you make that move?

AP:     Once you’ve established that business case that you do need to move to structure content, one thing you can start to do is really take a look at what you’re doing right now with your tools. I’m going to make the assumption that you were working in some kind of unstructured tool, some kind of desktop publishing tool, word processing tool. There are lots of them out there, Microsoft Word, InDesign, FrameMaker, any of those kinds of tools that are more on the traditional desktop publishing design side. And take a look at what you’re doing with those tools right now, are you using a template? Are you doing things or your people in your department doing things, shall we say in a Wild West way? Where anything goes. Because having a template is kind of like a baby step towards structure, because you have very specific tagging that your content creators assign and it gives an implied structure to your documents.

AP:     So there’s that mindset already there, yes. There are certain tags that I need to use and it’s best that if I use them in a certain order. And that kind of mindset would be very helpful when you move into structure where there is an actual enforcement under the covers by the software, to be sure you are following that particular organization of content.

EP:     And then also, you should probably take a look at the profiles of the people who create and review that content because that’s going to look different across the board.

AP:     Yes, it will. You have different kinds of content contributors in an organization. And for example, you may have people professionally, that’s all they do, is write content. Now that could be marketing content, that could be training content, that could be product content, support content. And then you’re going to have people who are reviewing that content and either making comments on it or are actually getting into the content and making changes and adding small bits and pieces to it. These people are not going to be your professional full-time content contributors, it’s more likely for example, a product engineer or somebody like that who has a deep understanding of the particular topic or thing you’re writing about. And then they’re going to offer input based on what you have created as a full-time content professional.

EP:     So what are some of the expectations that people tend to have when moving into a structured environment?

AP:     Again, it really kind of hearkens back to what we were just talking about. How are you using your tools now? If you’ve got a templatized system in place already on the unstructured side, it’s an easier adjustment, like we’ve already talked about. So those people, it’s going to be easier to get them to come along, if you will. However, if you have got, and this is a term that I have heard from many department organization heads, where they’re told, “Oh, we as content creators, we have to have creativity. We have to have free rein.” Dealing with that kind of scenario is a little more challenging and difficult if you’re the person leading this transition, because oftentimes that claim to need creativity is more really means, we don’t want to have any set rules, we want to be able to do whatever we want, how we want.

AP:     And so therefore, there is no consistency at all in the way tagging is applied, the way that content is structured, at all. So it depends really on the mindset of the people that you’re dealing with. And then beyond just those kinds of full-time content creators, what about your part time people? What about the people who were just going to contribute a little bit here and there, or review content? What are they doing right now? Are they marking up a PDF and sending it to you via email? Are they getting into the files and actually adding comments? You’ve got to think about how they’re working and the system, and be sure that the new environment you’re moving into can accommodate them as well.

AP:     And they’re probably not going to want a tool with all the bells and whistles, they’re going to want something a little more narrow that lets them address just what they need to do. Review, comment, or maybe add a little thing here and there within the content without getting bogged down in a bigger tool. So you’ve got to think about all the levels of people, what kind of contributions they need to make, the amount of those contributions and how those fit in the new tool system.

EP:     So could you touch a little bit more on the different levels of tools that you had mentioned?

AP:     Sure. There is an infrastructure that supports a lot of the standards for structured content. These tool makers know that there is a large market share for these standards, such as Darwin Information Typing Architecture, DITA, Docbook is an older one, there are a lot of people using those standards so a lot of the toolmakers out there will support them.

AP:     A lot of the content management systems that people use to manage their source, smarter, structured content, they even have built-in tools. So there’s a large choice out there of what you can use and not everybody has to use the same thing. For example, there may be a browser based tool that would be really great for your part-time contributors, for your reviewers. The interface is simplified. It’s stripped down. It doesn’t have all the bells and whistles, probably works a whole lot like Google Docs, for example. So it’s more basic, but it still gets the job done, especially for people who don’t have content production as their primary job responsibility. On the other side of that, you’ve got a lot of tools that offer really in-depth features that let you, for example, edit the direct XML code, the structured code, instead of seeing it with an interface, if you like to get in there and get your hands dirty. And it has a lot more features as far as guiding reuse and some other things.

AP:     That kind of industrial strength authoring tool, is gauge more time, your full-time content contributors. So it really depends on the level and the depth of how much you’re going to dive into that content, about what tool you’re going to use and like I said, it is not a one size fits all situation at all. You can have different people using different tools that still pour all of the content into the single repository, the single content management system. It’s just people connect to it differently based on the authoring tool that they prefer, and that works best for them.

EP:     Right. And so this is where we were talking about the different profiles of people and making sure that you’re asking yourself that question, it’s really important that you do that so that you can make sure that you are taking into account all of the different needs that the people on your team are going to have.

AP:     Right. And the thing is, a move to smarter structured content may start in one department, but it’s very likely because you have success there, it may go enterprise-wide. So that’s also really important to realize. Just within your group, there may be needs for different authoring tools, that need for those different tools is going to expand probably even more when you start going out into different departments and groups, and expanding the reach of smarter content across your organization.

AP:     So it’s just like, as you’re working now, the people in, for example, the product content department, they’re not probably using PowerPoint as much as the people in the training group. So just like on the unstructured side, you have different tool needs. The same thing is going to be true on the structured side. Don’t expect everybody to use the same exact tool, because frankly it’s not necessary. There are a lot of choices out there and they still will work together. Still put all that content in the same repository, the same content management system, your same single source of truth. People just have different ways of pouring content and reviewing it within that system.

EP:     Right. And this is why we’ve said in so many different podcasts and blog posts, not to choose your tools first, to make sure that you really understand what your needs are going to be.

AP:     Right. And it’s like we said at the very top, you have to have business requirements that drive your decision to do this. You need to do a little bit of investigation on your return on investment and to be sure that you’re going to be able to get that return, to pay for what you’re doing, to continue to pay for it through whatever costs-savings, more efficient localization, simplifying, rebranding, there’re all kinds of reasons and ways you can save money and boost efficiency with smart structured content. And I’m guessing we’ve got a white paper, or blog post or two that we can add to help people understand that return on investment. So we’ll put that into the show notes.

AP:     But once you have that business case, you understand your return on investment right. That’s when you start to need to really look at the requirements of the different people. It’s not one size fits all, and I’ve said that many times, but I do think that is a very common stumbling block, because this is structure, it must be just this one way. Yes, the structure itself of your content, it is going to be enforced. It is pretty tight, but the ecosystem that surrounds it, there’s going to be some flexibility there. And people need to realize that. And I think people hear structure and they run away thinking, oh no, we’re going to try and cram everybody into the same system. That’s not necessarily true when it comes to the authoring tools.

EP:     Right. So let’s say you really need highly designed content and you’re going to need to finesse that design. Are you still able to do that as you move to structured content?

AP:     Yes. You are, with caveats. And let me rewind a little bit here. This is also a very common challenge, misconception, whatever you want to call it. Generally in a structured authoring environment, the formatting is applied automatically. So you write your content and you basically tag it with the various elements to build in that intelligence. And then, you run a transformation process to create a website, to create a portal, to create a PDF, to create training materials, to create marketing slicks, whatever, the choices are endless.

AP:     Because that content is not formatted by hand, it is done automatically through a transformation process, a lot of times you’re not going to have super finite control over page breaks and things like that. Now the good news is, within the programming of those transformation processes, you can add a lot of rules that say, yes, I need to always keep like a caption with a table. I always need to have the first three or four lines of a section to stick with the heading, things like that. There can be rules about how tables break across columns. You can build in a lot of intelligence and really get to a very good point without having to actually manually touch everything. Everything’s automatic.

AP:     There are times where you have business requirements that say, “Yes, I do need the ability to really touch up the formatting.” A good example of this is, suppose you have workbooks that you sell to people and they are very highly designed. Your production staff spends a lot of time making sure that the text flows across pages to really help readers comprehension. They pay a lot of attention to the way images and tables are placed. If you have a case like that, you can create a scenario where yes, you were using the structured smart content as the source. You transform it into a form of markup language that one of your traditional desktop publishing tools can ingest. And then you can do those last little bits of formatting touch-ups in that tool.

AP:     And here’s an example of that, InDesign. You can take structured content, you can transform it into an InDesign compatible XML format. You can put that InDesign compatible markup into an InDesign template. And what happens is, is that that transform has basically matched styles within your InDesign template to elements in the structure, so when you put that InDesign compatible XML into an InDesign template, it will automatically format the content for you.

AP:     What it’s probably not going to do though, is get those page breaks, get the placement of images and all that kind of really more highly designed stuff. It’s not going to do that automatically for you because in some cases that’s going to take the judgment of a human being. One of our consultants here, Jake Campbell, had a really good saying, “It’s the art of design versus the science of design.” Yes, you can program the science of design and get a lot of those rules in regard to how styles are applied built in automatically, but what you can’t do is really get that last, say 10 or 15% of those touch ups you want to do to make something look really, really good. That’s when you need the art of design, the human intervention.

AP:     So at that point you have got an InDesign document that’s say 90% done, as far as formatting goes, then you go in and clean up that last little bit of the formatting that needs some tweaking, and then you make your PDF for print. So you can do that. It is possible. Same thing with training information. If you need to create slide decks and people need PowerPoint, you can set things up, because we’ve done it, where you take the structured content and you poured it into a PowerPoint template, and then it will apply the slide design, the correct formats for bullets and all that kind of stuff. So it is possible to do that. One thing I will say that you’ve got to understand this is a one way street. This is just for production, all the authoring of content, all the modifications to content still needs to happen in your structured authoring tool.

AP:     So you can’t go in and change words, for example, you don’t want to do that. You don’t want to change the content, once it’s ported into PowerPoint, once it’s ported into InDesign. What you want to do is make the changes in your single source of truth, that is, that’s your structured content and then re-import it if you need to make text changes. And all of that last minute finessing you did, as far as formatting goes, really the XML does not care. The structure content does not care because formatting is separated from the actual content. So it doesn’t see it. It doesn’t need to know it. That’s why I say it’s a one way street.

AP:     You transform your smarter structured content into an XML that your desktop publishing tool understands, open it up, and then do your last little bit of production work. So basically you were using the skills you already had in those unstructured tools, but the good news is, is most of the formatting, or the more manual labor is already done for you. All the assignment of the paragraphs for the title, the paragraph, or the styles for your paragraphs, all that’s done for you, so that’s something else to consider too.

AP:     If, if, if, if you have a very good business reason to continue to do this very specialized, highly designed content, there are ways to still create it, to still be able to manually intervene and touch things up when you need to. So it is possible, not everyone needs that level of format control, but you can do it.

EP:     Right. So I think we’re looking at, as you make this change, you’re looking at a lot of new processes that as a team you’ll have to adopt. So I just think that this is important to touch on. Is there anything that people can do to specifically help with change management when moving to structured content?

AP:     I think the important thing to remember is that you can invest all the money in the world in new tools, new systems, if you don’t train people on how to use them, and they don’t understand how to properly use them, that investment is a waste. You have to build in training as part of your process to moving to the new system, to smarter structured content.

AP:     There are lots of things you can do, classroom training, hands-on training. It’s also good too, to set up kind of like mentoring programs where you maybe break off into small groups, have someone who’s a little more seasoned, someone who already gets it, perhaps you’ve hired someone new who did it at another job, they could help you kind of work out the big picture concerns people have. How do I do this? How do I map my knowledge from using this tool on the unstructured side, how do I get that same result, basically when I’m working with the structured content? So classroom, hands-on training, web training, mentoring, a lot of Q&A and it’s always really good to have a continuous feedback loop. Because people, as they start to work with new tools, new systems may uncover some things that aren’t working quite like you intended. So pay attention to that.

AP:     Yeah, there’s going to be complaints, “I don’t want to do this,” but don’t assume that every observation is necessarily a complaint. It may be a valid, constructive criticism.

EP:     Right. And I think that that is a good place to wrap up. And like we mentioned above, I will link some additional resources in the show notes. So thank you so much, Alan.

AP:     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 Moving to structured content: Expectations vs. reality (podcast) appeared first on Scriptorium.

In episode 75 of The Content Strategy Experts podcast, Elizabeth Patterson and Bill Swallow talk about how content reuse can help you save on your localization costs.

“The savings you get from a reduced word count is all fine and good, but the translation is only as good as the quality of the translation itself.”

—Bill Swallow

Related links: 

Twitter handles:

Transcript:

Elizabeth Patterson:     Welcome to The Content Strategy Experts podcast brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way. In this episode, we talk about how content reuse can help you save on your localization costs. Hi, I’m Elizabeth Patterson.

Bill Swallow:     And I’m Bill Swallow.

EP:     And we’re going to dive in to talking about how content reuse can help you save on your localization costs. So I want to get started with just a really general question, and when we talk about reuse, what are we talking about?

BS:     That’s a very good place to start. When we talk about reuse, what we’re not talking about is copying and pasting of content. You could think of that in terms of reuse, but it’s not really what we’re talking about here. When you copy and paste content, you’re essentially duplicating it and then need to manage it in multiple places. What we’re talking about is more intelligent reuse of content, so writing it once and using it by reference wherever you need to use it. So this way it’s only written once, and it’s used multiple times as needed.

EP:     Great. And we have done a podcast and an additional blog post just solely on reuse, so I will link those in the show notes. But I want to dive into now looking more specifically at how content reuse, now that we’ve defined that, can help us save on localization costs.

BS:     Well, generally speaking, reuse reduces the overall number of unique words that you are translating. By using intelligent reuse in your writing once, and using it multiple times by reference, you have the opportunity to choose pieces of content that you will author once and only once, and that content gets translated once and only once regardless of how many times it’s being used. If you copy paste, you can still see a savings if the wording that you’re using is one for one, so if it’s absolutely exact all the time.

BS:     For example, I know Microsoft Word has an auto text feature, so you can throw a basic reusable component like a caution statement or some other boilerplate text, and you can use that to insert it every single time. That may save you a bit of time on the offering side and ensure that the text that you’re inserting is exact every single time. The only problem with that is that it is inserted as normal text every single time you insert it, so it does still increase the total amount of words that you need to send to the translator. It might be a 100% match, but they still have to do a check against it to make sure everything is fine. And the systems that they use will still count those words and say, “Yes, this is a 100% percent match.” But it’s still being counted as part of your incurred cost, because there’s something that’s going to the translator for them to see, even though there’s a match.

BS:     And in some cases you may even get what they call an ICE match, or an in context exact match, on that text. So if you are using something like Microsoft’s Word’s feature, you can drop that text in every single time and you can get this, “Yes, it is a 100% match every single time it’s inserted.” And if it’s a full paragraph, it could be, “Yes, it’s a contextual perfect match. It’s a paragraph and it says the same exact thing.” But more times than not, when you talk about inserting strings of text that say the same thing over and over and over again, the context may shift depending on where you’re using that text. In which case then you get maybe a 100% match, which still requires some review, or you get what we call a fuzzy match, where if you happen to make an edit to that text that was inserted and copied and pasted it’s no longer 100%, and therefore the translator has more work to do.

BS:     And there may be questions. This one has two words that are different from this other block of text. They say roughly about the same thing, should they be translated the same way or is there a reason why they’re different? That just slows down your translation process, it injects confusion, it injects questions that need to be mitigated and answered or you can then suddenly have a divergence in the translation where you shouldn’t have. The translator might’ve translated it two different ways because it used two different structures.

BS:     So true reuse or intelligent reuse moves that out of the way by taking the text that is being reused every single time, putting it somewhere to the side, is translated separately, and then can be used as it needs to be used throughout whatever it is you’re writing. Your manual, your web content, whatever you need to. And there are plenty of tools that are out there that do this well. Two of which that come immediately to mind for desktop publishing based tools are FrameMaker and MadCap Flare.

BS:     FrameMaker uses a series of conventions where they store content in chapter files, and those chapter files are assembled within a book file. And you can easily reuse an entire chapter in multiple different books just by linking to that chapter file from the book. You don’t have to rewrite the information, it’s not being copied and pasted. It’s a dynamic link that goes right to that file and pulls it into the book.

BS:     FrameMaker also has text insets which function a little bit in the same way where you have a separate file that has a block of text and you can say, “Hey, go to this file, grab that text, and place it here.” And the smart thing about this is that when you do that in FrameMaker you are not creating an editable copy of that text. It is a reference to the file that contains the text, but you cannot modify it within the context of whatever it is you’re writing. It is uneditable. You can see it, you can read it, but it is uneditable, and you can’t modify it.

BS:     The same goes for MadCap Flare, where you’re building things in a similar fashion. Where you’re grabbing individual files, and you’re putting them together in an order to create some kind of document or website or what have you. And MadCap Flare also has something similar to text insets, they call them snippets, and you are able to insert these snippets throughout your content. And those, again, are managed in a separate place, they’re written only once, and they are non-editable in the context of where you’re using them. They’re only there as a reference point.

BS:     Now, these are great, however, you do have some concerns when you’re using these tools for localization purposes. They’re not inherently bad, but if you are looking to do a lot more with your content, let’s say you are styling your content very differently for different outputs or you’re creating the same type of output, but the styling is different. The text insets in such are in the snippets. They’re going to, I believe, carry a lot of the formatting information over with them however they’re formatted, where they’re stored. So it’s not incredibly ideal, but it does reduce the total number of words that you’re translating.

BS:     When you move to something like XML, you have a bit more available to you because you have these conventions, but they’re built into a format of writing that does not have the formatting applied to the content. So it’s all text base and you can do quite a bit with organizing and reorganizing your content without having to worry about your headings being formatted one way or another. It’s all just plain text and the formatting is applied at the point you’re publishing.

EP:     Right. So I think what we’re seeing here, obviously, is that there’s really one main way that you’re going to be saving money on your localization costs through reuse, and that’s just reducing that word count. But the way that you go about making that happen in your strategy is really going to vary depending on where you’re at as a company.

BS:     Right.

EP:     So I want to get into a few tips. So what are some tips that you have for reusing content, particularly when you are planning to localize that content?

BS:     Well, the knee jerk response to anyone who is doing localization for the first time, and has all of this reuse potential in front of them, is to reuse as much as possible and to apply conditional text or conditional formatting as much as possible. And even I was guilty of that many, many, many years ago where we would have a manual that would go out in 19 or 20 different languages but one of them was over in Europe. And I figured, “Oh, well, for the English stuff we’ll just condition in and out the characters that differ between certain words. We’ll condition in or out a U in color or we’ll condition out a Z for an S for localize.” These types of things. And I thought I was being quite inventive and it came back immediately that no, you cannot do this, because when you send something for translation the translator gets a wall of garbage that they’re looking at and wondering what you’re trying to do with these words.

BS:     So my first bit of advice is do not go too granular with your reuse. Things like reusing words or phrases, I would really limit that as much as possible. You really want to reuse at a larger chunk level. So if we’re talking DITA or if we’re talking something like MadCap Flare, reusing at a topic level. So here is a topic with a heading and a bunch of text or a procedure or what have you, reuse that whole piece. If you need to reuse it five, six, seven times, that’s great. You’ve written it once and you can leverage it an additional four or five times. That’s fantastic. Reusing things like notes, cautions, warnings, they tend to stand on their own. I mean, they’re used in context with other text, but the warning itself, you can write those to be very standalone as far as what the thing you should not do is and what the outcome of that is within the context of that warning statement. And you should be able to put that off to the side, write it once and use it everywhere.

BS:     There are two benefits to that. One is the localization impact and the other one is that all your warning messages are exactly the same wording. And it will drill that information into your readers’ heads over time as they read it to say, “Oh yeah, I shouldn’t do this. I should not do this.” There are only so many ways that you really should say, “Don’t stick your hand in the machine while it’s working or you’ll lose it.” You really want to say it only once and repeat that statement multiple times until it’s drilled into your audience’s head to, “Hey, don’t stick your hand there.”

EP:     Yep. And you want to make sure that it’s being said in the same way so they don’t take a different meaning from that.

BS:     Exactly. Or have it translated differently even though you meant to say the same thing.

EP:     Right. And something that I’m thinking about as we’re talking about what companies give their translators, so that their translators are trying to figure out what they mean, is writing style. So when you get into an organization that has many different writers, what are some things that you need to be aware of when you’re planning on sending content to translators?

BS:     The first thing you have to do is have your style guide nailed down and make sure that all of your writers are following that guidance. Sometimes in larger organizations where you have too many authors, and perhaps not enough editors to clean up after them, you might want to look into some kind of editing based software or language based software like Acrolinx or Congree to do a lot of the spot checks automatically, rather than relying on someone to catch it in proofreading. Especially if you have tight timelines, quick turnarounds, and everyone’s just too busy to proof each other’s work. I know that the days of having a fleet of editors cleaning up after writers has kind of run its course. There are still many technical and editorial editors out there, but not to the degree they used to be in, let’s say, even the 1980s when, unfortunately, I started working.

EP:     Right. And content governance can help with that as well, right?

BS:     Oh, absolutely. The more you can nail things down and have a process for how you produce your content, the better off you’re going to be. And the one thing you absolutely must do, and I wanted to touch upon this also with the style guide, is you have to include your localization people in that overall plan for governance in styling as well. You want to bring them in to help define the language style that you’re going to be presenting this information in. The way they’re going to write their translations, how you want their translations to read, and which words they should use, and which words they should not use and why.

BS:     You really need to have a global style guide at that point and be able to provide glossaries of information to your translators, because you may have different translators for each language depending on when they’re available to take on the work. Unless you’re fortunate enough to have them all in house as employees, which is extremely rare. A lot of times that work is outsourced, whether it’s through a language service provider or you’re doing it direct with other freelance translators. So being able to have that global style guide in place, to have a global glossary in place. And what’s really critical is being able to, when you do have these reusable components, that you’re going to be giving them to translate not only the components, but the content where the component is lacking. Because when you’re reusing by reference that content does not exist in the file that they’re looking at.

BS:     So you want to be able to provide additional contextual information to the translator to say, “Oh, hey. When you get to this point there’s a bit of content that’s being inserted.” And maybe even provide them with the reasonable content to say, “This has already been translated, but this is what’s going in here.” So that way when they get to that point they’re not stumped and say, “Well, this doesn’t make sense because it goes from part A to part C, we’re missing part B. I don’t know what it says there.” That can certainly throw off the translation process. So being able to provide that additional context around what is going on in your content set is critical when you’re doing things with intelligent reuse.

EP:     Right, right. So I think really one of our main takeaways from today is that you certainly can save money when it comes to localization on the translation side of things, but you need to be prepared to really pay attention to your translator’s needs.

BS:     Absolutely. I mean, the savings that you get from a reduced word count is all fine and good, but the translation is only as good as the quality of the translation itself. And if you’re tripping up the translator in any way, you’re not going to see that return on an investment in localizing.

EP:     Right. Absolutely. Well, I think that that’s a good place to wrap up. So thank you so much, Bill.

BS:     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 Saving localization costs with content reuse (podcast) appeared first on Scriptorium.

In episode 74 of The Content Strategy Experts podcast, Gretyl Kinsey and Simon Bate continue their discussion about the benefits of establishing a taxonomy.

“Communicate with the stakeholders. Don’t just get their input and then go away. Communicate all along what you’re doing and identify your benefits.”

—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.

GK:     In this episode, we continue our discussion about the benefits of establishing a taxonomy. This is part two of a two part podcast.

GK:     So if you are at an organization and you have never had any sort of taxonomy in place and you’re starting to realize that you need something to help categorize your information, how do you go about starting that process to build a taxonomy?

Simon Bate:     Well, the first thing of course, is to meet with your project sponsor, the person who’s really asking for this thing and get a sense of what’s their purpose and rationale and what’s the actual purpose, why are you building out the taxonomy.

SB:     So then you want to, once you get a sense of that, you can map the scope of the project, including the knowledge domains and both visible and invisible stakeholders in those domains. So in meeting with the sponsor, you find out what do they need and who has a major stake in it.

GK:     Yeah, absolutely. And I think it’s really important. A lot of people I think skip that step of getting that sponsor buy-in upfront. Especially if you’re not the one who has the power to or the finances to sponsor that taxonomy yourself, then it’s really important to make sure that you have someone who does have that power to be your ally and really help understand what you need. And so if that person’s not the driving force behind it, but maybe you are, but maybe you’re not in any sort of management or leadership role where you have control over finances, it’s really important to talk to whoever does have that power and make sure that, between the two of you, you can get on the same page and prove to them. Here is the business advantage of establishing a taxonomy and here’s what we are losing if we don’t establish one. Here are all the customer frustrations with not being able to find this information in this way and that will kind of help you get over that first hurdle.

SB:     Yeah, absolutely. Having a justification, demonstrable return on investment or whatever, is really important before you can get started on any project like this.

SB:     So actually once you’ve then gone past that first step, you’ve got a buy in there, then the next thing to do is to go to those stakeholders that you identified and engage with them. You want to validate your map of the scope, you need to understand their needs and it’s really, really important.

SB:     If you try and start building a taxonomy out and you don’t include all the stakeholders, you’re setting yourself up for problems later essentially.

GK:     Yeah, and we’ve seen lots of cases where that happened where maybe one department or one small group within a department started a taxonomy because they had an immediate need for it. But they didn’t go talk to anybody else who may have been impacted by it later. And so then, down the road, they realize, oh, we’ve got a taxonomy that started over here in the training department, but the marketing department really needs to be using it and to be consistent with it. But because there was no communication, maybe marketing started their own taxonomy and it’s very different. And so kind of getting that alignment is a lot easier on the front end than it is to try to bring things into alignment later. So the earlier that you can engage other stakeholders and other groups, the better off you’re going to be.

SB:     Absolutely.

SB:     So the third step in building the taxonomy is to then refine your project purpose and get the sponsor’s agreement. So get things together and then go back to your sponsor and just make sure that they also have buy-in on what you’re doing.

SB:     The fourth step is design your approach and then step five, build your communication plan and identify the benefits. And really one of the important things here is communication, as in many things like this. It’s really important. Communicate with the stakeholders. Don’t just get their input and then go away and do things. Communicate all along what you’re doing and identify your benefits.

GK:     Yeah, it should be a collaborative process and that goes for, when you do design that approach, that step four, it’s really important to have that collaboration going on during that phase too because then you know if another group comes up with a concern and says, “Oh, we need the taxonomy to be able to do X thing for us,” but you also need it to do Y thing for you, it’s good to know that up front when you are designing how you’re going to put that taxonomy in place. And the same is really true, getting back to the point we talked about earlier when we were discussing that that sort of confirmation bias and the other sorts of biases that you may encounter, you want to make sure that no one group has too much bias in the taxonomy, and that if there is any customer end user information that any or all of the groups has access to, that’s being shared across the board. So when you are going through those phases of designing your approach and figuring out that communication among everyone and identifying how the taxonomy will benefit each group, it’s really important to collaborate throughout that whole process. And as Simon mentioned, not just have each group or one group go off and do their own thing. It really needs to be cohesive across the board.

SB:     That’s right. That’s right. Because eventually, getting your taxonomy back to the real world, when you present these things, when you present the terms that you’ve agreed upon on the taxonomy, they are present in many ways. Your company expresses things publicly, so you might have things appear in marketing brochures, you might have things occur on your website, you might have things occur on the documentation. And you really want, that’s well one of the advantages of the taxonomy is that when these ideas, when the concepts, terms of whatever, are presented in all of these areas of your company, they all come out the same. You’re using the same language consistently and that’s a major advance for you.

SB:     The sixth step here in building your taxonomy is to start the process of taxonomy governance. So a taxonomy isn’t a static thing. You don’t just build it, set it, and then go away. It’s going to evolve. It’s going to continually change. People are going to add to it, people are going to refine it. People are going to take things away from it. You do need to set up some process, some way that people are going to help remain engaged and continue helping to maintain your taxonomy.

GK:     Absolutely. And there are tools and systems out there that can help with this, but I think it really comes down to that agreement for everyone to continue collaborating on it in the end. I mean, you can put some kind of a tool in place that’s designed to help maintain a taxonomy and update a taxonomy, but everybody has to agree to use that correctly and to do the work it takes to keep that taxonomy managed and maintained. So it’s kind of a culture shift. If you’ve never had a taxonomy of your organization before, it can really be sort of a major change to realize, this is important. Here’s why it’s important. Here are the benefits that it’s going to bring us and therefore, we need to dedicate X number of resources toward maintaining and improving it over time.

GK:     So how does taxonomy fit within a larger content strategy?

SB:     Well, there are several places within your content strategy that a taxonomy can help. So there is search, for instance, there’s targeted delivery and personalization. These are some pain points where taxonomies can help you.

GK:     Yeah, absolutely. And I think we’ve actually seen that with several of our clients where, if something like personalization is a goal and they don’t have a taxonomy in place that needs to become part of their content strategy.

GK:     Same thing for search. Depending on how people need to search your content, and that’s both end users, but also content creators, subject matter experts, people like that, people in support, anyone that needs to search your content, the taxonomy really does a lot of the work on the backend of making sure they get the right results when they’re doing those searches. So all of these factors are a major part of your content strategy and the taxonomy can be the piece that gets recommended to help resolve those issues.

SB:     Yeah, that’s correct.

SB:     So another place is in borders or you may also want to think about silos. You want to prevent silos. So you have a whole number of different groups within your organization. They all had the same final goal. And what you want to do is use your taxonomy to help you get around those borders. Because your taxonomy, as I was mentioning a few minutes ago, helps maintain consistency across all of your groups.

SB:     And then of course, you can think vertically. There are your levels. So within your content strategy, you want to think about what’s happening at your corporate level, what’s happening at business group level, what happens at the department level. And in some cases, there are calls for different levels of taxonomy or different types of taxonomy within that. But essentially, in the end, it all boils down to the same thing. You have taxonomies that cover the needs of each of these different levels.

GK:     Yeah, absolutely. And that’s what we think of as an enterprise taxonomy where you are encompassing different groups, different levels, and the needs of each of those, and making sure that they are all in sync. But that then each individual group or level also has maybe some different taxonomies or different categories that apply specifically to them.

SB:     So one other place where we can fit a taxonomy within a content strategy is just your level of end user. So you may have experts, you may have novices. So for instance, you may be dealing with medical or a technical language and how physicians will search for information may use very different language than how lay people, people who are non-physicians, will search for things.

GK:     Yeah, that’s very true. And we’ve seen that, not just with medical but you said with technical as well, and the same as the case with an end user versus maybe a software developer. The same is true if you get into something like manufacturing. Someone who’s an engineer is going to use different language than an end user as well. And so it’s important to think about what levels are there. Maybe you have expert and novice, maybe you have more kind of intermediate levels in between, especially if you are dealing with educational content. You may have different levels for different grade levels in school or different course levels if you’re looking at a university. So it’s really important to think about that aspect of taxonomy as well.

SB:     Yeah, those are all great examples.

GK:     So we touched on this a little bit, I think when we were talking about taxonomy and how it fits with some of the aspects around search and personalization. But how does taxonomy relate to metadata?

SB:     Well, of course, metadata is information about your data. So metadata can be things like labels. You can add additional identifying information. There’s a lot of things you can do in metadata and the metadata in your content can be used for a number of different things.

SB:     And so there are four principle things that I like to think of when I’m dealing with metadata. You can have metadata that helps your managers track your content development. So for instance, the current state of things, who modified something, or when it was last updated. The metadata can be used by your authors. They may need to find appropriate content. They have an assignment to go and make a modification for a product change or a new strategy or something. So they need to go find the appropriate content.

SB:     Also, as they’re creating that content, they may need to reuse particular content, they have to find the content to reuse. They may also want to create cross-references. They need to find the content to cross-reference. Your metadata can also provide production information for your output generators. So for instance, when you’re creating a book or a PDF, you might have a copyright date and an owner. The cover might have part numbers on it. You might have branding, cover images, and so on. All of this can come from your metadata.

SB:     And finally, as we’ve been using as an example many times, the metadata in your content can be used by your users to search for information. So the search turns out to be, it’s the prime example, but it’s not the only way where we have metadata. And of course, that same metadata that we’re talking about for the search, this is information that comes from a taxonomy.

SB:     So, often, this metadata grows organically. It starts out somebody who’s just creating a user manual or just creates a piece of information about something, people add to it and over time, people start adding more and more metadata to it.

SB:     The problem is, if you want to develop this metadata in an organized and thorough way, the correct starting point is actually to roll back a bit and start with your taxonomy. It’s always difficult and time consuming to go back and modify or even add metadata to existing content. So it’s much better if the metadata can be developed along with your content. The earlier you can create a taxonomy with buy-in from all your partners, the better.

GK:     Yeah, I think that is very solid advice and the way I would wrap up that advice too is just to say don’t leave taxonomy as a last resort. Make sure it’s a priority. Especially if you know you have these requirements around search, around content organization, around the way that both your content creators and your end users are going to need to find and use that information. Taxonomy needs to be a really important priority for you and you need to make sure, as we’ve talked about all along, that you have that buy-in, that you can prove that value, and that you collaborate across the organization with anyone who’s got a stake in that taxonomy to make sure that it’s going to best serve your organization’s needs.

GK:     And I think we can go ahead and wrap up there. So thank you so much for joining me, Simon.

SB:     You’re quite welcome.

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 benefits of a taxonomy (podcast, part 2) appeared first on Scriptorium.

In episode 73 of The Content Strategy Experts Podcast, Gretyl Kinsey and Simon Bate talk about the benefits of establishing a taxonomy.

“Filtering is possible through the use of taxonomies. They have a real world benefit for people looking to find something.”

—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 the benefits of establishing a taxonomy. 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 are going to be looking at taxonomy today, and talk about some of the benefits that you might encounter if you establish a taxonomy within your organization. So I think the logical first place to start is just by defining, what is a taxonomy?

SB:     That’s a great place to start. So a taxonomy is an organizing scheme that helps us make sense of stuff. Let me give a couple of examples there. One is, if you go into the library and you try and find a book, usually you’ve used something like the Dewey decimal system or the Library of Congress system. That’s an organizing scheme. Another organizing scheme that we’ve learned about in school is the way that plants and animals get placed into kingdom, genus, species, and so on. These are a couple of the most well known taxonomies. And also if you’ve shopped on Amazon, you’ve encountered taxonomies there.

GK:     Right, if you have ever used any of the tools that they have to help narrow down some of the products to what you want to buy, that’s definitely a great example. So continuing along that path, can you use multiple taxonomies simultaneously?

SB:     Yeah you can. Let’s look at the Amazon example a bit more. Assume that you’re interested in buying a shirt. There are a number of characteristics of shirts that can be used to categorize or limit your search results. Do you want a red shirt? Do you want a green shirt? Color is one of the taxonomies. What size do you want? Small, medium, large and so on. That’s another taxonomy. Do you want a long sleeve shirt? Short sleeve, sleeveless. What material do you want, cotton, silk, rayon, casual or formal? All of these things which we call facets in taxonomies can be used to narrow down the options, so you can find just the shirt that you want. If you’ve ever used a used car finder, there’s exactly that same kind of filtering is done there. And that was made popular quite a number of years ago. All this filtering is possible through the use of taxonomies. They have a real world benefit for people looking to find something.

GK:     Yeah, absolutely. And I know that’s something I think all of us have used in our day to day lives at some points, not just in maybe our careers in terms of content, but going more in that direction, how else might you use taxonomies, what else are taxonomies good for?

SB:     Well, one of them is for standardizing data. So if you think about looking for a shirt and you’re looking for a medium, there’s a whole number of different ways, actually, that a vendor might describe something as being medium. They might just use a capital M, they might use Medium with a capital M, they might use medium, all lower case, medium, all upper case, they may use size range, so size 34 to 36 or something like that. If you’re getting this data such as shirt size from multiple vendors, and each vendor has a different standard for storing the data, and you blindly pass that along, your users are going to have a ridiculous set of choices to have to define to go through to find a medium shirt. So again, that’s not very user friendly.

SB:     So by correlating all of those into a single definition of medium, your taxonomy ensures, regardless of how you receive the data, it fits into a single definition everywhere.

GK:     Can taxonomies be reused?

SB:     Yes. The same idea of sizing can also work for other things, such as other than shirts. We could use it for coats, pants, gloves, anything that has a size, we can reuse that same taxonomy with those things.

GK:     That’s really awesome. We’ve been looking at this example, started out with Amazon and went more specifically into maybe clothing that you might use these taxonomies that are built in for that. But I want to shift gears and talk about some other ways that you can use taxonomy. So how might this be something that helps on a support site?

SB:     Well, the concept of taxonomy is the same there. In a support site we want our users to be able to retrieve information so they can perform their jobs. Taxonomies help with the users being able to locate the answers to their specific questions.

SB:     So in the retail site, we talked about clothing sizes. In a support site you can use the same ideas of taxonomy to help readers narrow down product type, product name, version, and so on.

GK:     When you’ve got this kind of a taxonomy built in, how do you know that your facets are correct?

SB:     That’s a good question. The taxonomies inherently reflect the person or group that created it. Diversity is key to ensuring that any biases are surfaced. That is, you can’t just create the taxonomy by yourself. You have to work and develop your taxonomy within a group of people. And the more diverse you can make that group, the more you can be assured that your taxonomy actually is as general as it can be, that it reflects all perspectives rather than just simply your perspective. So confirmation bias, selection bias, and these can limit your perspective on the facets.

SB:     Another problem that we have with taxonomies is they do enforce a sort of top down approach. Humans naturally want to group things and then break those groups down further. How do you know the thing at the top is really at the top, and how far down do you go in subgroups? One hint that Patrick Lamb offers in his book for us is to forget our scientific traditions. Rather than trying to find a single, perfect ideal spot for an object or a piece of information and put it where it’s most likely to be found, just don’t agonize over the perfect. You just find the information.

GK:     Absolutely. And I think that that’s one area where, with some of the clients we’ve worked with, that’s where getting into things like user testing and analytics and just really acquiring the information that they need about the real world cases of how users are going to make use of those facets and how they’re going to search for information, what kinds of information they’re trying to find, and how they’re going to go about it, can really help them if they’re coming up with a taxonomy and trying to figure out what those facets need to be. If you just come up with it from the perspective of how you think it makes sense from the way you’ve designed your products or the way your marketing team wants to emphasize things in the way that they are putting out that messaging, that may not actually serve what your users need. So it’s important to try to get that information from them as much as you can, and continue to use that to make your facets better.

SB:     Absolutely.

GK:     So how are taxonomies presented to the users, what are some different examples of ways that they might come across to the user?

SB:     Well, there are several different ways that your taxonomy can be presented to the users. One way might be lists, so you might just have a simple list of items. For instance, a list of sizes or a list of product names, variety of things like that. Now the simple list, that’s the basis for where we go off into taxonomies because as soon as you get more than about 12 items or so, this gets really hard to use. If you’ve ever been on a site where you’re presented with a dropdown list that goes off the screen, it starts to get really, really hard to find the thing that you want.

SB:     A couple of examples of these symbolists might be a shopping list, or a list of animals, say. So you could just have a list of any animals, a lion, a cow, a dog, a cat, a rat, something like that.

SB:     The next way of looking at your information is with trees, or hierarchies. You divide your list into a set of related subgroups. For example, if you create a shopping list, you might want to divide your shopping list by food type. So you could have a section on your list, or a sub-list for produce, a sub-list for things you want to find in dairy, sub-list you want to find in groceries, and so on. If you’re looking at a list of animals, you might want to list them in a tree, say according to their habitat.

SB:     But of course, one problem here is that one person’s idea of how to organize these things might be different than another person’s perspective. The trees then lead us to what we call hierarchies. And hierarchy is a tree with a very strict rule about the subdivisions. The tree is exhaustive; that is, it covers everything that there is, and it is unambiguous. So for everything that you have on the list, there’s no way that it can actually exist under two different categories.

SB:     One great example of this is the standard Linnaean classification of animals, where we actually break things down into kingdom, phylum, class, order, family, genus, and species. Each one of those different divisions, and actually above kingdom, now they’ve added domain. All of these divisions actually have very specific rules about what it is that separates one from another in each of the different sub classifications.

SB:     Now, talking about these ways, we have the idea of facets, and we brought the idea of facets up before. And a facet is essentially, it’s an attribute that may represent a piece of information. The facet itself can be a list, a tree, or a hierarchy.

SB:     Now, another way that this could be presented is in a matrix, or matrices. In a matrix, actually you can have two or three facets presented in a table. Let’s take the simplest facets, which of course are lists. In a matrix, you could have a table which is two dimensional. So in the rows you could have one list represented in the columns. You actually could have another facet presented. An example of a matrix is a table in a catalog that associates a specific product number with two or more characteristics, such as capacity and operating environment. If I’m looking in my catalog, I know I need to find a piece of equipment. I know what the capacity of that piece of equipment needs to be, whether that be voltage, maximum voltage that it can handle, maximum pressure, all sorts of things. And then I also need to find that piece of equipment that works in a specific operating environment. Does it have to operate in subzero temperatures, does it have to operate in normal temperatures, does it have to work in tropical climate, anything like that. So I can use that matrix of those two different characteristics and find the specific product that I need.

SB:     And finally, a little looser than a matrix, there’s a relationship map. And a relationship map is a way you show the proximity and relationships among the different entities in your taxonomy. A relationship map could be a physical map, so it could be actually a public transport system, or the human body showing something like the lymphatic system, the nerve system, those are relationship maps. Or it can be conceptual. A conceptual relationship map is something like a mind map.

SB:     So that’s a long answer to a very, very short question.

GK:     Yeah. And I think it’s really common to see these combinations of these different ways that taxonomies are presented to users, maybe even in the same interface or the same site or what have you, kind of like we talked about earlier with the Amazon example. When you go to search, a lot of times when you have over on the left, all these different ways that you can sort the thousands of results that you get from a search, there are multiple taxonomies and ways of presenting those taxonomies at work, because you can choose things from a list, you can choose things from ranges of lists, there are all sorts of different things you can do. And so I think that, again, it gets back to what your customer base needs and how they tend to look for information about your products that you would then say, okay, which of these different ways are going to be most effective to present this taxonomy to our users? And it might be more than one. It might be a combination that you find works best.

SB:     Yep. And there’s an interesting thought here actually, that we’re talking here about all the various specific ways of taxonomies, but I think a lot of the people actually listening to this podcast are probably looking for specific solutions that usually will relate to a computer interface, such as a help system, or trying to find a specific manual or something. And I have to say that while there are all these divisions, the lists, trees, hierarchies and so on, really a lot of the time we’re going to find ourselves, for the most part, really focusing on lists primarily, and perhaps then trees and hierarchies. But really, lists are the thing, mostly because of the interface of the computer. There’s not a really effective way on a computer, just with a standard HTML interface, to be able to show somebody a tree structure. And actually within the types of things we’re talking about, there’s no real need for it either. The tree structure really works very well with animals and things. A hierarchy works very well with animals. But we really are interested in lists.

GK:     Right, and I think that’s a good place to wrap up part one of this podcast. We will be back next time with part-two.

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 benefits of a taxonomy (podcast, part 1) appeared first on Scriptorium.

In episode 72 of The Content Strategy Experts Podcast, Gretyl Kinsey and Barbara Green of ACS Technologies continue their discussion about getting started with DITA.

“We experienced far more change than I anticipated from the time Scriptorium first came in to evaluate our situation. I remember you saying, “Expect change, expect resistance to change,” but reality is the great teacher of life.”

—Barbara Green

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 of getting started with DITA and taking the next steps forward with special guest Barbara Green of ACS Technologies. This is part two of a two part podcast.

GK:     So I want to talk a little bit about we’ve kind of covered where things stand right now and what you’re about to do by year end or beginning of next year. So I want to talk a little bit about how that fits into the fifth and final phase that Scriptorium recommended, which is interconnectivity amongst not just the R&D department that produces the realm product and all of its content, but all of the other content producing departments as well, such as e-learning and marketing, and how all of them can benefit from reusing content, from having content in the CCMS or connecting to the CCMS or the portal. And I want to talk about that phase that’s on the horizon, what kinds of plans that you have in mind, and how that all fits into what you’ve already been doing for delivering personalized content to your user base.

Barbara Green:     Yeah. Well we know that even now we’re working on some features in our products that are going to increase the complexity of our variance again. One of the things that if you’d asked me three years ago if I would really be passionate about I would’ve probably said no, but I am growing quite passionate about this, and I guess in a lot of ways it’s sort of like, oh dare I dream. What I would really love to see personally is a top down corporate content strategy that carries us into the future. Here’s how we’re going to set up our taxonomy, having all content creating departments, sitting at a table and agreeing on some things around voice and tone, other types of style guides, our taxonomy, and our reuse strategy.

BG:     We’ve identified with our development staff seven problem statements based upon what we know we could have done a better job with this year or what either content didn’t understand, because it’s a learning experience. I’ve always worked with developers, but when you really get down into technical things, it’s been a learning experience for me. And I can’t say enough, ACS is just a great culture, we have a phenomenal culture. Yes, we fuss and fight amongst ourselves, but we really do have a great culture of teamwork and we like each other. I think that that’s been a huge plus in this project.

GK:     Absolutely.

BG:     Yeah. We’ve identified these things and we want to work on those with Scriptorium’s help just to sort of align ourselves on what can we expect from development resources, not just for the help, but we have other groups like e-learning with really great plans and they stood up in LMS this year and our marketing department, even our risk management department is saying, “Hey, can I use this CCMS for policies?” And of course our vendor is going, “Absolutely you can,” and we have other customers that do that.

BG:     So we have sort of a lot of interest coming from other areas, and I’m personally working with IT now, like let’s test getting content out of the CCMS into web front ends. So we want to do all these things, but we are realizing we don’t have the resources, the human resources, and some of the documented here’s how we’re going to do it, here’s how we’re going to make decisions in place. So I really would like to see us make big leaps and bounds in 2020 around those things.

BG:     And I know I’ve read lots of articles. Some people would say, “Well, you should’ve had all that in place,” and in a perfect world you should, but we didn’t. So you go with what you got, right?

GK:     Yeah. And I remember when Scriptorium first came to ACS and we talked about what are the problems that you’re facing, and this was about three years ago. One of the biggest ones that we heard over and over was that all of these different departments just work in independent silos and don’t communicate with each other. And then I remember I went and visited last year and it was a world of difference because we got a lot of different representatives from these different departments in a room together and just had a brainstorming session of how we could all collaborate. And just seeing the difference even over those couple of years was pretty incredible.

GK:     And I think it does speak to what you said about even though you’d been working in these little disconnected silos, that you do have that great corporate culture where you all like each other and get along. So I think that goes a long way. There’s not as much of an issue of that sort of tension among departments or people saying, “Oh, I don’t want to work with this person over here.” It does seem like people are excited and onboard to start moving in that direction of collaboration.

BG:     Right. I think each department here has its challenges. They also have their business goals. I want to say that I do think business drivers were the key in our case. Even though each department has their own goals, our goals are big and personalization is a key driver behind how fast we’ve moved with some of this because just providing context to the user no matter… and also just user experience. Our UX designers do a really good job of communicating and helping us all think better about the user’s experience, so no matter what door they come in to our company, we want to create the right user experience and content is so important to that. We want to sound like one company, not five.

BG:     We all desire quality. We know we have some work to get on the same page, but I’m very optimistic that we’re headed in the right way and I’m really thrilled with the interest around collaborating more with each other, maybe even setting up teams and committees around strategies, a taxonomy committee or a team, whatever we decide to call it, somebody will come up with a fancy word here and we’ll call it that.

GK:     I think that having that in place already puts you miles ahead of a lot of the other companies that we’ve seen where they try and try to put that kind of initiative in place, but it’s just really, really hard to get out of the rut of all these disconnected silos. And so I think that over this next year or so, that leveraging that excitement is really going to help that last phase come together as you want it to and really help you achieve that goal of all these different content producing departments working together and truly delivering the best user experience possible.

GK:     So where I want to go next is just talking about we’ve gone through the overall strategy and sort of how that’s played out and how it’s going to play out in the future, but I want to do a little bit of a look back and talk about lessons learned. With hindsight 20/20, if you could go back three years in time and tell yourself here are some things that I wish I had known before taking the plunge, going into DITA and changing all of these content processes, what are some of those things?

BG:     Well, back to the very beginning, we know now that we should have educated stakeholders better, just helping set expectations around timelines for things like conversions and development and making sure that various mini projects we needed to be successful were scoped accurately. We also learned as a content team we needed to collaborate with development, especially our architects. We needed to get their input early on, and I think the RFP process that we went through, we had the head of R&D and we had a developer on that team was just really one of the best things that we tried. And it just worked great because programmers can often help create the case for your business case. They see things a different way than content people do. We haven’t always done that, and even since then, even though we learned that lesson, sometimes you continue to repeat mistakes of the past. But that’s a big lesson that we learned is to collaborate with our development team.

BG:     And just to take that one step further, what I now know at the end of this year is that I need to set those development expectations. This is not a one and done. Content needs ongoing development resources, and actually one of the things that R&D is doing is standing up a content team in 2020. They’re not completely dedicated to the CCMS and the portal, but that is one of their projects. They’re also going to be supporting the LMS and a few other content initiatives. So that’s a really positive change and definitely is one of our lessons learned there, is get our devs involved.

BG:     We also learned that the unexpected is going to happen. Have a plan for regaining your focus. Know some alternative resources that you can take advantage of. We learned that lesson last year and this year I think that’s actually a lesson we learned and we did something about. We had a content issue come up with our legacy system because we still have some legacy products in the Wiki this year. I took some time and wrote up a research project that needed to be done around that and then we went to HR and said, “Hey could you find us an intern or could you make this a career development focus? Because we have a program here for that.” They weren’t able to locate a resource, but my manager was then able to find a resource that could fix our problem. So looking for those things you don’t think are resources but just thinking outside of the box, that just worked great this year for us.

BG:     For us, we have supplemented our strategy with training, and actually I think that was a Scriptorium lesson learned, if I remember correctly.

GK:     Yeah, absolutely. I wanted to touch on that a little bit, because I know that earlier you mentioned the learning curve that’s involved with something like this.

BG:     Yeah.

GK:     And I think that where that learning curve really became clear to us is that the way that we have typically done a lot of these sorts of projects where we help a company move into DITA or any other kind of structured content is that we get everything converted, we get it in the new system, and then at the end we deliver training. And what we learned at ACS is that it was, especially with this kind of a phased approach to the strategy, it really was easier on the writers and the people that had to use DITA to have training delivered in kind of smaller chunks all along. And I think we found that when after phases one and two, after we did the initial conversion and getting things working in GitHub, we did a couple of days on site where we delivered some training to all of the writers and it was just sort of a DITA 101 basics, here’s how you create DITA topics, here’s how you put them together in maps and publish them, and then here are a few basic reuse mechanisms and I think that laid the groundwork.

GK:     But the problem is that at the time it was sort of not real so to speak, because the writers really needed to see all of that in action with their content, and because that conversion had just recently occurred, it was really difficult I think to connect us just delivering basic one-on-one level training with what they actually needed to do. And so what we realized was that it was really important to supplement that with additional training that went along with each phase. So I think this was something that, like you said, Barbara, with the last piece that you talked about, that we had a lesson learned and we actually did something about it.

GK:     And we’ve learned that with ACS it makes sense to kind of get through part of a phase and then if there is anything that the content creators are a little shaky on or have questions about to just do training in smaller chunks, and I think the most recent example of that is that we had a lot of the writers and even people in some of these other departments saying, “We don’t fully understand reuse and we really need some more training in that,” and now that all the content is in place and you’re starting to set up reuse amongst that content, we were able to look at real examples, look at what ACS is doing with reuse and then deliver some more targeted focused training based on that. And we did it instead of doing one big info dump, we did several just little one hour sessions over the course of several weeks.

GK:     I think that approach makes it a little more digestible, and if you are facing a very steep learning curve, I think delivering the training in those kind of smaller pieces really, really helps make it easier for people to get over that hump. So that’s actually something that we have changed to do with other clients as well. If we are working with a team that has no DITA experience, that has no structured content experience, they’re kind of coming into it the way that the writers at ACS were where all of them had been working in a Wiki, they had never worked with anything like DITA or XML, and so it was a totally unfamiliar learning curve and we keep that in mind now where if we’re working with a team that has absolutely no background in this kind of thing, that they’re probably going to need training delivered in these smaller, more bite sized chunks, and they’re going to need it delivered all along the way instead of at one big chunk at the end.

GK:     And so that’s been a lesson learned for us is how we approach training with different teams based on the way that their DITA rollout is going and the experience that they had beforehand.

BG:     Yeah, I agree. When I first began to just outline our reuse strategy, it really hit me, “Okay, I know we’ve talked about reuse,” and I felt like I had a grasp of it but I could easily second guess myself and we found that others were doing the same thing. So I thought that was really very helpful to go back and just zero in on various reuse strategies with our examples in hand. I think that was a big win for us.

BG:     Organizations are structured very differently, but our writers are embedded on agile teams and so their bandwidth is stretched depending on the two week sprint that they have. So doing those one hour trainings was definitely a win. It was an easy commitment and it gave them time to go back and reflect and get questions ready for the following week.

GK:     Yeah, absolutely. And I think that’s really helped us have a better understanding of just really further personalizing our different training approach to different companies, and this has been a real learning experience for us on that front as well.

GK:     And then I think something else that we learned firsthand from this particular project is what to do in the face of these external unexpected changes. We talked a little bit about how there was a lot of reorganization at ACS, and obviously that was not something that had been planned at the time that we initially put our content strategy together, and that just really hit home for us how important it is to have some flexibility in your strategy and in your timelines and to be able to accommodate those kinds of changes. In some ways it can be positive. It can present challenges, but ultimately I think some of the reorganization that you went through you were able to, after one of those first big rounds of reorganization, that was when you got into not only your CCMS but your portal pretty quickly.

GK:     So in some ways it can be really helpful. Even though I think that reorganization delayed your phase where you were just working in GitHub and stretched that out for a long time, I think it ultimately led to you getting into the next two phases more quickly.

GK:     And so what Scriptorium learned from that is just the adaptability that you have to have and then also being able to support a company through those changes when it starts to affect content, being able to advise a company on how to stick to your strategy or maybe adapt it a little bit as needed in the face of all of those changes and make sure that it doesn’t just throw you completely off track.

GK:     We talk about change management and dealing with change resistance a lot in our strategies, and we usually include some advice to our clients when we deliver a strategy to them about here’s how you might deal with resistance to change or how you might approach unexpected changes. But I think this project in particular hit home to us, how adaptable you truly have to be sometimes.

BG:     Yeah, I would agree. We experienced far more change than I anticipated from the time that you first came in to evaluate our situation, that was definitely a surprise and I remember you guys saying, “Expect change, expect resistance to change,” but reality is the great teacher of life. It really hits you, you learn. But it’s definitely been a growth opportunity, and again, we’ve had some very positive outcomes. I will say, I will add too that one of the problem statements that I’ve documented with my developers is that while it was such an awesome surprise to hear that we were going to get the portal, what we now realize, and Gretyl I have to give you credit for the right words, but we sort of robbed ourselves of educating all parties on what a portal is, what it does, what the benefits are.

BG:     So as a result of that, we really didn’t… We were lacking in some technologies that need to be in place to use a portal the way it’s meant to be used. Even now with our portal set up, we’ve got a solution for year end, but we know it can’t be our final solution.

BG:     Again, I can’t stress enough the importance of walking through the discovery phase. I’ll be honest, I had never in my life written an RFP. I could have probably not even gotten started without you guys. I also had a coworker here that used to review RFPs in New York and she was a big help with advice, but it was… Just looking back, it was just such an important part of this, and I’m asked all the time what tool did you pick? I just want to take and pick a tool. And I’m like, “No. You need to [crosstalk 00:22:46]”

GK:     Yeah, exactly. And I’m really glad to hear you say that because one of the things that I know we’ve stressed this time and time again on the podcast and on our blog is that tools should be the very last thing that you choose, you should first decide, determine what your business goals are and what things are blocking you from achieving that at the moment, and then what things need to happen to get past those blocks and achieve those goals.

GK:     And then once you do that, then it’s time to say, “Okay, what are some options of tools that might fit?” And then really screen all of those very heavily. Ask as many questions as you can think of from not just a content perspective but an IT perspective, and also maybe you get into like a marketing perspective or training perspective if they might ever use that tool. Anybody that’s going to have a stake in it will have questions about how it works, how it needs to be supported, and how it’s going to support you. Get very, very specific, get very, very thorough answers and have them demonstrate everything that they say that their tools could do so that you can get a firsthand idea of how that’s going to work.

GK:     And I think that going through that vetting process as thoroughly as possible is extremely important. We’ve seen a lot of companies where what basically happened was they got pulled in by the shiny marketing aspect of a tool saying, “Hey, look at this fancy tool that can solve all your problems.” And they say, “Okay,” they buy it and they haven’t really evaluated whether it actually can solve all their problems and then they get stuck using it.

BG:     Right.

GK:     Then they come to us for help saying, “Can you create a content strategy to get us out of this one tool and into some other workflow, and this time we’ll choose it more carefully.” And so that’s why we always advise companies to make that the last thing you do and to be very, very careful. Of course, part of our strategy is that we can help do things like write those RFPs or attend the demos and point out different things that maybe the customer wouldn’t necessarily see. It’s really important to take your time during that discovery phase and really just evaluate every single angle that you can.

BG:     I agree. And it also helps you know what you’re going to need from your own company as you go about implementing. I mean, believe it or not, I think had we really worked that discovery phase with the dynamic portal, we might have had that implemented a little faster because we would have known, “Oh, we’ve got to have this piece of technology in place.” And just to reiterate, when I was writing that RFP, I pulled out a list of every department in the company, and we’re about 400 employees. We’re not real small, we’re not real huge, but I pulled out a list of every department and just mentally went down that list and said, “Is there anything about this department that if my dreams came true, this system could affect them?”

BG:     I basically sat down with almost every department in the company. Even if they weren’t directly affected, sometimes there was an indirect benefit or something that they thought of that I didn’t, and that was a very helpful discovery process for me to see… just to hear what they thought it was and how they thought they could use it. That was great. It was a great process.

GK:     Absolutely. So just, I want to wrap up with one final thing and that is if you could give one piece of advice to another company that’s in the same boat that you were in a few years ago, what would that be?

BG:     Do your discovery process. Yeah, I really think that’s high on the list, but a very, very close second, if you’ll let me say too, is really work hard at educating your stakeholders or your contributors, like development. At the end of every year, I think I worked really hard and I always see places that I overlooked, I could have done a better job in my communication. But you want to have those conversations with your design group, your developers, your stakeholders, so that you have a well rounded understanding of the business objectives from different viewpoints.

GK:     Absolutely. It’s fantastic and solid advice. So thank you so much, Barbara, for joining us on the podcast.

BG:     Well, thank you. It’s been a pleasure.

GK:     And thank you all 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 Getting started with DITA (podcast, part 2) appeared first on Scriptorium.