Scriptorium

In episode 121 of The Content Strategy Experts podcast, Alan Pringle and Bill Swallow talk about content consumers as content ops stakeholders.

“If you look up a restaurant on your phone and go to view the menu, most of the time, that menu is going to be a PDF. And you are sitting there, zooming in, scrolling around, and pinching, and trying to read this menu that really should have just been a responsive HTML page.”

– Bill Swallow

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 continue our series on content operations stakeholders, and talk about content consumers. Hello, everybody. I’m Alan Pringle.

Bill Swallow:                   And I’m Bill Swallow.

AP:                   So, far in this content operations stakeholder series, we’ve focused on really at this point, many groups. Let me think, risk management, tech support, localization, the people who manage the tech stack, executives and the IT department. And today, we’re going to focus on content consumers. But before we get away from that list that I just rattled off, I think we need to point out those people are also content consumers.

BS:                   Right.

AP:                   And I think the one that really strikes me the most is tech support being a content consumer.

BS:                   Right. Tech support, definitely. There’s a whole podcast on that topic. But yeah, they are consuming the content and repurposing and adding to that content. Other people here that are content consumers, that we’ve talked about before, certainly those who are developing products that redistribute content or remix content, or produce new content. So, developers who are working on, let’s say a chatbot feature, certainly that chatbot is a content consumer.

AP:                   Yep, it sure is. And I think what you’re going to hear more and more in this podcast, what we’ve seen is this trend where a lot of content consumers aren’t necessarily humans at first, and I think we need to account for that. And we’ll get more into that later in this conversation. I think one of the most obvious content consumer is if you work at a company that develops products and services is your end users, your customers, that’s your most obvious user base of content consumers. So, I think we need to address them upfront probably first.

BS:                   Right, because they’re the ones who have bought the product or service. So, they have the thing and they essentially need to know how to use and care for, and otherwise manage the thing that they bought. So, they need that content to help them along, whether it’s learning about the product, being able to know how to order replacement parts, if it’s mechanical, or if they need to send it in for repair, information about troubleshooting and so forth. And a lot of these people rely not so much on the content that comes in the box, which is fewer and fewer these days, but they go online to receive that content. And a lot of times they won’t think to use the vanity URL that you supplied on the box of the thing that they bought, they will rather go to Google or their search engine of choice and start searching for what they perhaps think the product name is.

AP:                   Right. And that vanity URL is on a box that is probably in a landfill or recycling facility. So, that’s one issue right there you got to think about. But bigger picture wise, you’ve got to be sure that the way you’re disseminating information to these, I’ll say first line content consumers, is actually getting to them. If your content is not at the top of search results for certain phrases that have to do with your products, you’re going to have your end users looking at third party content. I would say that is suboptimal at best.

BS:                   Mm-hmm. And I would also say that the format in which you’re producing this content is critical as well. The one thing that comes to my mind and is not directly related to technical content or what have you, but if you go online on your phone to look up a restaurant that you want to go eat at and you go to view the menu, about maybe 99 out of 100 times, that menu is going to be a PDF. And you are sitting there, zooming in and scrolling around, and pinching, and trying to read this menu that really should have just been a responsive HTML page.

AP:                   Exactly. And usually, if I am looking at a menu or looking for menus, I am hungry. And when I am hungry, I tend to get unhappy. So, hey, restaurant industry, think about your end users who are hungry, and hangry, and need to get the content in the format that they need when they want it. And like Bill said, if I’m on my phone, I want it in a quickly displayed HTML menu that I can scroll through really quickly to get to the part of the menu that I’m most interested in. And that very much applies to people with products and services, very much. Be sure that your content, first of all, is findable via the search engines and is in a format that’s usable so people can actually consume that information the way they want to.

BS:                   Right. And I would also add, make sure that it’s accessible, so that those who need some other means of consuming the content, whether it’s text to speech or some other format, that they have the ability to consume that content, that they are not left essentially stranded.

AP:                   Exactly. And I will say, as someone who now has to correct for reading vision wise, and I will just let people figure out why that may be. I can tell you, getting a PDF, for example, online on my phone is really suboptimal, because it’s much harder to deal with that than it is usually with a website that you can pinch and open up a lot more easily. So, you can’t assume that everyone’s just like you, as far as your content consumers go.

BS:                   Absolutely.

AP:                   There is another group of people who go out on the internet and research your products. And those are people who are shopping or trying to make a buying decision. And I think they very much come into play as part of this conversation.

BS:                   Definitely. And a lot of times now, more and more technical based content is being looked up prior to people making purchases. Whether they are buying a new device, whether they’re buying a car or what have you, people are scouring the internet because they don’t want to sit in endless sales meetings where they’re only being told what the company thinks that the buyer wants to hear. They want to suss out the specifications and make a rational decision or an informed decision.

AP:                   Absolutely. I know I have seen, and I’ve had clients do this in recent meetings, say, “Well, our competition or a place where I used to work before I came here, which is often the competition, us doing it this way, we need to do it this way, in regard to how content is being distributed and consumed.”

BS:                   And yeah. I had a conversation with a client that not so much pulled up the competition, but they pulled up examples of other people’s documentation, just to say, I like this aspect about how they presented the information here. And then they’d pull up another company’s documentation say, but I also like what they did here, and can we somehow marry the two?

AP:                   Yep. Yeah. So, it’s not just shoppers and end users, it may be the people who were trying to steal your business who are looking at your stuff. So, that’s something to definitely keep in mind. One other, I think less obvious content consumer is government agencies, because there are a lot of people who are in regulated industries and the way that you distribute your content for consumption is highly regulated. And there’s certain rules about how it has to look, how the wording is supposed to be, and all that stuff. In a lot of cases, there are reviews. Your content is reviewed to be sure that it meets whatever standard that is. So, the government can be a consumer of your content, not necessarily to read it to use your product, but to be sure you can sell your product, which is probably, ultimately super important that you adhere to those regulations in the way that you talk to end users through your content.

BS:                   And in addition to those, there are also trade regulations, which means that you have to be able to show proof that you have content in the particular language for a particular country or a locale that you’re distributing your product. And I cannot tell you the number of times I’ve heard stories about product being left in shipping containers at the docks, because the company was scrambling to get the localizations required in order for them to get the green light to sell product in that market.

AP:                   Yeah. And again, is this regulatory agency, are these customs people really looking to read the content to use your product? Not really, but guess what? It’s just as important as if they were, because you can’t even sell your product if these conditions are not met. So, they’re consumers, not in the traditional way, but they’re absolutely consumers of your content.

BS:                   Yeah. And actually, I’d say they’re probably even more gatekeepers, because as Alan mentioned, I mean, they don’t care about what’s written on the page, but they care that it’s there because they are trying to protect the consumers in their country and make sure that their people get what they expect from a product.

AP:                   Yep, absolutely. And I think we also now need to talk about how the different kinds of content that are out there are blurring. I think we’ve seen really a trend where it used to have this very interdepartmental view of things. These are the people who are creating your user guide content. These are the people who are creating your marketing content. These are the people who are creating your learning content. And there were these very firm rigid silos in there. But with the blurring of those things, I think that also very much ties into the content consumers. Because at the end of the day, when you need to find a bit of information that you need, I don’t think you care where it comes from, from the company who’s providing that information.

BS:                   Right. There’s no expectation from a person to say, “I really need to go in and I really need to read the content that their technical documentation staff has put together.” They just go in there and say, “I need to know how to configure this new phone I got in the mail. And all it came with was a slip of paper and the URL that is on it got smudged. So, I don’t know where to go.” Something like that. And there is that blurring of the line because you have actual users and you have shoppers and decision makers, and other people all searching for your content, whether you like it or not. You never know, is this person a long time customer who just misplaced their bookmark or what have you?

BS:                   Is this person a brand new customer who is interested in our product? Is this person a competitor? How much information should we supply without a login? That type of thing. So, there is that blurring of the line, but since you never really know who’s going to stumble across your content, (that’s for lack of a better term) out in the wild, you need to make sure that it does have a bit of everything in it. That it has the tone and structure that your marketing team believes works with your market, but it also needs to contain the correct technical information that people may be looking for.

AP:                   And not only does it need to be correct, it needs to be consistent. You can’t have a situation where, say part of the website says that specification for product X is this, yet a marketing slick somebody picked up at a trade show. And yes, they still happen, believe it or not, says something completely different. That kind of contradictory information is really a huge problem. Because first of all, you’re going to probably have that customer or potential customer call and clog up your tech support asking, which is it? And you’re also setting a really bad example. And those people may go to use another company because they can’t get consistent, easily verifiable information from you.

BS:                   Right. They’re certainly not going to waste their time if they cannot find the information, that is pretty much clear. People really are making buying decisions, essentially content first. If they can’t learn about your product, if they can’t get the information that they deem important to themselves to make a buying decision, but your competitor is providing that information, it’s a no brainer. People are going to go with the people who are being transparent about their product.

AP:                   Yeah. And you’ve also got to think about how certain people like to consume different flavors or delivery formats of content. I for one would prefer to read something. I know people who prefer to see a video. I am not that person, I’m going to assure you that, who will instead go to YouTube. And a lot of places have YouTube channels that are corporate YouTube channels for those kinds of people. So, you’re hitting all of the different delivery targets and essentially providing that same information in these different formats to meet a particular user’s or end user or buyer, to meet their personal preferences. And there are a whole lot of delivery formats out there now.

BS:                   There certainly are. I mean, just from a human content consumer point of view, there is of course the ever present PDF online or what have you, that can also be printed. There’s the HTML, so whether it’s on a website, in a help system, in a knowledge base, or wherever you’re publishing your content, there’s the online factor. And then of course, you do have audio, so this podcast, which we also provide a transcript. So, here we are providing two different formats here. I will say that my personal opinion, when I go looking for information and I need that extra help to figure something out, so fixing one of my lawn tools seems to be the task this year.

BS:                   So, I look up the manual, I don’t find the information there. I search for how tos. I may get some information, but ultimately I do land on YouTube. And honestly, from my own point of view, I look for the shortest video possible that seems targeted toward my particular need, because the last thing I want to do is click through to a video that is an hour long on something, when I only need 15 seconds of information.

AP:                   Exactly. And really, I mean, to each their own. And people who deliver and share content have to remember that, that not everybody is going to want to consume information in the same way. And in some cases, as you were saying earlier, that content needs to be accessible because you cannot assume that everyone can reach that information like you can. So, you have to account for that. And at the core of this, with this exponential growth in the different kinds of ways that you can deliver things now, I still think it’s fair to say that this digital content transformation we’ve been going through the past few years is really far from over at this point. I guarantee you, there are formats for delivery we have not even thought about yet at this point. And I’m thinking more of a lot of this virtual reality stuff in particular, that people are just starting to poke at.

BS:                   And I will note that over the past few years, JSON has really grown in popularity as an output format or a delivery format for content, because that content is going into other devices. It’s being loaded into other systems and used in many different ways. So, it’s no longer just the classic PDF and HTML. I mean, it’s going out into a variety of different formats.

AP:                   And this comes back to what we said earlier, your primary consumer sometimes at first may not be a human being. It may be another system that has to decipher and render and combine information to then provide some kind of dynamic, customized experience for your end user or shopper or buyer or whomever.

BS:                   Yeah. And as those systems become more and more robust, I think we’re going to see a lot more happening with another buzzword that’s been hitting the market lately with Content as a Service.

AP:                   Yes, exactly. I do think this is where everything is headed, and I guess we need to go ahead and define that very quickly, what Content as a Service is. We will put some links in the show notes to give you some resources on Content as a Service, or CaaS as people call it. CaaS is basically, instead of a push model where you’re pushing content out to your end user, it’s more of pulling it from multiple sources, combining it, and then serving it up to your customer in some kind of format that’s usually a little more personalized and dynamic than, say your standard webpage, for example. And Bill, you can tack onto that barely adequate definition that I just offered.

BS:                   Well, no, definitely the pull is correct. And it’s also a pull from the consumer side, because the consumer is not receiving information, they are taking it.

AP:                   Exactly. That’s a very valid point. I think this comes down to where people can, for example, specify the product that they have or they want to buy, and then immediately get feedback on the particular features that they’re interested in. And a good example of this that I can think of, if you have got people who want to fix whatever product that they’ve bought from you, and you have numbers about where inventory for parts are available across the globe, wouldn’t it be helpful to present to a person who wants to fix something? This is how you fix it. And if you need to buy these parts, guess what? This place has these parts and this many left. So, there’s inventory there for you to go get. That’s the kind of thing that I see CaaS really trying to accomplish. And I think we’ve also got something, we’ve got a client in particular who has done some really interesting things with CaaS, but it’s, I think even more critically important, because we’re dealing with medical charts and cancer. Why don’t you talk about that a little bit?

BS:                   Yeah. So, there’s a American Joint Committee on Cancer, they publish a cancer staging manual, which basically, it’s something you never want to read because it will haunt you for the rest of your days. But essentially, it is every single type of cancer and how it can manifest and what to expect and how to identify it in each and every stage. So, a lot of that information is now digitized so that they are able to inject it right into active medical charts. So, no longer are medical professionals going through a heavy tome and trying to decipher which type of cancer might be there, might be a candidate for further study. But they also are able to pull in all the specifics. Once a person gets diagnosed, they have all that information at their fingertips and can just inject it right into the chart. So, we’re not dealing with any kind of missed transcriptions and so forth.

AP:                   And outdated print editions. You’re getting the latest information, some of which is experimental or you can get that kind of cutting edge, bleeding edge information, and it’s combined altogether with a medical chart. That’s pretty important, I think.

BS:                   Definitely.

AP:                   And I think this is probably a good place to end. So, Bill, thank you.

BS:                   Thank you.

AP:                   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 ops stakeholders: Content consumers (podcast) appeared first on Scriptorium.

In episode 120 of The Content Strategy Experts podcast, Gretyl Kinsey and Sarah O’Keefe discuss content ops stakeholders in risk management.

“Your regulatory environment for a single product could actually be different depending on where you’re selling it. You have to do things a certain way in Europe. You have to do things a certain way in the US.”

– Sarah O’Keefe

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 series on content stakeholders. This time focusing on risk management. Hello, and welcome everyone. I’m Gretyl Kinsey.

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

GK:                   And we’re going to be talking about risk management as part of the content stakeholder group. So my first question to you is what is risk management and what role does it play at an organization?

SO:                   Well, I hate to say risk management is responsible for managing risk, but the risk management group typically is a legal adjacent group of some sort, and their responsibility is to figure out how to enable the company to avoid, let’s say unnecessary problems. When we’re talking about risk and risk management, usually we’re talking about products that are inherently dangerous if they are used incorrectly. So a medical device is a really good example, right? You can save a lot of lives using a medical device correctly, but if you use it incorrectly, some really bad stuff can happen. There are machines that have pinch points, or that you don’t want to stick your hand in certain places, or they use certain kinds of chemicals that are potentially dangerous. So what we’re typically talking about here is working on products that have health and safety implications, and because they have health and safety implications, there’s potentially product liability, or there are regulatory concerns, which is sort of a different aspect of the same thing.

SO:                   So if I don’t document my medical device properly, the regulatory authorities may come along and tell me I’m no longer allowed to sell that medical device, which from my point of view, as the maker is very, very bad. And or if I don’t provide the right information about the device or even design it properly, there could be people that get hurt. So there’s that risk, which obviously we don’t want people to get hurt. And additionally, from the company’s point of view, there are potentially financial implications if somebody gets hurt and then sues the company for not providing the right instructions or providing a poorly designed product.

GK:                   Yeah. So clearly risk management is one of the most, if not the most important stakeholders at your organization. And that’s why I wanted to talk about that. Because I do think that gets swept under the rug or forgotten about when it comes to content. So I wanted to talk a little bit more about how risk management relates specifically to the content. And I think you already started to go there a little bit by talking about how there are sometimes legal and regulatory requirements around what information has to be included in your product documentation, especially when it is a product that carries high risk.

SO:                   Right. So most of the people I think listening to this podcast, if you have risk management as a stakeholder, you probably know about it. It’s pretty unlikely that you’re operating in a company somewhere that has safety concerns and you’re not aware of it. If you make software, particularly if you make things like video games, then probably you have fewer concerns in risk management, but even there, if you think about video games, very often, there’s a notice at the very beginning that talks about flashing lights and the risk of seizure for people that are photosensitive. Or you might get, there’s apparently an infamous warning of some sort having to do with video controllers and people mashing it in certain ways and getting terrible blisters on their hands. So your risk is of course more limited if you’re doing software because you don’t have probably scary chemicals or you’re not dealing with medical devices that get maybe implanted in people’s bodies.

SO:                   However, so if you have a risk management concern because of your product, you probably know about it. And then it comes down to an interesting question of perhaps regulatory. So again, I’m saying medical devices a lot. Medical devices, pharmaceuticals, drugs are regulated. You have to meet certain standards for them. Those standards are different from one country or one region to the other. So that’s a concern.

SO:                   When we talk about machinery, it gets very interesting because in the US machinery for the most part is not really regulated. It’s more, you better do this properly or somebody’s going to get hurt, and then they will sue you. So the concern is legal exposure due to a product liability suit of some sort. In Europe, generally, or in the European Union, we have things like the machinery directive, which require you to do certain things with your documentation. Your regulatory environment for a single product could actually be different depending on where you’re selling it. You have to do things a certain way in Europe. You have to do things a certain way in the US. And interestingly, when you start thinking about global content strategy, very often, one of the things you want to do is try and find a way to put all of that together in a way that meets all of your regulatory requirements.

GK:                   Yeah. And one area that I’ve seen in terms of software, where there can sometimes be differences from one region or one country to another is with data security. And that’s one area that it maybe doesn’t have the same level of risk of injury or harm that you might see with medical devices or heavy equipment or chemicals. But it’s something that a lot of people have concerns about. So if you’re a software company and you are collecting people’s data as part of the way they use your software, if it may be part of the way that you’re delivering it to them, if you are delivering a lot of personalized content and they have a profile that you are managing their data, then there can be regulations around how that data has to be kept secure, how you’re allowed to use it, how you’re allowed to share it or not share it.

GK:                   And those requirements can be different depending on region as well. So if you’re a global company and you work in software, that might be one of the areas that you have to think about. Maybe it’s not so much about how you’re documenting that safety information, but it’s how you’re handling the way that people are accessing your content if there is a data security concern.

SO:                   Yeah. That’s a really good point. And so there’s that sort of internal issue of what are we capturing about our software users and what are the legal implications of that, especially in again, Europe and California, which sort of begs the question of how do you know whether somebody’s in Europe or California in the first place. And then additionally, the type of product that you’re making, if you make a software product that collects your customers, customers data, right? So then you’re going to have to provide some information about how to manage these issues, the data security issues downstream. So if I’m a software vendor and I make a CRM, a customer relationship management system, then by definition, I’m collecting lots of data about people. And you need to make sure as the product designer and the content creator that your best practices can form, or at least you tell your end users, right, the people typing into the CRM, these are the implications of all this data you’re collecting.

GK:                   Absolutely. And I want to use that to segue into something that I have seen both with software and other types of companies, which is that your risk management group may actually create their own content around those exact types of things. So I wanted to get into some examples of the types of information that they may produce alongside of just the regular product documentation. So I’ve typically seen a lot of internal facing content come out of risk management departments. You might see things like guidelines, frequently asked questions, things like that around your safety information, your legal documentation requirements, so that people who are writing your content and documenting your products know what’s required, what has to go in there and how to make sure it’s consistent.

GK:                   You might see things like instructions or training materials for the risk management team, so that as they onboard new people, everybody is aware of all of the requirements. I’ve also seen some risk management departments be the ones in charge of creating the contracts that the company uses. And if there are again security concerns there, making sure that that’s included in those contracts. So all of that internal facing content is something that might be under the responsibility of your risk management department.

SO:                   Yeah. And I think additional to that, you see risk management very much involved again with products that are possibly hazardous, they will be involved with safety messages, those messages that say things like this content is under pressure so do these kinds of things, or always make sure that the second thing is set before you undo the first thing. Or make sure that the power is turned off so that nobody gets electrocuted when they go in and do whatever it is they’re trying to do. Another thing I’ve seen in addition to all the scenarios you’re describing, it’s not common, but the risk management team sometimes will be responsible for actually reading and reviewing the external facing content to make sure that there’s nothing in there that is potentially problematic. So they’re reviewing maybe from a compliance point of view, maybe from a legal exposure point of view, they want to make sure that the product documentation doesn’t over promise.

GK:                   Yeah. And I’ve definitely seen risk management departments catch things as part of that review that should not have necessarily been customer facing. So I think that’s a really important piece to include. If you are an organization that has a review process, make sure that your risk management group is a part of that so that nothing like that falls through the cracks.

SO:                   Right. And so then if we turn our attention to the content creation process and thinking about safety and legal information, which then results in risk management or risk reduction, what are some of the things that you see there? What kinds of content, techniques do we have that can help us with this?

GK:                   Well, one thing that I think it’s really important to ensure is that all of this safety information, legal information, anything that has to be there for compliance is consistent across the entire enterprise. And I think it’s really important to put some systems and tools in place that can make sure that happens, because if you have duplicated safety warnings and you have this information not being maintained in the same place, and then it gets out of date and you’ve got inaccurate and inconsistent pieces of information floating around, you’ve got some conflicting safety warnings floating around, that can lead to some real harm for the people who are using your products. And then that can get your company into legal trouble as we talked about earlier. So one thing that we always like to encourage people to do is have a single source of truth for your safety information.

GK:                   Typically, when people talk about content reuse, talk about content single-sourcing, safety information, legal information, regulatory requirements is the starting point for most people because that’s the information that it is the most important to have consistent. And one thing that can really help with that is getting into a structured content ecosystem. Something that can facilitate that type of reuse that can allow you to write an important safety warning one time, and then have it be reused across all of the documents where it needs to appear, have it update automatically any time that safety warning needs to change, because we’ve seen some situations where a company would have hundreds of separate copies of the same safety warning, and how do you keep up with all of that and make sure it’s accurate. You really can’t. So single-sourcing and reusing your safety information is a really big and important way to make sure that it’s accurate every time it gets published and distributed to your end users.

SO:                   Right. And then adding to that, you want all those safety warnings to be consistent when you translate, which,

GK:                   Yes.

SO:                   You’re going to take that one that you refactor, that’s the contents under pressure warning, and you’re going to translate it one time. So that then in your localized content, that warning will appear consistently as well. We’ve had some infamous cases where our customers looked at translations and were upset because the translations weren’t consistent, why’d they use three different words here. And then you go back and look at the English, the source, and it was inconsistent in the English. So it’s not too surprising that the translated version wasn’t consistent. So if you can get that source content refactored and cleaned up and aligned, then you can turn your attention to the localization and that downstream process to make sure that stuff gets cleaned up.

GK:                   Definitely. So if your organization has limited resources for content development, how can they ensure that the risk management requirements for the content are met?

SO:                   Well, I would say that this is not the most interesting content necessarily, but it’s really important, right? Because again, if you don’t get this right, your company could face some crushing legal liabilities, or even be blocked from selling a particular product. So that is a high priority kind of item. Do this or we are out of business. So from that point of view, it tends to be a pretty easy sell into the organization. And there’s a huge payoff, because as you said, when you have hundreds of copies of a single warning, which should be consistent and mostly it is, but not quite, there’s just a huge payoff to getting that thing reviewed, approved, made consistent one time. So the risk management team goes over it and says, okay, this is the language we want you to use. Great. Now we stash it in our content warehouse and we use it everywhere.

SO:                   And I, as a content creator, don’t have to worry too much. I just have to make sure that I use that approved set of warnings and cautions in my content consistently. And I don’t have to think about it anymore. I can go think more carefully about how I’m going to write that procedure or how I’m going to write that contextual information. And the safety warnings become essentially an asset that I have available to me, right?

GK:                   Yeah, exactly. And if that doesn’t convince your executives, if you show them, here’s how much cost and time we’re going to save on people writing and maintaining these multiple copies, translating these multiple copies. If we get it down to one, we’re going to save this much time and cost. If that’s not enough to convince your management to prioritize all of this risk management type of content, then another thing that might help is just providing some data around these safety related lawsuits. Here’s how much you stand to lose if this information gets us in trouble because it’s not reusable and not consistent.

SO:                   Yeah. I mean, you visualize a warning that says, stay back two meters and then you have the same warning, except it says, stay back three meters from whatever the thing is. Now, should it be two meters or three meters? I don’t know. But the main point is that you don’t want to give them two different numbers, right, for,

GK:                   Exactly.

SO:                   The same warning. You have to be consistent because otherwise somebody’s going to stand at two meters, get injured and sue, or they’ll be too far away. And so you have to get it right. I will say within that, as you said, the structured content gives you some opportunities to automate a lot of this stuff. So that from a content creation point of view, we can just do what we need to and move on. There’s a lot of value associated with getting the risk management, getting the safety content right. But it’s, and it’s bad to get it wrong, but it’s dreary. It’s just so not interesting. So what we want to do, I think is automate it as much as possible because then it’s going to be more correct, which is helpful. And also I’m going to spend less time on it as a writer, which is helpful because I don’t want to rewrite the warnings about high pressure and things getting under your skin and chemical exposure and whatever else it may be. I just want to know that they’re right.

GK:                   Exactly. So, is there any other advice that you would offer around risk management content for companies who are thinking about this for the first time, or maybe have a new regulatory requirement that they’re up against?

SO:                   Yeah, I think I would start with the question of what is your exposure, right? If you make heavy machinery, your exposure is significant. If you make video games, right, your exposure is probably less significant with the exception of some of these photosensitive issues. If you make mobile games that go on your phone, that seems pretty minimal except for don’t play while you’re driving.

SO:                   So you want to kind of look at your product and your product’s profile in terms of what the risks are, what the safety issues are. And then you want to look at where you’re selling your product because the regulatory compliance and legal issues are different in every region. So that’s something to worry about. And I think you probably have a risk management team or legal counsel somewhere in your organization, and it’s probably worth talking to them about this because they’re the experts and they’re again, a stakeholder in your content. And we want to make sure that this particular aspect is taken care of because the implications of getting it wrong can be really, really significant both to your customers in terms of them getting hurt or injured or worse and to the company.

GK:                   Well, thank you so much, Sarah, for this fantastic discussion.

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 Content ops stakeholders: Risk management (podcast) appeared first on Scriptorium.

In episode 119 of The Content Strategy Experts podcast, Elizabeth Patterson and Bob Johnson of Tahzoo discuss accessibility when authoring DITA content.

“By its very nature, DITA being strongly structured facilitates more accessible content.”

– Bob Johnson

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’ll talk with Bob Johnson of Tahzoo about authoring for accessibility in DITA. Hi, I’m Elizabeth Patterson. Bob, welcome.

Bob Johnson:                    Thank you. Glad to be here.

EP:                   So I think before we dive into our podcast, if you just want to give a brief intro, little bit about who you are, that would be great.

BJ:                    Sure. Currently, I am senior content strategist at Tahzoo. We are a company that specializes in customer experience, user experience, and using structured content to facilitate that. I have been a technical writer for almost 25 years now. I’ve been working with structured content and component content since 2000. I’ve been working with DITA since about 2006. And I’ve been working with accessibility since around 2008. I did some work for Oracle on implementing accessibility in one of the acquisitions about 10 years ago, and began digging into accessibility in DITA. And I’ve presented at a number of conferences and other venues on the subject of implementing accessibility in DITA and why you should implement accessible content.

EP:                   Well, great. Well, we are really looking forward to hearing some of your perspectives today. And we’ve really broken this podcast out into some different sections. But to kind of get things going, how can your designs, so PDF, print books, Web UIs, etc., How can those be made more accessible?

BJ:                    Yeah, that’s a good question. The foundation for whatever your deliverable format is, is the web content accessibility guidelines or WCAG, which is promulgated by the web accessibility initiative of the World Wide Web Consortium. And WCAG outlines what you need to do to make your content accessible. The current version is version 2.0, 2.1, and 2.2, which are cumulative, so 2.1 builds on 2.0. And 2.2 builds on 2.0 and 2.1. The later versions don’t supersede, they simply add more information. The foundation for the web content accessibility guidelines is a set of four principles, using the acronym POUR, P-O-U-R. Content has to be perceivable. You have to be able to get it from the screen into the user’s head. It has to be operable. The user has to be able to jump around, enter data, actually use whatever content is online. It has to be understandable. The user, once it is in their head, has to be able to decipher it and make sense of it.

BJ:                    And then the content must be robust. So if there’s a failure, there’s a fallback, so that the accessible content is still perceivable, operable, understandable to the user. And this is actually not just a backwards compatibility requirement. It’s a forward compatibility requirement. So content has to be compatible with future technologies, not just with current technologies.

EP:                   Right. That makes sense. So I think I want to dive into talking a little bit about structuring DITA content for accessibility. So how does the modular nature of DITA content help make it more accessible?

BJ:                    Well, as we all know, DITA’s a very structured format. And accessibility tools or user assistance tools really rely on that structure, so a screen reader for example, reads what’s called the document object model, which represents the structure of the document, and it uses that to navigate or to help the user navigate through the content. So by its very nature, DITA being strongly structured facilitates more accessible content.

EP:                   What are some challenges for accessibility when it comes to links? How can you optimize your approach for linking and managing related content for accessibility?

BJ:                    Yeah. Links can be troublesome in a couple of ways. One of the more fundamental ways is when the link text is either not very meaningful, or it’s repetitive. So I’m sure we’ve all seen websites that say something like, “Click here for this,” and the click here is the hot text. Screen readers, for example, have the ability to navigate from link to link. And if you’re just going from click here, to click here, to click here, that’s not very meaningful. The user doesn’t know. Where’s that link going to go? So you want to be sure that your link text is meaningful. So you want to know either the title of the resource you’re going to link to, or you want a meaningful text that communicates to the reader where they’re going to go, so they understand if they activate the link where they’re going to go.

BJ:                    The other challenge that links create is if they’re inline. Now I’m sure we all have seen a lot of pages with inline links, and it seems very natural. I mean, we’ve seen inline links from the very beginning of the world wide web. But inline links can be very disruptive for users on screen readers when the screen reader encounters the link. It stops and announces, here’s a link, and then reads out the link and then the target for the link. For a user with a cognitive disability like ADD or executive function, those inline links can be very distracting. So when someone encounters a link and clicks on it, they may lose where they are. And it can be very easy in a browser to lose your way back to where you started.

BJ:                    So it’s good practice to pull your links out of the running text, so they’re no longer inline, and organize them in groups, usually after the text so that the user’s reading flow or narrative flow is not interrupted. And then they can go directly to the links. And this is something I’m challenged on frequently because inline links just seem very natural. And I have to admit it took me a while to come around because it seemed natural to me. And what really changed my mind more than working with other accessibility experts was my own children with their own cognitive disabilities encountering problems caused by inline links. And that was the point where it became very real to me. And so I do have an understanding of why it seems unnatural. But I also have an understanding of why you want to do it.

EP:                   And I know in addition to links, that tables can also be difficult for accessibility sometimes. Is there a way you can structure your tables to make them easier to navigate?

BJ:                    So two things, one, you want to keep your structures standard and you want to keep your structures regular and consistent. And what do I mean by that? You really don’t want to merge cells in your table because it makes navigation inconsistent. When you’re navigating through the table, and if you’re on a screen reader, for example, or if you’re a user with a motor disability, and you need to use the keyboard to navigate rather than the mouse, when you tab into a merged cell, the browser really doesn’t remember where it came from. And so when you tab out of that cell, you can lose context. What typically happens is the browser defaults to the first row or column in that merged cell. And then when you tab out, you go there, which you continue on in that first column or first row, which may not be where you came from.

BJ:                    You also want to be careful because table designs that look meaningful may be difficult to build a mental model. It’s important for people on screen readers particularly to remember that they’re not viewing the table. They’re building a mental model of that table. And you need a very well structured, regularly structured, consistently structured table to help them build that mental model.

EP:                   Okay. That’s great information. So in addition to kind of going off of the tables, I want to talk a little bit about objects and resources that you include in DITA content, and how to make that accessible. So for example, what is needed to make images accessible? Are there any particular challenges around images with text, like callouts?

BJ:                    Well, let’s start with images in general because one of the first things people think about when they start thinking about accessibility is, oh, we need to add alt text to our images, and that’s very accurate, in fact. But alt text needs to be meaningful, so it’s not useful to, for example, repeat the file name as your alt text. You want to have alt text that explains what it is that the image is depicting. So this is a screenshot of the default whiffle jangle dialogue with standard configuration, so that users on a screen reader or other low vision users understand what the image actually is.

BJ:                    If you have a complex image, it is acceptable for the alt text to say, “The image is described in more detail in the running text,” and to indicate if it’s running text before or after the image. When it comes to call outs, we have to remember that low vision users probably are not able to perceive the details within the image, so callouts, you probably want to use a table to index to the call out IDs. But even those in the image are probably not accessible to a low vision user. So you want to be sure that your alt text clarifies that. You have a table that is indexing that callout text to the index numbers in the image.

EP:                   And what about audio and video?

BJ:                    So under the 21st Century Video Accessibility Act, organizations over a certain size, and it’s a surprisingly small size, it’s 50 employees, are required to provide transcriptions or closed captioning for streaming audio and video. What you can do leverage that using your DITA content is to build that transcript from the DITA content customizing a map that actually is attached to your streaming audio or streaming video that describes what is being said in the audio.

EP:                   So I want to take a minute to talk about localization considerations. Are there any interactions or connections between accessibility and localized content?

BJ:                    There are, particularly tying into that principle of being understandable. You want to be sure that the language of your text is called out so that if you’ve got a user on a screen reader, for example, it’s read out in the correct language. So for example, if you have the strings C-H-A-T, you want to specify that my language is US English, so the screen reader pronounces it as chat, as in a small conversation like we’re having right now, as opposed to if it’s in French, it pronounces it in French as the word for a small feline. So making sure that your language is specified in your content, and if you have strings not just … You don’t just specify at the topic level, but if you have strings within the content that are in a different language, you want to be sure that language is specified as well, so the screen reader can read that and call out the content correctly.

EP:                   Great. Well, I think this has been very useful. And I think that is a great place to wrap up, so thank you so much for joining us, Bob.

BJ:                    Thank you for having me. Glad to help.

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 Accessibility when authoring DITA content appeared first on Scriptorium.

In episode 118 of The Content Strategy Experts podcast, Bill Swallow and Sarah O’Keefe discuss content ops stakeholders in tech support.

“If you are delivering multi-hundred page PDFs to your tech support people, then I can assure you that your tech support people hate you. Opening a 600 page document and then having to search through it while you’re on the phone under all this pressure is not the experience that you want.”

– Sarah O’Keefe

Related links:

Twitter handles:

Transcript:

Bill Swallow:              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 series on content ops stakeholders, this time focusing on technical support and field service. Hey everyone, I’m Bill Swallow, and I’m here with Sarah O’Keefe.

Sarah O’Keefe:              Hey, everybody.

BS:              And this episode is part of an occasional series we’re doing on content ops stakeholders. You can find other episodes on scriptorium.com or wherever you get your podcasts. We’ve previously discussed a few different stakeholders, including IT executives and developers. This time we’re focusing on technical support. So Sarah, how does tech support fit into content ops?

SO:              Tech support is interesting because they perhaps uniquely tend to be both content contributors at times, and also content consumers. So when we say technical support, we’re talking about the frontline people that pick up the phone or answer the chat when you call with a problem and/or in a hardware world, it might be a field service technician or a field technician, people who go out and actually fix hardware, fix machinery. So on the content consumer side, the phone rings or the service tech gets a work order and they have to fix a thing. They have to do some problem solving and fix a thing.

SO:              And in that scenario, they are content consumers. The customer calls up and says, “My thing is broken. I hate you. What is going on?” And it’s the tech support person’s job to figure out as quickly as possible what the problem is and give the customer some answers, remembering that at the point when they call, they are probably upset and angry because their product isn’t working for them.

SO:              So tech support is not just a content consumer, but very much kind of a frontline emergency, kind of first responder content consumer. On the other side of things, tech support also tends to be a content contributor because I pick up the phone, I deal with some weird problem that involves an edge case of, “Oh, they have an older version of our software and they have a weird version of Linux and they have an audio driver. And those three things together contributed to some very bizarre problem bug that we’ve never seen before.” So when something like that happens, tech support will go in and document it. “I saw this configuration, I had this combination of things and we eventually figured out that if you uninstall and reinstall the audio driver, it will work.”

SO:              So they create a case or a knowledge base article that says, “Hey, if you have this configuration or this combination of circumstances, you may also run into this problem.” And so in that case, they are content contributors after, I guess, being an attempted content consumer and discovering that particular case was not yet documented in their content universe.

BS:              Right. So given that they’re both a contributor and a consumer, I’m assuming we do have and pretty much every tech support group out there has a knowledge base that they rely on. How does that kind of feed into things?

SO:              So in theory, the knowledge base is full of these weird combinations or these weird edge cases. This is something that it’s not, “Here’s how to log into the database.” But rather, “If your login fails and you have these 16 other conditions, you might see this problem or this might be the root cause, or this is how to solve the problem.” So it’s kind of like, “Here’s a problem and here’s how to solve that particular problem.” That’s related to, but not the same as the core product documentation, which tends to be more like, “Hey, hi, type in your name and type in your password. And oh, by the way, every 90 days you’ll be told to update your password.” That’s kind of the context of what you’re going to see in the docs probably.

SO:              So the knowledge base tends to be very, very specific and situational. The problem with saying that is that’s all true in theory, but in practice, a lot of the core user instructions tend to creep into the knowledge base because as you’re answering these calls and documenting what you’re finding, you’re probably going to capture information that either is all already in the user docs so you’re duplicating, you just didn’t find it, or should be in the user docs. It’s not there, but it should have been.

BS:              Right. So in that case, you have a nice blend of documentation that resonates or I should say amplifies what’s in the core documentation set and then another complete set of information that completely contradicts what was written in the first place.

SO:              Yeah, I mean, it’s really kind of a mess, because what you really want is for the knowledge base to be the quick look up, and we want to have some sort of a loop back to the user docs so that the user docs can be updated with this new information that’s being uncovered in tech support. So essentially tech support would be to a certain extent stress testing the accuracy of the docs and finding mistakes and reporting those, but they’re also finding edge cases and then you have to make a decision as to whether that edge case belongs in the core docs or not.

SO:              We have seen a number of places where the knowledge base was duplicative. It just explicitly duplicated what was in the user docs. And then it was worse than that because it actually contradicted them, typically because the tech support content was more accurate than the user docs, because it’s based on bitter experience. And so they contradict each other. And now what do you do not to mention the fact that you have two copy or two sets of your content that both document how to log in, but do it in different ways?

BS:              Right. So they have this whole set of content that the consumer has. So this way of course they can point people to, “Oh, look at page six of this particular guide and you can see where the instruction is to do the thing you’re asking about.” How else are they really seen as content consumers?

SO:              The tech support team or the field services people are going to use what’s in the user docs to provide support. So they will look up the information that they need, or they will search for the information that they need and hope that it turns up in either the user docs or the product content. And getting those kind of into alignment can be a really big problem. Typically, if you’re, again, frontline tech support, you’re answering the phone, your number one priority is speed of search, the ability to find something very quickly, because probably there’s somebody on the phone kind of yelling at you and that’s not the most fun thing.

SO:              So they tend to push back on content formats or delivery points that are not fast. And what I mean by that is if you are user docs and you are delivering multi-hundred page PDFs to your tech support people, then I can assure you that your tech support people hate you. Opening a 600 page doc or even keeping a 600 page PDF open just on general principle, but then having to search through it while you’re on the phone under all this pressure is not the experience that you want.

SO:              So what tech support needs as a consumer is a fast search that gets them to the place they need to be as fast as possible. And then secondly, and we can argue over whether it’s more important or less important, but secondly and also critically, they need accurate information, accurate up to date information that they can get to quickly. If any of those things fail, then they basically can’t do their job or at least can’t do their job with the user docs.

BS:              Or at least not efficiently anyway, because they’re spending all their time looking up the info.

SO:              Right. And getting yelled at, which is suboptimal.

BS:              So we’ve been talking a lot about tech support for software, but what about people like field technicians or service engineers?

SO:              Right. So here we’re talking about somebody who goes out into the field, which is to say out into the world outside of their corporate environment, the product manufacturer. And they go maybe onsite in a factory to fix a machine or they go to a hospital to fix a medical device that’s not working. So the field service tech is sort of, I mean, there’s tech support, but they’re mobile tech support instead of being call them up on the phone tech support.

SO:              So as a field service tech, I show up on your doorstep, you’re my customer. And you say, “Hey, this machine is broken, fix it.” And I go look at the machine to figure out what’s going on there. Well, at that point I start plugging in the issue that I’m seeing. Maybe there’s an error code. And if I’m very, very lucky I can plug in the error code and have it tell me, “Oh, that means the battery’s low,” or, “Oh, that means you need to unplug it and plug it back in,” which I think in general is good life advice although not for medical devices. I’m not giving anybody medical device advice.

BS:              Especially don’t unplug it if you’re not supposed to.

SO:              Yeah, don’t unplug the thing. So the service tech is responsible for service and/or repairs. And so they need the same thing. They need their procedure that says what to do. How do you turn the machine off? Which part do you pull out? Which part do you replace? How do you do that? Which things do you have to unscrew and open up and disassemble to get to the piece that you need to correct, put in the new part, put it all back together, do whatever you need to do?

SO:              So service techs, I would say in general, produce less content than the technical support people. You might get annotations like, “Oh, I did step four, but it wasn’t quite right. You might want to do it this other better way,” that type of thing, but they don’t generally write extended procedures. And I think part of that is because the service techs tend to be experts. It’s like a car mechanic who knows how to fix the car. I would need 127 step procedure. The car mechanic needs a procedure that says like, “Open the hood, remove the battery, put in the new battery, close the hood maybe.” I need a lot more than that, even for something like replace the battery.

SO:              And so for a service tech you might get a very high level procedure that’s four or 10 steps, but then maybe you can expand those steps because if I can’t quite remember how do I do this one thing that I need to be doing, I can kind of expand it and it’ll give me the more detailed version of that. But service techs in general are relying on detailed standard operating procedures, instructions, how to do this. From a content ops point of view, the service techs very often want or need integration with their dispatch system. So Bill you’re the mechanic in this scenario. I’m a hundred percent sure you’re a better mechanic than I am. And-

BS:              No, we need all the help in the world if that’s true.

SO:              I’m sure you’re better at it. So you show up for work and they hand you this work order that says, “Hey, we need you to go work on this car. It has this problem and we think this is the fix.” And so you kind of get this work order that says, “Go do this thing, but it’s already got the procedure glued into your work order essentially.” Again, the work order is, “Replace the brakes,” or, “Fix the battery,” or something that I understand. And then the procedure down below is, “Oh, well, for this model, from this year in this configuration, here’s what you actually need to do to replace the brakes.” Now, again, if it’s you or me we’re going to need all the details. If I’ve been doing mechanical work on that type of car for the past 20 years, I really just need to replace the brakes.

BS:              Mm-hmm (affirmative) And likely you’ll find places where the docs are wrong and you need to annotate it so that you don’t run into it a second time.

SO:              Yeah. And if I’ve got 25 years of experience, I’m probably not even looking at the docs or I’m only looking at it to get the work order and the high level. “Wait, what did they do? Oh, no, that’s probably not the brakes. They diagnosed this problem, but I’ve seen this before and it means something totally different.” And so there’s that level of expertise, but it’s interesting because the service techs very often are, again, looking for that integration between the service management system and the procedural content that tells them how to do particular kinds of tasks.

BS:              So stepping way back, so what are the core priorities that tech support and field service has for content ops?

SO:              From a content ops point of view, again, the field services people really need that connectivity between their work orders and their instructions. On the tech support side, we ask questions about how to connect the knowledge base, whatever that may be, and the product content delivery endpoint. So basically the user docs and the KB. How do you connect those? How do you establish a good feedback loop so that people are farming the tech support database looking for content updates and corrections.

SO:              And I would say, ultimately, we really want to think about how do we distinguish between core product content and sort of support only content. And I mean, I’ve said repeatedly knowledge base versus content delivery, but at least in theory those could be delivered in the same place even if your access points or your entry point as a content developer are different. But those are kind of the things that I see as the key priorities here are connecting to what amounts to the dispatching system or service management and what that looks like. And then this question of how you align product content and tech support knowledge base content, and how you feed back into that loop to make sure that they all get updated properly.

BS:              And I think that’s a good place to leave it. Thank you, Sarah.

SO:              Thank you.

BS:              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 Content ops stakeholders: Tech support (podcast) appeared first on Scriptorium.

In episode 117 of The Content Strategy Experts podcast, Sarah O’Keefe and Patrick Bosek of Heretto continue their discussion about Content as a Service.

“Content as a Service is becoming a necessity to really deliver a strong customer experience from an answers and knowledge perspective.”

– Patrick Bosek

Related links:

Twitter handles:

Transcript:

Sarah O’Keefe:                   Welcome to the 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.

SO:                   I’m Sarah O’Keefe. In this episode, Patrick Bosek and I continue our discussion about Content as a Service. This is part two of a two-part podcast.

SO:                   So, looking at this from a slightly different point of view, who are the companies, or the industries, maybe, that need Content as a Service the most?

Patrick Bosek:                   So, I think it’s going to be the usual suspects. I mean, I wish I had a more interesting answer here, but it’s technology companies. And sure, You can say, okay, we’re all technology companies now, and to an extent, that’s true. But I think if you look at the people who are going to adopt this most aggressively, right out of the gate, it’s the people who are going to have the most benefit from it. And what we see is it tends to be software companies, or companies from a high tech perspective that maybe they sell a thing. But realistically, the thing is just something that they can load software onto and sell you that, right?

PB:                   So there’s that really blurry line between high tech manufacturers and software companies. It’s really good for them because of the as licensed thing they run into. There’s this natural progression as a software company that I think every software company that reaches a certain scale goes through.

PB:                   You make a thing. It’s simple. People want it. It solves a simple problem. People come and buy it. You sell a bunch of it. Well, as you sell more of it, you gain more validity and bigger people want to come and buy it. But bigger organizations, they want this changed and they need this other thing, or they need to integrate with this thing. And over time you want to serve them, those bigger organizations or different niches, or there’s market demand that pushes a product in a bunch of different directions. And what happens is that your product becomes more complex so that it can access more niches, it can access more larger accounts. It can have its 90% value plus 10% for a lot of different groups. And what that means is that your product is very different, based on who’s using it, which group is using it.

PB:                   So now there’s this as licensed model for your software. If you’re this group, if you’re in FinTech and you’re using our product, it’s mostly the same, but it’s got this little thing that’s different. If you’re in this group, there’s all that, right? But you don’t want to… So now your choices are, okay, we can produce one manual that covers 90% of the product, or we can produce 40 manuals that all cover a bunch of different parts of the product. And they copy 90% of the content.

PB:                   Unless you move to a Content as a Service model where it can be dynamic, it can be whoever’s accessing it gets 100% of the product. And it’s just that 10% that changes based on who they are. So Content as a Service becomes a necessity to really deliver a strong customer experience from an answers and knowledge perspective, to serve those people after the fact. And I think those are the organizations that we’re seeing adopt this most aggressively today.

SO:                   Yeah. And the as licensed thing is interesting because we’re actually seeing this in that space, but also in the as built, which is essentially the hardware equivalent of as licensed. I mean, you mentioned tractors, right? Well, it turns out in some manufacturing organizations it’s, ‘oh, I need a machine,’ a tractor or a truck or a car or something. And those are in fact getting customized per customer. So they need, ‘what did you build for customer X on this date?’ And that gets super tricky and really kind of obnoxious.

PB:                   Oh yeah, the automotive industry is full of that. I was just talking to somebody from that industry. I don’t know, it was on Coffee and Content. It was actually… His name’s Nick, he’s from Tweddle. And they were talking about VIN specific content, right? So, that’s kind of like that whole thing taken to its nth degree where the number that identifies your product, it’s like a checksum almost, is the thing that determines the content that goes into your product. And because almost all cars can display content, you have a perfectly dynamic experience that relates to the person who’s sitting in the product. How much more Content as a Service could that possibly be? And to fulfill that you have to have a really strong content operations methodology that feeds into a Content as a Service infrastructure, because Lord knows cars are largely software. And when your car updates… I mean, they are. You laugh but they are.

SO:                   Yeah they are, no they totally are and it’s depressing.

PB:                   I mean, yeah, the software’s eating the world, right? Everything is software. And there’s software in everything. So when that software updates, the content updates, your car updates, you have to be able to push that stuff out, along with all those things.

SO:                   So as we get started with this, I mean, there’s a lot of people talking about Content as a Service and there’s some stuff happening. But if we look ahead, 10 years or five years or 18 months, however far you’re comfortable in looking ahead, where do you envision this going? I mean, what do you think this is going to look like when it reaches its full potential?

PB:                   Oh boy. Small question. I think the interesting thing about Content as a Service is that… I would like… Here’s how I’d like to answer that question. And then I’m going to tell you after I answer it this way, why this is probably not realistic. I would love to say that we’re going to get to a place where Content as a Service itself has its own well defined and well understood standards. And we have interoperability in a way that we have with content storage formats today, right? So like you think about DITA, right? DITA is a structured content storage format. It’s not a good format for Content as a Service, because it’s just… It’s too semantic, it’s got a lot of information in it you don’t want directly represented, you have to transform it into HTML, all those kinds of things.

PB:                   So you don’t want to send DITA through an API. You don’t want to leave that to the last mile. You have to compile DITA and you’d lose a lot of the power of DITA if you didn’t compile it, that’s just kind of part and parcel of using DITA. But what if there was a standard for what comes out the other end of a Content as a Service, right? It was like DITA where everybody knew what they were going to consume.

PB:                   Well, you’d end up in this situation where the systems that create experiences were interoperable, right? So you’d have Heretto, and Heretto would send you whatever this open source standard was over your Content as a Service. And then maybe you’d have something like Contentful and they would send the same thing, right? So different content, but it’s a standard format. And then you could just have frameworks that were just out there that knew how to interpret this stuff.

PB:                   All the rules of the road are, are put together, right? It’s all… It’s the maximal implementation of cards and components and the modularized enterprise as it relates to content and Content as a Service and modular experiences and all that kind of stuff. So that’s what I want to say is going to happen. And I want to believe it’s going to happen. I do. It’s a thing that I dream about and I hope is in the future and it’s a thing that I’m going to actively pursue. Right. It’s a thing that I believe in and I’m going to push towards. But…

SO:                   However…

PB:                   Right. So why am I a little skeptical about that? I’m a little skeptical about that because I think that the industry as a whole is very privatized. And I think that there hasn’t been any real appetite for getting to something like that.

PB:                   And I think that what you’re going to see is that if you try to go down that road, you’re going to run into a lot of forces that are going to say, well, part of the beauty of where we are today in Content as a Service is that it can be so customized. It can be so one to one. You can build these models that really fit you. And there’s no really strong way to perfectly containerize that and have it be available in a broad, universally understood interchange format. I don’t know how true that is. I don’t know if that’s necessarily the thing that would kill the ability to do this, but whatever way it goes, this is the future.

PB:                   Everybody’s going to run on this, the idea that we’re going to use things like WordPress in 10 years. I mean… I don’t know… I mean, somebody is, for a blog, but no company is going to be running on WordPress in 10 years. You know DXPs, the monolith DXPs? I think those are dinosaurs too. I think anybody who’s going and implementing a DXP today is just deciding that they’re going to re-implement that on Content as a Service in, four to five years.

SO:                   So I won’t ask you to name names, but DXP is digital experience platform.

PB:                   Yeah. That’s true. And some of them are very sophisticated technologies, and they do a lot of stuff. So they used to be web content management, right? And then they moved to digital experience. And when the Content as a Service industry can find a way to break down all the different pieces of functionality that you get in these big monolith DXPs, and provide them as perfectly modularized, interoperable, interchangeable services that you can clip together into what you need for your content experience platform, then you’re not going to buy DXPs anymore. It just doesn’t make any sense. I think that’s a big part of the future. So people are listening to this and they’re going, okay, well, how does this relate to me? What I would say is in terms of very specific technology, you should definitely understand the primary approaches to structured content because that’s not going anywhere.

PB:                   And if you really need more proof of that, which I don’t think you do if you’re listening to this podcast, honestly, but maybe somebody near you does. And if that person does, go and look at Schema.org, that’s Google stuff, right? The way to improve your search engine ranking is to inject more Schema.org into your content. That’s structured content, that’s metadata, right? And that’s what Google wants you to do. That’s where those quick answers come from. That’s where the FAQs on the front page of Google come from, it’s how they ensure that certain things are more relevant. It’s literally because you tell Google it’s more relevant. It’s not keyword stuffing. Google, in a lot of ways, gave up on like the AI approach to this. And they said, actually just go put metadata in your content. It’s like that’s the direction.

PB:                   So you’re going structured in this way. And so understand the structured formats and then get to understand the primary delivery formats. So there’s really only two ways to deliver Content as a Service. And that’s a RESTful API and a GraphQL API. Yep. That’s basically it. I was trying to think if there was a third, but nope, that’s it. So understand the two of them and understand the ones that are going to be more effective for your use cases. And then kind of get a recognition of what the different models for presentation look like and how those things come together. And I think that’s a foundation of understanding content operations, which is just an aspect of content operations that’s going to work well for you, no matter where you go. And if anybody is to write a book on content operations, I would recommend you go read it. That’s my last recommendation.

SO:                   All right, people. So it appears you have homework. It wasn’t me. It was Patrick, and that sounds like a good starting point for some of this research, but also, that sounds like about six months of reading work. So…

PB:                   Hey, you’re the one who asked me to come on here. This is not my fault.

SO:                   I’m going to stop it here before you give us more homework to do.

PB:                   No, that’s fair.

SO:                   But Patrick, thank you. 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 Content as a Service (podcast, part 2) appeared first on Scriptorium.

In episode 116 of The Content Strategy Experts podcast, Sarah O’Keefe and Patrick Bosek of Heretto talk about Content as a Service.

“Do we still have places where building a static site or a static set of help materials makes a lot of sense? Totally. But there’s a natural aspect of dynamic changing content. If that content is going to be a little bit different based on who or where or when you access it, then you can’t build it statically. That’s one of the things you’ll never get from a PDF.”

– Patrick Bosek

Related links:

Twitter handles:

Transcript:

Sarah O’Keefe:                   Welcome to The Content Strategy Experts podcast brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way. In this episode, we talk about Content as a Service with special guests, Patrick Bosek of Heretto. This is part one of a two-part podcast. Hi, I’m Sarah O’Keefe. Patrick, welcome. We’re happy to have you here.

Patrick Bosek:                   I am happy to be here. Thank you, Sarah. I’m excited to chat with you on this very special podcast about content strategy. I love content strategy, you know that, and I also love Content as a Service, which is our topic. So, excited.

SO:                   Excellent. So tell us a bit, for the people that don’t know, tell us a bit about yourself and about Heretto.

PB:                   Yeah, sure. So I’m Patrick Bosek, as you mentioned. I’m CEO and one of the founders of Heretto. And what that means is that I get to kind of run around the digital universe and talk about how cool content is if you do it right. And then talk a lot about how to do it right in a bunch of different places. I do that with Coffee and Content and Win with Content and the Content Components podcast, if you see a theme. I like to get out and talk about content. I also write for CMSWire from time to time. I like to blog on our blog and all this comes down to talking about, mostly the technology aspect of how to get content operations set up in place, make it run effectively, and just get more efficiency, scalability, lower cost, and joy out of your content systems.

PB:                   And then in my more … in what I’m actually paid to do, which is to run Heretto a little bit, Heretto is a component content management system that runs on DITA and it is a content operations platform that you can use to scale up your content, manage the localization, collaborate with people who are a range of levels of technical. So you can have people who are non-technical, people who are in legal, all those kinds of things, all the way through to developers and technical authors, creating structured content in an online Software as a Service, Wiziwig environment. And then we can put that into deployments, which can go out into the cloud and power content experiences across whatever you want to hook it up to the API. And we do that using an API, which is a Content as a Service, which leads very nicely into what we want to talk about today. Yeah.

SO:                   And there we go. So for first of all, we will get links to hopefully everything you just mentioned into the show notes so that people can go find all these other podcasts and resources and the Heretto site, and your CMSWire link while we’re at it and all the rest of it. But yeah, so not too long ago, I was on one of the podcasts that Patrick mentioned and we got into an active discussion about a number of things. So I thought it might only be fair to return the favor and let you give your perspective on some of these things after our little knock down drag out. So I wanted to start with the basics, which is how do you define Content as a Service or CaaS?

PB:                   Yeah, that’s actually not that hard. When it comes right down to it, if you can access your content over a web available API and you can do it in a production way, so if I can set up an application or a website or some other user interface or really anything that’s going to be able to select content using a web call, that’s a content as a service. I’m able to make a request and it will serve me that content on the request. So it’s provided to me as a service. It’s Content as a Service application. It’s not that complicated.

SO:                   Okay. So when we think about Software as a Service, it was generally this idea that you would buy software and put it on your laptop, I guess, or your computer on your local drive and run it there versus Software as a Service was kind of like, you go to a website and you get stuff. So you’re saying that content, not as a service, the old version is essentially packaged stuff, right? Like here’s a PDF or here’s a book, or even here’s a website that I have pre-built.

PB:                   Totally. That is exactly the difference. Now there’s a bunch of, I mean, I don’t know how nerdy we want to get on this podcast. I mean, this isn’t Components after all, but there are places and there’s a time and place for both of these things. Content as a Service isn’t meant to be, even though it’s the next thing, it’s the new thing. It doesn’t remove the need for some of the packaged content, just like we have apps on our phone today. That’s the old model of software. You download them and you install them just like we used to do before. They’re not software as a service, the apps that are on our phone. So that model hasn’t gone away. Software as a Service has just become a really effective model for certain types of applications. The ones that spring to mind are obviously, social media is an application that tends to be really strong through Software as a Service when you’re on a web browser. And a lot of business applications.

PB:                   Salesforce famously is the first one to really embrace it in business applications. And Content as a Service is very much kind of the same thing but for content. So do we still need PDFs that we can download and print and take with us? Yeah, sure. I use PDFs every day. Do we still have places where building a static site or a static set of help materials makes a lot of sense? Totally. But there’s a natural aspect of dynamic changing content. If that content is going to be a little bit different based on who or where or when you access it, then you can’t build it statically. That’s one of the things you’ll never get up from a PDF. If you and I, based on who we are or where we are need to have a different piece of content in a paragraph, you can’t do that with a PDF efficiently or at scale. And that’s when you need Content as a Service. And that’s kind of the same thing with software or anything else that comes as a service in that way.

SO:                   So what do you see? I mean, you’re mentioning contextually aware or personalized kind of content. Where does this matter the most? What are the kinds of use cases that you’re seeing for Content as a Service where people need it and are using it appropriately?

PB:                   Yeah. So that question is so much fun because everybody wants to call it personalization and it is personalization. The problem is that when everyone thinks of personalization, they kind of go right to really dynamic stuff, which is Facebook or Amazon or stuff like that. Those types of experiences, which are really very individualized, personalized. When you’re thinking about Content as a Service, personalization, the purpose of it is to get us the things that we need, which is to say the information we want more quickly without having to wade through a bunch of other things. And those other things are going to be navigation or they’re going to be not having to read things. So when we think about where Content as a Service makes the most sense and where it’s having the biggest impact, it’s typically in business functions, where there is a necessity to either deliver less content to make it more easily digestible, more quickly digestible, get people to an answer or to a resolution faster, or content specifically that has an aspect of confidentiality or security or privilege.

PB:                   So if I have 10 different groups of people and what they can see changes. So the classic example is support distributor customer. Let’s say you sell tractors, I don’t know, and your distributors get certain version of the manual. You want them to be able to work on everything. Support gets a different version of the manual. You want them to be able to support people really effectively, but maybe they don’t need to know how to re-time the motor or engine. And then the end customer gets another version of the manual which is some Venn diagram of those three things. That’s a really classic example. Each of those personas, based on who they are and what their function of the product is, need to have secured effectively different access to a shared pool of content.

SO:                   Yeah. And I remember, I mean, a long time ago we had a … it wasn’t the most challenging thing, but we had a situation where a customer had support content where essentially the external facing support said, “Oh, the thing is broken, try this, this and this.” And then the last line in the knowledge-based article was more or less, if that doesn’t work, call corporate support. But the corporate support version of that same page said try the first three things that was identical. But then instead of saying call us, it said, “Okay, if a customer calls you with this problem, here are the weirdo things that you can do.” For which you need higher levels of access than the customer has or that we’re willing to give the customer. And I mean, that was doable with just a pretty simple switch, but you extend that as you said to more versions and more people and more variants, and all of a sudden it gets complicated.

SO:                   I also feel like there’s an element in here of security in the sense of if you get it right from an API point of view, there’s less likelihood that the content will leak out inadvertently.

PB:                   I think there’s an aspect of that, but I would warn people against thinking that they’re going to be able to prevent somebody from removing that content and creating a copy. I wouldn’t endorse that concept, but you can certainly make it more challenging and you can make it a thing that someone has to maybe have active male intentions or whatever you want to say. Something where they’re doing something that they know they shouldn’t and that is probably a really strong deterrent. But yeah, if it goes through the internet, people can hang onto it, for sure.

SO:                   If it’s digital, it’s … yeah.

SO:                   I think that’s a good stopping point, but we will continue this discussion in the next podcast episode. Patrick, thank you.

SO:                   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 Content as a Service (podcast, part 1) appeared first on Scriptorium.

In episode 115 of The Content Strategy Experts podcast, Bill Swallow and Sarah O’Keefe discuss content ops stakeholders in localization.

“Using baseball examples isn’t going to work well in a country where baseball is not a thing. So you have to think about that. Does your text, does your content, do your examples work and are they appropriate in your target language and culture?”

– Sarah O’Keefe

Related posts: 

Twitter handles:

Transcript:

Sarah O’Keefe:                   Welcome to The Content Strategy Experts podcast brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way. In this episode, we continue our series on content ops stakeholders. And this time we’re focusing on localization. Hi everyone. I’m Sarah O’Keefe and I am here with Bill Swallow today.

Bill Swallow:                   Hi there.

SO:                   So this podcast is part of an occasional series that we’re doing on stakeholders in content ops projects. We’ve done a few different stakeholders already, and you can find links to those episodes in our show notes on scriptorium.com or wherever you get your podcasts. In this episode, we want to focus on stakeholders in localization. And I guess the first question then becomes, Bill, who are the localization stakeholders?

BS:                   Well, it’s a lot more than people think there are. We could start with the localization project managers so the people who are essentially running the entire localization operations for your company. Then you have your regional marketing people, so those who are promoting products and services in the target markets that you’re trying to reach with your content. Then of course you have the actual translation team or localization service providers, whether you’re using internal or external resources. Those are also stakeholders there. Another group that somewhat gets overlooked are the internationalization developers. So anyone who’s working on products or websites who have to account for any translated content. Those people have a rather large stake that is often kind of left in the dirt behind. And then of course you also have your content consumers. So those who are ultimately going to be reading, listening to, or viewing your content.

SO:                   And I know that a lot of times when I talk to these groups of stakeholders about some of the work that we do, they’re very interested and they would love to have better content, better content ops, better information flowing into the localization function. But what they typically say is, “Well, we don’t control that. The people upstream from us, the content authors, the information architects are the ones determining what this content looks like when it goes to localization.” And so I guess there certainly IA and content authors have an effect on localization.

BS:                   A big effect. Essentially, anything, a content author or an information architect does impacts the localization process, whether they are conscious of it or not, it can come down to how they write, so the style that they use in developing their content. It could come down to the infrastructure that the authors use, so which tools they use and how they use them. The time at which they send content off for any kind of translation work. There are a whole bunch of different factors that come into play here. And Sarah, you’re absolutely right. A lot of times these stakeholders are kind of well left holding the stake, so to speak. They receive stuff that may not be in the best format that may not be written well, that might be somewhat confusing to translate. And they may be given next to zero time to turn it around. So they have a lot of concerns.

SO:                   So we’ve already used at least three words to talk about this function, right? We’ve said localization several times, you mentioned the translation team, the linguists, and also internationalization. So what are those three? I mean, if you’re not somebody that lives in the space, what is the difference between translation, localization and internationalization?

BS:                   I think the easiest way to think about is that localization is the general term for all of it. It’s the process of being able to take content that’s written in one source format. Let’s say, I’m not even going to suggest a language here and then taking a look at the processes and the needs for being able to develop that content in a format and in a language that another person in another part of the world would be able to consume that content appropriately.

BS:                   Internationalization is kind of the backbone of the entire translation process or I should say the entire localization chain. Internationalization is basically the things that you bake into how you develop something that accounts for a need to change to a different language, to a different market, switch formatting and so forth. So that’s all, it’s kind of all of the technical bells and whistles that you bake in behind the scenes that allow you to easily produce content for multiple different audiences. And then the translation process is what we’re all accustomed to when we think about developing content in a different language. It’s the act of actually rewriting the content in a target language.

SO:                   Yeah. I like when I talk about internationalization, I tend to fall back on talking about currency, because if you think about it, if you develop a product, let’s say in the US, and it is dollar based and you want to bring that into the European Union, you will almost certainly have to support euros as a currency inside your product. Well, that’s not really a translation problem per se. There’s also going to be translation, but the idea that you can’t just bake in dollars as the only currency that your product understands is important, right?

SO:                   That’s that kind of internationalization layer. Then you’ve got the linguistic layer, the translation, and then there’s a separate one using baseball examples and US content isn’t going to work well in a country where baseball is not a thing. So you have to think about that. Does your text, does your content, do your examples work and are they appropriate in your target language and culture?

BS:                   And just like currency. There’s another really accessible example of internationalization. And that’s the use of time zones and being able to send a calendar invite from one person to another, in any region. If you’re setting it for 2:00 PM your time, it should not show up on their calendar at 2:00 PM their time. Otherwise, you’ll never connect. So there is that extra layer of internationalization behind the scenes that says, “Hey, what time zone am I in?” And then add or subtract hours until you get the correct time for the meeting.

SO:                   Yeah. I mean, there are other examples of this. I was talking to somebody, a few years back, at a conference in India and they politely said to me, “So your logo has an owl in it. And that’s interesting. And why did you choose an owl?” And I said, “Well, in the U.S., owls connotate wisdom and intelligence and various positive of things.” And I said, “So what does the owl say to you in Indian culture?” And he looked at me and kind of cringed because he didn’t want to give the answer. And I was like, “No, really it’s okay. So, well, what does an owl mean in Indian culture?” He says, “Death.” And something about being silly. I mean, it was very … it was a negative thing it’s as if we picked a, I don’t know, a rat or something as our logoed animal. Right? And so that was a really good example where we didn’t think too hard about the implications globally of picking a particular visual or a particular animal. So we have something that in a non-US context in certain other cultures doesn’t necessarily work exactly.

BS:                   And that’s really where the style guide is important. And being able to make these decisions both visually and with authored content about how things are being represented. There are a lot of different issues that come around different imagery, whether it be using hand gestures, I suggest you don’t. Using colors a certain way. Even certain layouts can be a little problematic when going to certain markets.

SO:                   And so related to that, the most common pushback we get, let me say, you’re going to need to do translation or localization, or you need to really have a strategy around globalizing your product. Right? If you want to sell your product in these other markets, you have to think about other languages and what we get less these days, but certainly in the past five or 10 years, we got a lot of, well, localization is expensive. So we’ll just ship English and the people who are buying our products speak English, which, I mean, if you’re only shipping in English, then that’s probably true.

SO:                   But you’ve just limited your market to the people who are willing to buy a product in their country that is only available in English. So it’s a bit of a chicken and egg, but I wanted to ask you a slightly different question, which is not is localization expensive because it is, but why? And what can you do about it? And is it really just expensive? Or is it that you need to … How can you best leverage that? If you’re going to spend the money, how do you make it as valuable as possible what you’re producing?

BS:                   Well, if you’re going to spend the money, it’s best to spend it the right way. And that’s to look at your entire chain of how the translation process, the localization process runs. The one thing you don’t want to do is spend a lot of time and money upfront, authoring your content, the way you feel it should be authored for where you are in the world. So if your company is United States based, you don’t want to be just authoring for a United States’ customer or audience. You want to take into account with the baseball references that Sarah mentioned and so forth, you don’t want to use a lot of these local idioms, anecdotes and so forth in your content, because it makes it more difficult to translate. Likewise, you don’t want to spend six months developing content and then throwing it over the wall to some poor translator saying, “Hi, we need this back on Tuesday.”

BS:                   That’s going to be expensive for a couple of reasons. One, it’s going to incur a markup for a rush rate. Two, you’re not going to get their best work. So there are going to be errors, and there’s going to be a lot of cleanup. And if there isn’t cleanup, you have another expense of having to essentially deal with the damage that your content causes down the line. It could result in incorrect procedures. It could result in offending somebody. So you need to make sure that you’re doing things the right way. And you’re including all of these stakeholders in the localization process from day one of when you’re developing content.

SO:                   Yeah. And I think it’s important. And I fall into this trap as well. You know, very often we start talking about localization and what we talk about is global markets like, “You started in the US, and then you’ve decided you want to sell in Europe. And therefore you need localization.” However, there are somewhere in the vicinity of 30 to 40 million people in the United States whose primary language at home is Spanish. Well, 30 million people is a pretty good size European country. So you might think hard about whether your first language, your first localization effort is in fact not a different geography, it’s the US market, but in Spanish, because that is a big chunk of people that you are probably not going to reach with an English only approach.

BS:                   Definitely. And Spanish is just one really good example. There’s another huge Chinese market and others in the United States alone, not withstanding any regional differences as well. When it comes down to talking about specific items in everyday life, we have different terms and we talk about them differently, depending on whether we’re in the Northeast, the Midwest West Coast. It’s also important to look at the expense of localization in how long it takes to get localized product and localized content out to those who need it. If your process isn’t as efficient as it could be, you could see a significant delay in shipping to other countries or even other regions or other target language markets, because you’re waiting for the localization work to finish. Whereas if you planned for it upfront, you can bring that time in. And you can kind of not necessarily spend less money, but you can realize the fruit of labor earlier.

SO:                   So we’ve talked a little bit about how localization essentially has implications for nearly everybody in the content chain. Who’s the stakeholder for localization? I mean, it might be easier to say who’s not a stakeholder because if I write the content properly, the first time around and follow standards that will flow through all the way into the actual translation linguistic process. We infamously had a customer where the Spanish translation team got criticized because they used six different terms for the same thing in the Spanish content. So along the lines of car seat versus baby carrier versus infant seat and you need to pick one and go with it. So they got dinged when somebody reviewed the Spanish translation for using six different terms for the same thing, and this is terrible and we should fix it.

SO:                   Well, they went back and looked at the English source content. And what they discovered was that in the original English language, they used eight different terms for the same thing. So the translators, they had improved, it was still way too many terms, but the fact that they used six instead of eight was not really on the localization workflow. That problem started much, much earlier. So what does that look like? What kind of collaboration do you need across all of these different stakeholders who are either directly with a title like localization manager or indirectly as a content person involved or contributing to localization?

BS:                   I think the big thing to think about first and foremost is making sure that everyone is aligned on the purpose of developing this content for multiple different language markets and making sure that everyone understands what the key factors of success is for those markets, making sure that everyone understands the importance of having the correct vocabulary in place and using it consistently. So we’re talking about style guide here and language rules and writing rules, to bring in those internationalization developers who often get forgotten about. These are people who are going to build in the efficiencies that you can leverage as a content author to make sure that you are doing things consistently. So using things like variable strings for commonplace terminology throughout your content set, things like labeling notes and cautions, warnings, those types of things. If you can externalize that stuff and have it programmatically inserted, it makes it very easy to replicate it across the board in any language, because you can do that customization outside of the content. And then it’s reused automatically when you’re publishing.

BS:                   Another key aspect is to agree on the workflows that are involved and it cannot be develop your content and then throw it over a wall and expect it to come back perfect. There has to be some checks and balances throughout the entire process of developing your content so that the authors get the feedback that they need should they be doing something wrong at the time when they’re doing it wrong and not six months later when they are just grumbling about the fact that edits have come back and they thought they were done with this piece of the work. Having that timely feedback helps hone in on the process and making sure that not only are things being corrected, but that things are being built into the process to ensure that those mistakes don’t happen again in the future.

SO:                   Okay. So I’m told that machine translation is going to solve all these problems. And all we have to do is shove our text in and the machine will make it into magically into all the different languages. And off we go. So why aren’t we doing that?

BS:                   I got an Amazon Echo for Christmas and it still does not understand half the things I ask it for. So I’m not putting my money on machine translation if I can’t even get my device to play the correct song that I’m looking for. Machine translation will get you a part of the way, but the machine translation is only as good as the database it’s referencing and as good as the content is going in. Aside from those two factors, you can still get very close to 100% clean and appropriate, and you will still have to do some cleanup on the machine translation side after that work has been done. It really does require a person going through proofreading. And just asking the very basic question, is this clear and does it make sense?

SO:                   Yeah, because I think we’ve all seen some amazing machine translation by which I mean amazingly plausible, but totally inaccurate.

BS:                   Totally. I used to work in translation and on my desk at that job, I had a collection of little toys and gadgets that I’d pick up along the way if I was shopping in a grocery store or a toy store with my kids, I’d find this bargain bin item that was absolutely ridiculous. The copy on the box was just outrageous. The instructions on the inside were absolutely horrendous. And I’d keep those as a reminder so that when people started complaining about quality of translation and so forth, I can pick up these examples and say, “Well, how do you think that this got out the way it did?” And that’s because no one was no one was proofing behind the work that was being done. And it was just being rushed out the door as fast as possible.

SO:                   And that’s, yeah. And I think that’s probably a good spot to leave it. Machine translation has its place, but do you really want a machine translated set of instructions on a medical procedure that people are performing on you? I am going to pass on that one.

BS:                   Yeah. It’s a hard pass.

SO:                   Hard pass. So, well I think we’ll leave it there. Thank you, Bill.

BS:                   Thank you.

SO:                   And thank you to our audience. 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 ops stakeholders: Localization (podcast) appeared first on Scriptorium.

In episode 114 of The Content Strategy Experts podcast, Bill Swallow and Gretyl Kinsey talk about developers and managers of the technical stack as content ops stakeholders.

“Without a gatekeeper, things can go awry very quickly. Other groups can take ownership of a particular piece of the tech stack and then you start to have some issues.”

– Bill Swallow

Related posts: 

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 series on content ops stakeholders. This time focusing on those who develop and manage the technical stack. Hello and welcome everyone. I’m Gretyl Kinsey.

Bill Swallow:                   I’m Bill Swallow.

GK:                   And this is part of our occasional series on stakeholders and content operations projects. So on some of our previous podcast episodes, we’ve discussed a couple of different stakeholders, including IT and executives. And you can find those episodes on scriptorium.com or wherever you get your podcast. This time we’re focusing on the technical stack and the people who develop and manage that. And we want to start out by just talking a little bit about how that’s different from IT, which we’ve covered before.

BS:                   So IT is in charge of making sure all the systems involved in the content lifecycle work together and with the rest of the company’s technology. Here, we’re talking about the tech stack developers and managers who are more deeper into the weeds of creating the custom plugins, templates and what have you of that publishing system.

GK:                   So when we talk about the technical stack, some of the things that may be included in that are things like system configuration. So if you have got authoring tools, if you’ve got a content management system of some sort, if you have publishing engines, maybe you’ve got some other connected systems like translation or learning management software, then people managing the technical stack will be responsible for configuration on all of those kinds of things. And as Bill mentioned, there’s also going to be things like style sheet and template creation. And of course, there’s also going to be ongoing support and maintenance.

BS:                   And your technical stack developers or managers might include any of the following, either an in-house person or a team that you have available to you to develop against the technical stack and to add additional things. It could include outside contractors or consultants who are brought in to do the technical work and then head off and come back again when they’re needed. It could be developers who work for some of your systems vendors who come in and develop against their own system for you, or could be some combination of all of the above.

GK:                   Yeah. And we’ve discovered in a lot of our projects with clients that, who manages that technical stack often comes down to the industry that you’re in or the type of products you make. It could also be related to things like your company size, your location, or just your general corporate culture. So for example, if you’re the type of company who produces software, you work in high tech, then you might be more likely to have some of those in-house resources for things like developing your custom publishing templates and other parts of your technical stack. Whereas, if you are in a completely different industry, you may be someone who brings that in from the outside, and in some cases we have been a part of that technical stack as the outside contractors or consultants.

BS:                   Right. And company size does often come into play here as well. If you have a content team of 50, 100 or more people, chances are you probably have the bandwidth and the knowledge in house to be able to take that responsibility on internally.

GK:                   Yeah, absolutely. So when you are developing a content strategy, what are some of the most important considerations from the perspective of those who work on the technical stack?

BS:                   So one key consideration to keep in mind regarding the tech stack is to have both the short-term and long-term plans. Even with the long-term plan in place, it’s important to have the short-term ones in there as well. And this includes everything from setting your goals for the tech stack itself, all the way up through the costs and the time it takes to implement. One of the short-term plans that you might have in place is being able to develop a proof of concept within a particular system. So that would be not only selecting the software and the systems involved, but being able to put together your information architecture, your content model, all the way down to how you’re going to produce your outputs. So what are driving the transformations involved to get your raw content out into a published format?

GK:                   One other thing to mention on the long-term plans in particular is that a big part of that is going to be content governance. And it’s really important to think about where your tech stack fits into that. Because like we mentioned, one of the things that the people involved in the technical stack do is ongoing support and maintenance. So if you think about governing your content lifecycle, it’s not just the content development, but also, how you’re going to govern the maintenance and the changes made to all the different parts of your technical stack over time.

BS:                   And speaking of maintenance, it’s another key consideration here is that the more you customize your systems in the tech stack, it does mean more maintenance of all of those customizations. So you have to kind of balance the benefits of doing those levels of customization with the costs associated not only with implementing them, but with maintaining them over time.

GK:                   Yeah. And I think that’s where it’s really important to think about what resources do you actually have available. So we talked about how maybe a larger company or a company that is more tech focused in its industry might be more likely to have some of those in-house technical stack people. And that if you’ve got that available, then maybe you can afford some more of that maintenance cost over time, because you’re going to have more of that continuity if you can do it in house and more of the resources available. Whereas if you don’t have that at your disposal and you are going to be relying more on contractors, then it may not be worth the cost associated with having that higher level of customization.

BS:                   And regarding those resources, you have to keep scalability in mind. As Gretyl mentioned, do you have the people available to you to do all the work? Do you need to have them stop on a particular project in order to work on the tech stack because something might have broken or something needs attention? Or are they a full-time position within your company and they are eager and ready to jump right in and get their hands dirty? Likewise, there’s a scalability of cost involved. So if you are working with outside resources, you have to keep that in mind that every time you need someone to come in and fix something, you need to be able to budget for that need.

GK:                   Yeah. And one thing I like to think about with scalability as well, which circles back to that first point we made about your short and long-term plans is that a lot of times when people are coming up with a content strategy, the scalability angle they’re thinking about is how will this grow over time with the growth of the company? So that’s one thing to think about is how does your technical stack grow and change with that? Can it grow? Can it scale? And do you have those resources available? And if you don’t right now, how can you plan for the future to make sure that you do?

BS:                   And with that in mind, I guess it’s good to ask, what type of collaboration is important between those who are managing or developing the technical stack with other stakeholders?

GK:                   Yeah. So if you are a content creator, it’s really important to talk to those involved with the technical stack about your delivery channels. So which ones do you need right now? This kind of gets to that short-term planning. Which ones do you need to add later? And that gets into your long-term. And again, how much do they need to be customized? What kinds of delivery are you looking at? What kinds of output formats? How do those need to be styled and formatted? And what is it going to take to get all of that up and running and keep it going in the future?

BS:                   Right. Because there is a significant difference in the level of effort of being able to include someone within a particular publishing run, let’s say you’re producing content for a new group within the company, it’s very easy to produce their content once it’s in the correct source format into the target delivery formats that you have available. But if they need a brand new system, even if it’s just another portion of the website where you’re potentially publishing content into a slightly different format. So if you’re doing a knowledge base for your content currently, and they want to do something that’s a little more marketing driven or is highly customized for a specific audience, it’s a completely different consideration that you need to keep in mind.

GK:                   Absolutely. And I also want to point out that when it comes to content creators and technical stack folks collaborating on maybe a new content strategy or a new direction for your content, that often involves a shift in the way that both teams have been working. So it’s really important to keep those discussions going constantly, keep them productive and make sure that you don’t have this separation or siloing off of those two groups, because it’s really, really important that they work together.

BS:                   Right. And not just work together within a one particular environment, but if they have a separate environment that also can work within your tech stack, you want to be able to keep that in mind as well. So if they are really accustomed to working in a specific tool set, if it somehow splices into the tech stack beautifully, then great. If it doesn’t, then you have a bunch of other considerations to deal with, everything from being able to secure funding for new tools, to secure training and potentially a lot of conversion of their existing content in order to get into that shared environment.

GK:                   And along those lines, I think if not only you’re a content creator, but also you’re someone in IT, it’s important for those two groups and the technical stack people to have a lot of discussions about the systems that are there to support the content lifecycle. And in particular, if you are choosing any new technologies to be part of that content lifecycle, it’s really, really critical for content creators, for IT people and for your technical stack people to be heavily involved in that decision making process in choosing whatever technology is going to be the best fit for the company, because each group is going to bring in different, but equally important considerations about how that technology needs to work.

BS:                   And I would say on the management side and the executive side, you want to make sure that you have these conversations with those who are managing the tech stack about the real cost of support. So what types of development efforts take the most time or require the most expertise to complete? Whether outside expertise is also needed in addition to internal expertise. And whether or not you do have additional costs beyond that. So additional tools that may be required to implement a particular thing into the tech stack.

GK:                   Absolutely. So what are some other things that it’s important to keep in mind regarding the technical stack and the people who work for it?

BS:                   So I think first and foremost, if your technical stack developers and managers are not in-house resources, then there needs to be a transition plan and some training for any in-house people who would be taking that role on afterwards, whether it’s doing the deep development or just managing the systems and being able to keep an eye on things.

GK:                   Yeah, absolutely. I think a lot of the projects that Scriptorium has worked on, one of the goals where we try to get companies is if they don’t have those in-house resources at the start, that they train them up over time so that they do have them and can take on their entire content lifecycle eventually. And that does take months or even years to do, especially depending on how much expertise you do or don’t already have.

GK:                   But that is something to really keep in mind when you first start planning your new content strategy and you get into those earliest phases of getting everything stood up and in place, don’t leave out the training because that is really, really important. And sometimes the training, as Bill said, can often be kind of more of a transition or an ongoing thing. So I know that with some of the projects we’ve worked on, there will be an initial training when you get a tool stood up and then there will be some ongoing sessions, maybe once a week or once a month for the next six months to a year after that, just to make sure that everyone involved knows how to use it and you’re not just kind of turning people loose with this new tool.

BS:                   Right. And also, in that same line, making sure that there’s plenty of clear documentation about things that authors should and should not be doing with their content or doing with the tech stack specifically. It usually goes back to documentation about the content model and so forth. But there need to be some expectations set that even if the content model allows for a new approach to authoring something, it may not be supported downstream or deeper in the tech stack. And it may have unintended results in the final output.

BS:                   So being able to identify exactly what people should and should not be doing with regard to the technology and the way it’s set up, because even if you have a tool in your tech stack that can do something very specific, it may not be set up to do that out of the box. And you want to make sure that no one is injecting anything that’s going to break things down the line.

GK:                   Yeah. And we always say, “Just because you can do something doesn’t mean you should.” So it’s really important, again, to just have that collaboration that we talked about between the content creators and the people who are in charge of managing the technical stack. Making sure that there aren’t these kind of miscommunications and that you don’t have some content creator just saying, “Why don’t we try this because we actually have the technology to support it?” Maybe you do, but maybe it would involve a whole lot more cost than you realize, or maybe it would involve a whole lot more time to get that stood up.

GK:                   So again, that’s why it’s just really, really important to have those ongoing discussions, to have that documentation and to have a plan so that if you do ever need to change what you’re doing, you do maybe need to add some new thing that you can do in your content or some new delivery channel or output type that you don’t just start adding that ad hoc, but you actually have a plan for that to go through to make sure that it can be supported.

BS:                   Mm-hmm (affirmative) And likewise, with doing any updates to the technology that’s in your tech stack itself, it may be that a new version of one particular tool or one particular technology comes out. You want to upgrade to the latest and greatest. You need to step back and take a look at the entire ecosystem that you’ve put together and make sure that that one change doesn’t trickle down into multiple problems elsewhere in the tech stack. You need to understand how all of the pieces fit together and where those dependencies are because one small change can equal a lot of change across the entire stack.

GK:                   Definitely. And I think one really important thing to keep in mind when it comes to managing all those dependencies and when it comes to the idea of content governance and content lifecycle governance that we talked about before is that it’s important to have a single point of contact who is in charge or responsible for all of this. So even if you don’t have that in house, it’s really still important to at least designate someone who can own that process, who can understand how all of the different pieces and parts of your technical stack fit together and who can be the gatekeeper, who can be the person in charge of that level of governance. So they can collect change requests. They can communicate that to all of the stakeholders internally. They can collaborate externally with any of your technical resources that you have contracted out. And they can just be the person who keeps everything running smoothly.

BS:                   Right. Regardless of whether you’re in-house or external, you do need that in-house person who can keep tabs on things. Because without that gatekeeper, things can go awry very quickly and other groups, other people can, with all good intentions, take ownership of a particular piece of the tech stack and then you start to have some issues, perhaps with some changes that are being made on one side that aren’t being reflected on another side of the tech stack.

GK:                   Yeah. And we have absolutely seen that happen with some of the companies we’ve worked with where that’s even maybe the reason they brought us in in the first place is because they’ve got this kind of disconnected technical stack and they don’t have that one single point of contact managing everything. So it really, really is critical that you don’t end up in a situation where you’re adding pieces and parts to your technical stack and then resulting in things not working together, not meshing well and not serving your content lifecycle overall. And with that, I think we can go ahead and wrap up this discussion. 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 Content ops stakeholders: Tech stack managers (podcast) appeared first on Scriptorium.

In episode 113 of The Content Strategy Experts podcast, Sarah O’Keefe and Dawn Stevens of Comtech discuss trends that are of interest to techcomm managers.

“We have an aging technical communicator community. We’re not necessarily attracting the younger generation. UX designer sounds more modern and interesting.”

– Dawn Stevens

Twitter handles:

Transcript:

Sarah O’Keefe:                               Welcome to The Content Strategy Experts podcast brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way. In this episode, we talk with Dawn Stevens of Comtech about trends that are of interest to techcomm managers. Dawn, hi, thanks so much for being a guest on the podcast today.

Dawn Stevens:                               Hi, Sarah, thanks for having me.

SO:                               Absolutely. So to get things started, for those of us who don’t know, tell us a little about yourself and Comtech and also the Center for Information Development Management.

DS:                               Sure. Again, I’m Dawn Stevens and I have been in technical communications basically my entire career, which is now well over 30 years. I’m one of those few people who started off saying, “I think I’ll be a technical communicator.” And so I went to school for it and have been working in it my entire career. And I was fortunate early on in my career to find Comtech, and so I’ve actually worked at Comtech twice. I worked for JoAnn for 10 years in the ’90s. Then I left because my children were small and I didn’t want to travel as much in those types of things, and then I came back after my youngest went to college and have been back since 2010. So I’ve been here at Comtech a total of, well over 20 years and I purchased it actually now five years ago, if you can believe that, Sarah, five years.

SO:                               Yeah.

DS:                               So Comtech is a competitor really of Scriptorium from, your introduction is, “Yeah, that works for Comtech as well.” We’ve been in existence since ’78, I believe is when Joanne formed it. And then about, oh, 25 years ago, she started the Center for Information Development Management, which is an organizational membership for managers largely to talk about concerns that have to do with managing technical communications and the challenges that are associated with the unique people that you manage and the people that you have to work with in terms of stakeholders and so on. And so that membership organization sponsors conferences and things like that.

SO:                               Yeah. And so in my mind we’re friendly competitors.

DS:                               Yes, that’s right.

SO:                               Because every once in a while we bid on the same project and one of us gets it and the other one doesn’t, but what I think is more important is that we as business owners and all of that, we have a lot of the same issues and challenges. So I really value having access and getting to talk to you and people like you in that peer group about all of our mutual pain and suffering.

DS:                               Absolutely.

SO:                               So with that position that you have as an industry consultant and also with CIDM, I wanted to ask you about trends, like what’s happening in techcomm that’s of interest or maybe the techcomm managers are terrified about, and I guess we really have to start with hiring, right?

DS:                               Yeah, absolutely. It’s an interesting time, the last couple of years with the pandemic and some of the changes that have been just general in any kind of industry that whole quote unquote “Great resignation” is that really impacting us. I would say there’s definitely been challenges as managers of people are leaving, people are not necessarily leaving the industry, but redistributing is what I’ve seen a lot within my clients of, oh, there’s greener pastures over here, there’s a bit more competition, I guess, for getting people. And I’ve got a lot of people who keep coming to me and saying, “What do we do to attract people?” And there’s been some interesting challenges associated with, well, what are we looking for? What kinds of people should we be looking for? How do we make the industry as a whole more attractive?

SO:                               Yeah. And redistribution or resorting maybe is a really interesting point because people aren’t… Some people are leaving the industry across the board, not just ours, but a lot of people are just going from the big company to the small company, or they’re moving up in the world or they’re leaving the company that won’t let them continue to work remotely, or they’re leaving the company that isn’t going back to the office.

DS:                               Right.

SO:                               There are some people out there that think offices are fun and that want an office as oppose to working out of their house. So within that, are people moving into certain kinds of specialist positions or generalist positions? What does that look like?

DS:                               Yeah, I think that’s actually the key piece of this redistribution or resorting is that there’s been I guess, a cycle that I have seen over the years of do we have generalists, we have technical communicators who can basically do everything. You write, you index, or you create a taxonomy nowadays. You have to be able to deal with your formatting, in some manner you have to create your own art, all of those types of things as a whole, generalist you need to be able to do everything. Versus there are specific areas that maybe interest you in within technical communication more than all of these other things, you’re better at all those. If you ask me to create an illustration for technical manual, you’re going to be very disappointed.

DS:             So the people don’t have all of those various skills, and so one of the things with this resorting that I’m really seeing is do we need to specialize more? With things like structured authoring a decade ago, these questions started coming up of, oh, do we need an information architect? Do we need content strategists, etc, as a specific position, or is that something that everybody should just be able to do? And what I think I’m seeing more and more is no, we’re backed into that trend of we need the specialists, we need somebody who absolutely understands content strategy or information modeling or information architecture, whatever you want to call that to really think about what are our goals, what kinds of content are going to meet the needs of our particular customers and how do we structure and design those particular things.

DS:                               And then somebody else who can write those things and somebody else who can program those things or film those things, or whatever those things happen to be, somebody who’s an expert in SEO, how can people find that content? So I’m seeing more and more of, I need to find people who have these specific skills and that’s a challenge when you think about a lot of budgeting. Budgeting tends to be head count where you can have 10 people. Whatever it happens to be and the idea that, well, of my 10 people I’ve only got two people who actually want to be writers and then somebody who wants to be a strategist for this, and an expert in that, that can be a big challenge for the managers.

SO:                               Right. And now your team of 10 with your one information architect, the information architect quits, and the others are all specialized into not IA, and now what do you do?

DS:                               Right.

SO:                               So there’s a risk. Yeah, I’ve always kind of associated generalist versus specialist with small company versus big company. If you have one writer or two, or one or two technical communication people, they’re going to have to be generalists because you’re not getting an illustrator or an editor.

DS:                               Right.

SO:                               But it does seem as though some of these bigger groups are swinging in some ways towards, well, we do want some of these, we’d like to have overlapping skills and we want to have the ability to take you or me and assign me to a new project that I’m not so specialized that I can only write this one thing. Now, how do some of those newer titles fit into this? I’m hearing UX writer, I’m hearing content design. The other day I actually saw somebody that said, “What do you call like a UX writer for technical content? What would that be?”

SO:                               And I thought, “Well, that would be a technical writer.”

DS:                               Exactly, “Oh, well, that sounds so boring or unappealing in some manner.” And I’ve always laughed about job titles to a certain extent, at one point in my career I just said, “Call me the scope change goddess,” because I was doing so many projects where the projects kept changing, I’m like, “That’s my new title.” So titles have not seem like they shouldn’t be that important and yet they are and what do they do is certainly associated with that title. And there in is where I got a lot of people in CIDM are talking about that of like, “Do you have any good sample job descriptions for? What is it that an IA does or a UX writer does, or those types of things, and what does distinguish them from what we’ve always called a technical writer?

DS:                               Are there special skills that make you a UX writer as opposed to just a technical writer? And I think that there are potentially aspects of that certainly of understanding in a UX situation of space and how things fit together and how the I goes through an interface and those types of things. So I think there are probably some special skills that you might call out. I don’t know that means the technical writer didn’t have them in the first place, but in terms of what you’re emphasizing for one of those particular job descriptions, I guess there’s an emphasis more on a specific title.

SO:                               Yeah, and it is obviously short form, shortest possible form writing if you’re doing-

DS:                               Absolutely.

SO:                               Strings that go on a software application versus a long form. I’m going to explain to you everything that you need to know about relational databases, but how do you do that? I guess they be subspecialties, right?

DS:                               It could be. I think there’s an interesting thing that just occurred to me, is that of course the UX part, the user part of it and we talk a lot. You’ve talked about it, I’ve talked about it, of the importance, the success of a technical writer is understanding their audience and who those users are. And yet I still see that struggle happening a lot, is that technical writers, oftentimes in an organization are banned from talking to users. That, no, you weren’t allowed to talk to them, I don’t know what the fear is per se, but you don’t talk to them, only these types of people and oftentimes that user part of a title, the user experience gives you maybe that permission to talk to people, does that imply potentially skills that are different? We know we’ve seen a lot of presentations, certainly about how technical writers tend to be more introverts.

DS:                               I know JoAnn did for a long, long time, Myers-Briggs test of every single person she could get her hands on in the industry and said, yeah, mostly they tend to be introverted. Maybe they don’t want to go out and talk to their users and so forth. They’re just happy sitting at their computer and writing. And there’s that maybe implication that if you’re a UX writer, there’s more of that, “Hey, you need to go out and understand what your users really need.” I don’t know that I want to draw that line, but it’s something that just occurred to me as we were talking.

SO:                               Yeah. It also feels to me based on really no evidence or research whatsoever, we should clarify that UX writer, it’s the new title. And the old, old title was technical writer, and then we had technical communicator and we’ve had information developer and we’ve had some other things like that, API writer maybe, and the write the docs people will talk about documentarians, but UX writer feels like the cool new thing.

DS:                               It does and I think that’s an important aspect. We have an aging, technical communicator community, people have talked about that in the past is that we’re not necessarily attracting the younger generation and something that sounds a little more cool, like you said, of being a UX designer, maybe sounds more modern, sounds more interesting. If I’ve talked to a variety of young people, I’ve asked some of the people who are in our industry that are younger, why is it that our AI industry is aging? And it’s been interesting to hear them say, there is that perception of, well technical writing, it doesn’t have a big impact to the world and that a lot of this new generation is wanting to make an impact, make sure that they’re saving the world in some manner, joking about just like area of waste of like, “Oh, good God, if you print something,” that nobody wants to be associated with, oh, you’re creating printed content, that’s a big wasted.

DS:                               And even just the idea that from a writing perspective, you create manuals. Well, does anybody really read those manuals? At least with a UX design, they’re using the interface. So you’re having some kind of an impact on a person and what I’m really hearing, and I’m not saying that I didn’t want to do that when I was young either of making an impact, but I definitely seem to hear it more than ever that I don’t want to write something that nobody ever looks at, I want to have an impact on people and make a difference in their lives.

SO:                               Yeah. So basically we’ve had such bad press for, I’m going to say forever. Nobody reads the docs, et cetera. I will say the best definition of technical communication that I ever saw actually came from Tim O’Reilly, who said that it was the purpose, the purpose of technical content, of technical communication is to enable people to use the product successfully. And so it turns into this, it’s just like good editing, if you do it well it’s invisible. People rarely say, “Oh, wow, that was a really fun experience of reading a five step procedure about how to do a thing.” They just successfully get their washing machine to turn on or drain or reset and they move on with their lives. Yeah, I don’t know what that says about us as a group, other than I know that we are super, super terrible at marketing ourselves.

DS:                               Sure, sure.

SO:                               Horrendous, the worst and there’s a whole podcast in there about why that is. But if you ever have a chance, go to a conference that is only tech writers, immediately followed by one that is only marketing people and real at the difference. It is incredibly entertaining.

DS:                               Yeah. Well, I like the definition that you gave there, that if we did market it more that way, if we are enablers, but I think back to that UX design title and everything else, there is that ideal that has existed since long before you and I entered the scene too. We should be creating products that document themselves and isn’t that part of the implication of, oh, if I’m a UX designer or UX writer, I’m helping to move in that direction.

SO:                               Well, that’s fine. But then I look at the research that says that 20% of product returns are because people can’t figure out how to use the product. So yes, the products should be obvious and intuitive and self-documenting, and self-healing and all the rest of it, but they’re not.

DS:                               And that gets to one other aspect-

SO:                               It’s just not.

DS:                               I think it gets to one other aspect of hiring or skills that really managers need to be thinking about is, what is the relationship of the writer to the product designer? Is that oftentimes as a writer, you’re trying to document something and make it sound like a feature or those types of things, or at least make it usable. And you can immediately see here it would be a whole lot easier to write this, or we wouldn’t even have to write it if you could just make this one tweak to the way you’ve designed it. But we oftentimes see ourselves in this position the way they’ve been hired in as a technical writer, the way that corporate culture is, whatever those factors are, that we’re not the expert. The people we deal with are the subject matter experts and we’re just the writer. And I’ve spent so much time with my clients coaching them to the idea of, no, you’re not just a writer, you are the writing expert or the user expert, or let’s put the word expert into our title as well.

DS:                               And yes, we’re dealing with a subject matter expert who knows what they did, what they have designed for the product, but that oftentimes needs some tweaking and can we build that relationship between them? And from a hiring perspective, that is something to take a look at is how confident are the people that you’re hiring? Will they speak up? If they have a seat at an agile development table or that type of thing, would they say something to say, “I think we could improve this,” and then that would save me 20 pages of writing.

SO:                               I think that’s a really good place to leave this. So I’ll be curious to see what the people listening to this come up with in terms of feedback, because I think you and I have some strong opinions on where this is going and why going the way it’s going. So all those of you out there, speak up, we want to hear from you, see what you think, and we might need to do a follow up on this one depending on what comes back. So Dawn, thank you. I’m going to wrap things up here. 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 Trends for techcomm managers (podcast) appeared first on Scriptorium.

In episode 112 of The Content Strategy Experts podcast, Elizabeth Patterson and Bill Swallow discuss content scalability.

“As you start approaching a greater percentage of bells and whistles in your process, the more work it takes to get each bell or whistle in place.”

– Bill Swallow

Related posts:

Twitter handles:

Transcript:

Elizabeth Patterson:                   Welcome to the Content Strategy Experts Podcast, brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way. In this episode, we talk about content scalability. Hi, I’m Elizabeth Patterson.

Bill Swallow:                   And I’m Bill Swallow.

EP:                   And we’ll go ahead and kick things off today with a question. Bill, what does it mean if your content is scalable?

BS:                   Well, scalability basically means that you can increase the volume of your content, deliver to multiple different channels and add new channels as needed, translate into more languages and extend other facets of how you are developing and using your content without really bottlenecking the entire process of content production.

EP:                   Great. In order to have scalable content, you have to remove points of friction from your content life cycle. How can you go about identifying those points of friction?

BS:                   Well, one point is whether or not you have things essentially locked down, so things like templates or some kind of underlying structure that is enforcing rules on how the content is being developed. Otherwise, just making sure that you have some pretty rigid and… I shouldn’t say too rigid, but rigid, yet allowable processes in place and things that are repeatable.

BS:                   So that when it comes to developing a new piece of content, that you aren’t necessarily starting from scratch, that you have a game plan from getting from point A to point Z without stumbling and without adding any additional things that are unhandled by someone else in your content chain. Another area to look at is how reusable is your content and how smart is your reuse process? Are you copying and pasting across places, or do you have some kind of intelligent reuse via some kind of reference?

BS:                   In the former situation where you’re copying and pasting. You have to kind of guarantee that any time you reuse that content, that it is written in a way that is reusable. If you modify that language, then you suddenly have a discrepancy between where it’s used in other places. Likewise, if you have to then update the information, you have to update it in every single place where you’ve reused it or copied and pasted it. If you’re using intelligent reuse, that gives you a lot more flexibility.

BS:                   You can essentially reference one piece of content exactly how it’s written and use it wherever you want it to appear. You can also do a little bit of work with conditional text variables and other types of things to make the content unique for where it’s being used in any one instance, but you’re still reusing a singular written piece of content across multiple places. You’re are not duplicating it. Another one is to look at the publishing process and how hands-on that process is.

BS:                   If you are manually creating page flows, if you are doing some really high dynamic changes between different pages, moving images around, and so forth, your production schedule is likely, or your production process is not terribly scalable.

EP:                   Make it a little more difficult.

BS:                   Exactly. It makes it a lot more difficult. It takes a lot more time to produce. You might have something that looks extremely polished in the end, but it takes you many, many, many hours to get there.

EP:                   Right.

BS:                   On the flip side, if you have something that’s completely automated, as long as there are rules in place as to how the publishing process goes and how things are formatted as the publishing process is going, it’s a completely push button operation, in which case your content velocity for publishing has skyrocketed.

EP:                   Right. You might not have all the bells and whistles if you are taking a more hands-off approach. But if you’re doing everything yourself manually, it’s just not scalable.

BS:                   It isn’t. No. It’s not to say that you won’t have the bells and whistles, but there is. In any kind of automated situation, the more you bake into the automation, the… Basically as you start approaching a greater percentage of bells and whistles in your process, the more work it takes to get each bell or whistle in place.

EP:                   Right.

BS:                   Another area where you can remove a lot of friction is in your localization process, and that really comes down to how content is translated, how content is made available for translation, and essentially how you’re baking internationalization practices into your content development. The more that you have baked in at the beginning using good internationalization practices, the easier the localization stage and the translation stage… The localization process, including translation will be.

BS:                   This way, you are setting yourself up to use a lot of reusable factors and being able to reduce the overall number of words and so forth that you need to translate in a unique setting.

EP:                   Right. Identifying these points of friction and removing them is going to take a little bit of time, but it is essential to give you that scalable content. I want to shift focus now a little bit to web publishing. Are there any scalability issues when it comes to web publishing?

BS:                   Well, in terms of scalability, especially when it comes to technical content, web publishing can get a little hairy. The sheer volume of content that you’re producing could pose some problems. The technical content that you’re publishing through to let’s say a web CMS is highly templatized, highly standardized usually, and it’s very massive in scale. It’s kind of like drinking from a fire hose at that point. Traditionally, when you’re publishing on the web, usually pages are crafted one at a time or in small batches.

BS:                   Let’s say you’re doing a small support site, or what have you. Those pages, they might be templatized and you may have some ways of importing content into them. But by and large, they’re created manually. But when you’re talking about publishing a massive reference, for example, some kind of an API reference or product manual or what have you, you could be talking about hundreds, if not thousands of generated pages.

BS:                   It takes a very different approach to staging that content for the web than using a traditional web development mentality. The entire web system for that particular guide, for example, is generated all at once. There’s really no way to go in and hand massage things on the fly. It’s all being generated at once and ready to go.

EP:                   Okay. When we’re talking about scalable content, how exactly does the review and editing process work?

BS:                   Review and editing happens way behind the scenes. Taking a page by page review is fine, and you can certainly do that with the output that’s being generated from this collection. But you’d be looking at hundreds or perhaps thousands of pages at once to do this type of review. A lot of the review and editing really needs to happen on the source side and needs to be fixed before any publishing begins. Once any fixes are implemented, then the output can then be regenerated.

BS:                   This is true for really all output types when you’re talking about pushing out especially to multiple different channels at once. Whether it be PDF or web or some kind of API related repository, or what have you, all of that content is generated at once. If you need to fix it, you go back to the source and do a review cycle within the source before you get to that publishing stage.

EP:                   Okay. You mentioned earlier drinking from the fire hose. I want to come back to that for a minute. How do you best prepare for the fire hose of content?

BS:                   I like how you phrased that. When I talk about the fire hose, I mean, yes, there’s a lot of content going through. It’s not really an issue as far as publishing things like PDFs. Because in the end, you may have a fire hose of content going through this publishing process. But in the end, you still get a PDF file. But there are some big considerations for publishing to the web. You really have to have a framework for publishing a massive amount of content all at once available. You have to have the right targets lined up.

BS:                   Where is this content going to live? Is it going to get pushed to a staging area, and that’s going to get moved out into some kind of published area? Do you have a direct published pipeline? As soon as you click the generate output button on whatever you’re using, it generates the output and you can then go online and view it on your website. You need to think about how that’s going to work and what the pieces are that need to happen in order to get the content to the right place for that web server.

BS:                   You also have to have the right metadata in place, both in the content and in the web CMS, to make sure that as content is being received, as it’s being generated, that it’s being assigned the right metadata, both for search, for personalization, and really any other way that the content is going to be used on the site. If you have let’s say a customer portal and everyone has their own login, they’re probably assigned a certain user group. They’re probably assigned other metadata, such as what their client name is.

BS:                   You can provide easy access to perhaps the products that they have versus the products that they don’t have, so that they are free to just search your repository and pull back all the results that pertain what they own versus what somebody else owns. And other things that facilitate how the content is going to be used on the web. You also have to make sure that where this content is being published and where it’s being shown on the web, that it has all the right UI elements built around it. You might have some kind of…

BS:                   Frameset is a bit of an old word, but some kind of a wrapper UI that might have certain type of branding around the content in addition to the content itself. Perhaps another layer of UI elements, buttons, fields, so forth that they can use perhaps to refine a search or even to provide a search console that they can use to search through the content that’s being provided to them. There are a lot of things to really think about, and you need to line all of that up before you push that content out to the web.

BS:                   Otherwise, you might have a rather unruly mess of files to then go ahead and wrangle and apply each metadata piece and each personalization piece and assign other aspects of the web experience to each individual piece of content.

EP:                   Right. Definitely take the time and make sure you have those elements in place and things set up correctly so that you’re prepared for this.

BS:                   Exactly. Measure twice. Cut once.

EP:                   I think that is a really good place to wrap up. Thank you, 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 Content scalability (podcast) appeared first on Scriptorium.