Scriptorium

March 2025 update: We have moved LearningDITA to a new platform. The Introduction to DITA course is still free, and you can sign up for courses at store.scriptorium.com.

In episode 141 of The Content Strategy Experts Podcast, Alan Pringle and Christine Cuellar discuss the story behind LearningDITA, the free DITA training created by the Scriptorium team.

What we are trying to do with this site is give people a resource where they can go and, at their own pace, learn about what DITA is and how it can apply to their content and their content processes. It’s a way to take some of the technical mystique out of it, to bring it down and help you learn what it is and how it works.

– Alan Pringle

Related links:

LinkedIn:

Transcript:

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 talking about LearningDITA, the free DITA training created by the Scriptorium team. 

Hi, I’m Christine Cuellar.

Alan Pringle: And, I’m Alan Pringle.

CC: Alan, welcome to the show. Thank you so much for talking with me today. We’ve just received a lot of great feedback about learning DITA on LinkedIn. A lot of people are thanking us for the course, talking about how it was a great experience for them, so we thought this would be a great resource to dive into.

AP: Sure.

CC: My first question for you is, what is Learning DITA, for those listeners that have no idea what we’re talking about?

AP: Learning DITA is a free online resource where people can go and take several courses to learn about DITA. DITA is an open source standard that gives you a way to describe your content in a modular fashion. It’s really good for helping you basically build in intelligence into your content, so then you can then filter it, sort it, and do that stuff with it.

CC: Got you. Okay. Learning DITA is the free training that the Scriptorium team created many years ago. When was Learning DITA created?

AP: We may have started somewhere in 2014 into 2015. That’s when we started. I think the first course came out, probably came out right around 2015.

CC: Okay. It’s been around for a while. Was there anything like it at the time? Why did you feel the need to create this resource?

AP: Well, I mean, you just heard me describe DITA and you hear things like –

CC: (Laughs) Yes, it’s a lot of words.

AP: You hear Darwin information typing architecture and, you may hear from someone at work, someone you work with, “We may need to use this,” and you’re like, “What is this? This sounds like some scary sh*t. I’m not doing this.” What we are trying to do with this site is give people a free resource where they can go and, at their leisure, at their own pace, learn about what DITA is and how it can apply to their content and their content processes. It’s a way to take some of the, I guess, technical mystique out of it, to bring it down and help you learn what it is and how it works.

CC: That’s amazing. Yeah, that’s a great resource. Who are the experts that are behind the Learning DITA course? Who created it? I know you mentioned the Scriptorium team, so who was involved in that?

AP: Well, a lot of the people that you have heard on this podcast have contributed Gretyl Kinsey, myself and several other team members have. We have written a lot of that content. It’s not completely Scriptorium, I will be very clear on that. We’ve had some other people who have contributed some content and we appreciate it. We have set this up so that the actual source content for learningdita.com, which is DITA XML files, they are freely available in GitHub. You can download them and look at the source. You can treat it or view it as a proof of concept.

This is how DITA works. The source files are DITA, and I don’t want to go too deep into the weeds, but we basically transformed that, DITA XML, into a WordPress friendly format, markup language, and sucked it into WordPress where we use a learning management system that sits on top of WordPress. You’re going to see courses where you go through exercises. There are assessments in addition to reading about things. They’re linked to reference information. There’s all kinds of ways to absorb and understand DITA through learning DITA. Again, it’s free and we tried to make it, shall we say, less threatening, very accessible.

CC: Yeah. Yeah. I’m actually taking it right now. I’m going through the courses and my whole career has been in marketing. I know nothing about technical writing. DITA was a whole new word to me when I started this position. If I can do it, anyone can do it, basically. It really has made the concept very down-to-earth for me.

AP: Don’t sell yourself short. That’s one point, I’m glad you brought this up. People really may assume that DITA is strictly for product and technical content, and that is no longer the case. I think it’s fair to say early on, it was created specifically by IBM for technical content, product content, but it has expanded its reach. The fact that you are using, when you’re taking the class, you were using an LMS to basically consume DITA content that is training content, that shows you right there, this is not just about user manuals anymore, not by a long shot. There’s proof in the pudding. There it is, you’re using learningdita.com, and believe it or not, you’re consuming DITA content, but you may not know it, but it’s there under the covers.

CC: Yeah. It’s been really helpful. I’ve always been really passionate about processes, optimizing processes to make everybody’s jobs easier, to make your workflow easier so you can do more, better and easier. Just work smarter, not harder, I guess is a better way to say that. The whole approach to structured content and DITA, it was scary at first to be looking into, but that’s the core concept is, let’s structure things in a way so that we’re flexible, we’re scalable, we’re not making our team repeat things over and over, we’re doing things better in a way that’s more accurate, and I really love it. I still have a while to go, I haven’t completed the course yet, but I love that heartbeat behind what DITA is and what Learning DITA is.

AP: Right, and it’s really, it’s trying to bring something that may seem very scary and technical down to Earth. A lot of people hear, XML, that is “extensible markup language,’ they think they’re going to have to type computer code.

CC: Yeah, that’s what I thought.

AP: Right, that is not necessarily the case. Sure, if you are comfortable typing code, you can type code, but there are a lot of authoring tools and experiences that can sit on top of DITA to hide all that, so you feel more like you’re just using a word processor. But the bonus is, under the covers of that authoring experience, the DITA structure is basically managing your content. Like enforcing a template, it is forcing you to write to a particular structure and to include intelligence about what you’re writing like, who’s the audience? What product is this for? Is this for a teacher or is this for a student? All of those kinds of things, and when you build that kind of intelligence into your content, it makes it much easier to mix and match and assemble and filter and create all kinds of versions and alternatives based on the audience who is consuming your content.

CC: That’s great. Like you said, not just product and technical content. Every aspect of content needs to be thinking about that. I know in marketing content, that’s a big thing. Who are we writing to? What’s the purpose of this? Having a structure that forces you to keep that in mind is a no-brainer. It feels like it’s great.

AP: Right, exactly. If you feel that you are in a situation where you find yourself doing a lot of manual work, you’re doing a lot of copying, pasting, that may be the biggest clue. If you find yourself in a content development process where you were making multiple versions of the same file and then making a change here, change there, but then forgot about the fact you’ve got versions 14 and 15 over here that also need that change. That’s the kind of thing that DITA can help with.

If you have any kind of inkling that you might need a better way to make versions of content to reuse content, take a little visit to learningdita.com and learn a little bit about DITA and see if it might be a way that it can solve some of your problems. I am not going to sit here and tell you that DITA is a fit for every organization, it is not, but it does address a lot of the common pain points that anybody who creates content in a professional way, the kinds of things they have to deal with and that make their work life a lot of times just downright unpleasant.

CC: We’ll include a link to Learning DITA in the show notes. Something also to mention, not only is Learning DITA free, but it’s a flexible course, so you can take it at your own pace. You can do a lot of it and then stop, whatever you need to do. It’s not scheduled or anything, it’s as flexible, free, low risk as possible.

AP: Yeah, there are multiple courses and it starts with the basics and then builds upward. Are you going to take all of the courses? No, you may not need to, and I’m going to have to do a refresher, I’m going to cheat and look and see how many courses we actually have, because I don’t remember, let’s see. I think we have 9 or 10 courses right now, so there’s a lot there. Like you said, you take it at your own pace. You can start with the introduction, get your feet a little wet, and then start diving in a little more deeply into the structures that make up the DITA standard.

CC: We talked about this a little bit. Who is Learning DITA for? I know you mentioned that the most common scenario is someone saying, “Okay, here we’re going to introduce DITA, this is what we’re going to start working with,” tells it to an employee who may be like, “I have no idea what you’re talking about,” and is panicking. For one, is that the only scenario for learning DITA? For two, who is Learning DITA for?

AP: Learning DITA is for anybody who wants to know more about the DITA standard and how it could apply to their professional world, or even not even professional world. If you have any interest in improving content processes, content operations, and you may be more of a manager who doesn’t actually create the content but still want to understand what’s going on with DITA and how it can maybe help your organization, it’s for anybody who wants to understand better content processes and how DITA could possibly provide fixes for any problems that you have with your content operations.

CC: How many people have registered for Learning DITA or taken or completed the courses?

AP: Well, we did start in 2015, so there’s quite a few. I think we’re somewhere hitting near, as of this moment, 15,000 people have signed up to use the courses, so yeah, it’s a lot. It makes me feel good to see something that we put together being embraced by the content community and getting their hands a little dirty and figuring out how this DITA thing works and doing it at their own speed and sometimes on their own time. My hat’s off to them for digging in and learning these things.

CC: Yeah, I love that it’s such a community-oriented resource. It feels like it’s been so helpful for people. It sounds like people also contribute or give feedback or have asked for other courses.

AP: They have. We have a lot of resources listed on the site and within the courses, and a lot of those point to things that other people in the DITA community and content community they have created. Again, it’s not just about us at Scriptorium, this is about the content world and how you can really improve your content operations by breaking your stuff into more modular structured content that DITA supports.

CC: When someone finishes the Learning DITA courses, but then they need more training, they realize, “I’m going to be getting more into this,” where would you point them? What should they do next?

AP: Once you’ve gone through those courses, I would say there’s a good chance that you may be in an organization that is looking at implementing DITA, and if you need help doing that, we as Scriptorium and there are other consultants that do this too, talk to somebody who can help you, for example, set up your workflow, your database workflow, help you figure out how to map your content to the DITA model. Then, not only do that legwork upfront the assessment stuff, you also may need help actually standing up and configuring your DITA system and then training people how to use that system. We do all that at Scriptorium. If you need help beyond what we offer for free, we will be more than happy to oblige you and provide you with some consulting and training services to get you set up and running in DITA.

CC: Absolutely. Well, Alan, is there anything else that you want to be sure we communicate about Learning DITA or anything else that’s coming to mind that you really want people to know or understand about the resource?

AP: We appreciate people contacting us. If you see something that’s not quite right or you don’t understand, we appreciate that being pointed out and we will do our best to correct it at some point. It’s also a community resource. I can’t stress enough, we’re trying to demystify DITA, make it less scary, and that’s the point. If you, in your head, have an idea of how you can contribute and do something along those lines, please do it, I will note. Other people have taken our Learning DITA source content and then created versions of Learning DITA and German and French, and I believe even Chinese.

CC: That’s amazing.

AP: There are other people who have taken that stuff and then translated it and then used our process to create the same thing in other languages to make it even more accessible and reachable to other people.

CC: Yeah, that’s great. That’s really great. Well, I’m just really impressed with the whole Scriptorium team for coming up with this resource. Since I’ve started, I’ve just seen nothing but really positive feedback about it. I love how, as we’ve already talked about, it’s community-oriented, it’s just a free resource that helps people really understand. I love the phrase that you use de-mystify, because I think that that can happen a lot of times in our jobs, we just get overwhelmed by what we don’t know, especially when there’s the expectation that we’re going to do this now or you need to know this now. It’s great that the team saw that need and then fulfilled it with this resource. It’s really great.

AP: Yeah. and it’s always a problem when you’re dealing with technology. There’s always this fear of the unknown involved. If you can cut that fear out, you’re going to have a much better time when it comes time for you to possibly implement a DITA workflow.

CC: Yeah, absolutely. Well, thanks so much for talking about this, Alan, and thanks for being here today.

AP: You’re welcome.

CC: 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 What is LearningDITA? (podcast) appeared first on Scriptorium.

In episode 140 of The Content Strategy Experts Podcast, Sarah O’Keefe and Éric Bergeron, president and CEO of IXIASOFT, share the story behind the MadCap acquisition of IXIASOFT.

“The question that everybody is asking, and we really want the answer to, is this seems like a very sensible combination, but MadCap as an organization has done a really excellent job with their marketing, and much of their marketing has been based on the concept that DITA is not something that you need. Flare is happy and easy and safe and wonderful, and DITA is none of those things. So, when you say this is a bit of an odd combination, I think everybody’s looking at, ‘Well, wait a minute, there’s been a lot of DITA bashing over the past 10 years or so.’ What do you do with that?”

—Sarah O’Keefe

Related links:

LinkedIn:

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.

Hi everyone, I’m Sarah O’Keefe. In this episode we’re talking about MadCap and IXIASOFT with Éric Bergeron, president and CEO of IXIASOFT. 

Éric, welcome to our podcast.

Éric Bergeron: Thank you very much. I’m very happy to be here today.

SO: Well, and we’re excited to talk to you, since I think the entire industry has been talking about nothing but this merger for the past couple of weeks since the news broke. And so I wanted to ask you a couple of questions about what’s happening here and where is it going and what does it mean for those of us that live in the DITA XML world. And I’ll guess I’ll lead with the obvious question, which is why sell IXIASOFT to MadCap?

ÉB: Yeah, very good question. Unfortunately, I will have to give you some background before answering that question, and I will try to do that very quickly. Six years ago, IXIASOFT was a very traditional software publisher. We were selling perpetual licenses with a yearly maintenance plan. We were installing the system on-prem, customer side. And the product was a desktop application connecting with the backend server. So very traditional.

And six years ago, we decided to change the business model and provide to our customers a SaaS solution. So we had to change the business model to provide subscriptions. We had to change the product to move from a desktop application to a web-based application. We also had to put in place a new team to manage the hosting and the management of the solution. And we knew that it would take approximately five years to do all that work. And we were near the end of that five year period.

So the timing was good for us to look, “Okay, what’s next for IXIA? What will be the next growing phase? What should we do to grow, continue to grow?” And at that time, MadCap arrived with Battery and they contacted me. And they had a plan. And we listened to their plan, and we discuss it with them. And finally, we realized that the timing was perfect. I think the story and the plan, the project is great, and that’s why we decided to sell. And also because I will turn 60 very soon and I was starting to think about my retirement. It’s true. But really, the driver was really the plan, the project, I think they had something interesting to propose and that’s why.

SO: So what can you tell us about that plan or that vision? What is the vision for the combined company that you can share?

ÉB: And again, I was a teacher in the past, so I need to explain things. But for me, there’s a spectrum of solutions on the market. And some solutions provide the ability to manage documents, other systems provide the ability to manage more components, and some systems manage components with structure. And I think with the combination of MadCap and IXIA, the last two, we will be able to provide that to the market. We will be able to provide a component system to create unstructured components with MadCap Flare and Central. And with this IXIASOFT CCMS, we will be able to provide the tool that will let our customer manage components and very structured components.

So that’s the goal, I think it’s to have a broader offer and propose to the market a solution that will let them move from unstructured on-component systems like Word and FrameMaker, move them to Flare and Central. And eventually, if they need more structure, they will be able to move to the CCMS. And I think that’s a great project.

And the other reason why I was interested to proceed with that transaction is also because MadCap, they had some big customers that outgrow their solution. And they were looking for a more structured system. And IXIA will be the place they will go. So that will make the IXIA customer base grow. And that was a guarantee for us that we will have more customers, they will keep the product, they will continue to improve the product, and that will also increase the customer base. So that’s also an answer to your first question. But that was also the other reason why I was interested in that transaction. And I think for the market it’s great to have those two products together in the same organization.

SO: So I know that you and Madcap, both IXIA and Madcap have said in the short run, “Nothing is changing. Do not panic. Remain calm.” But looking at this a little bit more long-term, what kinds of changes should IXIA, or for that matter, Flare customers expect in the midterm? Six months, a year, five years, what does that look like?

ÉB: Yeah. For the next six months nothing will change, really. It’ll continue to be the same. However, IXIA for example, we will have a user conference at the end of May in Munich. This year the user conference will be in Europe. And we will have MadCap customers that will come to the IXIASOFT user conference. Because some of the MadCap customers are interested to learn more about DITA and maybe use that eventually. And we will provide to them a path from Flare Central to IXIA CCMS. So those are small changes, but we will start to see MadCap customers maybe more in the IXIASOFT CCMS community. But internally nothing will really change.

Over in the next year, two years, what we want to do is really propose to the market some tool to make the content move more fluently from Flare, Central to the CCMS. So we’ll have an importer, for example, to import Flare content to the CCMS. That will arrive probably after the first six months, but it will be there. And that will clarify the path for customers moving from Word to Flare, and eventually from Flare to the CCMS, to DITA. So that we will see in the future.

And more midterm, long term, I can say that Battery, you mentioned Battery previously, we talked about that, they decided to invest in MadCap and IXIA, but they want to continue to make that combination grow. Maybe eventually there will be other acquisitions to continue to complete the offering and to propose to the market a broader offer for people that want to create and publish content. So that will probably happen eventually.

SO: So what do you think this looks like in sort of in that five years down the road? My track record on five years is not very good, I don’t know about you. But what do you see as the big picture vision in that longer term timeframe?

ÉB: Agree with you, five years in technology is very long. And I’m not the best for visionary things. One thing I really believe is technical documentation, but documentation in general will change a lot. We are moving definitely from books to components. In the past we were providing documentation with books and manuals. Now, for me, documentation is more and more knowledge base. And there will be more and more modern tools to publish that information. ChatBot, for example. ChatBot will ask questions to users. With the answer, they will find the relevant content, then they will push that to the end user. We will have tools like Fluid Topics, Zoom and Congility that will be used more and more. So we need to create content that is compliant or compatible with those tools. And I think component systems are very good systems to create content that can be leveraged by those modern tools.

The other thing is, for sure, in the past there were a lot of text and picture diagrams. I’m pretty sure we’ll have more and more video, audio, augmented reality, virtual reality objects too. So that’s the future of the documentation. And our tools will have to provide the functionality to create those contents, but also to publish those contents. So that’s the future of our world, I think. I don’t know exactly how we will navigate in that evolution, but it’s definitely for me I’m sure it’s going in that direction.

SO: So I guess the question that everybody is asking and we really want the answer to is this seems like a very sensible combination, but MadCap as an organization has done a really, really excellent job with their marketing. And much of their marketing has been based on the concept that DITA is not something that you need. That Flare is happy and easy and safe and wonderful, and DITA is none of those things, right? And you don’t need it and it’s just generally not great. So when you say this is a bit of an odd combination, I mean, I think that’s what everybody’s looking at is that, well, wait a minute, there’s been a lot of DITA bashing over the past 10 years or so. So what do you do with that?

ÉB: Yeah, it’s funny that you mentioned that, because after my first call with Battery and MadCap, I went to the MadCap website. And I look at that saying, “Oh, how can we work together? We’re so different.” But when you are selling a product, you are doing the best marketing pitch to sell it. And not having a DITA tool, they had to do that. And so I fully understand. But we talk about it and you probably realize that all that information was removed from their website after the transaction, because they had to do that to promote their product, but they don’t need that anymore. And it’s the opposite now. They need to embrace DITA and put DITA at the right place. And it’s true. And I still believe that not everybody needs DITA. Some organizations, they don’t need that highly structured content. And so it’s okay to produce content that is not very structured. If it answers your needs, it’s fine.

Maybe eventually they will need more structure, and the good news now they have a solution for that. We can propose to the market the path to move to higher structured content. And what we want to do is provide tools that will let you move from unstructured components to structured components. So yeah, it was funny to see that on their website, it’s funny to see that disappear now. And now we will put on our website content that will explain the new reality. But I fully understand it was… And you’re right, we were a little bit like an odd couple, but we’re learning to live together now and I really believe that it’ll work very well.

SO: I have some questions about who’s the neat one and who’s the not so neat one, but I think we’ll set that aside. Is there anything else that people should know? Things that I haven’t asked you about, but information that you want to make sure is out there about this merger transition?

ÉB: Maybe one thing I would like to share with you is the fact that, for me, it was my first experience selling my company really, and I was really happy to do it with MadCap. And especially because Anthony, the CEO of MadCap and I, we share a lot of values, same values. And when you look at the history of Antony, he founded MadCap 17 years ago with friends. He was working before at eHelp. And they worked together for a long time. They grew organically all those years. And it’s the same for IXIA. If you look at the IXIA team, we are working all together for a long time, very, very long time. And 20 years, 25 years, some of them. And we have the same experience a little bit.

So I think this transaction, this merger was interesting and went very well. Because when Anthony and I, we were talking, we were at the same place. We were able to understand each other. And I believe that that merge will work because of that and because people working on both organizations share the same values. And for me it was really, really important. And that’s another reason why I accepted to enter in that transaction because I wanted to make sure that my team, my customers, and I say my, but IXIA is not a one-man show. It was really the IXIA team, the IXIA customer base. I’m sure they will be respected in that process and they will be happy in the future. So that’s just another thing I wanted to say.

SO: Well, and that’s an interesting point because we always talk about how… I mean, the work that we do and everything else, it’s about people, right? It looks like a technology problem, but it’s always about the people. And I guess here again, we’ve fallen or I’ve at least fallen into that trap of saying, tell us about the technology, tell us about the integration. And you’re saying, well actually, as always, it is about the people. So yeah, that’s a great point. I think I’ll leave it there. So Éric, thank you for being here and sharing this background and this information.

ÉB: I was really happy and thank you for the invitation.

SO: And congratulations to you and the whole team and to the MadCap team and Anthony and all the rest of them.

ÉB: Thank you.

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 Éric Bergeron explains the MadCap acquisition of IXIASOFT (podcast) appeared first on Scriptorium.

In episode 139 of The Content Strategy Experts Podcast, Sarah O’Keefe and special guest Keith Anderson dive into their experiences with structured content, DITA, and user content.

“My definition of context is anything that affects the cognitive processing of information. […] So, whether you’re consuming information by reading or listening, there are so many factors that affect how you process the context of the content.”

Related links:

LinkedIn:

References: 

Transcript:

Sarah O’Keefe: Welcome to the Content Strategy Experts Podcast, brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way. In this episode, we talk about structured content, DITA, and user context. Hi, I’m Sarah O’Keefe, and I’m here with a special guest, Keith Anderson. Keith is a longtime friend and one of the very few people I think in the world who understands both DITA’s structured content and the world of UX content. So Keith, welcome aboard.

Keith Anderson: Hi. It’s good to be here.

SO: Thanks for coming.

KA: Of course.

SO: So first, give us a bit of a background on structured content and DITA and what your sort of experience is in that space.

KA: Oh, okay. So I go back to SGML days when I was working at a telecom company and we were doing structured content back then, and it was mainly in DocBook, but structured content lent itself really well to being repurposed or single sourced, like we used to call it. There was a point where we were actually single sourcing out the instruction sets for online help, for printed documentation, for instructional design, and we also used them for test scripting. So that’s kind of how I understood the power of structured content.

SO: I just want to note that we are still wrestling with single sourcing and learning content and technical content. So having somebody tell us we did this back in the day, pre-DITA is pretty encouraging.

KA: Yeah.

SO: So then digital transformation comes along, and I think you’ve said that there you can’t really apply DITA directly, but you came up with a way of making that work. What does that look like?

KA: Okay, so out of what I would call the mainstream content management systems, out of all of them, only Adobe Experience Manager actually natively supports DITA. And Adobe has DITAWORLD every year, but when you look at content management systems like SharePoint and Sitecore, they don’t support it. So I was brought on board to do a project a few years ago. It was an online help system, and when I did the content audit, it was like two and a half billion words, and they had been maintaining it in some old tool and then they were just porting it over to the online help system. But it was taking a lot of time. They were trying to move everything into Sitecore. And a few things that I noticed, one was they weren’t using some of the best Sitecore features, which are inheritance and repurposing content. That’s just built in.

The other thing that they weren’t doing was planning out content to be repurposed. So I got the bright idea that I would use DITA because when we did our design thinking sessions, we kept coming back to that, the fact that this was an online help system and DITA lends itself really well to that. So I came in and I ended up with my own little server and … Let me back up just a second. Sitecore, all it is a fancy interface for a bunch of XML schema. And so I thought, well, theoretically it’s possible to enforce DITA on Sitecore and DITA broke everything else. And I started doing research and I talked to a guy in The Netherlands who told me that the surest way to hell was to try to put DITA in Sitecore.

So what I did to circumvent this was I did content modeling and I came up with the idea of using DITA as a platform independent model, meaning that we use it for terminology and we use it for reference, but we can’t technically implement it. So the platform is not dependent on any of the schemas in DITA. And we did that, and that actually helped quite a bit because it did provide us with structure. And then we were able to set up search hierarchies and things like that on the solar server. Solar is the search engine that ships with Sitecore most times, and it worked out pretty well that way.

SO: So you’re saying that essentially you used the concept of a DITA reuse or something like that, but you implemented it without using the standard DITA [inaudible 00:04:39]?

KA: Right. But it was a really good place to refer to. So we used the DITA vocabulary, we used the idea of how DITA content is separated out into topics, and then I introduced topic-based writing to these authors who had been doing very verbose writing on things that didn’t need to be verbose. So we were able to cut out two thirds of the content just by going through and doing that.

SO: So that’s really interesting because it’s one of the big issues that our clients struggle with is this question of, okay, we have web content and we have DITA content, and how do we put the two together? Or how do we integrate them in some way? So in your work, in addition to looking at these sort of structured concepts and putting them in, even if you’re not strictly speaking using DITA or I guess even if you’re not using DITA period, you focused very much on context and the relationship of content and context. So I guess we have to start with the basics, which is what is context or what is your definition of context?

KA: My definition of context is anything that affects the cognitive processing of information. It’s an idea that context is three-dimensional and that, well, the author Luciano Floridi, he created a term called infosphere, and he essentially says that in today’s world, we are living in an infosphere. And it makes a lot of sense because if you imagine context is all around you. So whether you’re consuming information by reading it or you’re listening to it or whatever, there’s so many factors that affect how you process the context of the content. So for example, when I lived in the Chicago area and I took the train downtown every day, I was constantly reading, but was interrupted a lot just by train stops or noise or whatever until I learned to put on headphones just so I could read and focus on that instead of what was happening around me.

So context is very situational. Some things affect you, some things don’t. There’s many, many examples of when you have more context, it completely alters the way that you see something. One example that I could think of is controversial, but it’s Bill Cosby. With all the controversy that’s happened with him, does that for you as an individual, does that affect how you see his life’s work, which was comedy? And so there are factors where context utterly changes things over time. And some things you can control, some things you can’t. I think companies like Comcast who are notoriously hated by most consumers have trust issues regardless of the intent of content writers in the company. And that’s a context those writers cannot control.

SO: So they have no goodwill and that’s their context.

KA: Yeah. And the flip side of it is the context of creation. And back in the day when we were doing online help, you remember how we would talk about can you write good online help for bad software? I mean listen, we had late-night drunken discussions about this at STC conferences, but I think the modern dilemma for content strategy is can you write good content for a bad corporation or for a bad organization? I think it’s a philosophical issue. How do you build trust? How do you be authentic without engineering authenticity? All of those things are contextual and people pick up on it. It’s like magic. You can tell if somebody has written something under pressure versus they’ve taken their time and they’ve crafted prose. Readers know this and they know it intuitively just because of the way our brains are wired.

SO: So I guess this is really interesting because the canonical example of context is always location. If you’re at this location, you get different kinds of information, or if you look up weather, if you look up weather that corresponds to your current location and there’s a tornado warning or something like that, it will give you a very different experience than if your phone knows where you are but you’re looking up a tornado warning hundreds of miles away. And it’s just like, hey, by the way, there’s a tornado warning, maybe traffic, but if it’s right on top of you, it’s going to give you a different kind of experience because the context matters. Obviously I’m concerned about the tornado no matter what, but if it’s on top of me, I’ve got an immediate, “I need to stay alive” problem as opposed to a sort of more, I guess, academic distant interest. So what does it look like to have DITA or generally what you were describing, DITA like structured content and context? How does that work?

KA: Well, there’s a couple of things that I’ve noticed with it. So context can end up being synonymous with metadata, and that works out really well because then you can have contextual cues built into the metadata for people who want to dig deeper. But when you’re writing agnostic content, so when you’re chunking and you’re putting things in structure and you’re writing agnostic content, that content usually gets assembled almost like a stack of Jenga pieces and it’s put together. And so if you repurpose my instructions, and you repurpose a concept topic like in DITA, and you put concept of procedures together, they could be written by two different authors, the style of the pros and all of that needs to be under really strict editorial control for consistency purposes. But with some of the projects that I’ve seen lately, what Microsoft is doing with Microsoft Viva, another good example is Notion. I don’t know if you’re familiar with Notion, but you notice these building blocks and you build things on top of each other and you can have different contributors all building onto the same thing.

All of that stuff taken as a whole is how readers actually take in the information. So inconsistencies in those building blocks will be evident. So one way to handle that is definitely having strict editorial guidelines and following a way to do it. But the other thing too is to have metadata and have enough content to orient the users to the whole piece of what they’re about to read. Every page is page one idea of producing content.

The other thing that I’ve noticed is that when you take agnostic content and you don’t really give it a lot of thought, sentence construction starts to fail because good writing is like you write one sentence after the other, but each one is building in anticipation of what the reader is looking for. And so you’re trying to build the anticipation and then you’re trying to reward the reader by continuing to read. Very hard to do whenever you have chunks and different people are working on chunks.

SO: Yeah, it’s interesting because I don’t think I’ve ever thought about the … We think about the emotional state of our readers, but I don’t know if we’ve connected that to the idea of context. But certainly in technical communication, the generalized assumption is that somebody who is looking something up in the docs or for that matter in the knowledge base is annoyed or frustrated or angry because they’re blocked. The only reason they’re looking in the docs is because they’re trying to do a thing and they can’t do the thing and they need help. So they are somewhere on the continuum from annoyed to having a tantrum. And it makes for a very difficult writing challenge because as you said, they’re not going to give you the benefit of the doubt. So here we are. So what does that look like? I mean, what does it look like to integrate the ideas around context into your overall content strategy?

KA: Well, what I’ve been working on, on the side is developing a universal context model that should be conjoined with standards like DocBook and standards like DITA. And the context model would help drive or maybe not drive, but guide authors as they’re writing as to what should happen next. I’ll think of a completely non-technical example, but something that everybody probably understands is with all of the police shootings and things that have happened in recent years, I don’t know if you’ve ever seen where the police reports get changed, and then they get released again, and then they’ll update them again. And a lot of this has to do with officer trauma, it has to do with different witnesses, everybody’s on an adrenaline rush when they’re trying to get the paperwork started, then people remember things later. The problem with that is that a lot of police reports are free form narratives. They’re not scripted.

So in some ways, the old school green screens, like call centers used to use with scripting, worked a lot better because it guided somebody down to where they needed to be to get something done. So having a context model that kind of underlies the content and it helps drive form fields and things like that, I think that’s critical for the content of the future because as artificial intelligence is growing and language learning models are expanding, they still need guidance and they need human interaction. And I almost think that it’s better that the machine learning happens within a more closed system as opposed to learning like what’s happening with ChatGPT, where it’s just all of the internet ever is what the chatbots are learning. And I don’t think that’s doing anybody any good. I’ve seen all kinds of horror stories about it already, and I think Microsoft just released their demos for Bing just a few weeks ago. And the horror stories are, I see one in the news just about every day.

SO: So what kind of challenges do you see lying ahead? What are you trying to achieve with connecting context into content strategy? And what does that look like? What kind of interesting challenges do you foresee coming?

KA: I think it’s a way of building trust. So let’s take journalism. So if you look at really good reporting that you see, you realize that there is institutional knowledge that larger publications, New York Times, The Washington Post, they all have that institutional knowledge, and we make assumptions based on their reputation that they have an editorial process. But because of the way politics have kind of become so divisive, a lot of the articles and things get picked apart.

A context model on the other hand, might have reporter notes, might have direct quotes from anonymous sources, and then you might have editors who sign off on it and it’s all part of the metadata that maybe you want to know more about the story that you just read, you could actually access. And I don’t think there’s anything wrong with even tying a context model to blockchain for trust purposes. This editor who works for this organization, has this many years in, and it’s almost like having a reputation server to help provide trust. So that way you’re able, as a reader, to weigh how much you trust the news source based on the metadata rather than just taking the article at face value.

SO: Well, you’ve given us a lot to think about because, and I suspect we could go on for another 20 minutes or much, much, much longer, but I think we’ll leave it there for now. Keith, thank you. This was really, really interesting.

KA: I’m glad to be here.

SO: Yeah, a whole bunch of new ideas and we’ll leave some additional resources in the show notes, including I believe Keith’s website and some other bits and bobs that should be useful to people listening to this podcast. 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 Unpacking structured content, DITA, and UX content with Keith Anderson appeared first on Scriptorium.

In episode 138 of The Content Strategy Experts Podcast, Gretyl Kinsey and Christine Cuellar talk about a common content strategy trap: what happens when information architecture (IA) is missing, and why you need IA.

“Without IA, you can’t get the most value out of your content. When we think about things like the time it takes to create your content, or getting benefits out of it like reuse, saving money on your translation costs, saving time to market on your translation, all of these things really make your content work for your organization. If you don’t have solid IA in place, it’s going to be really hard to do those things and truly get that value out of your content.”

Related links:

LinkedIn:

Transcript:

Christine Cuellar: 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 a common content strategy trap, what happens when IA is missing and how you can avoid it. Hi, I’m Christine Cuellar, and today I’m joined by Gretyl Kinsey. Hey, Gretyl!

Gretyl Kinsey: Hello everyone. How are you?

CC: Good, how are you doing?

GK: Doing well.

CC: Thanks so much for joining the podcast. So in a previous podcast, you and Bill were talking about some common content strategy pitfalls, and you briefly touched on this topic, but we wanted to unpack it a little bit more today because it seems to be something that’s commonly resurfacing. But before we dive in, I’m going to pull the newbie card. Gretyl, can you tell me a little bit more about who you are, your role here at Scriptorium and some of the experiences that you’ve had?

GK: Sure. So I have been a technical consultant at Scriptorium for actually more than a decade now. I started as an intern in 2011 and I’m still here still learning all kinds of new things with all the different projects that we do. I mostly am on the content strategy and information architecture side, so that’s why I think it’s perfect that we are talking about IA today, that’s a lot of the work I do. I’ve seen all kinds of things from really, really ideal IA projects all the way to ones that needed a lot more help and a lot more guidance, and so have a lot of wealth of experience to draw on at this point.

CC: That’s great. So can you tell us what is IA for maybe our listeners that don’t know what that is?

GK: Sure. So if you’re unfamiliar, IA stands for information architecture and it is sort of a subcategory under the overall umbrella of content strategy. And IA specifically focuses on things like your content model, metadata, reuse, linking, basically how you plan to organize and structure your content and what decisions need to go into the process of doing so.

CC: Got you. Okay. So why does IA commonly get skipped or overlooked?

GK: There are actually several reasons that we see this happening. One of the big ones is just a lack of resources. So depending on the size of your company, how much budget you have, how much time you have to dedicate to content, how much content expertise that you have on board, you may or may not have the resources that you need to actually plan and create a good IA. So that’s a big reason why it might get skipped. Another one is just not prioritizing content until it’s too late. So maybe putting the resources that you do have into other areas and really thinking about content as more of a last minute or a last resort kind of thing.

And another one is a culture of disconnect around content. So in some organizations we will see a lot of collaboration around content and that can tend to lead to maybe a better thought out IA, but then in other organizations there may be content silos where you have different departments or different groups working on different kinds of content or different pieces of content, and we can see in organizations like that a general lack of collaboration.

And sometimes even if you’re not in silos and you are more interconnected with your technology, there may still be on the people-side, a lack of collaboration. So if there is that culture of disconnect around your content, then you’re probably less likely to have a good IA or to skip it or overlook it. And then another one is mergers and acquisitions. And this is just because when one company acquires another or when multiple companies come together, that’s going to give you a mix of the IA and content processes that each group may or may not have had before and maybe no clear winner. And depending on what other things are happening in that merger, then IA might fall by the wayside if, again, it’s kind of not a big priority.

CC: That totally makes sense. Okay. And why is it a problem not to have IA?

GK: Well, without an IA, you can’t get the most value out of your content. So when we think about things like the time it takes to create your content, getting some benefits out of it, like reuse and saving money on your translation costs, saving time to market on your translation, all of these things that really make your content work for your organization, if you don’t have a solid IA in place, it’s going to be really hard to do those things and truly get that value out of your content. Another reason why it’s a problem not to have an IA is because it makes it hard to deliver content as effectively as you could otherwise. And especially if you have a really heavy customer demand for things like content delivered in digital formats rather than print only, or if you’ve got a lot of demand for highly personalized content, those are the kinds of things that really require a solid information architecture.

It’s also really difficult to convert content from one format to another. If you have a need to do that, we see this a lot with, for example, going from unstructured content to structured content such as something like Microsoft Word or unstructured FrameMaker into data XML. If you don’t have a good information architecture for what you’re converting your content into, that conversion is not going to go very successfully because there’s not going to be the kind of consistency and structure and organization in your content that you need to make that work well.

And then of course, one of the biggest issues is that without a good IA, it’s very hard to scale up your content development processes. A lot of times content production can work really well on a small scale if you haven’t done a lot of planning and a lot of organization and thought about how your content is put together. But then as soon as your business starts to grow, you realize that you have to get a lot more content out the door a lot more quickly and maybe have it personalized for different segments of your customer base. Maybe you’re starting to translate for the first time and you’re just have this need to scale up. If you don’t have a solid IA in place, that scalability is also going to be really painful, if not, impossible to achieve.

CC: Yeah, that makes sense. I feel like growth is always such a good indicator of gaps and processes and it’s such a good time to take a look at things and see where you can change. So scalability is always something I feel like we come back to on our podcast and our blog post. So what are some of the examples from your work where these issues have come up?

GK: There are actually all kinds of challenges that we have faced here at Scriptorium with IA. So one of them kind of touches on what I mentioned in the last question, which is we were talking about taking your content from unstructured to structured. We see a lot of clients who are looking to do digital transformation, and so that’s going from more of a print-oriented life cycle to a digital-oriented life cycle for more flexible delivery. And a lot of times that does involve a move from unstructured content into structured content. And so, of course that does mean a major change is required in your IA. So that is not an easy one-to-one match if you are working in something like Microsoft Word, something desktop-oriented to start, and then you are going from print only to print and digital, some kind of a hybrid and maybe involving some personalized delivery in there. You’re not going to have a one-to-one match of what you had before in your Microsoft Word, your unstructured frame, your InDesign to what you have now that is going to put that digital delivery on the table.

So that’s a really big IA challenge to think about what is our implied structure in the content that we have right now that is more desktop publishing oriented, and then what does the structure need to be for something that’s going to allow us to have a more digital-oriented life cycle. So that’s always really difficult. It’s a long and oftentimes painful process, but it’s a necessary one. And it’s where I think for us, as consultants, we can really come in and help if an organization is struggling with that. Another challenge that we faced is helping content creators deal with the learning curve that comes with a new IA. And just like I mentioned on that last point about digital transformation projects, that’s where we tend to see a lot of us happen the most is that you’ve got a lot of people who are very experienced writers and experienced at that aspect of content creation, but they don’t have the experience of working with a more digital focused content life cycle and the IA required to support that.

So for example, if they’re going into something like data XML that would support a new digital life cycle, then they’re going to require a lot of knowledge transfer, a lot of training, and a lot of support all throughout that process because that learning curve is pretty steep. Another challenge that we see a lot is conflicting ideas around how the IA should be designed and built. And this is true whether you have one IA that you’re already working with and you’re looking to improve it or whether you’ve never thought about it before and you are just now realizing that you need to solidify an IA for your content. So there can be differences of opinion with different groups who are working on content. Like I mentioned earlier, if you’ve got those content silos and people who don’t work collaboratively, then they might have really, really different ideas of how the IA should be done going forward.

You can also have an issue where if an organization isn’t really getting adequate feedback from their customer base, then they don’t have that in mind how that should feed into decisions around how the IA should be built. And all of this is really where it can help a lot to get some outside perspective from a consultant. So when we come in and we see these conflicting ideas happening, we’re able to give them that perspective and say, “Here’s what we’ve seen at a lot of other organizations that might help you to learn from that experience. Here’s what we typically see as industry best practice.” And that can help resolve those conflicts and guide them through to getting an IA that’s actually going to serve their organization best.

CC: That’s great. It’s just like a tiebreaker, a third party to come in and be able to be that unbiased voice to give support for what’s going to be best.

GK: Sure, absolutely. And then another challenge that we faced is trying to work around aggressive or sometimes even unrealistic implementation schedules. And this happens a lot because the schedules are often set by non-content creators. It might be people and upper management people at the sea level who aren’t really in the weeds and don’t fully understand all the ins and outs of what’s required to create content, convert it from one format or structure to another, develop an IA that’s going to work for you going forward. And so, if there’s that tension with the schedule saying, “We have to meet this deadline because that’s going to affect our scalability, our other goals,” that can sometimes result in a project being pushed forward without adequate time to plan for your IA.

And then what that eventually causes is some messy situations where because you did not put an IA in place properly or didn’t think about all of the different things your IA might need, then you try to produce content and it’s not going to serve you in the way that you thought it would. So even though a schedule might be really aggressive, even though you might have deadlines, it’s still important to prioritize the IA and not let that be something that falls by the wayside in favor of meeting a deadline.

CC: Got you. So I’m curious to know a little bit more about pilot projects or proof of concepts. I know it was mentioned in a previous podcast and we’ve talked about it a little bit in some other places. Can you unpack what those are and how they may be able to help your developing a new IA?

GK: Absolutely. So pilot projects and proofs of concept are a really good way to mitigate risk when you are developing a new IA or changing an existing one or really doing any kind of change to your content processes. So specifically when we’re talking about IA, you could use a pilot project to try out a new IA that you are planning and thinking about on a small subset of your content and that can let you see what works and what doesn’t in real-time, give you that practical example, and that way you can make adjustments to the plan for your IA before you roll it out across your entire body of content. And then if you’re still trying to convince management that a new IA is a good idea, you’re trying to get the budget required to roll that out across the organization, then having a successful pilot project can actually help you do that. It can really convince people, “Here’s the return on investment that we’re going to get if we put this IA in place and here’s the proof that it’s going to work.”

CC: That’s great. Yeah, that’s really helpful.

GK: I also wanted to note that IA development does require a lot of flexibility. You are almost guaranteed to have to go through multiple iterations, you’re never going to get it perfect on the first try. And that’s why we do recommend a pilot project or a proof of concept because it lets you start small and it allows you to build in the room for that flexibility all throughout your project rather than being under that deadline pressure that I talked about. If you have that pressure to get it right and you know that that’s not going to work, then you’re setting yourself up to fail. So putting a pilot project in place, doing a proof of concept really just helps get rid of a lot of that risk.

CC: Yeah, absolutely. I’m sure it puts everyone’s minds at ease. So I’m curious if someone wanted to start a proof of concept or organization wanted to invest in these first, how do they do that?

GK: That’s always really interesting. It kind of varies from one organization to another, but where we see it often originate is there will be maybe a writer or a manager of a group of writers, one person who really sees an opportunity and isn’t at the level where they have the pull at the organization, where they have the budget, have the resources, but they do have the knowledge for, “Here’s an idea that might work.” And so, a lot of times these proofs of concept just originate from the ground up from people who are actually working on the content, and that’s what allows them to grow their IA and their overall content strategy for the larger organization.

CC: Got you. Yeah. So they’re the ones that are really recognizing the need, probably the ones also hitting the pain points, unfortunately, to say something needs to change. So that’s interesting. Circling back to your response earlier on that actually, when you mentioned that sometimes content isn’t a priority until it’s too late. Could you kind of unpack what could be included in too late? Either signs that it has been too late and we need to focus on content or some pain points that might be coming up to help you avoid getting stuck in too late.

GK: Sure. So one of the red flags that we see a lot that says, “Either it’s too late, you should have started planning an IA earlier or now is the time to start,” is that if you have a lot of inconsistencies in your content getting in the way of being able to take advantage of all it can do for you, that’s definitely a sign that you need a lot better IA planning. So if you are trying to do reuse for example, and you’re unable to do so because of how your content is structured, if you realize that you need to start translating into other languages, or maybe you already are, but you need to translate into a lot more languages and that’s costing you a lot of money because you can’t do reuse, if you are running into issues with publishing, so if you’ve got people requesting custom content or personalized content and you just are not set up to deliver that, all of those things because your content is written inconsistently, it’s structured inconsistently, that’s definitely a sign that you need an IA.

Another one is the inability to search your content or filter your content due to a lack of sufficient metadata. So metadata is a really important piece of your overall IA puzzle. And a lot of organizations don’t really think about how it’s going to be used both internally by content creators and externally by your audience, by your customer base. And so, if you haven’t thought about all the ways that people might need to search the content and find information they need, that they might need to filter the content down to delivering specific pieces to specific people or even filtering your search results, all these different ways that you can find the right information within your set of content, a lot of that is driven by having the right metadata in place.

So if you find that people are unable to do that, then that’s another one of those signs or pain points that says, “Okay, we need to rethink our IA and make sure that metadata is a big part of that and that we have considered that.” And then just like we’ve talked about several times throughout this discussion, challenges the scaling. So if you have issues with meeting your goals for growth and scaling your content up to meet that demand, then that tells you, “Hey, let’s go back to the ground up and think about our IA that we should have had in place all along. And then that will allow us to do what we need to do to scale up our content development processes.

CC: Yeah. So if any of those pain points sound uncomfortably familiar, that is definitely something that we can help with here at Scriptorium. So we’ll have a link in our show notes where you can contact us to get a conversation started. Gretyl, is there anything else you can think of that you want to share with our listeners about IA or anything else we’ve talked about today?

GK: I think the biggest thing is just don’t overlook it and don’t leave it out.

CC: Yeah, absolutely. Well, thank you so much. I really appreciate you being part of the podcast.

GK: Absolutely. Thank you.

CC: Yeah. 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 Why information architecture matters (podcast) appeared first on Scriptorium.

In episode 137 of The Content Strategy Experts Podcast, Sarah O’Keefe and guest Larry Swanson talk about the fragmentation of content over the past 30 years, from the delivery of books to UX writing.

“What are the changes that this fragmentation has introduced from a business or an economic point of view? One is the notion that we’re all publishers now. This is where the whole field of content marketing comes from — this notion that it’s a better way to promote yourself if you demonstrate expertise around what you’re doing.”

Related links:

LinkedIn:

Transcript:

Sarah O’Keefe: Welcome to the Content Strategy Experts podcast, brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way.

In this episode, we talk about the fragmentation of content over the past 30 years, from delivery of books to UX writing, where you publish content inside software. Our guest today is Larry Swanson, an independent content designer and content architect who also has his own podcast called Content Strategy Insights. Hi, everyone. I’m Sarah O’Keefe, and, Larry, hello!

Larry Swanson: It’s great to be here, Sarah. I love your podcast and I’m delighted to finally be on it.

SK: Well, likewise. So we’re going to have, I think, dueling podcasts and it’ll be fun. Tell us a little bit about what you do. Tell us a little bit about who you are and where you’re coming from and what your life looks like in business.

LS: Yeah, it’s inevitable that I ended up where I am. I’m a word nerd from birth. My mom was an editor. I’m also… My dad was an engineer, so I’ve had this weird combination of technical and grammatical stuff throughout my life. And yeah, so I went to journalism school, which seemed like a good idea at the time. I immediately abandoned journalism for book publishing when I got out of college. I went to a course called the Radcliffe Publishing Procedures Course. Because of that, I think just that journey, the way I got into journalism school was interesting, the fact that I went right into book publishing out of there. I’ve always been more interested in the process of how this happens than about the writing itself. I’ve done some writing and can communicate well, but I’ve never been a writer. I’ve always been the publisher, the editor, the marketing guy, the meta-practitioner.

SK: Yeah, which is interesting because I think that that’s quite similar to how we describe ourselves here, that if you’re looking for domain knowledge, that’s something that you should have inside the organization. We’re the people that come in from the outside looking at your publishing systems and what that looks like.

So you and I were talking a couple of weeks ago, which is actually where this podcast topic came from, because we were looking at this question or this idea that many of us actually came from traditional book publishing, and now we’re doing things like publishing software strings inside software, doing UX writing or UX design, but we came from this traditional book world. And that got us started on the concept of fragmentation and what that means and what the implications are. I wanted to start with content challenges. What kinds of content challenges do you see in this long term, I guess, but 30 years is really the blink of an eye, but in this transition from a book-based publishing world to UX design, UX writing content embedded in software?

LS: Yeah. Well, it’s funny. The first thing I reflected on when we talked about this is what’s the same. And I’m surrounded by awesome word nerds and good collaborators, so that’s been the same throughout. But it manifests entirely differently now. Whereas we used to have these long, convoluted, literally years-long processes to develop a manuscript, put it into that sausage factory of everything from developmental editing to the composition, and then all the distribution and the physical manufacturing of the books and all that, a quick turnaround would be nine months. Sometimes if you got a really hot topic, you could turn it around that quickly. Now we’re dealing in milliseconds for some of this stuff. I think of that Oreo commercial during the Super Bowl. Remember when the lights went out? And they created a whole advertising campaign in 10 minutes about “you can dunk in the dark.”

So we’ve kind of gone from years to seconds and the whole cycle. Around the time, the start of this transformation, for me, a guy named Nader Darehshori. He was at the time the CEO of the publisher Houghton Mifflin. He said that publishing is just the business of the discovery, development, and dissemination of ideas. There’s a lot going on in there, and it used to take a long time for it to happen, but that ad that Oreos did during the Super Bowl, that whole thing happened in literally 10 minutes or something like that. So that compression of time has led to, I think, the need to be super hyper-attentive to the procedures, how you do stuff, and the stuff you have in place to facilitate that sharing of ideas more quickly.

I think one of the very first books we read is, when I went to a publishing course right after college and read this book called One Book/Five Ways, where they took the same manuscript and gave it to five different university presses and got five different treatments of that. So I’ve always been really conscious of… and there were sort of best practices exemplified in that, but everybody did it their own way, and that’s another thing that’s only magnified. There used to be something much more like best practices. Now it’s like everything is bespoke. And yet, you have to have a way to do it so that you can be bespoke. And that’s where we’ve gone from these long tunnels of production and distribution stuff to these more fragmented, increasingly decoupled modular architectures that permit taking content, mostly words in text form, but also recordings of various kinds and even 3D stuff in the metaverse, and being able to do stuff with them more quickly.

That’s been the biggest change, is it’s still people sharing ideas with other people in a media format. I think a person from Mars who could magically look in at us and just look at… They would think, oh, it’s just the same thing. And it’s like, yeah, it kind of is, but there’s a lot more going on now to make it all happen.

SK: So I understand the concept that a lot of the increase in velocity is that we got rid of physical distribution. We don’t have this process of printing books and binding books and shipping them to bookstores, which does take a significant amount of time. But backing up from there, you mentioned developmental editing, and where are the developmental editors in our fragmented content chain? Is that concept just gone?

LS: No, I think it’s still here, but it manifests differently. I think think that happens in the craft. Content strategy is a discipline. You might call it fragmenting, but I call it… I think I’d equally call it specializing. I’m still a generalist and I’m kind of weird that way, but for the most part, the content practitioners now, they’re either a content creator or a strategist or a designer or an engineer or a content operations person, people managing it, and there’s many other specializations that are happening. I think that’s part of how it’s happening, is that it’s the craft that permits the acceleration, that things are developed differently, and we’ve figured out… We are still figuring out, I should say, because the articulation of the field of content design is really only… I mean, people have been doing it a long time, but people have only been calling it that for 3, 4, 5 years, something like that. But look at how quickly it’s taken off. And Kristina Halvorson is shutting down Confab to focus on content design at Button.

So it’s a very fast-evolving thing, but it’s the collection of crafts that develop the ideas now rather than this kind of sausage factory, linear progression of things. Does that make sense?

SK: I think so. So looking at… You’ve mentioned the sausage factory a couple of times, which is, I think, an apt metaphor, unfortunately. What does this look like from a tech point of view? What are the changes in the processes, systems, and I guess especially software that we use to produce content?

LS: Yeah. I think what’s funny is what… I remember being exposed to SGML, the predecessor to HTML 30 years ago. I knew that there were ways that you could deal with words separately from their presentation. But I think that’s been the main thing, is the disarticulation of the content, the meaning, the words, the pictures, the images, all that stuff that make up the content, their disarticulation from the physical… We used to have these physical artifacts where we shared the information, and now it’s all digital. And within that sharing, the tech that makes it happen, it’s instrumental to the whole thing. Where it used to be tech was the facilitator that created the object, now the tech is the object. It’s like an interface at the end of a thing rather than a physical artifact.

And it’s more of a people challenge, I think. It’s not hard to get into all that technical stuff and figure out, oh, I can make these words appear here with this technology. Piece of cake. Getting people to abandon WYSIWYG mentalities around graphical user interfaces and author content in new ways for more abstracted out and then reassembled experiences, I think it’s… The technology has kind of made it, to my mind, a logical evolution, and it’s like, oh, cool, we can do all this. We can make our little Lego kits however we want and put them together however we want. But I think there’s still this legacy thinking that a lot of us have that I still struggle with every day of that linear process that creates physical artifacts that we still have.

People still talk about creating web pages. It’s like, really? Is that what you’re doing? I don’t think so. I mean, maybe it manifests as a page in that one moment, but the elements on that page are increasingly customized or maybe even personalized for a unique experience. They’re responsive to the device that they’re on and the screen resolution and the accessibility needs of the end user. There’s all these different things that go into that are technically easy enough to implement, but helping everybody along the way understand this different way of doing stuff. On my podcast, it almost always comes back to, you know, this is mostly about people, and I think the technology stuff, yeah, it’s mostly about people.

SK: Yeah. Well, and it’s interesting. I mean, as you’re talking about WYSIWYG and people acting as though WYSIWYG is their birthright, which has been around forever, it hasn’t. I mean, you don’t have to go very far back in book publishing to find that people would on a typewriter type a manuscript, which bore no actually resemblance to the final book. It was a typed manuscript with no formatting, I mean, paragraphs and maybe some chapter headings, but it had to be actually composed into a book, and woe be unto you if you had figures and tables. Those were nearly always included in an appendix at the end of your manuscript, right? Here’s Figure 1 inserted on typed page 75. So this concept of WYSIWYG and putting it all together and getting a visual preview for the author is relatively, I mean, relatively new. We’re talking about, what, 1987 or thereabouts.

LS: Yeah. When was it? PageMaker and then Quark, and I think that’s where that came from.

SK: PageMaker was… Yeah, roughly. I think the first time I saw it was about 1988, so somewhere in the ’80s. Yeah.

LS: Yeah, that’s right. You know, it’s funny the way you said that, like it’s our birthright to be able to see what we’re doing. It’s like, nah, it’s just a little blip in publishing history.

SK: Right, and, well, of course if we go far enough back, then we will discover that people used to actually compose their pages as they went, and they were totally WYSIWYG because…

LS: Right. No, and as we were talking about before we went on the air, like Gutenberg, the implications of that were more about replicability, and the scribes before him knew what they… You saw exactly what you were publishing. 

SK: What you see is what you get.

LS: Exactly.

SK: No podcast of ours is complete without a mention of Gutenberg, so we’ll check that one off the list.

So the tech, it swings back and forth, and sometimes you’re WYSIWYG and sometimes you’re a cog in the machine. And people seem to prefer largely not being a cog, right? They like to exert that at least perceived control over what they’re doing. So then turning our attention to the business of publishing and the business of content, what do you see there? I mean, what are the changes that this fragmentation has introduced from a business or an economic point of view?

LS: At least two big things. One is that notion that we’re all publishers now, that this is where the whole field of content marketing comes from, that this notion that it’s a better way to promote yourself if you demonstrate expertise around what you’re doing. We both do that with our podcasts. This is why people know we’re so awesome at our content practices. It’s because we have podcasts. And there’s a million other ways that you can do publishing-y kinds of things. But the business intent of those, rather than selling podcast episodes for money, we’re using it as marketing.

There’s that, that notion that everyone is now a publisher, but there’s also the notion that the business of publishing itself has changed. There’s both the fact that we’re all now publishers, just made that whole world a lot bigger, but there’s still publishing happening within there. You think about media like Netflix and the New York Times and game publishers, everything from consoles to the new 3D stuff. So publishing is still happening, but there are a lot of other business things that happen with the same technology, which I don’t think that was true. I mean, it was kind of true with old-style publishing. You would use the printing press to create an internal newsletter or something like that.

But it was not as ubiquitous as it is now, because everybody has access to this stuff. No matter what line of business you’re in, you’re using those technologies to do slightly different stuff, which I think is where the whole field… That’s one way to contextualize the rise of user experience design, because you’re serving like, okay, I just need to sell some stuff. I’m a merchant, and so I have this e-commerce world of stuff that I can do with these ostensibly publishing technologies, because they’re about just sharing information. But you’re sharing information in service to getting somebody to place an order. Or if you’re a marketer, you’re sharing information in service of getting a lead. Or if you’re a publisher, you’re sharing information to get paid for that thing you just published, whether it’s an advertisement or a subscription. And if you’re…

So that kind of publishers, merchants, marketers have always been, to my mind, the three main buckets in the business world of digital business. And their websites all kind of look similar now, but there’s different business prerogatives that underlie them that lead the whole… I’m working at a big travel company right now, and this business logic that underlies that whole thing, it just looks like any other website, just lists stuff about the travel products. That’s way different than a big affiliate site that was just selling links back to Expedia. A big travel company like Expedia is doing all that business stuff. The travel agents and airlines and hotel chains used to do it. So I think it’s broken down a lot of barriers that make new kinds of businesses possible.

So I think that’s the biggest level of it, and they’re all using the same technology. They all have to abide by those same practices around, if you want to be found, you better have a responsive website so you better abide by responsive web design principles and be using CDMs and all… whatever the latest technology thing is to improve the end… and it’s always about user experience. The reason that’s important is because users don’t have the patience to wait for a slow-loading webpage. I can’t articulate it as well as we hoped I might when we talked about this interview, but there’s something going on there where it’s much more about the end user and meeting their needs. So I think you can trace back almost all these developments to the need to improve that, the places that are doing it well, anyway, to help people find the right information at the right time.

Google does that pretty well, help people get the movie that they really want to chill to that night. Netflix does that really well. And it’s all about satisfying user needs. And that, to me, is this technology that we first saw as a way to accelerate and increase the velocity of publishing activities, it’s like, oh, I can sell stuff with that too. Oh, I can deliver media that’s customized to a person’s interest. Yeah, that would’ve been nice to have Blockbuster could have sent somebody to your house and interviewed you about what video you want to watch, but that’s not very scalable. So anyhow, so that notion that it is all technological that permits the scalability, that’s the foundation of most of these business models, is that ability to take a good practice and just, boom, do it for millions of people at once.

SK: Yeah, I think scalability is a really, really good point. And velocity, velocity of publishing is sort of related to that. They’re not exactly the same thing, but can you scale up and produce more and more and more content and can you do it fast or instantaneously by… because our old distribution, put it on a truck and send it to a bookstore, has been replaced by push this button.

LS: That’s right.

SK: And sometimes not even that.

LS: There’s something in there about… I think one of the other really important things that we just don’t think about consciously enough but we’re all doing all the time is automation, that we’re automating tasks that used to take… I think that’s really coming to the fore now with the generated AI stuff, ChatGPT and those kinds of things, that, like, oh, I don’t have to outline this. I’ll just have ChatGPT do this for me. That kind of task automation underlies a lot of this. I can’t articulate exactly how that’s going on, but I think that’s an important part of it as well.

SK: Well, and I guess with a call-out to AI is up next and we’re not really sure what that’s going to do for us, that seems like an excellent place to close this. So Larry, thank you so much for coming in and sharing your thoughts and giving people something to think about and be scared of.

LS: I hope I didn’t scare anyone. And thanks so much, Sarah. I really enjoyed the opportunity to chat with you, and I hope that rambling stuff made some sense.

SK: Well, I think so. We’ll see what our audience thinks. So thank you, Larry, and thanks to 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 fragmentation with special guest Larry Swanson (podcast) appeared first on Scriptorium.

In episode 136 of The Content Strategy Experts Podcast, Alan Pringle unveils horror stories of content ops gone horribly wrong.

Related links: 

LinkedIn:

Transcript:

Christine Cuellar: 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 share some content operations horror stories. Today I have our COO, Alan Pringle, with me. Hey, Alan. How’s it going?

Alan Pringle: Hey there, I’m doing well.

CC: Are you ready to talk about some horror stories?

AP: The question is, are you and is our audience ready for this? Because I’m not sure that they are.

CC: Well, I hope we all like horror because we’re diving deep into some stories. So, Alan, why don’t you kick us off?

AP: Well, I do appreciate the horror genre, I have for a very long time, and I’ve noticed that my favorites tend to have very short titles. Like last year there was Barbarian, which I really liked. Then there was the 1978 movie Halloween, the original. I’m not talking about the newer ones. I don’t like those as much. And then the Evil Dead and the Conjuring, they’ve got these short, snappy titles. So I thought we could kind of play with that whole idea and label some of the things that I have seen along with the other Scriptorium folks over the years.

CC: Absolutely, love that idea.

AP: So let’s talk about the first horror story. So everybody, let’s gather around our digital campfire and we can exchange scary tales.

CC: Grab our marshmallows.

AP: Yes, that. Yes. Let’s call the first one, The Update.

CC: Dun, dun, duh.

AP: Exactly.

CC: Always chaos and carnage with an update.

AP: In this case, it was ugly and gory indeed. We had a client who was changing their name, changing their branding. They had hundreds of desktop publishing files, and unfortunately, these files were not templatized, which means to do an update to change the company tagline, to change the company logo. They were going to have to go through and touch every single one of these files. Yeah.

CC: Talk about horror.

AP: Absolutely awful. The good thing is there is a happy ending here that is not all blood and guts. Because there was so much of this content involved, it made more business sense to convert all of these desktop publishing files to structured content. And by doing that, we set up an automated publishing workflow. So instead of going through and touching all of these files, we did the conversion and then we set up transformations of that structured content into, for example, PDF files, and the automated publishing process automatically put in the new logo, put in the new tagline.

So people didn’t manually have to do it. We ran that structured content through this transformation process, and voilà, we had the PDF files that had everything in it, and people didn’t have to physically touch them. So instead of making a huge one-off investment in all this manual work, the company did something really smart and invested in better content ops. So since then, if they have had to update their logo or their tagline, all they would have to do is go in and touch their transformation process, fix that there, and just rerun everything and then the process will handle it for them.

CC: So much better.

AP: Yeah, it’s magical.

CC: Yeah, so much better. I love that it’s not only easier for the team, but it’s also better quality. It’s easier to produce better systems rather than leaving things open to mistakes. I just love that about content ops.

AP: No. No, you’re exactly right. This created a repeatable automated process, and those are two huge wins. So that has a happy ending.

CC: Unlike most horror movies, there is a happy ending here.

AP: Well, you got to have the sequels.

CC: Yes, that’s true. That’s true. The 500 sequels.

AP: Exactly.

CC: All of which pale in comparison to the original, but yes, correct.

AP: Usually. Correct. You’re a hundred percent correct. Let’s go with the next story, which I call Cut and Paste, and this is not limited to just one client, and I am sure our listeners have been through this very thing before where you have one piece of content that pops up in multiple places in your documents. Unfortunately, that content has been cut and pasted manually a zillion times, so you have a bunch of different versions of that and a bunch of different files. And this is where your sequel comes in. Somebody will go in there and slightly change one of those, which is supposed to be the same wording, change a word or two in there, and now you have the sequel, Cut and Paste: The Mutation. That is never, never good, and it just compounds headache after headache. And then for part three, which probably should be in 3D, a three-dimensional movie.

CC: Yeah.

AP: It would be… yeah, Cut and Paste Three, Localization. Yeah, that’ll have ‘em running out of the theaters, because every time that you translate something like this and you’ve got all this copy and paste in your source content, and then you translate it, what are you doing? You are basically replicating the same horror that you had in how many different languages? It’s incredibly inefficient, it’s incredibly expensive, and it’s a headache for everybody involved.

CC: Yeah.

AP: This is why you need better content operations, and you basically need to figure out reuse scenarios. You don’t necessarily have to do XML or structured or authoring or use X tool or Y tool to do this. A lot of tools have the ability to set up mechanisms for reuse. Even Microsoft Word at a low level has some of these features. So what you need to do, you need to templatize this content. You need to set it up so you are referencing things that are going to be repeated often. So when you do have to make an update to that, you change it one time and it just automatically fixes itself across your body of content. That is the ideal thing you need to do, especially before you start localizing your content into other languages.

CC: Absolutely. Yeah. And that’s something we do touch on more in our blog posts that we published about how Scriptorium optimizes your content. We’ll go ahead and link that in the show notes as well, so you can check that out.

AP: Yeah, no, and that’s a very good point. Localization is often one of the drivers that has people talking to us and realizing our content operations, they’re broken. So yes, localization is one of these things that can really make or break you when it comes to your content.

CC: And from my understanding, a lot of times companies are reaching out because they’re missing out on a localization opportunity, is that correct? That’s the pain point that they’re experiencing is they’re missing out on something they either are being told they need to do or something they want to do, but there’s no way that they can go ahead and meet those requirements or step into that new opportunity with their current operations process.

AP: No, it’s true. In some cases, there are regulations that say you will provide this content in the languages where you’re shipping this content, to locale specific content. So are you going to end up having your products sitting on a dock somewhere while you scramble to get these documents in place? Which sounds absolutely bonkers. It has happened. Same thing for services too. I mean, in this global international environment, if people don’t have that content in their language, they’re not going to use your product. And that goes for the interface. Is it in their language? Is the content that explains how to use it in their language? So yeah, you can lose out on an income stream because you are not ready to localize and to do it efficiently.

CC: Absolutely. All right, now onto our next horror movie. It’s The Spreadsheet From Heck. And I’m very curious about this one because this one really messes with me.

AP: Yeah. The more R-rated version is spreadsheet from (beep). I know I will be bleeped for that, but that’s more accurate. So yeah, Christine’s going to have to get out her buzzer and bleep me on that.

CC: I will, yeah.

AP: Spreadsheet From Heck. First of all, if I saw a trailer for a movie that had the word spreadsheet come up when I was in the theater, I’d just get up and leave. Yeah., Because I get enough of that during the workday. I do not need to see it when I’m trying to have fun, thank you very much.

CC: Trying to escape reality here by going to the movie

AP: Exactly. I don’t need it reinforced in my face for an hour and a half. But someone has made the observation, it was not me, and I want to be very clear it was not me, someone has made the observation that the most common content management system is probably an Excel file.

CC: That’s horrible.

AP: It is horrible, but there is a degree of truth to this. There’s a kernel of truth there. A lot of people will plan out their workflows. “Here are all our files. This is the schedule. Here’s when it needs to be reviewed. Here is when it needs to be approved,” all that stuff. There is some degree of automation, yes, that you can do in a spreadsheet, but that only goes so far. And there’s some really critical things that you need to keep track of when you’re trying to manage just gobs and gobs of content.

I cannot imagine trying to do all of that in a spreadsheet, yet some people valiantly try, and they may be successful for a while, but I am nearly certain there has got to be a tipping point where you cannot do this anymore. And that’s true of almost everything we’re talking about in this episode. These things can work one off, or if you’ve got a very small body of content, the minute your requirements change and require you to do more, the stuff doesn’t scale. And this is a perfect example of where scale is going to inflict a great deal of harm on you. Maintaining that sort of stuff in a spreadsheet, that is a no-go from my point of view.

CC: No, I can’t even imagine from a content marketing perspective because I know I just specialize in content marketing and I’m not producing content on the scale that a lot of our clients and even our staff are producing content. I can’t imagine organizing all of that in a spreadsheet and having tasks remind me of when to follow up, when to do what, when to update what, all that kind of stuff. I truly can’t imagine managing that. I think it would just…. It would be a horror movie.

AP: Exactly. Like I said, it’s not ideal, but it happens more than it probably should.

CC: Speaking of something that happens more than it probably should, let’s move on to the next movie, The Email Chain.

AP: And people are going to think this may be some throwback to some lower tech era, and the sad truth is yes, today in the 21st century, there are still people, still companies who do content reviews by sending either PDF files or bits and pieces of information in an email. And they go back and forth making changes and getting approval. That to me, I mean, please just set me on fire. It’s deeply, deeply inefficient, yet it still happens today. And I’m sure there’s some people out there saying, “Surely not.” Surely yes, it does still happen, believe it or not. Very painful.

CC: Yeah, less efficient and more overwhelming, like you said. So things are going to get lost. Little updates, revisions, that kind of thing, that’s definitely going to get lost. So it’s more work to produce a lower quality piece of content versus moving it over to a streamlined content operations system.

AP: Yeah. And we think the spreadsheet is bad, I think the email chain may be more horrific than spreadsheet from whatever word you want to say there.

CC: Yeah.

AP: Those both point to using technology that’s really not the right fit, but it’s ubiquitous, you’ve got it handy, so you’re going to rely on it. Not the best business decision. I can understand why you would do it, but in the bigger picture, it’s not where you should be going.

CC: And speaking of the bigger picture, one thing that stood out to me when we were… on our previous podcast with Sarah is companies often reach out to us when they’re hitting some pretty significant pain points and when they’ve definitely recognized that it’s time, something’s got to change, we’ve got to become more scalable. But you don’t have to wait until then to optimize your content operations. I mean, I would recommend doing it now before you hit those pain points. Don’t wait until you’re missing an opportunity. Don’t wait until things are… you’re stuck in a never ending horror movie and you can’t get out. Now’s the time.

AP: Yeah. Yeah. Basically nip it in the bud. And what’s popped into my head is the movie, and there have been multiple versions of this, Invasion of the Body Snatchers. In our case, I think we might want to call it Invasion of the Time Snatchers, because if you let this stuff compound, compound and compound, all that’s going to do is just basically completely drain your organization of any resources to even try and make incremental improvements in how you create your content.

As you improve how you create your content, it is going to make it easier for you to create better content. The content itself will improve, but if you’re stuck in this mire where all of these inefficient processes are eating up all of your time and they are not something that you can repeat, they are not scalable, it’s like the Groundhog Day of horror. It just repeats and it loops back on itself over and over again. And that is a sad reality for a lot of people. But as you suggested, the minute you start having an inkling that’s happening, that’s when it’s time to realize it’s time to take action. Let’s fix this.

CC: Yeah. And anybody that produces content has content operations. So there’s always the opportunity to optimize. There’s always the opportunity to see where you can automate and make things better.

AP: And it can be baby steps. Absolutely. And I think that’s a very good point to make. All these things that we have mentioned that are not super efficient or sound even remotely fun, they are all content ops. They’re just really bad content operations. So it’s not a matter of, “I don’t have ops, I need them.” It’s a matter of improving, and these things can be taken in baby steps. You can be incremental. For example, even trying to templatize things to give you some degree of consistency, that is a small step you can take if you’re working in word processing or desktop publishing. Templatize things so you have a very standard way that you create content, the formatting is standardized. Because if the content creators don’t have to spend time fiddling with that stuff, that is time they can invest in writing better content to help the people who are reading it.

CC: I like that mindset shift that you brought up: When you have bad content ops or things aren’t working well, those problems compound on each other. But in the same way, when you have good content ops, the benefits of that compound on each other. So you have more time to be able to make content better, and to even revisit your processes and revisit them over and over to see, “Now that we’ve optimized, how can we get to the next level? How can we get to the next level?”

AP: Absolutely. There is always room for improvement, and it’s a good idea not to rest on your laurels and do a check every once in a while, because you never know what creature might be hiding in your closet.

CC: Yeah. Might be Jason.

AP: Michael Myers, Freddy Krueger, the Babadook, you name it. Yeah.

CC: Not that this is about content and ops, but the sequels in Halloween cracked me up, how they continuously repeated, “Evil dies tonight.” And evil never did die tonight, so.

AP: No, it didn’t, and I wish that it had. This could be a whole other podcast. Those later reboots did not please me, but we’ll talk about that some other time amongst ourselves.

CC: Yeah. Good idea. Well thank you all for listening to the Content Strategy Experts podcast, brought to you by Scriptorium. For more information, visit scriptorium.com or check out the show notes for the links we talked about today. And thanks, Alan.

AP: Thank you.

The post Nightmare on ContentOps Street (podcast) appeared first on Scriptorium.

In episode 135 of The Content Strategy Experts Podcast, Sarah O’Keefe and new team member, Christine Cuellar, talk about who Scriptorium is and how we use content to optimize your business. 

Related links:

LinkedIn:

Transcript:

Sarah O’Keefe: Welcome to the Content Strategy Experts podcast, brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way. In this episode, we’re talking about who we are and how we use content to optimize your business. And I’m joined by our newest team member, Christine Cuellar. Hi everyone. I’m Sarah O’Keefe. Our host today is Christine, who has just started as our new Marketing Coordinator. So of course we put her to work right away. Welcome to the team Christine, and guess what? You’re in charge of this podcast.

Christine Cuellar: Sounds good. Hello everyone. I’m excited to be here. Since I’m new, I’m going to be asking all the newbie questions. So I thought this would also be an interesting podcast for our new podcast listeners. Sarah, I’ll go ahead and kick it off with a basic intro question. What started Scriptorium?

SO: Well, canonical answer is I was annoyed by a layoff. So a million years ago, I worked for a software company that did the canonical hockey stick growth from zero to 60, from 80 people when I started to 500 people 18 months later. And then that company with about four others got acquired by a larger company. And in the process of sorting out all those companies that the mothership parent company had acquired, in the process of that assimilation, many of us got laid off and we were all a little cranky about it. And I decided that if executives were going to make dumb decisions, I could be the executive making dumb decisions. And so basically I was angry, and here we are 26 years later.

CC: That sounds great. And you have an article that goes more in depth on that story as well. We’ll go ahead and link that article in the show notes. So what does Scriptorium do?

SO: That is…

CC: A big question.

SO: I know you think I’d have it figured out by now. But we are interested in content and technology and publishing, and specifically we’re interested in product and technical content. How do we take that information that is so often overlooked and under-invested in and manage it, produce it, do things with it in such a way that we can maximize its value for our customers? So we are interested in taking interesting technology and applying it to content so that we can perhaps automate content development or automate content delivery or improve the publishing process or do multi-channel kinds of things. All those buzzwords that you hear these days we’re interested in how do we make the most out of the investment that you have to make in technical content.

CC: And what’s the scope of our work?

SO: We start typically with an assessment or an analysis or a where are you now? What’s working? What isn’t working? Where are the pain points? And then work our way from that to what are your business needs? What are you trying to achieve? Do you have problems with people calling tech support with basic questions that are or should be in the documentation, but instead they’re making an expensive phone call? Do you have problems with translation, localization with people who would prefer your content in their local language, but you haven’t made that investment because it’s so expensive to translate or localize. So part A is what are your business needs, what are the problems you’ve identified? And part B is how do we develop a solution that leverages your content to fix that? And then I guess part C is we actually build the solution.

CC: Wow.

SO: So some really, really common things here are people saying all our stuff is in Word and it’s not working. We can’t scale it, we have a problem. Some huge percentage of our work is actually structured content. So that’s definitely a point of emphasis right now. That’s not where we started because 25, 6, 7 years ago, structured content had less market share than it does today. But that’s a common thing that we hear is that people have identified that structured content will address some of their requirements, and they need us to help them get there from whatever system they’re in right now. And then I think a key point is that we do not have software. We are a pure services company. And in addition to not having software in the sense of having a product that we sell, we also don’t resell software and we don’t accept referral fees from the software vendors in the space.

CC: Great. Thank you. And thanks for those examples too. Those are really helpful. So what kind of implementation work? You mentioned that briefly. Can you expand on that a little bit?

SO: A typical project for us is somebody who has decided that they need to improve the maturity of their content development processes, move it out of a word process or unstructured, sort of flailing at it, and just throwing bodies at the problem in order to make more and more and more content. And instead design and then build out a system that is more efficient, that leverages reuse, that leverages formatting, automation and all the other cool stuff that we can do. So when we say implementation work, what we’re talking about is that we’ve been through or you’ve been through as the customer and have said, this is the problem. Here’s the proposed solution.

And now we need to do things like pick a content management system, convert all the content from whatever format it’s in now into future state content format, get it moved in, stand up the system, configure the system, get all the people, the authors, the content contributors, the reviewers, the approvers moved into the system, move the content itself, and then go to production. So when we say implementation work, we’re talking about the process of actually building out or configuring the system that’s going to support all these things for you.

CC: Great. Thanks. And you mentioned earlier on that one of the first parts of the process is to just identify some pain points, figure out what’s going on in the organization that needs to be addressed. What are the most common pain points?

SO: I think the number one issue that we see is scalability, as in we can’t scale. We are being asked to do more and more formats. We are being asked to do more and more languages. We are being asked to do more and more content variance because our products are complex or we do customer specific information. So a given customer gets a custom version of the product, that type of thing. Scalability, especially scalability in localization, I think is the number one issue that we run into. So that looks like somebody saying, we know our process isn’t great, but it works okay because we only have five languages, but now we’ve been told we’re expanding into the European Union and we’re going to need 30. We simply cannot take the current five language inefficiencies and multiply by six to get to 30 languages.

There is no way. We have to automate, we have to refactor, we have to reuse because if we don’t do those things, our costs are just going to skyrocket. And maybe more importantly, our time to market. We can’t get to market on time in all these languages in our current process. It just piles, delay upon delay upon delay. So scalability is a big one. Now, related to that, we see things like multiple incompatible content creation systems that don’t talk to each other, but yet need to share information in some way. This is really, really common after a merger. Because company A had system A and company B had System B, you put them together, they can’t talk to each other, but they need to because the customers now are joint customers. From my point of view as a customer, I don’t care that you were company’s A and B, you’re now company merged. Company C.

And I demand that when I go to your website, it looks like a single company, and you can’t get there because these two content creation systems are just not talking to each other. Now, having said that, when I say A and B and two content creation systems, what’s actually far more common is that it’s more like five to eight. It was two companies, maybe it was three companies.

CC: Wow.

SO: But five to eight systems that simply do not talk to each other in any way, shape, or form. Happens all the time because old company A, they had a different merger five years ago and they never did the work. And so they’ve never pruned and it just piles up.

CC: So it just piles up.

SO: And you get this just, it’s technical debt to a certain extent. It’s content rot. You can call it whatever you want, but it’s a mess. Inside of that, it doesn’t require multiple systems, but duplication and redundancy of content. Content is expensive to develop, expensive to manage, and expensive to translate well. And so it’s not good to have multiple copies of the same thing. And it’s especially not good to have multiple copies of the same thing that say two slightly different things for no reason. Happens all the time. So scalability, systems incompatibility, which then blocks you on the things you need to do with your content flowing back and forth, and duplication, redundancy. Those are three things where it’s actually pretty easy to get a hard return on investment.

Some really solid numbers that show if we clean this up, things will be better. In addition to that, we’re seeing a lot of demands now for content integration. The E-Learning or training group is sourcing content from tech docs. They can’t do it well because their learning management system and the tech docs content management system refused to talk to each other, but they really do need to integrate that, and then they need to flow it over and link it to marketing content. And it can’t be done because all these systems hate each other. That’s becoming a big issue. And there’s some really interesting solutions coming on that, but that’s where we are with this. So if you’re looking at those first three issues, if you’re looking at formatting automation, scalability, content creation, duplication, we actually have a calculator for that on our website that lets you get at least a first cut at what this is going to look like.

CC: Great. And we’ll go ahead and have that in the show notes as well. So why content strategy?

SO: It is of course an overloaded term. I look at it as thinking about how you manage information across the lifecycle within an organization. How do you create, how do you edit, review, approve governance, which I know is a dirty word, but when you create content, typically you have to delete it at some point. For the most part, it doesn’t live forever. Some content does live forever and explicitly needs to live forever. But how do you do that? How do you first make sure you have the right information in a given piece of content, and then how do you get it where it needs to go and manage it and update it and translate it and foster it throughout the entire life cycle? So content strategy to me is the overarching plan. And it’s the people, the processes and the technology that you use within that plan to do the things you need to do. So you’ve got your business needs, business requirements, and then the content strategy that provides the solution or the plan that gets you to meeting those requirements.

CC: So when and why should someone, any of our listeners, when do they know it’s time to contact us?

SO: Well, everybody should totally call us immediately. Everyone. No. I would say it this way. If you are in a situation where it is pretty obvious to you sitting inside your organization that the current approach is not sustainable, you can’t hire the people, you can’t scale up because you just have to keep adding people because you have all these terrible processes that take up too much time. You have too many manual workarounds, too much copy it over here and then paste it over here and then spend hours and hours reformatting it to get it into wherever, that kind of thing. If you’re frantically running in place just to keep up or even not able to keep up, it might be time to take a look at whether better systems, better, more mature content life cycle, better, more mature content strategy can get you to where you need to go.

And I would say that in the big picture, people call us when they reach the point where they look at this idea of doing some sort of a transformation on their content and… Because it’s going to be painful. I’m not going to tell you, it’s going to be painful. The fear of doing that is less than the pain of staying where you are. And we’ve done a lot of these projects and we’ve done all sorts of fun, successful things, but ultimately people stay with what they have almost always too long because it’s comfortable. We all do this. I’m not pointing fingers at anybody other than maybe myself, but we all do this. We’re like, no, this is good enough. And then at some point you realize that you passed okay and good enough two years ago, and it is time. And that is the point at which you should probably reach out to us.

CC: That’s great. Well, thank you so much Sarah, and thank you all for listening to the Content Strategy Expert Podcast brought to you by Scriptorium. If you want more information, visit scriptorium.com or check out the show notes for relevant links. And we’ll see you next time.

SO: Thank you, Christine. Welcome aboard.

The post Who is Scriptorium? (podcast) appeared first on Scriptorium.

In episode 134 of The Content Strategy Experts Podcast, Sarah O’Keefe and guest Jodi Shimp talk about the role of content strategy in UX teams.

Related links:

LinkedIn:

Transcript:

Sarah O’Keefe:                 Welcome to the Content Strategy Experts Podcast, brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize and distribute content in an efficient way.

In this episode, we talk about content strategy as a part of UX teams with special guest Jodi Shimp.

Hi everyone, I’m Sarah O’Keefe. Welcome to the Content Strategy Experts Podcast, Jodi.

Jodi Shimp:                       Hi. Thanks for having me.

SO:                                     I am so glad to see you and/or hear from you. So for those of you who don’t know, Jodi and I worked together for many, many years on a lengthy project, and at one point, she introduced me into a big meeting as her content therapist, and I guess this is my revenge. So today we’re here to talk about content strategy and what the role of content strategy is in UX teams. And Jodi, what brought you into this? What’s your interest in this topic?

JS:                                       Yeah, so I spent those many years working on that project with you, but a lot of years developing and leading content strategy from the ground up for a large manufacturing business, and even as part of product interfaces, and then I switched over to join Wayfair as part of their customer-facing content-strategy team. And by that, that team was responsible for the UX content for all five Wayfair brands in all locales.

So although we worked with branding and merchandising teams and content ops and a lot of different groups, we were really primarily part of the experience design team, along with product designers and user researchers. It was a real change from content strategy work when we’re talking about all the levels of structure and meta, and all of the different things that you think of with content strategy, and it was a big departure from working on physical products. So there was a really fast learning curve necessary for that.

SO:                                     So what was the biggest difference? You came out of producing physical products, which by the way is pretty hard to say, and moved over to a digital product company. And from a content strategy point of view, from that lens into the organization, what happened? How was it different?

JS:                                       Yeah, so coming from the physical product side where I had also built content strategy as a function from the ground up, and working with a product that requires a longer lead-time and a longer development time, and moving over to digital where things move very, very quickly, working with a lot of very intelligent people who have created things in a very fast-moving environment that changes super quickly, it was a lot harder to put the wheels on that vehicle as it’s moving forward at a really quick pace than it was in the physical product world that I had been used to before. Even though that had also been accelerating because of more and more content on the product itself in the form of digital displays, it was nowhere near the same speed as the technology companies move.

SO:                                     So you come into a digital product moving at the speed of, I guess, electrons, and into an experience-design team. So I guess foundationally, I keep asking this question, how is UX different from content strategy? And also, please tell me the difference between content strategy and content design.

JS:                                       Yeah, so I think that’s a blurry thing that maybe nobody knows the answer to quite yet, but I can frame it up in how I’ve been seeing things develop specifically at Wayfair, and talking with different content strategists that are at companies like Amazon and Spotify and Shopify and all of those.

So content strategy as a terminology is really starting to become something that people think of marketing as in the technology world. So they’re thinking of those marketing teams, because of marketing content strategy and whatnot. And then there’s the UX content strategy. We’re often starting to hear more content design in that, and I think that’s because those content strategists in UX design teams are often part of experience-design teams. So they sit with the product designers and the user researchers and work side by side with them in these user-experience-design teams.

So that’s starting to be called more commonly content design. But I’ve also seen it still called content strategy, as it was Wayfair. And some places it’s content strategy, some places it’s content design, and sometimes I think they’re really being seen interchangeably still. But I’m starting to see a little more definition between the two.

And then I still think of content strategy as an overall, more talking about that structure and adding the meta and making that smart content that it’s really able to be reused in different places, and it identifies itself of what it is and how it should be used and all of those things. So I hate to say that the lines are still really blurry, but I think they are.

And I think the other common thread that I’m still hearing, whether it’s at conferences like LavaCon or just talking to peers in other companies or on LinkedIn posts, is content strategists, content designers, UX writers, all feel like they spend a lot of their time explaining what they do to other people and trying to help people understand why they’re there and why it matters. Just because you can write in a particular language doesn’t mean that you really understand how to get a user from point A to point B in the most concise way, and most delightful way in a lot of situations, so they enjoy doing so and can do so effectively to accomplish the task that they’re trying to achieve.

SO:                                     And it’s like you said. I mean, in a scenario where you have to say, “Oh, I’m a content strategist, but no, not that content strategist, I’m the other kind. No, not that kind, the other, other kind.” I mean, it’s just-

JS:                                       Right.

SO:                                     And we’re not even going to deal today, because we don’t have enough time, with the question of content engineering and content operations. We’re just going to put that aside and move on. I mean, we’re supposed to be content people, and we are super terrible at self-description, and we argue these terms for years.

JS:                                       Yes. Yes. One of my most enjoyable things in joining that technology team was to the entire 180-person design team, I gave a presentation about what is content strategy and why does it matter to product design, and went through all of the pieces. Here’s why it matters. Here’s what we do. Here’s how we approach content. And we’re not just wordsmiths that come in at the end and make the words pretty, just like you product designers aren’t there just to make the interface pretty. It serves a function and a purpose to help a user achieve their end means. And I got, surprisingly, to me, a lot of feedback on that particular presentation from product designers and user researchers about how they now understood it.

And we also followed that for people who were interested in doing content workshops, content studios, where we took different product managers, user researchers and whatnot through the process of how we would think about content and how we would structure the content and why that matters and what it means in the long run for the content. So that was another effective way with those teams to help them understand the purpose of content strategy in design teams, and we had a lot of success with that over a longer period of time.

SO:                                     So you’ve mentioned content designers, content strategists, user researchers and product designers, I think. And so what did that look like? So you’d have, I guess, an experience-design team that had those four contributors, and then what?

JS:                                       Experience-design team works in a lot of technology companies as part of atomic teams, or sometimes called four-in-a-box model. And that four-in-a-box model really means user-experience design, which includes the groups or the individuals that you talked about. It also includes product owners or product managers, and back-end engineers and front-end software developers.

So the goal is that they’re working in an agile environment on specific features or digital products to, from start to finish, create new or revise existing product features or products together. And the goal is that they’re there from start to finish so that everybody’s working in lockstep and having different review points throughout that development so that what is designed by the user-experience-design team is actually what’s created at the end and tested and then published, released, for the end user, whomever that end user is.

And sometimes, that is super effective. Most of the time, it’s super effective. But there are a few drawbacks that I noticed, being in those technology teams. One of those is, because you have each of these individual atomic teams working on features, it can be really difficult for those teams to connect with other atomic teams.

And so as content strategists, we’re often really concerned with, “Okay, how does somebody get to this feature? Where are they going after they leave this feature?” Because a user might experience multiple features over the course of accomplishing one task: deciding what they want to buy, being inspired, looking through choices, all the way through that end checkout, and then maybe coming back. “Where’s my box? Where is the thing that I ordered?” three weeks later when it still hasn’t shown up, or things like that.

So as content strategists, we want to connect all those different groups together, but the atomic team wants to move fast and quickly, and sometimes that makes them separate from the other groups so that each can move independently and quickly. So there’s positive things to that model, and then there’s some drawbacks too for content strategists, and I’m sure the other teams as well, but especially for content strategists.

SO:                                     You talked about the speed, the velocity at which you’re working in an organization like this. We haven’t talked about whether that’s a positive or a negative, but we’ll just say it was faster. But was there anything that you really missed coming from physical product that was different that wasn’t there, that you’re sitting there thinking, “Ugh, we used to have this and I don’t have it any more”? Was there anything like that? I’m curious about the difference.

JS:                                       So I’ll start with the reverse of that, actually. The thing that I did really like about digital products is you have a lot different opportunity to iterate on ideas and introduce gradual improvements, where with a physical product, once you’ve released the physical product, apart from the actual user interface, it can be really difficult to make incremental improvements, and expensive to make incremental improvements.

So I think that is a thing that I actually enjoyed, was that opportunity to go from a true MVP product that can be released and then incrementally improved, where when you put an MVP physical product out there, there’s more risk in that, I think, and you can’t go back and, “Hey, I’m going to install this new feature on your car because we think it’s cool, so we’re going to add a new button,” after someone’s already purchased it, where with the digital products you can.

But the negative was not having that hands-on piece through the development where you’ve seen a 3D-printed model or the mock-ups and you’ve compared hand in hand, one beside the other. You’ve got A/B testing in digital and other user-testing opportunities where you can mock the different ones up in a digital environment. But it felt very different from the physical progression, to me, than the digital progression.

SO:                                     That’s interesting. What about localization? I know that you had a heavy emphasis on localization in your former life, and what did that look like in this digital product world?

JS:                                       Yeah, so localization’s my pet favorite thing to have around. I don’t know why, but it really is. So I look at every product, whether it’s physical or digital, through that lens of localization, and I’m constantly asking myself, whether it’s something that I have anything to do with production or not, “But how would that work if you put it in a different environment?”

And there’s some things that work great if you put them in a different environment. My blow dryer is one that doesn’t work great if you put it in a different environment. I’ve probably burned up a more than one hair dryer trying to use them in the wrong environment. But those are the sorts of things where that’s my lens always.

So in the technology teams, in the UX design teams, working for a company that did not do a ton of localization beforehand, that was probably… And originally the reason that I joined Wayfair was to work on localization and really help guide that map and create playbooks: how do we do this better?

So there was a lot of education, and one of the biggest things that I took away as a positive from Wayfair was a really cool look at what software engineers could do with localization, and having software-localization engineers on those teams, how cool that was, because I had always relied on outside vendors to do any of that before. But now you have software engineers who are creating APIs right into the work-stream of how to translate content right there.

So they’re building and testing and playing with machine translation engines. They’re building a platform, an interface, that takes whatever we feed it from whichever software within Wayfair, and then that can feed that out to the localization providers or a CAT tool or whatever that needs to be, an interface there. So that was really cool working with those localization teams.

But I did find the same similarities that I’ve seen in other industries, where a lot of the localization problems, they get blamed on the translators; they get blamed on that localization team. And they’re really problems of the source content, whether it’s problems because it wasn’t written succinctly and clearly, or if it’s problems because they didn’t think about the fact the expansion was necessary and the same words won’t fit in the same space when you translate from English to German. So lots of education back to those source-content teams and the source software-engineering teams to learn how to handle localization libraries for metric units and things like that. So translation problems often start at the source, and I found that to be the same whether it was digital or physical, the source.

SO:                                     I just remember that incident, which I think you know about as well, where we were looking at a particular translation and the feedback came back, “Ugh. The Spanish translation is terrible.” They used five different terms for brake-pedal or some word or phrase that should be a single word. And they were like, “This is a terrible vendor. They used five different terms for this word, and we need a new vendor and localization is bad,” and et cetera. And then we went back and we looked at the original English source, and what we discovered was that in the English source, they used eight different terms for brake-pedal.

JS:                                       Yes.

SO:                                     And the localization team, or the linguist, had actually gotten it down to five, which was a big improvement.

JS:                                       So much.

SO:                                     And they were still getting yelled at for being bad and not getting it down to one. It is true that it should be one; it’s just that it wasn’t one in the source, which is where the problem originated, and they were getting blamed for not magically inferring that these eight different terms were actually a single thing, which seemed a bit unfair.

JS:                                       Yes. It is unfair, and that’s why one of my… Well, actually at both the big companies that I’ve led, this type of thing, terminology-management program, is one of the most critical elements. And as machine translation becomes a greater part of localization, really it’s going to be for everyone, I think 50% of translations for customer-facing products are coming from machine translation at this point. And that’s pure machine translation. That doesn’t even include machine translation with post-editing. For companies to manage terminology well, whether they’re physical products or digital products, it doesn’t matter, that terminology is critical to having well-translated products, as with all the other content.

SO:                                     And presumably it’s only going to rise.

JS:                                       Exactly, because I hear a lot more already company leaders saying, “We can translate, so we should,” where in the past, when it was much more expensive and much slower, and machine translation wasn’t an option, you’re very, very specific about which content gets translated. And now the expectation is becoming that everything should be translated, so how are we going to do that effectively?

And a lot of the localization aligns with accessibility. If you make it so the source content is written well and well structured, and that metadata is there, then accessibility requirements serve everyone better, whether you need the specific accessibility adjustments or not. And the localization requirements drive the same thing. It’s talking in simple language. It’s talking in consistent terminology, consistent structure, that makes localization smoother too.

SO:                                     Well, that seems like a perfect place to close this out: with a call to make your source content better and more accessible so that people can use it better, or we can translate it better, and/or it can be more effective out there in the world. So Jodi, thank you for coming in and sharing some of your hard-earned wisdom with us.

JS:                                       Well, thank you for having me. It’s been a pleasure, as always.

SO:                                     Yeah, it’s great to see you. And thank you for listening to the Content Strategy Experts Podcast, brought to you by Scriptorium. For more information, visit scriptorium.com or check the show notes for relevant links.

The post Content strategy in UX teams (podcast) appeared first on Scriptorium.

In episode 133 of The Content Strategy Experts Podcast, Sarah O’Keefe and guest Carrie Hane of Sanity talk about headless CMSs.

If your organization isn’t already going down this route, it will probably go there soon. Whenever it’s time to get a new CMS or change hosts. It’s usually triggered on the IT side to switch to it. But like I said, the developers love the flexibility and ease of this decoupled tool. Yeah, it’s really technology driven, but it’s a real opportunity for everyone in an organization to rethink how they’re creating and using content.

—Carrie Hane

Related links:

LinkedIn:

Transcript:

Sarah O’Keefe:                 Welcome to the Content Strategy Experts Podcast brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way. In this episode, we talk about Headless CMSs with Carrie Hane. Hi everyone, I’m Sarah O’Keefe. I’m here with Carrie Hane from Sanity. Carrie, welcome.

Carrie Hane:                     Hey, Sarah, good to see you.

SO:                                     You too. Tell us a little bit about your background and what you’re doing these days at Sanity.

CH:                                     Yeah, well, my background. For longer than I would like to admit, I’ve been working in-

SO:                                     I know what you’re talking about.

CH:                                     … web and content strategy and helping organizations use technology to better serve the people they’re serving. Obviously the web exploded in the late nineties, and that’s where I started. And so I’ve been able to learn from really smart people, lots of mistakes, and finally get to a point where I guess I’m considered an expert. Five years ago, I co-authored the book, Design and Connected Content, that really laid out a framework for developing future friendly digital products, which includes websites but isn’t exclusive to websites. And then last year I started at Sanity, headless content platform as Principal Evangelist. Now my work involves helping people understand structured content, the value, how to use it, what value it has, and how they can make their lives easier by using technology to support their work, no matter who they are.

SO:                                     Tell us a little bit about headless CMSs. What is a headless CMS specifically?

CH:                                     Technically, it’s a content management system that separates where the content is stored, which is the body and where it’s presented, which is the head. You can store your content in a headless CMS and then send it to any display anywhere. Yes, it’s a website. It could also be an app, it could also be voice assistance. It’s Google, everybody sends their information to Google whether they know it or not. It’s all of those things. It’s a future friendly way to think about plan and store and create your content for whatever comes next.

SO:                                     When you differentiate between a headless CMS and I guess a head on CMS, but I suppose generically, we’re talking about web CMS versus headless is kind of how this breaks down. Although I guess technically headless CMSs are a subset of web CMSs or something like that. But what makes the headless CMS special? What’s the main point of differentiation between, we’ll call it traditional web CMS and headless?

CH:                                     Well, a few things. For content creators, it allows us to really embrace the create once, publish everywhere, the cope framework of working. Whereas in a traditional, monolith web CMS, we could only ever create content for one website and that website only. We would have to create another instance if we wanted that same content to go to an app or to go somewhere else, so those different heads. It lowers the amount of content that we need to create and maintain, kind of future proofs our content because it’s not tied to any specific presentation. Then even if we are only using it for one website, we can reorganize the content because it’s not tied to a certain site map. Or we can redesign the website without having to redo all the content. That is, if your content is good in the first place, which is a wholly separate thing, which we will have to have another podcast about.

In that sense, it kind of lives up to a promise I think a lot of us have been expecting for a long time. On the technical side, it helps technologists create more componentized ecosystems, so that no matter what the latest trend is in front end frameworks or processing or hosts or whatever, I don’t even know all the terms for all of the things that IT needs to be thinking about now, but that tech stack is no longer all tied into one product or one suite. It can now use the best in breed of whatever is needed, so it’s future friendly in that way as well.

SO:                                     Who’s the target audience for this? Who’s adopting headless CMSs, and what are some of the justifications for that? You’ve touched on a few things already, I think.

CH:                                     Yeah. Well, honestly, organizations of all types and sizes are adopting headless CMS. I just saw this week we were talking about it among my colleagues, that the size of the market of headless CMSs is expected to more than double by 2030, which is only seven years away, by the way.

SO:                                     That’s not helpful.

CH:                                     If your organization isn’t already going down this route, it will probably go there soon. Whenever it’s time to get a new CMS or change hosts or, I don’t know what else. There’s a lot of things, it’s usually triggered on the IT side to switch to it. But like I said, the developers love the flexibility and ease of this decoupled tool. Yeah, it’s really technology driven, but it’s a real opportunity for everyone in an organization to rethink how they’re creating and using content.

SO:                                     What does it look like to implement, to make that transition over to headless CMs, assuming that you’ve started in, I hesitate to say traditional web CMS, because that’s ridiculous, but here we are.

CH:                                     It looks different for every organization. I think one of the things that can happen when you make this switch is a complete digital transformation. Organizations who are committed to going through digital transformation, are really completely changing how they’re approaching their digital experience. Other groups are like, “We need a new CMS, a new something yesterday,” so they literally just recreate what they have in whatever tool that they buy, just reconfigure the connections, but all the content goes over in whatever way it was.

The design looks the same, they might even have the same underlying CSS in frameworks, so it really varies from that. Going from exactly what you have now to a new tech stack or completely changing everything. And then obviously lots of things in between. But yeah, it’s an interesting time to be watching all of this because it is accelerating. I remember first hearing about headless, maybe 10 years ago, and now I don’t know how you can work in the content management world and not hear about it and not be thinking about it.

SO:                                     I know a lot of the people listening to this podcast, and certainly my side of the world is sitting largely in XML, DITA and technical and product content world. What you’re describing to a certain extent when you talk about multichannel publishing and separating content and formatting, kind of sounds like XML based publishing and kind of sounds like DITA specific… Well DITAs obviously an implementation of that. I guess then the question I have to ask is, is a DITA component content management system actually a headless CMS?

CH:                                     I suppose technically because it’s a body that’s separate from the head, I don’t really have any experience with DITA CCMSs, so I don’t know more. What I associate that with is technical communications, which is only in my mind, one use case for any of these systems. I don’t know, have you seen other use cases? What are your thoughts and what are you seeing?

SO:                                     Well, there are other use cases, and we have some customers that are using XML structured content and specifically DITA outside the core tech pubs, tech com world. But ultimately, when I look at these two, I would say the DITA world, the DITA XML world is optimized for a certain kind of content type. And what you’re describing with headless is a lot of the same principles, but it’s not specifically optimized or built around a framework that is designed for technical content specifically. It’s almost like the DITA CCMS world is the specialized… Sorry, people that was not really intended to be a terrible pun. But is sort the solution that’s intended for a specific industry or a specific use case, we’ll say. Whereas the headless approach, or when we talk about headless CMSs, we’re talking about something that is intended for more of a general purpose solution. I guess it’s a subset. Is that fair?

CH:                                     Yeah, I think-

SO:                                     Sorry, headless is the super set and DITA PCMs would be the subset. And I guess the other important note is that although it’s not required, DITA and XML are based on a sort of a tree view of a document, similar to HTML. And the headless CMSs as a general rule, are built on knowledge graphs, which are less of a tree and more of a multidimensional thing that’s hard to conceptualize.

CH:                                     Yeah, a graph.

SO:                                     Yeah. The knowledge graph. And the really sad thing about knowledge graphs is that I saw those for the first time about 20 or 25 years ago when we had things like information models and entity relationship diagrams in some of the software that I was supporting. What do you see as some of the biggest challenges, as we talk about this concept of moving websites or web content or content outside of tech com might be the fairest way of saying it, into this headless approach. What are the biggest challenges that you see there?

CH:                                     I think the biggest challenge is the content creation world. The content strategy world is not ready for that. And not because people don’t get it, it’s because they don’t even know what they don’t know. Most organizations are not mature enough in their content operations to really take advantage of a headless CMS. And so the danger becomes the tech. IT moves them there because they need it for their tech ecosystem. And then they’re given the keys. I’ve heard some people say they’re given the keys to a Lamborghini and they don’t even have their driver’s license yet.

I hear a lot of people say, “I don’t like headless. I don’t like that,” because they’re disoriented. It’s not what they’re used to. It’s set up completely different. And so then they blame this technology for a problem that’s not the technology’s fault. And then what will happen? Will we go backwards? Probably not. But it’s going to take a lot for the whole… I think it’s even bigger than a market, the whole world really. We’re all moving or moved to digital first publishing, and what isn’t digital these days. And we’re still in this old mindset of print analogies, print whatever, and haven’t thought of new ways of approaching how we can create and publish information. And I think headless is a big opportunity and it’s potentially a jumping off for a new era in publishing, but we’re not going there fast.

SO:                                     What you’re describing sounds exactly like the pain we went through in trying to move people from a word processor, style based mindset, to a structured content, separation of content and formatting mindset. And I’m not saying we’re done and it’s been super painful and the change management issues have been extensive. If it’s going to be pain and there’s going to be all this change and change resistance and all the rest of it, what are some of the opportunities? What makes it a worthwhile change?

CH:                                     It opens the door to doing more fun stuff because it can reduce the amount of content you’re creating and maintaining. People who create content can get out of the business of constantly reacting and putting out fires and move to being more proactive and creative and thinking about these new ways to reach their audience, connect with their audience, and instead of constantly trying to keep up. As people who work within organizations or with organizations are so far behind actual people, the consumers out there who want new things and new ways of interacting with things. And I think we’re on the cusp of that. I’m not saying headless is the end goal, but I think it’s a good jumping off point for trying out new things and getting our houses in order enough, so that we can then move forward instead of being on a treadmill and trying to keep reaching for a different goal that just keeps staying the same distance away.

SO:                                     That seems like a good place to leave it. We are going to attempt to get off the treadmill and onto the, I don’t know, the ski slope, maybe a little bunny slope.

CH:                                     The trail.

SO:                                     The trail. That metaphor did not work at all, but we will hop off the treadmill onto an undisclosed other means of transportation that is actually going to advance us forward. And Carrie, thank you for coming in and talking about this, because I think this is, at this point, a topic that’s not well understood and we need more people out there to explain it and explain where this is going.

CH:                                     Yeah. Well thanks for having me. It’s always fun to chat.

SO:                                     Yeah. And we’ll do some more of that in 2023. That’s a truly terrifying thought. 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 What is a headless CMS? (podcast) appeared first on Scriptorium.

In episode 132 of The Content Strategy Experts Podcast, Alan Pringle and guest Jo Lam of Paligo dispel misconceptions and myths about structured content.

“Science and history shows us that structured content, structured authoring, is actually very intuitive. And if I may rewind back to, say, the paleolithic era where we first started using a lot of symbols, and then eventually converting them into what we now know as letters. Understanding patterns on an extremely micro level, and that’s how we actually learn to read and write.”

—Jo Lam

LinkedIn:

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 discuss misconceptions about structured content with special guest Jo Lam of Paligo.

Hi everyone, I’m Alan Pringle, and we have a guest for this episode. It’s Jo Lam of Paligo. So Jo, introduce yourself.

Jo Lam:                              Hello, my name is Jo. I work at Paligo. That’s intentional, for all of the rhyme. I’m a solutions engineer, and I generally work as someone who helps figure out the best approach and the solutions, if you will, for people moving into a structured authoring environment. And as suppose I should tell you what Paligo is…

AP:                                     Yes.

JL:                                       Since I just mentioned that’s where I work. So we at Paligo, we are a CCMS and content… Sorry, whoops. Component Content Management System, where we use the DocBook standard as our base. And really what we strive to do is provide the perfect entry point for people moving from unstructured to structured content by being as user friendly as possible and making the entire process very intuitive for them.

AP:                                     Well, that is actually perfect for what you and I are about to talk about, because we’re going to talk about the misconceptions people have about structured content. And having worked with structured content decades myself, I can guarantee you there’s lots of apprehension and misconceptions about it, and I am sure you’ve run up against them, as well. So I’m going to throw the first misconception out there about structured content. And by the way, I will post in the show notes a link to a white paper about structured content and structured authoring for those who want a little more background about structured content.

So let’s go and talk about the first misconception, that structure is hard. What do you have to say about that, Jo?

JL:                                       Well, science and history shows us that structured content, structured authoring, is actually very intuitive. And if I may rewind back to, say, the paleolithic era.

AP:                                     Okay.

JL:                                       Where we first started using a lot of symbols, and then eventually converting them into what we now know as letters. What this is, actually, just understanding patterns on an extremely micro level, and that’s how we actually learn to read and write, is through systematic training of our brains. Because our brains weren’t actually evolved to read and write naturally. Language and speaking it, yes, but reading and writing is not natural for our brains. So through this whole process of learning how to read and write, we actually have employed the basics of structured authoring.

So to give you an example, if I have, on my desk, maybe a very far distance from you, on the other side of the room, two sheets of paper. One is a resume and one is a cover letter, and all you can see from a very far distance is the blocks of the ink, but you don’t know what letters they are. But you can already tell which one is the cover letter and which one’s the resume. And that’s because there’s structured authoring employed in there and you naturally know those structures are associated with those particular types of documents.

AP:                                     Yeah, that makes a great deal of sense. It’s like intuitive, almost built in for us. That makes a lot of sense. And also too, beyond intuitive nature, any time someone is doing any kind of process change, and that includes moving from unstructured content to structured content, if you do not put in basic change management practices, of course it’s going to be hard. You can’t just say, I’m going to do structured authoring, or this company, this department’s going to do structured authoring, and then not consider all of the business requirements that drive that decision. And then buying the tools such as Paligo for that, training people on how to use them and keeping those lines of communication open.

So merely just saying, I’m going to do structure and not thinking about what that entails, yeah, structure will be hard, as any process change would be. So yeah, I’m trumpeting the change management mantra again, and I’m sure people listening are tired of hearing about it if they listen to any other episodes, but it’s a huge component here. It is not just about structured content, it is not just about the tools, it is about change management and people, as much as all those things.

JL:                                       100%.

AP:                                     Yep. So here’s another misconception. I’m going to have to write code, I’m going to have to type pointy brackets and slashes. Don’t make me do this.

JL:                                       There’s a lot of fear behind that there.

AP:                                     Yeah.

JL:                                       Well nowadays there are a lot of different interfaces that hide all that. But let’s say you do have to write with the pointy brackets. I really like that, the pointy brackets. Let’s say you do have to use the XML tags. Well, I would like to think of it as using identification labels for what we are writing. I mean, we tag everything as it is. We all use social media, we tag exactly what that thing is about. And in a lot of senses, it’s kind of the same thing. If I have a list and I tag it, hey, this is a list, I’ll tag it within those brackets, now we don’t have to think about how that looks like. So you’re not thinking about, oh, well it is indented plus a dot in the front of it, and you don’t have to think about all of those formatting things, you know immediately it’s a list.

And typically in structured authoring, you have all the look and feel of the document handled somewhere else.

AP:                                     Exactly.

JL:                                       So you really don’t have to do anything beyond, say, it is identified as a list or identified as a table, and I know exactly what that’s going to be when it gets pushed at the other end.

AP:                                     Yeah, I think that’s an important distinction to make. When you’re talking about structured content, structured authoring, you basically have a predefined organization hierarchy for your content, and then you tag things to follow that hierarchy, that organization. And what you’re talking about is, there is no thought about formatting. The structure content itself is, shall we say, formatting agnostic. What it cares more about, like you said, is this is a list item and an unordered list, or this is a paragraph and a note. When you build in that kind of intelligence with the tagging, then wherever you publish to, and these days we all know print pdf, everything, eBooks, E-learning, websites, I mean, you name it, it is anything.

And things can look slightly different, even though you’ve got an unordered list in all of these things, they may not be formatted exactly the same. That is not the concern of the author. All that author needs to do is just be sure and say, this is an ordered list, this is an unordered list. And then the processes later take on all that formatting that you’re talking about.

So let’s go to the next misconception. There’s a lot of content here and we’re going to have to convert it to structure. I don’t have time to do this.

JL:                                       Yeah, so the time thing is a huge concern for large organizations, especially if you have a massive amount of documentation, maybe spanning back the last 50 or so years. That’s actually a nightmare for any technical lawyer. That’s horrifying. I don’t want to dream about that. So what most of the tools now have, just the good news here, is there’s a lot of import tools already built in, and if not there’s a lot of import tools outside of CCMSs is that can help you with that, that into integrate with a CCMS.

But generally you’re going to be hard pressed to find one without one built in already. And the great thing is, generally, whatever you’re working in is likely something that spawned out of the original SGML. So SGML went to evolve into XML. Well, not evolved, but we derived it from SGML.

AP:                                     Yes.

JL:                                       And then from that we derived a lot of other things such as, well, everybody knows HTML, and a lot of other [inaudible 00:08:47] formats are derived from that. So meaning the conversion is actually relatively simple, and you don’t have to do it yourself because so many tools out there already know that and will bring it in for you.

AP:                                     Exactly. And your tool’s one of them that will do that. And even if the tool doesn’t, there are third party vendors, that is all they do. They write scripts and automate that stuff, and it means less dirty work, really, for the authors.

And one thing that we have learned at Scriptorium, and we really advise people not to do this, don’t let conversion be your content creators first exposure to XML, or structure, or whatever, because they may end up resenting it because of the amount of work that they have to do just upfront, converting. They should be putting their focus on creating content as efficiently as possible. So anything you can do with an import tool like you mentioned, or with a third party vendor who can automate that for you, I highly recommend it. It is money well spent and it will keep your content creators far happier than they would be otherwise.

JL:                                       You know what, that exposure to conversion there, I thought my example was a nightmare, that is a true nightmare, right there.

AP:                                     It is.

JL:                                       I would not wish that upon anybody.

AP:                                     No. We’re on the same wavelength there. It is not a good thing to do. And it is something, if you’re going to move to structure, be sure to budget time, money to do this, but use tech to do it. Don’t make people manually do it if you can avoid it.

JL:                                       Absolutely.

AP:                                     Yeah. So let’s go to number four of our misconceptions. And that is structure is just for technical communication and other technical content.

JL:                                       That it is very much not. I mean, earlier I talked about the resume versus a cover letter. How about we think about what we usually use on a regular basis. And I love food, I am actually very hungry right now. And so I will think about recipes.

AP:                                     Sure.

JL:                                       And we all know what recipes look like.

AP:                                     Yeah.

JL:                                       There’s always going to be, near the top of that recipe, an ingredients list followed by procedures. Nowadays, we’ll also usually see yield times or how many servings, and then you can toggle that back and forth. Now every single part of that is identified. So the procedure, well that’s a procedural element. And the ingredients list, well that’s a list element. And that’s all actually structured authoring right there. And that tells us the difference between, well this will tell me how to make a dish versus, oh, that page with the five paragraphs that’s telling me concepts I should understand about the culinary world, or something like that.

AP:                                     Yeah.

JL:                                       So those distinctions between that structure is in our everyday stuff, even your social media post. We know it’s a social media post, it’s only two lines long. We know that’s an update, so that’s like a reference topic, per se. And we know what we get from that is just a, oh, you should know this, not, oh, I have to do something about that. Right? So very different kinds of information in very different structures every single day, in every aspect of our lives.

AP:                                     Sure. And I know from working with many clients that people are now applying structure to marketing content. They are applying it to learning and training content. It is not just about technical information anymore, especially considering we’re seeing these trends where these lines between different kinds of content are blurring. So it would make sense that structure would start to kind of seep out and work for all different kinds of content. So let’s talk about our last misconception. Readers don’t care how we author this content.

JL:                                       I think all the people working in tech support, what customers coming to them after not understanding the documentation, would disagree.

AP:                                     Yes, they do. And often.

JL:                                       Very often, yeah. Readers do care, even if they don’t know it, they don’t know it’s structured authoring. But again, it’s all about intuition. If someone wants to know how do I do something, they’re going to look automatically for numbered steps, procedures. And if you give them a paragraph, yeah, they’re going to be pretty angry.

Or even just on a more casual level, let’s go back to my resume versus cover letter. Let’s say in the resume, you can derive from that, what are the skills. And you can look exactly for that because we have these filters in our brains, the patterned thinking actually helps us with applying these filters. So you’re using contrast, repetition, alignment, and proximity, these principles, to really figure out what’s on a page before even seeing the very first letter. And that’s going to tell you, oh, I want skills, I’m going to look on the resume for a list. And you’re going to ingest that differently than say, I want to learn more about this person’s personality and therefore I’m looking at the cover letter for the biggest paragraph, and you switch gears in your brain to absorb it very differently. So if you imagine writing that paragraph in point forms, how would you process that, how would you prepare your brain to actually start reading that? And then you’re going to just be very confused and get frustrated and start all over again.

AP:                                     Yep, yep. Exactly. I think this is a great place to end this conversation. I think you’ve given some really good examples and kind of dispelled these myths about structured content. So I want to thank you for this, this has been a great conversation.

JL:                                       It’s been fantastic and a lot of fun. Thank you very much, Alan.

AP:                                     Absolutely. And we’ll include a link to Paligo in the show notes. 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 Misconceptions about structured content (podcast) appeared first on Scriptorium.