Scriptorium

In episode 101 of The Content Strategy Experts podcast, Elizabeth Patterson and Sarah O’Keefe talk about what life is like with and without a content management system (CMS).

“You have to decide, by looking at your particular organization, whether you need what a CMS will give you. You will get improvements in consistency and automation for formatting and traceability. You can get improvements in translation because you have more consistent content and better workflows.”

– Sarah O’Keefe

Related links: 

Twitter handles:

Transcript: 

Elizabeth Patterson:                   Welcome to The Content Strategy Experts podcast brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way. In this episode, we talk about what life is like with and without a content management system. Hi, I’m Elizabeth Patterson.

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

EP:                   And today we’re going to dive into the world of content management and CMSs. So I think it would be great to start with a couple of definitions. Sarah, could you tell us what content management is, and also what a content management system is?

SO:                   Content management is, according to Wikipedia because that’s always the right place to go, is a set of processes and technologies that support management of information, basically. So collecting, publishing, managing, editing, delivering. A content management system or a CMS then is software that helps you do content management. So how do you create, how do you modify, how do you deliver digital content? Within the CMS world, we then distinguish, there are hundreds, if not thousands of CMSs with different kinds of sub-features or sub-specialties, learning content management systems for learning content. But in our world, there are a couple of important ones. One is the distinction between a back-end content management system and a front-end CMS. A back-end CMS is where you park the content that you are creating, editing, reviewing and approving. And a front-end CMS is where you park the content that you’re delivering.

SO:                   So a lot of today’s websites, maybe most of today’s websites, run on web content CMSs. So it’s a delivery system of some sort that controls the display of what we’re doing and what we’re dealing with. Now, in addition to all of that, in our world of structured content, you also talk about a component content management system or a CCMS, and that is a specialized back-end content management system that lets you manage typically XML, but structured hierarchical content. It typically does not have formatting associated with it. That’s the job of the front end delivery system, whatever that may be. But a CCMS is there to help you manage modular, smart, intelligent XML content. If you’re involved in any sort of content operation, if you work in content and you have any scale at all, then you know that managing the content that flows through your operation is just an enormous challenge.

SO:                   Keeping track of who’s writing what, and what’s already been written and, “Was this delivered, and is it up to date. And when is the next time that we have to update it, and when does it expire? This thing should go away once a certain event happens or after a certain amount of time.” So a CMS can help you keep track of your content and do a lot of the heavy lifting around that sort of governance, but also around authoring, delivery, management, all the things.

EP:                   Right, because there’s so much involved when we’re talking about content management. And so really what I want to talk about today are some of those different things that you are going to deal with when it comes to content management and what those might look like with a CMS or without a CMS. So I think a good place to start would be traceability. This is really important because, especially if you’re in a regulated industry, there’s a lot of legal stuff associated with that. So we can start with a definition of traceability.

SO:                   So traceability means that you can connect the change that you’re making in your content with the reason that you’re making that content change, or possibly with the person that made the content change and the person that approved it. So you want the ability, and as you said, especially in a regulated industry, you want the ability to say, “Hey, somebody reported a mistake in our documents on this date. And we tracked that mistake. And then we went over to our content management system, or over to our content corpus, and we made a change related to this defect that was reported. And then we published it on thus and such date.” So traceability means that you’re following that change from the request to the content change that was made to the approval to the publishing and delivery, and possibly expiring the incorrect version that was in there. Now, traceability without a content management system, almost certainly means that some very depressed person has a spreadsheet.

EP:                   A big spreadsheet.

SO:                   A big spreadsheet. And I’ve said this before, but people say, “Who has the number one market sharing content management systems?” And the answer is Excel. That is the number one way that people manage content. It happens to be a really painful way of doing it, but that is in fact by far the most common way of doing this. So you create a terrible spreadsheet, you track the inbound request, you track who you assigned it to, you track when they made the change, you track when they publish the change. And somewhere there’s somebody with a full-time job of just keeping track of that in the spreadsheet. If you have a content management system, then what you can do is you can embed the request for the update or the correction or the change into the content itself.

SO:                   Or you could give the change request, which if this were software, we’d be talking about bug tracking, you could insert that ID into the CMS or into the content itself. And then when you publish the change request, the idea is carried along. So when you look at something, you say, “How was this paragraph modified?” You can trace back to what happened. “Why was that paragraph modified? Who modified it? When did they modify it? And also why?” So that’s traceability. And if you’re doing video game documentation, then traceability is probably not your top priority, but if you’re in a medical devices or pharma, or potentially machinery that people operate and can get hurt if they don’t operate correctly, you do develop a pretty solid interest in traceability.

EP:                   Right. And speaking from someone who has plenty of past experience with spreadsheets, it’s really easy to make mistakes when you’ve got a really long spreadsheet. And so when we’re talking about the medical industry, that can be very problematic when people’s lives are at stake.

SO:                   Right. And in addition to that, it’s just mind numbing, right?

EP:                   Mm-hmm (affirmative).

SO:                   The computers are really good at keeping track of stuff like this, and humans are really bad at it. So let the computer do it. I mean, I just don’t have any interest in having to manage the monster spreadsheet of death. I don’t want to.

EP:                   Right, work smarter not harder.

SO:                   Exactly.

EP:                   So let’s talk some about collaboration, because when you’re working in any team, you’re going to have to collaborate. Or if you want to be successful, you’re going to have to collaborate. When you have a team with multiple writers, things can get confusing if you don’t have the right processes in place. What might collaboration look like with and without that CMS?

SO:                   I think probably all of us, in days past have worked in organizations where the collaboration process was literally that you would say, “Oh, I need to update this piece of content.” And you would pop up from your cube and yell at the people in the cubes around you and say, “Hey, is anybody working on X, Y, Z document?” And they would all say, “Nope, you’re good. You can go work on it.” That works pretty okay in a group of, say three to four people who are all in the same location, working at the same time, and don’t have meetings where they might miss somebody popping up in the cube farm and asking that question. We need something a little more sophisticated than that to address A, you have 20 writers and we can’t have people popping up all the time.

SO:                   Plus your 20 writers are not in fact in the same location all the time or ever. And you need to just have a much more formal way of dealing with this. So if we need to collaborate, if you and I, just the two of us are working on a single piece of content, okay, we can create a Google doc and we can work in there together. And that would work pretty well. It gets a little weird if you get up to five or 10 or 15 people all in the same big document. At that point, you start thinking about like, “Oh, hey, Elizabeth, why don’t you take section one and I’ll take section two and then we’ll put them together later? We sort of chunk it down.” Or, “I’m working on a white paper and you’re working on a white paper, or we’re working on two different articles.”

SO:                   Okay. Well, now we have to think about, “I want to make sure that the changes that you make are reflected in my document. And by that I mean, whatever word choices you make or terminology that you choose, we need to be consistent about that. You might’ve written a really great product description, which I want to use in my document. And I don’t want to copy and paste because later you’re going to go back and change the product description and update it and correct it. And I just want that to cascade into my document.” So the collaboration becomes partly, “How do we author consistently? How do we establish a consistent voice and tone? How do we make sure our terminology is aligned?” And there’s not so much the content management system itself, but some of the things that you can layer on top of that. And then reuse, “I want to go and find that chunk of content that you wrote that I want to reuse.”

SO:                   And that’s much easier to do in a CMS versus saying, “Hey, Elizabeth, where’d you put that product description? Or where’s that logo?” What we don’t want is for people to write a bunch of content and stash it in their own private folders that nobody else has access to, because then you can’t share. So a CMS, they all of course are different, but they’re going to give you the ability to understand what content you have, where it’s being reused, what was changed recently, “Oh, I see that somebody touched the product description file. I should go look in there and see if that affects the content where I’m using the product description.” And again, lots of people are doing this with spreadsheets, and it’s terrible.

EP:                   So you just mentioned people storing that document in private locations. And that’s how you end up with different versions of the same document, which leads us to our next topic for discussion, which is consistency. So what might that look like if you have a CMS and if you don’t have a CMS?

SO:                   So versioning is a key part of that. If I can just be consistent about using the same bio for a person. Every time I publish a blog post, let’s say from one of our coworkers, we want to make sure that the same bio appears at the bottom of that page. We don’t want to copy and paste the bio in there a million times. What we want to do is just tell the CMS, “Stick the bio at the end of every single blog post written by Bill.”

EP:                   Right.

SO:                   Okay. And then that’s updated of course in a central location. And if you update it, the older posts get the updated bio, that type of thing. So you have some pretty straightforward version control over your content. Also, I mentioned terminology. So using the same words to mean the same things across all your documents. Terminology management is theoretically possible without a CMS, but in practice, it’s one of the things that people very often integrate into a CMS build. And then there are two other things which have to do with formatting consistency.

SO:                   So if you think about just pushing content, you want to publish a document or an article or a book or whatever, you want to have some formatting consistency. You want all your notes to look the same. You want all your warnings to look the same. You want all of your little summary paragraphs at the beginning to look the same. Because if they don’t, you make my life much harder for the person who’s reading the document. I mean, if I read a magazine article, I slowly learn that the byline for that author is always at the end of the document, those kinds of things. With CMSs, now the ones that we work with, the component CMSs has pretty much stripped off all the formatting and apply that upon delivery.

SO:                   So that gives you a really actually rigorous degree of consistency in terms of formatting, but even an unstructured, more of a web CMS, does have the ability to have template-based publishing. So you have a magazine article template, or you have a blog post template, or you have a knowledge-based article template. And that means that your document formatting, when you deliver it is going to be consistent. If you live in the non-CMS world, in a file-based workflow, then you probably know that rebranding happens, right?

EP:                   Mm-hmm (affirmative).

SO:                   So your company gets acquired by another one, or you just decide to change your logo, or you decide to change your company name, and you’re looking at the set of 1,000 or 10,000 or 100,000 files in some word processing or page production software, and you have to rebrand them all. You have to go through there and replace all the logos and replace every mention of your product name, or your company name with the new one. That is-

EP:                   Lot of work.

SO:                   … it is crazy expensive. And so we’ve had cases where actually moving into a content management system with all the headaches and all the costs that that entails, was justified because it was actually cheaper than going through and rebranding thousands of InDesign files one at a time.

EP:                   I think this has been a very insightful discussion, and I really want to close things out with something that everyone is going to ask. You can tell them about, of the great things about a CMS and why they should have one and how it’s going to make their life easier, but they’re going to want to know about cost. And a CMS does cost money. So why is the investment worth it?

SO:                   Yeah. So I guess we should. And this is probably a good point to mention that we at Scriptorium do not get paid by the CMS vendors, all appearances-

EP:                   Yes, correct.

SO:                   … to the contrary. And it’s also probably worth noting that there are actually CMSs… I mean, there’s a wide range of cost, from zero to millions of dollars.

EP:                   Right, depends on what you’re looking for.

SO:                   Depends on what you’re looking for. And there are open source CMSs, not so much CCMSs, not so much component content management systems, but there are open source content management systems. So that’s at least theoretically free, right?

EP:                   Mm-hmm (affirmative).

SO:                   Except of course it’s never free. It may be license free, but there’s going to be cost. So why is the investment worth it, or is the investment worth it? You have to decide, by looking at your particular organization, whether you need what a CMS will give you. You will get improvements in consistency and automation for formatting and traceability. You can get improvements in translation because you have more consistent content and better workflows. So you can look at those issues, but you have to basically look at those issues and those costs and then decide is the investment in a CMS, of course, all the pain of getting there, worthwhile to get those improvements. Among our customers, the most common justification that we hear for moving into a content management system for the first time, there are basically two. One is mergers. And I would put rebranding as a sub-issue underneath that.

SO:                   But with a merger, what typically happens is that you have two or three or five groups that each have their own content workflow. They were all doing things different ways because they were two or three or five different companies. And what you can do is you can consolidate. Now you could of course consolidate onto a single file-based workflow, but usually when you merge, you end up with a much bigger group. If you had five groups of three people, and now you have one group of 15, if you have 15 writers, you can probably justify a CMS on efficiency alone.

EP:                   Right.

SO:                   So mergers is a big one, to allow you to consolidate your tool set, not have five different tool sets that you have to support. And then the other one is localization and translation. As your organization gets bigger and has to go global, you have to start… First, it’s like, “Oh, we’re going to have to do Spanish. And oh, we’re going to have to do Canadian French. And oh, we’re going to Europe, but we’re only going to do four languages in Europe. We’ll do FIGS, French, Italian, German, Spanish.” And then, “Oh, whoops, we’re shipping into Russia and Turkey.” And, “Oh wait, we’re going to East Asia.” And next thing you know, you have 20 languages. The inefficiencies in a file-based workflow on two or three or five or six languages get multiplied. Every time you add a language, you add inefficiency or you duplicate or replicate that inefficiency. So when you have 20 languages, it gets really painful. So localization, which means streamline the content development so that the translation workflow goes better, is the other big justification that we see for moving into a content management system.

EP:                   Well, thank you, Sarah. That was a lot of valuable information.

SO:                   Well, 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 Life with a content management system (podcast) appeared first on Scriptorium.

In episode 100 of The Content Strategy Experts podcast, Bill Swallow and special guest Jodi Shimp discuss their experience with digital transformation and implementing a new content strategy at Crown Equipment Corporation.

“The initial and earliest win in the project was the go-ahead to even bring on consultants to help us determine what the scope would be and what the true need would be across all the different groups.”

– Jodi Shimp

Related links: 

Twitter handles:

LinkedIn profiles:

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’ll talk with Jodi Shimp about her experience with digital transformation and implementing a content strategy at Crown Equipment Corporation.

BS:                   Hi, everyone. I’m Bill Swallow. And today I have a very special guest, Jodi Shimp joining me. Hi, Jodi.

Jodi Shimp:                    Hi, Bill. Hello, Bill. Hi, everyone.

BS:                   Thanks for coming here. So before we dive in, can you tell us a little bit about yourself?

JS:                    Yeah. So, like Bill said, I am Jodi Shimp with Crown Equipment Corporation. I have been working with Scriptorium implementing a content strategy in the past, probably about seven years. So we went from a very unstructured content development process, and I started that as a technical writer, and over the past seven or so years, we’ve been working on a big digital transformation of all that content at Crown.

BS:                   And what was your reason for starting that project?

JS:                    For Crown, there were really two major starting points that got our strategy rolling from people, just talking about a need for something different to actually moving things forward. And for the main content teams in marcom and techcomm, it was the fact that we had overlapping product in different regions and overlapping content to support that project in different regions, being supported by two or more different content teams. For executives, the big pain point was the need to better support our globe growth and our burgeoning global market. Their need was to fix translations because at that point we did have a patchwork of translations and content processes, but we just needed to get that overall into something smooth that felt like it was a consistent process as opposed to ad hoc responsiveness.

BS:                   So it was more or less both getting your arms around those source content development problems. And then also being able to get your arms around the translation spend.

JS:                    Right. Thankfully it aligned very much to be two birds with one stone, if you will, because the content creators, the problems that they were seeing in their source content are what was actually causing a lot of the problems in the localization processes and content. So fixing the source was really the key to getting it all right.

BS:                   And I suppose that came with a bunch of wins during the course of the project.

JS:                    It did. So really, the initial win and the earliest win in the project was that initial go-ahead to even bring on consultants to help us determine what the scope would be and what the true need would be across all these different groups. I was told quite a few times that I wouldn’t be able to get financial support for a non-engineering project. And I was fairly new to Crown. In reality, the company really does a great job in investing heavily outside of engineering and design and development and all kinds of other places, but I didn’t know that.

JS:                  I think the key was really listening to the executive pain points and goals, and then determining how the things that the content teams needed to change could be improved to truly align, to support the company objectives and then move everything forward.

JS:                    Another big win for us with the approval to invest in that proposed strategy and actually begin the project. I ended up presenting the vision and objectives to the entire executive suite, including the president, owner and all the VPs. It was another case where probably my determination, when I was told it probably won’t go forward, really came into play. And I think you do need someone who is willing to put themselves out there when there’s some doubt on things, but it was definitely the right thing for the content teams. And it was the right thing for the overall business strategy and objectives at that time.

BS:                   So really bringing it back to what are the core pain points that the company as a whole were seeing rather than focusing on the writers could be more efficient if they did X.

JS:                    Right. Because it really did come down to focus on what was important to executives and the overall business goals. Instead of spending a lot of time discussing all the ways that a content strategy would make things better for content creation teams, I really worked on working with different directors and above to highlight the parts that would further the primary goals of each group and of the overall company. 

BS:                   So with those going on, is there anything you’re particularly proud of with regard to those goals?

JS:                    Yeah. So, really the overall strategy. We proposed a multi-layered digital transformation, and that crossed all kinds of departments and locales. We knew that the project would need to include authoring guidance with terminology and style. We knew that it would require structured authoring, a translation management system, and then a content management system to really get it done and done well. And then even more important than all of those things, we didn’t want to automate bad processes. We knew it wouldn’t be short and quick, and we knew it wouldn’t always be painless.

JS:                    But one of my favorite days in the entire project was pretty early on, after we had gotten support from the executive VPs, there was a meeting with executives from our regional headquarters across the world. And the senior VP of Engineering was talking with other VPs before the meeting started and he began discussing one of the large visuals. And when I say large visuals, I mean, we had a content inventory printed out and that was crazy to see all the different languages and all the different content. It literally covered an entire wall of this giant long room in one of our buildings. And he was discussing that with some of the other VPs in there. And then before you know it, he was passionately presenting what I had shared with him only days before.

JS:                    So that was the point that I was like, not only does he understand the goals of something that’s completely outside of any of his verticals, but he understands how it affects the company as a whole in his vertical specifically. And so once I realized that we had support at that level outside of our own vertical, I knew that we could actually accomplish this. So, that was super exciting.

BS:                   So he was totally bought in at that point.

JS:                    He was, and that was a really important win for the strategy.

BS:                   And it sounds like, before you had a bunch of different groups kind of supporting their own regional needs or their own product line needs. I know from working with you that you had the opportunity actually to create a more central group to support all that. And how did that help things?

JS:                    We did. So after the original strategy was approved, for the first year, there was a lot of solo work that happened, but we were able to show how a team would better support the initiative long-term. As we proved things out and actually implemented pieces of the strategy, at each point, we were able to show where long-term, whether it would be in the governance area or just kind of a systems administration area, content strategists, and then especially on the localization team, where those people could be very effective long-term in managing all of these different things around content strategy.

JS:                    So they turned into full-time positions that turned into its own small little department over time, that’s now running very lean still, but quite effectively. Definitely shown the value.

BS:                   That’s awesome.

BS:                  And I’m sure it really helped with managing all the change and being able to roll out all the training and being able to support all these different teams having that central group.

JS:                    It definitely did. And from a localization standpoint, again, for example, having experts within the company that people know that they can go to, it means that not every group is completely trying to reinvent the wheel every time they want to add something.

BS:                   Can you speak a little bit more about the change management process that you used and were there any really big obstacles that you had to overcome in that regard?

JS:                    Yeah. That was probably-

BS:                   Probably a loaded question.

JS:                    Yeah. And it was probably the most unanticipated thing for myself that I experienced in the project because I’m not adverse to change as an individual. And so I guess I did not understand the depths of the change management requirements that such a big change would cause for people. If I were to go back and do things again, that would probably be the place where I spend more time with the different departments before the project even started to talk about “What does that change mean? What is it going to look like? What is it going to look like when it’s messy because it isn’t always perfect and straightforward? So how are we structured and how are we anticipating the need for adapting the plan as we go or implementing that change?”

JS:                    There was an opportunity for the team to do a lot of empathetic listening, to really determine the pain points that we could solve, that sometimes people didn’t even realize existed, but they also couldn’t always see how the transformation would be needed in the coming years to support the growth that was coming, the digital change that’s coming across the world. So we did a lot of design thinking sessions, a lot of show and tell to get people on board. So once we really focused in, in the beginning, we tried to do everything all at once and we stumbled there. So we really focused in on one area and one group and one thing to get right. Once we got that right and we started being able to show that to the other groups and do more show and tell sessions, then we were able to get other groups more rapidly on board and more willing to deal with the painful pieces.

JS:                    So one of the wins on that though, was really finding the go-to person in each department and find that expert because we found that when we could get the expert’s idea on board and really listen to their thoughts and their concerns and help alleviate those thoughts and concerns and get them really engaged and on board with it, then they could bring the rest of their team on board with them as well. 

BS:                   Excellent. So you mentioned that the change management was a really big obstacle for you. Did you do anything during the project specifically to combat those particular obstacles around change management and what worked well?

JS:                    Yeah, so I mentioned a few minutes ago that of our biggest obstacles was really knowing where to start. Since that first year was such a struggle and I didn’t really have a team and my direction was just do it all, we did try to do it all. And once we got a small team, we were still trying to do it all. But we were able to then really step back one day and take a look and say, we keep trying to do everything and we just keep hitting walls and we keep going in circles, and we get something done and then we feel like we’re redoing it over and over again.

JS:                    With all of that complexity in mind, we really talked about and presented to our director at the time, can we break this up into smaller goals? Because tackling it all at once, we’re getting a lot of resistance, a lot of teams feel like we’re just spinning and wasting time and never get anything done. So what if we take our approach, instead of doing it all, and really focus in, on a certain team and a certain set of processes or content type. And that really seemed to help because people at Crown stay there for a really long time and even their entire careers. And so someone always knows who to call to get something done. It’s really great from a get-it-done perspective and we have a lot of people who are always trying to do the right thing, but answering those questions immediately and doing things immediately, sometimes at the expense of a process, it’s really hard on processes.

JS:                    So while we were configuring our content management system and the workflows that were part of that and everything else, we were sourcing a centralized translation management system. So we were working in two parallel paths, but on small departments and small areas first and getting it right there. And then as we brought in different groups and different content types, we’ve changed how a lot of things are done from a process perspective, who is involved in the content creation, when content creation begins, how versions are controlled and released, and all of those things. We’ve gotten to the point now where content development, terminology development, and things like that are actually a part of our engineering product development processes. And for a manufacturing company, that was a really big deal.

BS:                   It’s a big change.

JS:                    It’s a huge change. And the content management team, we learned so much. Like I said, we all learned a lot and there was evolution in our process too. So we had had very much a waterfall project management plan in the beginning. And now we’re in a quasi-agile approach because some of our software development teams are that. 

BS:                   So you basically started small, focused on very specific things with a tools-last approach, which is phenomenal, being able to do that because a lot of times you choose a tool and you get the blinders on that, come in the box with the tool and never really look at different ways that you could be doing things. But it sounds like also even after you have the workflows and such in place and the tools in place that you still went back and were reworking some of those workflows and how people work together, what the content needs are, how things need to happen. So, that’s phenomenal, being able to put that all together and still have an evolving ecosystem with regard to your content there.

JS:                    I often get asked the question, “Well, Jodi, when are we going to be done?” And at first I kept thinking, oh my goodness, when are we going to be done? That kind of bothered me and pressured me in the beginning. And then I realized that, well, the content will never be finished. We’re always developing new product. We’re always developing new content. There’s always going to be new end points and new delivery methods. So in reality, there never is a done. Especially as digital will continue to change and transform how people interact with the content and interact with our product, there will always be a need for continual development and continual improvement. So switching to that kind of quasi-agile project management, it is going to be that way, I think, for a long time.

JS:                    And it’s important not to get stuck exactly where we are right now, because if we do get stuck, then in another 10 to 15 years, or maybe even half that time at the rate things change, then there’s going to be another group that’s sitting there saying, well, that’s the way they used to do things, but we need to change everything again, to do it forward. And I think this at least goes a long way into future-proofing our content and giving the opportunity for change, having much more knowledge about the content itself and the content being smarter and having all that semantic tagging and everything.

BS:                   So since you’re never done, I assume you have to kind of show some kind of return on investment over time. So what are you measuring to be able to show success?

JS:                    Yeah. So that was one of the things, being a manufacturing company, KPIs are important. And I’m sure they’re important in every industry, but definitely something that was hard to do. And I think that was a real struggle for all the content development teams at one point was to show the value of what they bring to the table because content development is looked at as a cost center in a lot of situations. If you’re producing 1200-page service manuals, because you have to, to support a product, it’s a lot different than selling those. 

JS:                    So it was really important to figure out ways that we could show the value and the return on investment for what we had done. One of the things that we couldn’t put a handle on was exactly how much the entire organization in all the different countries were spending on translations. And that was because some groups did have translation as a line item in their budget, and other groups just bulked that in with other costs in other costs areas. So, that was really hard to tell how much we were spending. We weren’t spending it all with the same vendors. We weren’t spending it all out of the same, like I said, budget lines. And we could kind of have an idea about what we might be spending, but no one really knew the answer to that.

JS:                    Establishing those KPIs to show kind of a baseline of where we were starting and where we were going to, it took a little while, but we were able to do it. So now we’ve published content for much larger audiences up to 37 languages, depending on what the specific content is. And even though our annual translation spend is higher than what it would have been in the beginning, our coverage is much more consistent and less frustrating and it’s much more extensive. So we were able to start showing a translation savings, an annual $1.2 million savings, which exceeds our budget, but compared to off-the-shelf, if we were just going to a translation supplier and handing them a piece of content and getting it back, we do know how many words we’re translating. So we can say, if we were just doing it in the old way, versus with all of these terminology management and translation management and translation memories, now we save about 1.2 million annually on those translations.

BS:                   That’s a lot.

JS:                    It’s a lot. It is a lot. And that was really easy to show an ROI faster. We had said four years is what we thought it would take and we were 18 months. So that was really good. And then now we’ve started developing KPIs on our content reuse, and that’s been something that our content strategy manager has been putting together with our supplier. JS:                    We’re also working right now on a new digital content delivery system that will take full advantage of all the technical content that’s produced every year, which it’s very extensive, but it’ll take full advantage of that and allow us to really publish digitally all that translated content and take advantage of all the work that was done on the backend of content development. And this new system will give us a new way to deliver all of that across the globe.

BS:                   That’s fantastic.

JS:                    It’s really great to hear the executive updates where other teams throughout the company actually talk about how the content management team and those systems are allowing them to achieve the goals what they were trying to deliver.

BS:                   That’s great. I really appreciate you coming on here to kind of tell your story and I’m so glad we were able to get you as a guest here.

JS:                    Thank you.

BS:                   Thank you.

JS:                    Thank you. My pleasure.

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 strategy success at Crown (podcast) appeared first on Scriptorium.

In episode 99 of The Content Strategy Experts podcast, Alan Pringle and special guest Larry Kunz of Extreme Networks talk about the evolution of smart, structured content.

“I’m a huge believer in big picture. We really need to stand back and ask ourselves, ‘What is this really all about? What are we trying to accomplish?’ It’s not about the content. It’s about the customer.”

– Larry Kunz

Related links: 

Twitter handles:

Transcript:

Alan Pringle:                   Welcome to The Content Strategy Experts podcast, brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content, in an efficient way. In this episode, we talk with Larry Kunz, about the evolution of smart, structured content. Hey everyone. I’m Alan Pringle. And today, we have a special guest on the podcast. I’ve got Larry Kunz here. Hi Larry.

Larry Kunz:                    Hi Alan. It’s great to be here. Thank you so much for having me. It’s a real pleasure.

AP:                   Absolutely. And I want to give our audience a little bit of understanding about your background. So would you kindly introduce yourself, and tell us a little bit about your experiences in the content world?

LK:                    Sure. I’ve been in technical communication, mostly in the computer industry, for more than 40 years. I won’t allow us exactly how many. I was working for IBM, when structured content came to be a thing, when DITA was being developed. I wasn’t one of the people who was developing it, but I was a very early user, and very quickly came to understand the value of structured content. I really thought it was a good thing, and my opinion has never changed. I have done time in marketing communication. And I’ve done training and consulting. But when the income tax form comes around every year, I still put technical writer as my occupation.

AP:                   And I remember, at one time, I had technical editor on mine. So I totally get that. And because you do have that really deep expertise, and we all know you got started when you were an infant. We all know that you got started very, very, early in this industry. But I think it would really help this discussion. And what I’m going to talk about is how smart, structured content has evolved. And for what it’s worth, I’ve been doing this for over 30 years now. And I will not be more specific than that. You’ve got a little more experience than I do. But I’m glad to be paired up, and to have this discussion, because I have seen things change quite a bit over the years. But on the flip side of that, sometimes it’s say, the more things change, the more they stay the same.

AP:                   So let’s talk about that, first, to level the playing field. I want to talk about, basically, what is smart structured content? Now, on the Scriptorium side, this is how we define smart content. It’s modular content with tags and metadata. And the formatting is separate. It’s applied later, based on the intelligence that you build in to that tagging and metadata. Now, I know before we started this podcast, we were talking about ideas. And you said you had a little bit of an issue with the term “smart content.” So I would very much like to hear your perspective on that.

LK:                    Sure, Alan. And I think your definition is an excellent one. I like to swing it around to the point of view of our audience, or our reader, rather than the content itself. And I don’t have a better term than smart content. Perhaps effective content is better. But it’s content that gives our readers the information they need, when they need it, in the proper place, the proper context, and adaptable to whatever format. It helps them complete a task, or make a decision.

AP:                   And I don’t think we’re too far apart, much at all, beyond some semantics there. Because basically, to make that customer facing content as flexible and useful, you’ve got to build in that intelligence.

LK:                    Absolutely right, Alan.

AP:                   So let’s go back, because you’ve already mentioned that you were involved in the early times. And I am not slamming you at all, because I was using some of these same tools, by the way, back in the day. When is the first inkling you got of this smart, structured content? Can you take us back to that moment?

LK:                    Well, I think it was, again, at IBM, when I realized in this new, they called it, it was an SGML format. And I don’t want to throw a lot of alphabet soup out-

AP:                   Yeah.

LK:                    … But that we were no longer talking about, let’s do a line break, let’s change the font, let’s change the indentation. We were talking about, this is a section, this is a paragraph, this is a list. That was the first inkling. And as I said, at the time, it made a lot of sense to me. I took to it really quickly. It wasn’t until later though, that I understood the potential, that by doing things that way, we could, as you said, modularize the content, and apply formatting later. And have a whole variety of uses for it.

AP:                   And my experience is very similar. I started working, early in my career, on projects for IBM. And we used their SGML, which I believe was called BookMasters. Is that correct? It’s been a while.

LK:                    That’s correct.

AP:                   And I used BookMaster. And that was my first job. And I think I’m fortunate, in the sense that my first job was more working with SGML with structured content. So I really didn’t have this notion of desktop publishing, because it was so much in its infancy. The whole, what you see is what you get. I didn’t have that mindset shift to make, because I was thrown right into the structured content pond. Here you go. But later on, when desktop publishing came along, I started seeing people who were much more focused on the formatting, because you could basically make what a page looked like, or a representation of what a printed page would look like, on your screen. How have you dealt with those very different mindsets in your career?

LK:                    I’ve tried to show people the potential of what you can do with structured content. And candidly, it’s been hard, because I think most of us have seen the effects of structured content, and what things it can do in a consumer context. Obviously, e-commerce, shopping on the web. You can break content down by facets. If you’re ordering clothing, size, color, style. The business to consumer, or B2C world, has done a good job of that. And the B2B world has really lagged behind.

AP:                   Right. Right.

LK:                    So that is changing. But-

AP:                   It is.

LK:                    … But I think the one way that I can help people understand, is by saying, “Well, when you go home from work, or maybe while you’re at work, I won’t tell, you’re shopping. You’re shopping for clothes, or gifts, or electronics.” And this is the sort of thing you’re experiencing. This is the customer experience that we can create, using smart content.

AP:                   Exactly. And that’s a really good analogy. To take something so every day and ubiquitous, like online shopping is for many of us, and to turn that on its head, with more of a content-focused lens. Because to me, this is where I really started seeing the value of smart structured content. I was working on the documentation for a very early laser printer for Lexmark, which had just spun out of IBM, by the way. So I’m really dating myself by saying that.

AP:                   But we basically wrote documentation for multiple models, that were very similar and had overlapping features. And we’re able not to have to maintain completely separate bunches of content, for every one of those models. We were able to reuse a lot of that content. And to me, now, I cannot stress how lucky I am, or was, to fall into a job that introduced me to that fairly early on. How you could do that reuse, when you have content that is, has that intelligence built in to say, “This is for model A. This is for model B. This is for model C.” And then, mix and match those parts to create your end product, which, at the time, was a printed manual.

LK:                    Yeah. You were fortunate. And I’m afraid, I see a lot of writers who still struggle with doing that, because you have to understand reuse. You have to know something about metadata and taxonomies. And this is a hard concept. And I don’t know the answer to that, but it’s something that we have to make sure that everyone has enough familiarity with, to really use these tools that are available to us, effectively.

AP:                   I think it’s also worth noting. I think in some cases, people may be so focused on the tool, and using it to its maximum ability, that they’re focused so much on how that tool works. That they’re sometimes can’t see the bigger picture about, especially, if things need to shift away from that tool, because that tool no longer supports whatever business drivers are behind, for example, a smart content initiative at a company, to move away from desktop publishing. If that has been your world, and you’re an expert at it, I can understand why people would be reluctant to want to give that up, because they are a leader in that skillset.

LK:                    That’s a good point. And you mentioned big picture. I’m a huge believer in big picture. We really need to stand back and ask ourselves, what is this really all about? What are we trying to accomplish? And it’s not about the content. It’s about the customer. Helping them get the information they need, just in time. I use the supply chain analogy. So get that information to them, just in time, in the right place, the right content, when they need it.

AP:                   Speaking of bigger picture, what are some of the other business drivers you’ve seen, pushing people and companies, to go to more of this modular, smarter content?

LK:                    Well, this is fairly recent. And I’m delighted that I’m seeing it. But people are understanding more and more, that our content is part of the overall customer experience. The silos are coming down, especially between marketing and tech pubs. Last week, I heard Megan Gillhooly say that our audience is made up of the same people who go home and shop online. And so, even if we’re writing highly technical manuals for a business audience, we can do these things. It’s part of their customer experience. Marketers no longer talk about a sales funnel, where a customer is drawn in, and then the sale is made. They understand that marketing continues after the purchase. It’s about building engagement, building loyalty. And our content can do that. That’s beginning to be seen as a business driver. The content truly is a business asset. And I say, I’m seeing this recently, because it’s been more than 20 years that structured authoring has been around. But really, only in the last four or five years, have I seen this mindset starting to take hold.

AP:                   And I agree with you. And I think it’s very good news. I think the walls really separating content types, some of which, are fairly arbitrary, that does make a huge difference, and is a huge driver for some of these initiatives. And before we wrap up, what’s the piece of advice you would give to people who were just starting their careers in content, in regard to structure? What would you say to them as they’re getting started?

LK:                    Well, first and foremost, I would, again, say, stand back and make sure that you can see the big picture. And there are so many demands on our time and attention every day. Going to stand up meetings, hitting a deadline, putting out all those fires. It’s really hard to remember what we’re doing here, that we are providing information for our customers, again, in that just in time fashion. And trying to build engagement, and build loyalty. I think if practitioners can keep in mind those principles, what we really are doing here, why we’re doing this job, it will help them embrace the possibilities of structured authoring, and look beyond the silos, and really think about what is in the content, that we need to give to our customers.

AP:                   Larry, that is a great piece of advice. And I think it’s a great place to wrap up. Thank you so much for your time and perspective. I think it will be very helpful to people.

LK:                    Well, thank you again, Alan, for having me participate on this podcast. It’s a privilege and a pleasure.

AP:                   And we share that. Thank you so much. Thank you for listening to The Content Strategy Experts podcast, brought to you by Scriptorium. For more information, visit scriptorium.com, or check the show notes for relevant links.

The post The evolution of smart content (podcast) appeared first on Scriptorium.

In episode 98 of The Content Strategy Experts podcast, Sarah O’Keefe and Dr. Carlos Evia of Virginia Tech continue their discussion about the pros and cons of markdown.

“If you want to make a website and you need to write the text in a fast way that does not involve adding a lot of the brackets that are in HTML syntax, I think that’s the main use for markdown.”

–Dr. Carlos Evia

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. My name is Sarah O’Keefe and I’m your host today. In this episode, we continue our discussion about the pros and cons of markdown with Dr. Carlos Evia. This is part two of a two-part podcast. So when we talk about markdown, because I think that probably most of the people on this podcast in general are more familiar with DITA. When you talk about markdown, what is the sort of use case for markdown, the clearest possible place where you say “oh, this is a case where you definitely want to use markdown.” What are those factors?

Dr. Carlos Evia:                   You need to make content that is going to be published mainly to the web and here I say mainly because markdown now, that part of processing the syntax that used to be in the beginning, “let’s process with this tiny, tiny tool that will only convert to HTML or XHTML,” now there are many other tools that can actually process and transform markdown to other things to create that multichannel publishing that we also do in DITA.

CE:                   So, I think the main use case is if you need to have something that is going to be published or presented in a website, and you do not want to write HTML. It’s a shorthand, just like when we were back in junior high, the cool thing was that you will take a course in typewriting, so you can be working with computers. This is back in the Fred Flintstone days.

CE:                   But before you could touch the keyboard, you had to take a course on shorthand, and shorthand was several syntaxes. I think there are two amazing texts for shorthand. You had to learn how to do it with a pencil, actually a special pencil. And there were different notations that you will do. And then, once you dominated those things and you could take dictation super fast, you can go and transcribe it using the keyboard.

CE:                   So I think that’s kind of the equivalent of markdown. If you want to make a website and you need to write the text for your website in a fast way that does not involve you adding a lot of the brackets that are in HTML syntax, I think that’s the main use for markdown. Write it following this very simple text-based syntax.

CE:                   And then there will be a tool that will transform it, and mainly to a website. But like I said, there are some things, and these are things that I use all the time, I use Pandoc, for example, and Pandoc is a tool that can transform a markdown file to a ton of things, including XML. So we can send my markdown file or files to HTML, to EPUB, to DocBook. There’s no native transform for DITA. And I considered building one a few years ago, but it’s developing Haskell and I don’t understand Haskell as a programming language. So I gave up, but that’s the main use. The main use case is you want quick HTML. So go ahead and use markdown.

SO:                   What are some of the limitations that you found in markdown, the factors that caused you to look at it and say, this is not going to be a good fit for what I’m doing?

CE:                   The biggest problem is that it’s not really structured text. The structure provided by markdown is mainly at the block level. You can have a heading, you can have a subheading, you can have paragraphs and then you can have a couple of inlines, but there is no real structure like we have in XML, and particularly in DITA, that allows you to put attributes in a sentence or even a word to tell it how to behave, to tell it how to look, to tell it filter it out or filter it in when you create user aimed documentation. So that’s one of the biggest challenges when you’re working with markdown. If you only have one version of content to publication, and there are no filters involved, you don’t have to feed it the needs of different audiences. You don’t have to feed the needs of different platforms. Okay, use markdown.

CE:                   And people here are going to be like, “wait a minute! Well, there’s this flavor of markdown that if you add a YAML header and you put a bunch of little pairings of variables, and then you start spicing it up with more of those squiggly brackets and semi-colons,” yes, I agree. But that is not markdown. That becomes something new, a new spaghetti kind of thing that actually, John Gruber, one of the guys who invented markdown, he doesn’t like it when you start adding things to your markdown because it breaks with that idea of making it simple.

CE:                   So that’s the main limitation that I see from my perspective. When I started talking about it in my classes, when I started using it for my specific publication needs, the structure happens at the block level.

CE:                   Beyond that, it kind of becomes the worst enemy of the content specialist, which is that blob, the blob of text that we all fear that we see when we’re working in a word processor and there’s no real structure behind it. That can easily happen in markdown, that you’re just writing paragraphs and there’s really no structure to it. And again, not every document, not every website in the world needs serious intense structure, but if you’re writing for an audience of human beings in a potential audience of machines that are going to be taking your content to do some machine learning, artificial intelligence, are going to be sending this to voice assistants and sending it to the dashboard of your fancy Tesla, markdown is going to face those limitations that your text is mainly a blob with a header and a subheader, but it’s not really structured in a way that enables behind the scenes computation. And again, you can claim that “oh, but my flavor if you add these twenty-five hundred other characters,” yeah, but that is not simple markdown.

SO:                   So I know that you’ve been involved with Lightweight DITA and are leading that effort along with a couple of other people. Does that have potential to kind of unify markdown and DITA, unify these two use cases in some way?

CE:                   Yep. That’s precisely one of the ideas behind Lightweight DITA. When my colleague, Michael Priestley, came up with the idea of Lightweight DITA after, Don Day and Michael Priestly, who came up with the idea of DITA, by the way, they came up with the idea of Lightweight DITA in 2015, they wanted to have a simple way to represent the most frequently used elements of DITA in a smaller set of XML tags. And as they started working on it, then they realized, wait a minute, what if we also create a way to do this subset of elements in HTML? And it was a logical thing that as markdown became more popular as a shorthand approach for creating HTML, why don’t we have a Lightweight DITA flavor that is in markdown and you write it in simple text and then it becomes those HTML elements.

CE:                   And somebody mentioned a few years ago, somebody sent me a paper, an article that said DITA is a universal publishing solution. And I want to say Lightweight DITA is not universal. Lightweight DITA is ‘pluriversal’ because it allows different languages to be merged into DITA-like workflows. And at the end, when you publish, when you create a document and you give it to your users, they will not know what came from markdown, what came from HTML and what came from XML. When they get their document or their website or whatever it is that you’re going to transform to, it all looks like it came from the same source. And that is one of the biggest principles behind that design and development of Lightweight DITA. We want to take topics that follow some basic rules and you can create them in XML in HTML or in markdown.

CE:                   And they all live together in a map and you can transform them. Then develop documents that when you give them to your users, they won’t know what came from where. So it’s a ‘pluriversal’ approach instead of the universal “use these one way,” no, we want to be open to possibilities. So that’s what we do with markdown and by design, we have really tried to avoid creating our complicated flavor of markdown in Lightweight DITA that has a ton of bizarre characters. We don’t want to over spice our markdown with squigglies and brackets and stuff.

CE:                   So one of the principles is okay, do you want to bring a markdown file to a Lightweight DITA party? Bring the most basic, a couple of hashtags for a Heading 1 and a Heading 2 and two paragraphs, bring it on, put it in a DITA map or a Lightweight DITA map, and it will work. It will publish. It will transform. And that’s something that you can do now. And to be honest with you, it’s something that you probably could be doing. And some people are doing it since 2016, when the DITA Open Toolkit started having a version of Lightweight DITA. So I know people that do that on a daily basis. They mix their DITA with markdown topics and nobody’s complaining.

SO:                   Yeah, we actually do have a couple of clients that are doing some version of that. And it’s been interesting trying to figure out how to bring those things together and unify them while maintaining, I think in their case, it very often comes down to markdown is more convenient for the people who are creating it. And very often stashed in something like Git or GitHub and then they have this full-on narrative authoring environment, which is the DITA content, but they need to unify the two, as you said, for delivery purposes. So they slurp the markdown into DITA and then out through the DITA processing pipelines.

CE:                   And you know what, when I teach my students how to use DITA with markdown, everything lives in the same GitHub repository. And the most beautiful thing that we have seen is that you can have one GitHub repo that has topics in DITA, and some topics were filed in markdown. And then inside that same repo, you have a DITA map or an XDITA map in the case of Lightweight DITA that brings them all together. And from that, you can build and publish whatever you want, but in another repository that might be yours or might be your classmates’, you can have a sub module that borrows, that repo. And that other repo can be a headless CMS source that builds a website with a react or whatever it is. And it’s using the same markdown files that the other repository is using to build something in a Lightweight DITA workflow.

CE:                   So see, they can work together and because we’re avoiding to over spice the markdown with squigglies and whatnot, they can still work and they work in both systems, there you have it. Have a repo that builds something in a Lightweight DITA workflow and embed that as a sub module in another repository that is using react, a static site generator, you’re using the text markdown, and you can have them both living together and nobody complains.

SO:                   Well, I think I’ll leave it there because nobody complains. Seems like a good closing for this podcast. Carlos, thank you so much for coming in on this. I’m going to leave some resources, both on markdown, but also on Lightweight DITA in the show notes and I think your background information is in there and we’ll have a couple of other things. So with that, thanks again. And thank you for listening to The Content Strategy Experts Podcast brought to you by Scriptorium. For more information, visit scriptorium.com or check the show notes for relevant links.

The post The pros and cons of markdown (podcast, part 2) appeared first on Scriptorium.

In episode 97 of The Content Strategy Experts podcast, Sarah O’Keefe and Dr. Carlos Evia of Virginia Tech discuss the pros and cons of markdown.

“I think markdown has a huge user base because most people need to develop content for the web. But there’s a set of people that need to be working in something more structured for a variety of reasons, and those are the ones who use DITA.”

–Dr. Carlos Evia

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. My name is Sarah O’Keefe and I’m your host today. In this episode, we discuss the pros and cons of markdown with Dr. Carlos Evia. Dr. Evia is a professor and associate Dean at Virginia Tech and also the Chief Technology Officer in the College of Liberal Arts and Human Sciences. Additionally, he’s an expert on DITA XML and has worked toward bringing structured authoring concepts into university curricula. This is part one of a two-part podcast.

SO:                   Carlos, welcome and welcome back to the podcast.

Dr. Carlos Evia:                   Yeah. Thank you for having me again on the podcast.

SO:                   Well, welcome back. And let me start with the basic question and the theme for this podcast, which is what is markdown?

CE:                   Ay yay yay. Well, that’s a tricky thing because if you go back to the 2004 definition from John Gruber, markdown was supposed to be a very simple text to HTML syntax that will kind of look like, I don’t want to use the word structure, but here I am using structure. Like a structured email message or the kind of structured text that we all people used in use nets. For all you youngsters out there, when the web was this new thing and the internet was pretty much text-based and using it was well, you could get all your entertainment, but it was text. To make the text readable, we used some hashtags and underlines and asterisks to emphasize and highlight components. Markdown came to life as part one, precisely that, kind of simple syntax that would make text easy to read, easy to digest, easy to understand. But then the second thing that markdown had was a little tool that will convert that syntax to actual HTML because people were running HTML and they would be like, oh, brackets, who needs that?

CE:                   Then you wouldn’t need to have brackets. You will just write following that syntax. And then there was a little tool that will attach to blog engines, like mobile type back in the early 2000s and that will automatically convert that text to HTML syntax to actual HTML or back in the day, XHTML, that would be presented to web browsers. And that’s it. That’s where markdown was. But I think the evolution of markdown has gone in very interesting ways, not because of the developers or the creators of markdown, but by the use cases that users have given to markdown.

CE:                   And now you can see people who think of markdown as a, I don’t want to say complete but a partial workflow for developing or storing or presenting or publishing content. And I think that’s kind of weird because if you were to see some of the flavors of markdown that are out there that add lots of squigglies and chain of semicolons and colons to make the content more structure or behave more like something that is not just plain text, that’s not markdown because it’s really breaking with the principle of making it easy to read and making it just plain text. That was a long, long answer to tell you what markdown, the original intention behind markdown was and where some flavors or versions of markdown are today.

SO:                   Okay. It started out as super simple and now it’s getting increasingly complicated. And I think for those of us that live in the XML and DITA world, there’s a good bit of, I don’t know, infighting or conflict between the markdown people and the DITA people. Not everybody falls on one side or the other of that fence, but there definitely seem to be two factions. Why? Why are those two groups fighting?

CE:                   Are they fighting? I don’t know about fighting. And let me tell you something. I think that markdown and DITA live in parallel. Not so much parallel because they have intersecting points, universes of content creation. And I think that the fight is something that is being represented by at least three types of individuals. Number one, publishers of self-authored, non-peer reviewed books that write something and say, “This is the way,” like the Mandalorian. “This is the way and you have to follow this way.” And because they self-publish, they are not peer reviewed, it’s my way and you’re going to think that what I propose is the way to do it. And if you don’t agree with me, don’t write my self-published non-peer reviewed book. But if you do it, you’re going to probably think that, okay, that is the way and I’m going to think about it. That’s one group of people that are like, yeah, there’s this fight.

CE:                   The second group will be people who let’s be honest, get paid to say that. We know some people on the Twitterverse who try to create this fight of DITA versus markdown, markdown versus DITA, depending on who you think should go first. And I don’t think there’s a real war. It’s just that people get paid to do that in order to sell a product. DITA versus markdown, DITA be bad. Markdown be good if you buy my content management system or my blogging platform or whatever it is that I’m selling and I get paid to tweet that there’s a war.

CE:                   And the number three in this type of individual that kind of supports this war or conflict, this friends of the DITA world who have tried to reach out to the markdown-based crowd and they went to one conference or they did one presentation about DITA and they weren’t a little sad or disappointed because not everybody in the audience immediately jumped and said, “I love you DITA.” Oh, kiss, kiss, hug, hug, I’m abandoning everything else. When they came back to the universe of DITA users, DITA developers, they were like oh, the markdown people, they don’t like us. But I don’t think there’s really a war. I think that the big population and it’s huge of people who use markdown as it was intended, as it was developed, as it was created, as a text-to-HTML tool, many of them don’t even know that DITA exists because they don’t have a use case for DITA. They have a use case for a simple shorthand approach to creating HTML and they use markdown. It’s not like they’re like, we hate DITA because they don’t even know what DITA is.

CE:                   And in the other hand, we have people who use DITA because they are in highly structured, highly regulated environments and they use DITA because that works for them. But on their everyday lives, say they want to build a website, if you want to put a comment on somebody’s blog, you use markdown. And that’s my case. I live in the DITAverse, but when I need to make a quick website or I need to tell my students how to do something super simple, that is going to be only posted on a website, we use markdown and we up here in my classes, I think we’ve been teaching markdown since 2005 or something like that. And at the same time we’ve been teaching DITA sometimes in the same class or in different courses since, I don’t know, 2002 or something like that. I don’t think there’s a war. I think it’s different use cases and I think that those funding the idea of a war fall into those three groups of individuals that I presented. But you can have them both and use them for different purposes and I think life can be good.

SO:                   Okay. It sounds as though you’re going to take the grownup perspective on this.

CE:                   Well, I can be mean.

SO:                   Which good for you.

CE:                   And tell you that.

SO:                   Okay. I’m still thinking about the Mandalorian analogy and what I want to know is in this scenario, who is the child?

CE:                   I think the child, I don’t know because people think that markdown is new, but it’s not a new thing. It’s been around formally as both of those components, as the syntax and the tool to transform that syntax to HTML or XHTML, since early 2004. And if you just take the syntax of writing, using the hashtags and asterisks and underline, well that’s existed since the early 2000s, if not earlier than that. And that’s about the time that DITA came out of IBM and became a standard. I don’t think there’s necessarily a component in this situation that is going to be the equivalent of that child who has these powers that are in development and can bring hope to the galaxy and what have you. I don’t know. I don’t know if there’s a case in here where somebody’s a David or a Goliath. I think that they are about as they’re the same age and it’s just a matter of the user base.

CE:                   And like I told you before, I think markdown has a huge user base because most people need to develop content for the web. If they’re not using a Facebook or Twitter, if you’re writing content and you’re publishing your own stuff that it’s going to be on a website, you need to do HTML and ain’t nobody got time to write HTML hand coded anymore so markdown is an approach to do that. But there’s a small set of people, very highly specialized content specialists that need to be working in something way more structured for a variety of reasons, such as you know and as the audience of your podcast know, and those are the ones who use DITA. But I think that they can be both good people and then it can be both powerful, Jedis in different environments.

SO:                   And with that, I think we will wrap up part one. We will be back to continue our discussion about markdown with Dr. Carlos Evia.

SO:                   Thank you for listening to The Content Strategy Experts podcast brought to you by Scriptorium. For more information, visit scriptorium.com or check the show notes for relevant links.

The post The pros and cons of markdown (podcast, part 1) appeared first on Scriptorium.

In episode 96 of The Content Strategy Experts podcast, Elizabeth Patterson and Gretyl Kinsey talk about the importance of content governance.

“An important part of governance is knowing that changes can happen. Keep your documentation in a central place where everybody can get to it and understands how it’s updated. If you don’t, some groups may start creating their own and that can result in unofficial documentation that doesn’t necessarily capture what should be captured.”

–Gretyl Kinsey

Related links: 

Twitter handles:

Transcript:

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

Gretyl Kinsey:                   And I’m Gretyl Kinsey.

EP:                   And I think we’re just going to go ahead and dive right in, Gretyl. So could you start out by giving us a definition of what exactly content governance is?

GK:                   Sure. So when we talk about content governance, we are talking about a former system of checks and balances where we are defining the responsibilities, the accountability, the roles, everything that’s involved, and measuring quality each step in your content development process. And unfortunately, it is not as much of a priority as it should be at a lot of organizations, but it is critical for success. So it needs to be a big part of your content strategy.

EP:                   And I think it’s really important to note here, if you are in a regulated industry, you must have a plan for content governance and accountability in place, or you get shut down. And if you’re not in a regulated industry, that doesn’t mean you’re off the hook. You still need to document so that everyone knows what’s going on, what the plan is, and you can have that consistency in your organization.

GK:                   Absolutely.

EP:                   So when you are getting this plan in place, what types of things should you include?

GK:                   One is just standards for your content. So defining your content model and how that is going to be maintained and governed going forward. What are the workflows and systems that are going to be in place to do that? So that might be whatever your toolchains are for authoring, for publishing, for review, approval, editing, all of those kinds of steps all the way out through publishing and delivery, and all of the updates that are involved to your content. So just all of those kind of workflows for the actual development, and ensuring that that all goes smoothly as a big part of your governance.

GK:                   Another one is just defining the roles and responsibilities. So making sure we know who is in charge of doing what particular thing. I think one area where that’s really, really critical is that if there’s any sort of change to the content, that’s an overarching level. So if it’s something like branding terminology that changes, if a logo changes, that kind of thing we’ve seen with rebranding before. Who’s responsible for making sure that information gets disseminated out to everybody? Who is in charge of making sure that you’ve got processes in place to have all of that goes smoothly with your content and that it’s not this really awful manual process that takes forever?

GK:                   So that’s another part of it is those roles and responsibilities. And then finally a big piece is looking at the future. So what is your roadmap? What are your goals? What are your plans? And we like to look at short-term and long-term future when we’re helping our clients plan for this. So something like, what are your goals maybe in the next or two, and then five years out, 10 years out realizing that, of course, the longer you go in the future, the more that that can shift and change. But as long as you are looking toward the future and where you ultimately want to be, then that means you can future-proof your content and build that into your governance and always have that be something you keep in mind so you don’t lock yourself into one path with nowhere else to go.

EP:                   Right. Absolutely. And we talked about standards for content being a part of this content governance, and a part of that are the terms and vocabulary that you’re going to be using and your style guide, that type of thing. And so I want to get into touching a little bit about documenting things because you’re going to have so much information. You need to have it documented somewhere. So Gretyl, could you touch a little bit on what you should document when you are putting this plan together.

GK:                   Yeah, like you were saying, there are all kinds of things that’s important to document and you do need to document everything. Because what happens if you don’t is that inevitably change happens, people leave jobs, departments shift, all kinds of things can happen. And if something’s not documented and that knowledge is just in someone’s head and if that person then leaves, it’s lost. So it really, really is critical to get all that documented.

GK:                   And with the content itself, that’s things like your structure. So if you’ve got a content model, why is your content model built the way it is? What were the decisions that were involved in getting there? What does your structure handle? If you’re in DITA, is there specialization? All of those kinds of things, I think in particular around reuse as well if you have smart structured content and you’re doing reuse, documenting the mechanisms that you’re using and why, all of that reasoning behind it is really, really important to capture.

GK:                   It’s also really important to capture any kind of standards. And this is not so much about the content structure, but all of the little things that a structure itself can enforce. So things like your style guide, language usage, all of that stuff, it’s really, really important to document that as well. Alongside that, terminology is an important piece. And this gets into things like your branding. So the way that your company name is always written. I know we’ve talked to some people who actually had that as an issue where when they went through a rebranding, getting the company name updated, something as simple as that was really challenging because there wasn’t a documented process for dealing with it. And same for if you’ve got lots of different product names, really important to document that and say, “This is the official name we’re going with.” Because I’ve seen some cases where one department is using whatever the working title of a product was and the other one is using the official branded term. So getting all of that documented and standardized in one place is super important.

GK:                   Taxonomy is another big one. And this is a place where you can capture some of that. Taxonomy refers to how you categorize things so that people can sort and filter and find things. And so this really feeds into search. And it’s really critical for a lot of the metadata that you are going to have on your content. So that data about your data, capturing things like what the content is used for, who are the roles are the users who are involved with it? And some of the branded terminology often gets captured as part of a taxonomy as well because things like your products and the way that content is organized according to product names, product families, that sort of thing can make a difference in how customers search for it. So all of that, it’s really, really important to have that documentation.

GK:                   And then I think also when you are in a content management system, whatever tool you’re working in, document those processes as well. A lot of times the tool will have its own workflows to handle that. But it’s important for when you’ve got a new person, a new writer, or a new editor who comes on board and suddenly has to start using this, some kind of a quick start guide for that person that helps them navigate that system is another good piece of documentation to have.

EP:                   Right. And I think going back to when you mentioned planning for the future, and then also the rebranding situation, it’s important to keep in mind that a lot of these documents are going to be working documents. They’re going to change. You might have updates to your terminology and to your style guide. And so not to get completely set on it, but understand that while it’s really good to have that basis, that it might be changing as your company grows.

GK:                   Yeah, and I think that’s part of governance too, is knowing that those changes can happen, keeping your documentation in some sort of a central place where everybody can get to it, everybody understands how it’s updated, when it’s updated because we’ve seen something happen a lot of times where if there wasn’t really this good, solid central documentation that was updated and distributed periodically, that some groups would just start creating their own. And of course, you don’t want that because then you’ve got this unofficial offshoot documentation that doesn’t necessarily capture what should be captured. So really a big part of that governance is always keeping those documents updated and making sure that people get those updates as they’re made, that they’re not waiting and they’re not using old information.

EP:                   Right. So we talked about content governance being something that’s needs to be a priority, but can often be overlooked. And something that is also often overlooked is archiving content. So should you include a plan for that as a part of your governance strategy?

GK:                   Yeah, absolutely. And like you said, this is overlooked all the time. A lot of people just… When content gets old, it gets out of date, it becomes legacy content. They don’t know what to do with it, but it’s still around and it’s still there. And I think it’s really important to go through that, have part of those roles and responsibilities we talked about in that person or team, part of that responsibility should be go through the content. And when something is five, 10, even 15 years old, ask yourself, is it still relevant? Can this be deleted? Does it just need to be archived and kept somewhere, but not deleted in case it ever needs to be brought back?

GK:                   What are the guidelines around going through your content every so often and making sure that you are dealing with this archival and legacy content in a rational way? Because what often happens that we see is, if you’re doing something like a conversion, if you’re doing any kind of a content overhaul, any kind of a major update or improvement, and you haven’t sort of been pruning and dealing with your legacy stuff all along, then all of that suddenly becomes a big question of, what do we do with it? And you have to make a whole lot more decisions at that one time. Whereas if you deal with it all along, it’s a lot easier to manage if you ever have any sweeping changes to your content.

EP:                   So as you’re getting this plan in place, do you have any tips for getting the team on board with all the changes?

GK:                   Yeah, and I think that’s an important thing because change management is one of the hardest parts of any project. People naturally are resistant to it and they want to see what the benefits going to be. And I think that’s important. So make sure that when you are putting a plan in place for content governance, that you get input from everybody who’s going to be affected. And this is something we do at Scriptorium as part of our content strategies. We talk to all of the different content stakeholders because that really helps you know that there isn’t a need somewhere that’s being left out or the some group somewhere isn’t being ignored and that the content governance plan actually does encompass everything.

GK:                   So get that input from everybody, get that constant feedback, keep that input going because as you saidElizabeth, your content changes over time, your internal documentation about your content changes over time, your future goals change and evolve. And so I think not just getting initial input, but getting ongoing input from everybody is really important. And then also just be really transparent about the changes that you’re making. Don’t try to trick anybody or say, “Oh, this is going to be really easy if it’s not.”

GK:                   Be honest about what people are going to have to expect and support them. Make sure that you understand, yes, there is going to be some resistance. You’re going to have to help them through these changes if you are making a major change to the way that you are creating and governing your content and that you need to build that support in place so that people don’t get left behind and don’t get overwhelmed by those changes. And then I think going forward, once they get over that hurdle, if your content governance plan is good, it should continue to mitigate that change and make it easier for everybody going forward.

EP:                   Right. Definitely. So I think communicating, being transparent, this is going to tie into the next question, and this is how I’m going to wrap things up. But what else can you do when you’re executing your governance strategy to make sure that it’s successful in addition to that transparency and that communication?

GK:                   Yeah, and I think a lot of this is just wrapping up and reiterating some of the things that we’ve said, but my three big tips are one, like I mentioned, have that small team or that even just one person in charge of your governance. Like I mentioned, don’t just rely on the tools. Have that human intervention, have that person or that team who’s responsible. So that’s one way to make sure that you succeed.

GK:                   Another one is to communicate your plans and your updates regularly. Have some a schedule in place maybe where you say every so often and we see this sometimes in agile. It might be a sprint schedule. It might just be some other internal schedule you come up with. But every so often, here’s when the updates are going to come out about making sure when content has been changed, when documentation about our content has been changed, when we’re rebranding, when we can expect a new product to be added, any of those kinds of things, have that regular update schedule so people know when to expect that it’spcoming.

GK:                   And then finally, like I mentioned, keep getting that input from your content creators, keep those lines of communication open. And that way, if somebody has a problem, if something about your governance strategy is maybe not working so well, then they can tell you before it gets bad. And that way you can make sure that it does succeed.

EP:                   Right. Absolutely. Well, thank you so much, Gretyl, for being on the podcast today.

GK:                   Yeah, absolutely. Thank you.

EP:                   And thank you all for listening to The Content Strategy Experts podcast brought to you by Scriptorium. For more information, visit scriptorium.com or check the show notes for relevant links.

The post The importance of content governance (podcast) appeared first on Scriptorium.

In episode 95 of The Content Strategy Experts podcast, Sarah O’Keefe and Kris Eberlein (chair of the OASIS DITA Technical Committee) discuss the upcoming release of 2.0. What can you expect if you are currently in DITA? And what do you need to know if you are considering DITA?

“If you’ve been shoehorning diagnostic information into troubleshooting topics,  you’re going to have a good semantic place to put that content with DITA 2.0.”

–Kris Eberlein

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.

SO:                   In this episode, we talk about what to expect with the upcoming release of DITA 2.0. Hi everyone. I’m Sarah O’Keefe and I have Kris Eberlein joining me today. She’s the Chair of the OASIS DITA Technical Committee. Hey, Kris, welcome to the podcast.

Kris Eberlein:                   Hey, Sarah. Thanks for having me. I’m delighted to be here.

SO:                   So happy to see you virtually. So today with the great opportunity to talk to Kris, we wanted to talk about the upcoming release of DITA 2.0, and in particular, talk about this from the perspective of current and future DITA users. We’re not going to do a full overview of the specification, but I will include a link to the draft specification and some other DITA resources that Kris has shared with us in the show notes. So if you need to do some basic research about DITA 2.0, you’ll have those resources there.

SO:                   But with that said, what I want to talk about today is where this is going and try and gain some of your perspective, Kris, on what’s happening here. So let’s talk about current DITA users. If I’m a current DITA user and I’m in DITA 1.2 or 1.3, what’s the most important thing? Or what are the dozen most important things that I need to know about DITA 2.0?

KE:                   Well, the first thing everybody needs to know, and this is user’s, tool vendors, the community, is that DITA 2.0 Is our first release that is not backwards compatible. For all the DITA 1.x releases, DITA 1.2, DITA 1.3, DITA Technical Committee really went to a great deal of trouble to ensure that all the changes we made were backward compatible. There just comes a time when you need to do some housekeeping, when you need to do cleanup, make changes, correct design mistakes, and have a backwards incompatible release. And that is DITA 2.0.

KE:                   So it’s going to present some new challenges that folks who have been in DITA for a while and have maybe gone from 1.1 to 1.2, or 1.2 to 1.3, new challenges that those folks haven’t experienced so far. It’s going to be a release that is well worth current DITA users upgrading to. We have added very robust support for audio and video. And I think probably for the first time, it’s going to make it fairly easy for folks to really have multimedia in their content without going jumping through some unnecessary hoops.

KE:                   And just in general, improvements to hazard statements, to simple table, and just a whole lot of nice cleanup. But it does mean that folks that are currently in DITA and who are looking towards upgrading to DITA 2.0 in the future are going to have some planning and some work to do. And the very first thing I think people need to pay attention to is performing a content audit and assessing whether their content contains deprecated items that have been removed in DITA 2.0.

KE:                   The biggest items that I think are going to hit folks with existing content, is if you’ve been using the alt attribute instead of the alt element, or the navtitle attribute instead of the navtitle element. Those attributes are not included in DITA 2.0. And if your content has them and you move forward to DITA 2.0, you’re going to see breakage. So doing cleanup of your existing content, if you have any of these items that we’re deprecating.

KE:                   And just as a side note, those attributes have been deprecated since 2010. So it’s not as if we’re pulling the rug out from under people. We’ve given notice for a long time, “These are deprecated. They’ll go away in the future.” And DITA 2.0 is that future point.

SO:                   So 10 years seems like a reasonable timeframe.

KE:                   One would hope.

SO:                   I heard a rumor about steps. Tell me about steps and what you’ve done.

KE:                   Well, one of the things we’ve done in DITA 2.0 is we have removed sub steps, instead we’ve enabled steps to nest. This was done really at the request of many, many users who said, “We want to be able to reuse our steps. We want to be able to reuse steps that have substeps, and we’re running into problems because maybe we have substeps in one topic and they need to be steps in another topic. And just this whole structure of steps and substeps is impeding our reuse.”

KE:                   And so the Technical Committee listened to that and we made that change. So I think that’s going to be a change that will really affect almost every implementation’s task topics. The good news is, that is going to be a very simple change to make across a body of content using scripting or search and replace. And the DITA Technical Committee will be producing some documentation and some scripts and some other utilities to help people do this sort of migration. I also fully expect that CCMS vendors will be providing their customers with a certain level of support.

SO:                   So basically if I have a task topic today, then my first level steps would be step and my second level of steps would be substep. And first of all, I would get rid of substep and just make it step. So I would have a step with a nested step for the second level steps. And then you’re saying you could actually have a third level of steps or fourth or fifth or …

KE:                   Oh, it could nest to the depths of being ridiculous. And I hope people don’t do that. I mean, it’s certainly possible to implement some Schematron rules that would restrict the level of steps one could do. But we know nowadays that people really … If people want to have infinite levels of steps they use the info tag and they put in an ordered list within it, and so forth.

SO:                   What this means, as you said, is that a thing that used to be a substep, which is now just a regular step, it would make reuse much easier, because I don’t have to worry about the fact that it was a second level step over there, and I want it to be a first level step over here.

KE:                   Absolutely.

SO:                   Awesome. Okay. So for current DITA users, I guess there’s also the tools issue, right? I mean, there’s, as far as I know, very little out there right now that supports DITA 2.0, because I mean, it hasn’t been released yet, so it might be asking a bit much. But that’s something to keep an eye on.

KE:                   It is. I mean, right now the DITA Open Toolkit has a certain limited support for DITA 2.0. Oxygen XML Editor ships DITA 2.0 DTDs. But yeah, as of yet, tool vendors have not started making changes to their applications. You can create a DITA 2.0 topic in your Oxygen Editor, but if you want to use their insert Table Wizard, and you’re trying to insert a simple table and add a title to it, which is permitted in DITA 2.0, you can’t do that. There’s no support in the Oxygen Wizard for that yet.

SO:                   Do you have an idea of timing? Not so much for the tool vendors, but for the specification?

KE:                   I’m hoping that we’ll have the specification and the standard released in early 2022. Or sorry, early 2023. I wish, I wish it could be 2022. And this is one of the things that folks are always asking me, “Why does it take so long?” The wheels of standards organizations turn slowly. And to be honest, that is a good thing. Standards, they, they live for a long time and you really want us to get things right.

KE:                   The reason why we’ve got about a year and a half runway from now is, although we have just about finished all of the grammar files, the DTDs, the RNG, the things that codified the rules for the standard, we’re pretty much done with that. But we’ve got a lot of editing the specification to go, and reviewing the specifications. And all of that has to happen before we kick off the Oasis approval process, which takes six to eight months.

SO:                   So if I’m a current user, it sounds as though I need to start thinking about this and doing some research and doing maybe some planning, but there’s not an immediate crisis action.

KE:                   Oh, absolutely, no immediate crisis action. It is a good time to start thinking and planning. If you’re a company with a decent sized DITA implementation, this is the time to appoint somebody to be your DITA 2.0 captain. To do research, to look at your company’s content, to think about what it means for your implementation moving forward.

SO:                   Okay.

KE:                   It’s a good time to test drive DITA. It’s a little too early for people to put DITA 2.0 In production. I think that really can’t happen until there is a little more support from tools and from the DITA Open Toolkit. Or if you’re not using the DITA Open Toolkit for whatever processor you might be using to pre-process your content, or to generate your output, your PDFs, your HTML5.

SO:                   So it sounds like that’s our action item, is to do that research and, “Hey tools people, tool vendors, we need you.” So what about the future users? So, we’ve been talking a little bit about the current users. People who have working implementations, who could be looking at this and thinking about upgrade paths, but what about the people who are just considering DITA? They’re not using it, but they’re thinking about it. Should they be planning to implement in DITA 2.0, or should they just jump into 1.3? What would be the best solution there?

KE:                   It really depends on their timeframe. If you’re starting to implement tomorrow, you need to stick with DITA 1.3. And to those folks, I would say, be very careful to not use deprecated items, to not use elements, attributes, or things that are being removed in DITA 2.0. Obviously, if you’re writing task topics and you need substeps, you need to use your substeps.

KE:                   If you are looking now and maybe thinking your implementation is going to happen six, nine months or a year from now, you might be able to use to DITA 2.0, if you’re probably using GitHub as your repository. Again, I think the tools are really going to be the gating factor for people to be able to use DITA 2.0 in production?

SO:                   It sounds as almost like you’re saying if it’s a small project that would be done in three months or six months, that’s a quick and dirty. Or not even quick and dirty, but a smaller company with a smaller content set, they might jump into DITA 1.3 and then make the move, but it wouldn’t be that big a move. Whereas if it’s a big, huge enterprise behemoth that moves slowly, this might need to be on their radar.

KE:                   Yes.

SO:                   I mean, even today.

KE:                   I think it’s good to be on everybody’s radar, whether you’re tiny, small, medium, large, or ginormous. This is the time, this is the time to appoint somebody to be your DITA 2.0 resource person, to learn about it, to do that content audit. To figure out what are all the moving parts in your DITA implementation that will be affected?

SO:                   Are there any particular maybe industries or subject matter areas where DITA 2.0 would be particularly helpful, or not helpful as the case may be?

KE:                   Well, one of the things we did redesign pretty extensively for DITA 2.0 is the hazard statement element.

SO:                   So this is warnings, danger, that kind of thing?

KE:                   Yeah. Warning, danger, caution. So very much used for machinery, for medical devices, for anything that has to comply with particular standards, like particular ISO standards around hazards or ANSI standards.

KE:                   So I think we have really listened to folks in those industries and the ways in which the hazard statement element that was introduced in 2010 was falling short. I think it’s going to be very helpful for folks in those industries. And again, also, if you really have a pressing need to have a of multimedia content, the support for multimedia we’re adding is very closely tied to multimedia support in HTML5. And so I think that’s going to be very good news for a number of implementations.

SO:                   Okay. And is there anybody that you would put on the low priority, “You don’t need to do this right now, you can probably …” Who can wait?

KE:                   Wait to prepare for DITA 2.0, Sarah, or probably don’t need to go to DITA 2.0?

SO:                   More like, “This is going to be lower priority for you,” for whatever reason. Who is that person where you would say there’s not a lot here that’s going to be urgent.

KE:                   Well, I think if your company is offering content in DITA 1.2 or 1.3, and everything is working just fine for you. You’re not experiencing any difficulties with hazard statements, you’re not trying to do filtering on bookmaps. If you’re not experiencing any problems.

SO:                   Do you have any other big picture advice for people that are thinking about this? Anything that we haven’t covered that people should consider or know or think about?

KE:                   Well, I do have one thing I’ll add, you asked who I thought would really benefit from DITA 2.0. And I think companies, if you’re using the troubleshooting topic, one of the key things added in DITA 2.0 is we added structured elements for providing diagnostic information. So if you’ve been shoehorning diagnostic information into troubleshooting topics, now with DITA 2.0 you’re going to have a good semantic place to put that content.

SO:                   Oh, that’s good news.

KE:                   So that’s another area that folks will really get to see some benefit.

SO:                   Okay. Well, Kris, I really appreciate your time today and sharing all your hard-earned wisdom and knowledge about what’s coming up as the expert. And I think with that, I’m going to close it out. As I said, I will leave some additional DITA 2.0 resources in the show notes so that you can, you, the listener, can do your research and figure out where this is going. And we will make sure that we have some possible way of contacting Kris, if you have any inquiries about the DITA 2.0 committee and those kinds of things.

SO:                   And with that, thank you for listening to The Content Strategy Experts podcast brought to you by Scriptorium. For more information, visit scriptorium.com or check the show notes for relevant links.

The post DITA 2.0: What to expect (podcast) appeared first on Scriptorium.

In episode 94 of The Content Strategy Experts podcast, Bill Swallow and David Turner of DCL take a look at content migration and discuss all of the players and parts involved.

“It’s not just about moving the content and loading it to the new system. You actually have to transform the content from the unstructured formats.”

–David Turner, DCL

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 discuss content migration. Hi, everyone. I’m Bill Swallow, and today I have a special guest, David Turner of Data Conversion Laboratories, also known as DCL. DCL is an industry leader in data and content transformation services and solutions. Hey, David.

David Turner:                   Hi, Bill. Thanks so much for including me today.

BS:                   Oh, thank you for joining. And today, we’re going to take a look at content migration and talk about the players and parts involved.

DT:                   Yeah.

BS:                   I think to kick it off, what is meant by content migration?

DT:                   Well, that’s a good question. It’s actually a broad term. But in general, you’re just talking about moving content in whatever formats to some kind of a new repository. In the work that we do at DCL, that typically means somebody’s implementing a component content management system, or maybe moving from one CCMS to another, or a lot of times we work in scholarly publishing where they’re changing website hosting platforms. All that to say, it’s not always the most popular conversation. I think I heard one technology provider recently say, “Migrations are death.” But they are an important conversation, and those are the kinds of content migrations we typically work on.

BS:                   Alright. Why might you need to migrate content then?

DT:                   Well, depending on your use case, you actually might not have to do a lot of content migration. Some platform vendors will encourage you just to start from scratch, or you might even be able to write a script to just lift and load content. If you’ve got really well-formed content, it can just work. But I think in most cases, you typically need to be thinking about the migration strategy, specifically if you’re moving from, say an unstructured content management workflow to this SCM, or structured content management space, like we’ve seen at TechDocs, or we’re starting to see a lot more in Life Sciences, educational publishing. In these instances, it’s not just about moving the content and loading it to the new system, but you actually have to transform the content from the unstructured formats, like Word or InDesign, into component-based formats, like DITA or other flavors of XML. And, ultimately, you have to do that in a way that minimizes manual cleanup.

DT:                   Now, on the scholarly publishing side, it’s a little different. You’re typically not necessarily moving to a new kind of XML. You might be taking decades of content and just updating those content models. So really for them, they’re looking to try to clean things up, get rid of some warts, make sure that links are working, things like that.

BS:                   And I can imagine it’s not particularly easy to move from something that’s unstructured, like Word or InDesign, into some kind of structured content like XML.

DT:                   No, absolutely not. I personally didn’t understand how difficult it was when I first started, but all it takes is spending a day trying to convert a Word document to some DITA document, and you’ll pull your hair out, even if you have some technology that’ll automatically do it. So typically, you’ve got to think about these things with a big picture, and you got to really approach them in a strategic way. So in any case, while a lot of your tech providers don’t like to necessarily emphasize the need for content migration, it really can be a critical piece.

DT:                   One of my favorite quotes, I think from the SaaS Institute says that, “Bad data is the leading cause of the failure of IT projects.” And I think you can just insert the word “content” in there as well. The data that is in and around your content, if you don’t get that right, it’s going to cause your project to fail.

BS:                   Oh yes, definitely. So what’s involved in a content migration then in that case?

DT:                   Well, can I give the favorite answer of all consultants, technology providers and service providers? I’ll just say it depends.

BS:                   We use that one too.

DT:                   I think that’s a very… Honestly it does depend on a lot of different factors. I say, “First of all, how much content are you moving?” If you’re just moving a little bit of content, maybe it’s just some simple in-house expertise. But if you’re bringing content together from a lot of different legacy systems, you might need a lot more help. “How big of a change is this for your team?” For like a scholarly platform migration, there’s very little in change management. But if you’ve got a team of medical writers who are used to working in Word and are now going to be working in DITA or some other flavor of XML, that’s a huge change management endeavor, so there’s going to be more involved with that migration. And then honestly, when you look at content formats, that’s going to be another piece of this. “Is scanning required? Is this just Word content, or do you have Word and InDesign and PowerPoint and RoboHelp and FrameMaker? And do you have a lot of duplicate content?” So there’s a lot of those things that they go into it, that’ll help determine what you need.

DT:                   But in general, I’d say you can probably group the players in the ecosystem into three big groups. First of all, is the technology vendors? So that would be your platform provider, or if you’re moving to a CCMS, that CCMS provider. Typically, there are some add-ons to that. So with the CCMS, sometimes they have an onboard editor for doing the XML. But other times, you’ll want to bring in a third-party editing tool, some sort of a structured content authoring or editing tool. And similarly, you might have some providers on the back end that are going to automate your export formats or manage your delivery out to different places. So those are the key players, I think, in terms of the technology piece.

DT:                   From a services side, depending on how big of the engagement is, you’re probably going to have a systems integrator of some kind. You’re probably going to need to have a good conversion vendor, and almost definitely, you’re going to need to have a good consultant. And really, that’s for the services side.

DT:                   And then I think internally, you also need to be thinking about who your players are. An internal project leader, ideally, somebody who sits in between the content people and the IT side. Because in my experience, a lot of times, a project that is just led by the tech side, those tend to fail. And similarly, if somebody is just trying to lead it from that content team side, they’re going to run into a lot of trouble. But if you can have that person in the middle who speaks both languages and could be that champion, that’ll really help you to have success. And then that person needs to also cultivate some other internal project champions. Another sure way to fail is to have a good internal project leader, and then a year from now that person goes someplace else and nobody else is there to pick up the mantra. So that person’s got to be really good at spreading the gospel, if you will.

BS:                   Yeah. Yeah, it’s very true, because once all of these other players leave, all you are left with to keep things going is that internal team.

DT:                   Yeah.

BS:                   So, yeah, if the internal team doesn’t have a game plan going forward, then the whole initiative, really, can fail.

DT:                   Absolutely.

BS:                   All right. So you have all of these players, all of these different parts going on. How do they all work together?

DT:                   Well, I think the technology vendors, it’s pretty self-explanatory, and most of the time the technologies have been made to work together. So you’ll have the CCMS, which is your place to store the content, manage the content, share the content, reuse the content. And then there’ll be an editing tool that’s typically already been integrated in some way, and then the rendering tools and things like that. On the service provider side, if I were going to start one of these projects, I would start probably with the consulting piece. Having a consultant, they can ask the hard questions, help develop those internal leaders, implement the change management. And really, one of the things that I think is most critical is being able to stay focused on that big picture. From a format side, they also help to do things, like establish content models, content standards, content workflows, et cetera. Have I left anything out on the consulting side? I think you might have some expertise there.

BS:                   Yeah. I think you hit all the big ones. But yeah, the big one around there is change management, because any kind of project where you’re moving from one technology base, or several into another, basically everyone’s whole world is going to change at that point. So being able to make sure that you have all your ducks in a row with regard to every aspect of that process really helps. And again, it helps inform that team and that team champion and the ones that they’re working with to keep things rolling, to have that game plan going forward.

DT:                   Absolutely. So after the consultant, I think a good place to get involved now is with the conversion vendor. The conversion vendor is going to then take a look at this valuable asset, this content that you have, and is going to help you to meet those content standards that were established by the consultant.

DT:                   At DCL, we actually do a lot of upfront analysis on these kinds of projects to optimize the content for whatever the new platform is and to minimize any cleanup. And then we can really do it. So many people look at these projects and think it’s an all or nothing kind of a proposition. “I have to bring everything or nothing.” And we could do a measured approach, maybe start with a small amount of content, then that leads to ingesting one content type a little further down the road, then maybe just a little further down the road. We’ll convert those content formats, we’ll provide QA, we’ll help clean up metadata.

DT:                   I should probably also just caution you, don’t overlook this part. Sometimes you’ll have people that haven’t maybe worked with maybe a DITA integration before, and they’ll think, “Ah, can’t we just write a script?” Internal developers look at this, and they go, “Oh, we should be able to just automate this.” But I would just, again, caution you, because, again, bad data kills 80% of projects. And your content is not an afterthought, it’s an asset. And you’ll spend actually a lot more fixing bad content transformations later than just investing well in the first place.

BS:                   Yeah. It’s a garbage in, garbage out thing.

DT:                   Absolutely. And your user’s experience is going to depend on that. What they get from your content really is a reflection of you as a company, and it’ll lead to more sales or it’ll hurt sales.

BS:                   Yeah. Couldn’t agree more.

DT:                   Of course, the systems integrator, they’re going to be handling the plumbing, making sure that the tech environment works properly, whether it’s cloud-hosted or internally-hosted. They’re going to try to make sure that all the technologies are working together seamlessly. Maybe they’ll take, “This is how we’re going to do the workflows.” Well, they’ll actually implement that and make sure the inputs and outputs are working, et cetera.

DT:                   And then the other really important piece, as I said before, the internal players, they’re going to work with a consultant to make sure that the company has everything it needs and learns to stand on its own. Because, as we talked about before, the consultants and integrators, eventually, won’t be there every day. So this internal staff needs to make sure that things are documented, needs to make sure that they’re actually able to use this content, which is why it’s important to get the conversion done right at the beginning, and then be able to help get the company culture to adapt to this new technology and these new processes, to really ensure that that long-term success.

DT:                   I guess I would say in summary, there’s a lot of moving parts, but knowing these players and how they fit in and placing some value on that is going to make that a lot easier. And I think, ultimately, will help you to put together a plan that’s palatable for your management when it comes to migration.

BS:                   Yeah, absolutely. Well, I think we’re going to cut it off here, but thank you, David. This has been a great chat and a lot of great information in there.

DT:                   Well, thanks so much. And I look forward to maybe doing another one of these in the future.

BS:                   That would be great. Alright. Thank you for listening to The Content Strategy Experts podcast brought to you by Scriptorium. For more information, visit scriptorium.com, or check the show notes for relevant links.

The post Understanding content migration (podcast) appeared first on Scriptorium.

In episode 93 of The Content Strategy Experts podcast, Gretyl Kinsey and Sarah O’Keefe talk about how to determine whether DITA XML is a good fit for smaller content requirements.

“Scalability or anticipated scale is actually a good reason to implement DITA for a small team.”

–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 talk about how to determine whether DITA XML is a good fit for smaller content requirements. Hello, and welcome. I’m Gretyl Kinsey.

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

GK:                   And we’re going to be talking about small DITA in this podcast. So just to set the scene, what do we mean when we talk about small in this context?

SO:                   So when we talk about small DITA or small DITA requirements, it could be a variety of things, but basically, a smaller company, a limited number of content creators, and or a small content set. So instead of tens of thousands of pages translated into 50 languages, we’re talking about two or 3000 pages in four languages, or 500 pages.

GK:                   Right. And sometimes we’re talking about as far as the actual content production people, maybe it’s just one writer, maybe it’s a small team of two, or three, or five. And maybe it’s also something like you have a fair number of contributors who are part time, but you only have maybe one or two people who actually gather all of that content, and put it together. So the total operation for that content production is pretty small scale.

SO:                   Following up on that, I think we all know what we mean by a big group, a big implementation. So it’s almost helpful to look at small DITA as being not large. Not tens of thousands of pages, not 50 writers, not a ton of languages, not a ton of scale. So it’s one of these environments where you don’t have the slam dunk business requirement, because you have so much stuff.

GK:                   Yeah, absolutely. We know that DITA is typically a good fit for a larger team, like you’ve said, because it really saves a lot of cost from the single-sourcing angle. So for example, the larger content set that you have, the more potential you probably have for reuse across that content set. And that means that you can save a lot more from establishing that single source of truth in DITA, whereas when you’ve got a smaller content set, you may not have that much reuse, or what you have may not justify the cost of that setup.

SO:                   Yeah. I mean, it’s really common, I think, to see organizations that have a small chunk of content with actually zero reuse. So you look at it from the, do you have a business case for DITA point of view, and for reuse? The answer is absolutely not. Because there isn’t any.

GK:                   When we look at some of the other factors that typically work for these larger groups too, another one is localization. And in a lot of ways, that one stems from reuse, because the more languages that you translate into, the more times that you have to pay, and if you are using copies rather than true reuse, that makes your costs go up. But if you have a smaller team, or maybe you’re delivering to a smaller market, and you don’t have a lot of reuse, or a lot of localization, or maybe any localization, then again, it becomes a little bit difficult to justify something like DITA. Whereas when you do have a lot of localization, especially on top of a lot of reuse, then that does justify it for a larger team.

SO:                   Right, exactly. Because the more content you have, the more time and money you’re going to save by automation. I mean, just you automate, and then you automate across 10 or 15, or 20 languages, and you automate across all your deliverables. And all that stuff adds up. When you start talking about a team of 20 people, and they spend 10, or 15, or 20% of their time producing all these different channels or deliverables, and you automate that away. That’s a huge gain in productivity. When you have one person working through those things with limited or no localization, then the value of that is just not there. So far, we’re doing an excellent job of convincing everybody that if you have a small team, you probably don’t need DITA.

GK:                   Well, it really depends. There are some circumstances where it can be a good fit, and maybe there are some where it’s not such a good fit. It really depends on your specific situation. When it comes to determining that fit, it may or may not always work out because you may see that that cost of standing up the DITA environment outweighs the benefits, like we just talked about. If you have some a use case for DITA, whether it is reuse, localization, more automation, your publishing, if you don’t have enough content to justify that, even if you’ve got the use case, then your management may just look at your setup and say, “Well, yes DITA could get you all these things that you’re asking for and make things easier, but it’s never going to recoup the cost of the initial stand up.”

SO:                   So what are those things? I mean what does it look like to have a small DITA group, or a group for whom a small DITA implementation makes sense?

GK:                   So one example is if your content has high-value, and what I mean by that is that that content is something that really is worth a lot to a lot of different people, and maybe it needs to undergo some sort of digital transformation process where it can be delivered to the right channels, it can be remixed and reused and repurposed and all sorts of different ways, there’s a lot of demand for that content. So even if there’s not much of it there, that content still has so much value, that the benefits you would get out of putting it into DITA outweigh those costs.

SO:                   So we’ve seen this I think with content that is regulatory, not necessarily regulated, but in fact the regulations themselves which are then distributed to lots of different people. So if your content is in fact the standard that says, this is how you should be doing things in XYZ industry or in XYZ organization, that may be a candidate. The other place that we’ve seen this is in high-value educational content, which might not be a ton of pages per se, but it’s the standard curriculum or it’s referenced material that explains to you how to do a particular thing, or how to get a particular certification.

GK:                   Absolutely. And when it comes to that content that’s where you know the value of it and the need for it for that audience really makes the difference. And I will also add that this is an example where with some of the clients we’ve worked with that have this a use case. Some of them do actually have a larger content set, but they’ve got a smaller team working on it. And so that’s where it really becomes this question of is DITA a good fit? And they get a lot of those benefits out of having a pretty decent volume of content, and then they can use the small team as almost more of a justification, because they can say well it makes these two or three or five writers lives easier, if they don’t have to do so much manual wrangling of that content, and they really can you know get the efficiency out of producing that high-value content.

SO:                   Right. I mean it’s probably worth noting that when we talk about high-value content, and we’ve described a couple of content types. The reason that it makes sense to put that into DITA is because it enables you to label the content in useful ways, so you can have an element called regulation, or you can have a specific table that’s repeated over and over again that has elements that describe what’s in the table, so you can provide these labels that give you information about what’s going on in the content. And because of the remixing that you’re talking about, having specific labels instead of just heading or paragraph, allows you to then capture what’s going on in the content, and then remix it downstream and do what you need to do with it.

SO:                   So the content is high-value in the sense that it gets remixed, repurposed, distributed, used by a lot of people, and it’s worth putting into DITA, because that allows you to give it those labels that make that remixing and repurposing better.

GK:                   Absolutely. And that gets into another use case that we’ve seen where maybe a smaller content set or a smaller team can benefit from DITA which is that, if the customers are demanding a type of content delivery that is not possible where you’re currently setup, so if you’re in some sort of a desktop publishing based setup or you’re not digitally delivering your content but there’s a need for that, then that’s another area where you can evaluate, and say does it help to have DITA? And in particular, when customers start demanding personalization, they want custom content that’s delivered to them just based on maybe the products that they’ve bought, or the services that they have decided to use from your company, that if you get that semantic tagging in there, and you have everything structured, then that delivery then becomes possible.

SO:                   And I think it’s worth noting here that we still today see a steady flow of customers who tell us things like, “Well, we’re authoring in some desktop publishing tool and we’re producing PDF for our content. We really need to put this on our website, not as a PDF but actually as some sort of web HTML, for the first time, and we’ve never done it.” There are enormous numbers of organizations out there that are still in that boat. So for those of you that are listening to this thinking, but everybody’s on the web, the answer is that, in fact, lots and lots of people actually are not just yet.

GK:                   Right. And that’s something that surprised me a little bit with how frequently we still do see that. And I think that’s especially the case with some of these smaller teams, because they just don’t have the resources to make that jump, to make that digital transformation. So I think that, that’s where it really gets down to this point of looking at, is DITA a good fit? Because, it can make that leap over to that digital delivery possible.

SO:                   Yeah. I mean, we’re still seeing, it’s not super common, but we’re still seeing legacy content in PageMaker, in QuarkXPress, in Inner Leaf, and I’m going to stop there before I dig myself further. Those people are out there, and you’re not alone.

GK:                   Absolutely. So one other use case, too, that can help if you have a small content set, or a small team, is looking across the organization at a broader level. Are there multiple departments that you have at your company that maybe need to share content, but they are limited in their ability to do so? Maybe they’re working in very distinct silos. Because if you look at it that way, even if each team is small on an individual basis, when you put all of that content together, then it starts to add up, and you maybe start to have more of a use case for something like DITA to save you costs on the entire content set when you put it together, and to also look at those benefits that you can start to get reuse that you couldn’t have before.

SO:                   Yeah. I mean, we always start with the tech comm group as the default. And that’s, I mean, 100%, where DITA lives to begin with. But the groups that we see here are technical training groups who may probably are reusing content, from Tech Comm. And also increasingly, the sort of technical marketing, or maybe sales enablement, groups that are producing pretty scary white papers and other kinds of marketing materials that are not just a short product description, or a one-page data sheet, but rather a longer not long-long, but longer form document that really could benefit from this. And in addition to the content reuse and sharing that you’re talking about, there’s also value in sharing the channels, the delivery channels. So if I have to build out a delivery channel for HTML, or for PDF, or for a portal, or whatever else, it’s really handy to be able to share that with those two or three or five other departments, so that we can all take advantage of that infrastructure, instead of having to build it two or three or five times for all your different silos.

GK:                   Yeah, absolutely. And this is another case that cuts back to what we were just talking about how you’d be surprised how many teams are still out there that are still entrenched in desktop publishing, and haven’t gone digital. We see a lot of cases where along similar lines, these different departments when we go in and ask, how are you sharing content right now? Because you might have the training group that needs to reference something and the technical manuals, you might have a marketing team that’s using some of the training materials and their presentations. And when you ask them, how are you sharing, they just say, “We’re going to their published documents, and copying and pasting into our own systems,” which of course gets everything out of sync, it has a lot of issues with version control, it introduces a lot of inaccuracies. And so there are still many, many cases where this is the only way that they can make those connections, and use that content. And once you open those doors, and have everyone working together with DITA as the basic framework, then it really gets rid of all of those barriers and those silos, and allows for production to be much more efficient across the board.

SO:                   So what about a component content management system, a CCMS? We’ve been talking about DITA in small teams, but is a CCMS a requirement as part of this?

GK:                   It’s actually not. And I think a lot of people misunderstand that as well. But they think that if you go the route of a DITA setup, that you have to have something like a CCMS as part of that, and have those workflow benefits that comes from for things like reviews and approvals, and the sort of end-to-end authoring to review to publishing pipeline. But you actually can work in DITA without a CCMS. And we’ve seen several examples of these smaller teams doing this as a cost saving measure. So they might use something else, maybe something like Git for version control, and then they’re just working in some sort of a web editor in DITA, and using the DITA open toolkit for publishing. And they don’t have it all connected in a CCMS, but they have enough coordination, because it’s a small team that everyone is able to communicate about the process. And they don’t necessarily need that overhead of a CCMS to make things work.

SO:                   Yeah. I mean, to be clear, you do get additional functionality from the CCMS. It’s just that in a small team, you can do sort of an 80-20 solution, you can get 80% of the functionality with source control, that last 20%, it would be nice. And if you have a big team, you’re going to need it. I mean, I think we shouldn’t. We should be careful with this one. All of our CCMS partners are going to yell at us. But the bigger your team is, the more value you get out of a CCMS. If your team is smaller, there is still value there. It’s just that the overall value is smaller, because your team is smaller. And so you can look at that. But certainly there are lots of instances where the smaller teams need a CCMS, and of course, they’re going to scale it appropriately. They’re not going to spend huge amounts of money on a CCMS, but there are some out there that can be very reasonable.

GK:                   And we’ve seen a few cases too where a smaller team will start in one CCMS that is designed for a team of that size, they have different kinds of levels and plans for different sizes of teams or different amounts of content. And they can start small and work their way up. Sometimes they do that within a single CCMS and upgrade their plans. Other times, they might change from one CCMS to another, depending on how they grow and scale over time. And we’ve also seen some companies use the homegrown approach of managing their version control and their authoring and publishing themselves, temporarily maybe for a few months or a few years, while they get to the point where they truly do need to CCMS. And they have that stopgap period. So there are a lot of different ways that you can approach things. And it’s all very flexible, because it can change over time. And hopefully it will change as you grow.

SO:                   I mean, that might be… Scalability is a really interesting point. Because one option, or one strategy that you might use is that you look at your company, your organization, you say, we’re going to grow. We’re a hot startup, we’re in the space. We’re going to grow, we have to scale. And in that case, you might take a hard look at implementing DITA now while you have a small team. You may or may not have a really great justification for it with your team of two or three or five. But you know that you’re going to be 20 in a year or in a year-and-a-half. And at that point, you’re going to be working at lightspeed. And actually taking that pause and doing a big implementation is going to be problematic.

SO:                   So scalability or anticipated scale is actually a pretty good reason to implement DITA for a small team. Like we’re this big now, we know we’re getting bigger, we know what’s going to happen, we’re going to build this out now while we have a small content set, it’s going to be relatively easier to do it instead of waiting for that challenge to snowball, and then having to really do a big conversion process.

GK:                   Yeah, absolutely. And I think that just gets into the idea of future-proofing your content strategy, and building that end as part of it. And when we come in and do an assessment, which is the sort of how we would help make that determination of whether DITA is a good fit for a smaller team or not, that that’s a big part of it, as we look at what are the problems you’re trying to solve right now, versus what are your goals for the future and the things that you anticipate happening in the next year, in the next five years, 10 years down the road. And try to figure out how we can make a plan or help you come up with a plan that takes that into account. And that’s where that scalability piece is really, really important. Because if you anticipate that need early enough, you really can save a lot of cost and effort and headaches when it comes to actually getting DITA in place.

SO:                   Yeah, it’s much easier and cheaper to do this when you don’t have a ton of existing content in some other format.

GK:                   Yeah, absolutely. So is there anything else that you want to talk about when it comes to advice for small teams using DITA?

SO:                   We haven’t talked about conditionals really, and variant content. That would be another thing to just sort of keep in the back of your mind. If you have content variants DITA’s pretty good at that. And it’s one of the things that it handles well, that can be problematic elsewhere.

GK:                   Yeah. Conditionals really play into the personalization angle. We’ve seen that with some of the small teams that we’ve worked with where that’s been a necessary part of making their personalization happen. So that’s definitely a big thing to keep in the back of your mind along with all the other things that we’ve talked about.

GK:                   So with that, I think we can go ahead and wrap things up. So thank you so much, Sarah.

SO:                   Thank you.

GK:                   And thank you for listening to The Content Strategy Experts podcast, brought to you by Scriptorium. For more information, visit Scriptorium.com, or check the show notes for relevant links.

The post DITA for small teams (podcast) appeared first on Scriptorium.

In episode 92 of The Content Strategy Experts podcast, Elizabeth Patterson and Alan Pringle share how you get started with a content strategy project and what you can do if you really don’t have a solid grasp on your needs.

“It’s about opening yourself up to getting feedback from someone who’s done this stuff before, and may come up with some solutions that you didn’t necessarily consider in your own thinking.”

–Alan Pringle

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’re going to talk about what options you have when you know you need a content strategy but can’t get a handle on your needs.

EP:                   Hi, I’m Elizabeth Patterson.

Alan Pringle:                   I’m Alan Pringle.

EP:                   Today we’re going to discuss how you get started with a content strategy project and what you can do if you really don’t have a solid grasp on your needs. I’ll kind of start things off and just share that when we have introductory meetings with potential clients, there’s often a problem or a pain point that they express to us, but there can be a disconnect between understanding what you need to do and what you want to do in order to fix that. Alan, I want to ask you this question. Why do you think it’s common that we see that disconnect?

AP:                   To me, it’s very similar to when you go to the doctor, for example. You have got some pain or ache and you can’t quite figure out what’s going on, because guess what? You’re not medically trained so you go to the doctor and he or she looks at you and says, “Based on these symptoms, here are the systems in your body that could be contributing to that problem.” Again, because you don’t have medical training, the doctor may come back with some suggestions that you would have never have thought of, because guess what? You’re not a doctor. That’s kind of how I see it. You have an issue, a pain and ache, and in this case it’s content related, if you’re talking about content strategy projects, and you go to an expert and say, “We’ve got this going on, how can we fix this and make it better?”

EP:                   And that’s a very good point. I think also there’s a bias there, and it can relate to this doctor analogy too. If you take really good care of your health but you’re having some sort of issue, you might not really think clearly about some other causes and going to the doctor would help you. It’s the same thing with a company. You might be biased because you’re inside that organization and you’re not thinking about it as thoroughly as you should.

AP:                   Right. That gets into the whole third party thing.

EP:                   Absolutely.

AP:                   It’s like you go to a friend for advice. If you have got relationship problems or whatever, or you’re buying a house for the first time, what do a lot of people usually do? They go and talk to a friend who’s been through something similar to get their input on it because they’ve been there. Again, it’s about kind of opening yourself up and your mind to getting feedback from someone who’s done this stuff before, and will probably come up with some solutions that you didn’t necessarily consider in your own thinking.

EP:                   Right. That really pulls us into the next question, which is what you can do. One of the responses to that are to look into doing some sort of discovery project with a third party. Could you speak a little bit to what a discovery project is?

AP:                   Sure. When clients come to us they usually say, “We know we have this content related problem.” What we do, we say, “Okay, let’s take a look at that.” It becomes part of a bigger engagement essentially, because what we need to do is back up a little bit from that pain point. We need to figure out what the big overall business goals for the company are, and then we can say, “Okay, this pain point is likely happening because it’s not aligning with this particular requirement.” What we want to do is go in there and people usually come to us when something’s wrong or broken, just like you go to the doctor. It’s not usually, “I feel great. I’m going to the doctor.” It doesn’t work like that generally. Something’s wrong. They come to us. What we want to do is take a look at what’s broken, take a look at the big overarching business goals and how that content problem ties into it and what you can do to fix it to better align that content pain point with the business goals of the company and fix that problem.

EP:                   Right. Discovery projects, when we do discovery projects, there can be differences depending on the type of project that it is. But overall discovery projects are very similar. We’re identifying gaps. We are identifying tool possibilities. We’re putting together a map for solutions for your content project. They all look very similar in that sense.

AP:                   Right. There’s an overarching kind of theme or goal to these things. I’m glad you mentioned tools because there’s often this temptation when you’ve got some kind of problem, oh, I’m going to get a piece of software that will magically fix that. It doesn’t usually work like that.

AP:                   That’s why I think having someone come in to kind of evaluate and articulate what the requirements are to help you build that list so you can pick the right tools. There needs to be this conversation. There needs to be a lot of back and forth among different people in your organization, whether they are directly or indirectly affected by content, in the case of a content strategy project, of course.

AP:                   A lot of what we’re talking about applies to business in general, but of course our focus is more on content, because you want to get the big picture and get those requirements laid out and then find the tools and solutions that fit that thing and make those goals come to life and work. If you don’t do enough discovery and you don’t put a lot of thought process and you just pay attention to marketing, or what you heard another company did, that gets into a dangerous territory where you may not get return on your investment when you buy a tool and it doesn’t turn out as you anticipated.

EP:                   Absolutely. You’re talking about how important it is to talk to all of these people so that you can pick the right tool. Oftentimes stakeholder interviews are part of a discovery project so that the third party goes in and they talk to the different stakeholders that are going to be affected by that tool, find out what their pain points are, and then that helps to identify a tool that’s going to really solve the problems or fit your solution.

AP:                   Right. I think it’s also worth pointing out too, on these discovery projects, this is just about looking at tool options and suggesting the possibilities, and then later, what we generally do is have a phase where we configure and implement the tools.

AP:                   This is also very helpful from a business point of view. If you go into relationship with a consultant or a vendor or whomever, it’s probably good from a business point of view to separate out the discovery part from the configuration implementation part, because what if you get into the discovery part and you discover that you and that consultant are not sinking. It happens sometimes. You can’t quite sync, so that relationship probably shouldn’t continue.

AP:                   From a strictly business point of view, it’s a good idea to separate the discovery out from the configuration, the implementation. Also, it is very good from a budget point of view, say, “In this fiscal year, we’re going to lay out the discovery work and come up with a roadmap, which is a result of your discovery project.” Then later in the next fiscal year is when we’ll start buying the tools and implementing them, say, over the next two fiscal years or something like that.

EP:                   Oftentimes that roadmap and the results from your discovery project are what help you, or can help you to get buy-in from upper management to actually get the funding that you need for that tool or the implementation phase.

AP:                   Well, and really from my point of view, too, that when you mention upper management, they need to be part of the discussions from the get-go. They need to be part of those interviews because they need to articulate what they see as being the requirements are. They also need to hear about what the issues are in the content world. Because they’re the ones, A, like you mentioned, who have the money, and B, they’re the ones that also have the vision of how to reconcile those things. It points to a thorough communication system that you have to set up when you’re doing these interviews. You don’t just pick the people that are immediately affected by content, the creators who reads it, who edits it, who reviews it, how you distribute it. You also need to talk to your executives to find out what they expect from the content and how it aligns with their vision.

AP:                   You need to talk to your IT people, for example, because they’re controlling likely maybe some web servers that your web content lives on. They may be controlling tools. They’re the ones that do inventory of tools and decide, yeah, we’ve already got a tool that does this. Why are we going to get another one? It’s not a situation where you need to be in a vacuum. A discovery process is talking to people who were directly and indirectly impacted by decisions. And you have to include those people who have the bigger overarching vision, for lack of a better word, for where your company is headed.

EP:                   Right. We’re talking here about discovery as a way to solve a problem. Are there any other reasons that a company might consider a discovery project?

AP:                   Well, we tend to be focusing on the negative things and we really have done that in this podcast. Oh, it’s a pain point. It’s the bad things. But you’ve also in this process, have to look at the things that are working and figure out a way to either translate those or move those over into your new process or whatever new systems you’re going to recommend, to be sure those things are handled right. You’ve got to look at the good and the bad, but the bad is what usually brings people to us. But we also have to recognize as consultants and as the people who help run these discovery programs, that you have to also have a really good ear and listen, and find out about the things that people like and that in some way need to be kept as things move forward with improving whatever it is that is indeed broken.

EP:                   Right. Another reason to consider a discovery project, and this isn’t a problem, but there might be a merger and bringing in a third party to help with that merger and bringing content from two different companies together and making a plan, that can be very helpful because there’s a lot to unpack there.

AP:                   Right. There’s something to be said, especially for a third party in this case, because you’re going to often have two basically completely duplicative systems that are pretty much doing the same thing around content. From an IT point of view, keeping both is probably not ideal in the long-term, at least usually it’s not. It is not a hard fast rule here.

AP:                   It’s a good idea to have someone come in and to take a look who has had experiences helping other people with mergers, like you’ve mentioned. Is it likely you’re going to have someone on your staff that has gone through that? If you have, that’s great. Use that resource. But a lot of times you haven’t, and that again points to, let’s talk to a third party who recognizes the issues and the challenges surrounding our merger and content and how they can help us figure out how to integrate things better.

EP:                   Right. Alan, well, thank you. That was really helpful. Thank you for joining me today.

AP:                   Sure. Enjoyed it.

EP:                   With that, I think we’re going to wrap up. Thank you all for listening to The Content Strategy Experts podcast brought to you by Scriptorium. For more information, visit scriptorium.com or check the show notes for relative links.

The post How to align your content strategy with your company’s needs (podcast) appeared first on Scriptorium.