Deliver content dynamically with a content delivery platform

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Spotify | Amazon Music | Email | TuneIn | RSS

Struggling to get the right content to the right people, exactly when and where they need it? In this podcast, Scriptorium CEO Sarah O’Keefe and Fluid Topics CEO Fabrice Lacroix explore dynamic content delivery—pushing content beyond static PDFs into flexible platforms that power search, personalization, and multi-channel distribution.

When we deliver the content, whether it’s through the APIs or the portal that you’ve built that is served by the platform, we render the content in a way that we can dynamically remove or hide parts of the content that would not apply to the context, the profile of the user. That’s the magic of a CDP. It’s delivering that content dynamically.

— Fabrice Lacroix

Related links:

• Scriptorium: Personalized content: Steps to success (white paper)
• Scriptorium: AI in the content lifecycle (white paper)
• Fluid Topics, an AI-powered content delivery platform
• Fluid Topics: What is Content Operations and Why is it Important?
• Get monthly insights on structured content, futureproof content operations, and more with our Illuminations newsletter

LinkedIn:

• Sarah O’Keefe
• Fabrice Lacroix

Transcript:

Introduction with ambient background music

Christine Cuellar: From Scriptorium, this is Content Operations, a show that delivers industry-leading insights for global organizations.

Bill Swallow: In the end, you have a unified experience so that people aren’t relearning how to engage with your content in every context you produce it.

Sarah O’Keefe: Change is perceived as being risky, you have to convince me that making the change is less risky than not making the change.

Alan Pringle: And at some point, you are going to have tools, technology, and process that no longer support your needs, so if you think about that ahead of time, you’re going to be much better off.

End of introduction

Sarah O’Keefe: Hi everyone, I’m Sarah O’Keefe and I’m here today with the CEO of Fluid Topics. Fabrice, Lacroix. Fabrice, welcome.

Fabrice Lacroix: Hey. Hi Sarah. Nice being with you today. Thanks for welcoming me.

SO: It’s nice to see you. So as many of you probably know, Fluid Topics is a content delivery portal or possibly a content delivery platform. And we’re going to talk about the difference between those two things as we get into this. So Fabrice, tell us a little bit about Fluid Topics and what that content delivery portal or maybe platform. Which one is it? What do you prefer?

FL: For us, it’s platform definitely. But you’re right, depends on where people are in this evolution process, on how they deliver content. And for many, many customers, the piece stands for a portal. You’re right, because that is the first need. That’s how they come to us, because they need a portal.

SO: Okay, so in your view, the portal is a front end, an access point for content, and then what makes it a platform rather than a portal?

FL: Probably because the goal that many companies have to achieve is delivering that content where it’s needed. It’s many places most of the time. So it’s not just the portal itself, and that’s where solving the problem of being able to disseminate this content to many touch points, you need a platform for that. The portal is one touch point only, but when you start having multiple touch points like doing in-product help or you want to feed your helpdesk tool or field service application or whatever sort of chatbot somewhere else, whatever use case you have that is not just the portal itself, then that becomes a platform thing.

SO: So looking at this from our point of view, so many of our projects start with component content management systems, CCMSs, which are the back end. This is where you’re authoring and managing and taking care of all your information, and then you have to deliver it. And one of the ways that you could solve your delivery front-end would be with a content delivery platform such as Fluid Topics. Okay. So then, what are the prerequisites, when you start thinking about this? So our hypothetical customer has content obviously, and they have, we’re going to say probably a back-end content management system of some sort, probably.

FL: Most of the time.

SO: Most of the time.

FL: Depends where you go, depends on the maturity and the industry. If you go to some manufacturing somewhere, they mostly still are maybe on the word and FrameMaker or something like that in design, and then they generate PDFs.

SO: So maybe we have a backend authoring, well, we have an authoring environment of some sort on the back-end. Maybe it’s a CCMS, maybe it’s something not like that. And now we’re going to say, all right, we’re going to take all this content that we’ve created and we’re going to put it into the CDP, the content delivery platform. Now, what does success look like? What do you need from that content or from the project to make sure that your CDP can succeed in doing what it needs to do?

FL: The first answer to that question that comes to my mind is no PDFs. I mean, if you look at it, don’t laugh at me. If you look at it from an evolutionary perspective, it’s like regardless how people were writing before, it was not CCMS, mostly unstructured. And at the end of the day, people were pressing a button and generating PDFs and putting the PDF somewhere, CRM, USB key, website for download. But managing the content unstructured was painful. That’s where you start working with the CCMS, because you have multiple versions, variants, you want to work in parallel, you want to avoid copy paste, translation, so the story around that. So then companies start and they start moving their content into CCMS. All of the content, part of the content, but they start investing in a modern way of managing, creating their content. But again, if you look at it once they have made that move, most of those companies 10, 15 years ago probably were still pressing a button and still generating PDFs. And then they realized that they had solved one problem for themselves, which is streamlining the production capability and managing the content in a better way. But from a conception perspective, regardless whether you work with word FrameMaker or in DITA with the most advanced CCMS of the market, if you still deliver PDF, you are not improving the life of your customers. And then people started realizing that, oh yeah, so we should do better. So let’s try to output that content in another way than PDFs. And then say, “What else than PDF, do we have? HTML.” And was like, okay, and let’s output HTML. But HTML that is pretty much the same as the PDF. You see what I mean? It’s like static document. Each document was a set of HTML pages. And then they started realizing that they need to reassemble the set of HTML pages into a website, which is even more painful than just putting PDFs on the website is reassembling zip files of HTML pages on the website, and then it’s like static HTML. And then you have to put a search on top and have to create consistency. And that’s why CDP have emerged. That’s solving this need, which is, how do we transition from PDF to static HTML to something that is easier, that ingest all this content, comes with search capabilities, comes with configuration capabilities, and as well at the same time as API, so that back to the platform thing, it’s not just a portal, but can serve other touch points. So that’s really because we are in the detail world, DITA is the Darwin Information Typing Architecture. So that’s a very Darwinian process that led to this creation of the CDP and the need of a CDP is the next step in the process. And many companies really follow that process of, I have to go from my old ways of writing, which are not working painful, move to a CCMS, but in fact realize that they don’t solve the real problem of the company, which is how can I help my customer, my support agent, my field technicians better find the content better use my content? And that’s where this T, oh, okay. That’s where we need a CDP.

SO: Yeah, and I think, I mean, we’ve talked for 20 years about PDFs and all the issues around them, but it’s probably worth remembering that PDF in the beginning was a replacement for a shelf of books, paper books that went out the door. And the improvement was that, instead of shipping 10 pounds, or I’m sorry, what four kilos of books you were shipping as you said, a CD-ROM or this was before USB, a zip drive. Remember those?

FL: Zip drive.

SO: A zip drive. But you were shipping electronic copies of your books and all you were really doing was shifting the process of printing from the creator, the software, hardware, the product company to the consumer. So the consumer gets a PDF, they print it, and then that’s what they use. Then we evolved into, oh, we can use the PDF online, we can do full-text search, that’s kind of cool, that was a big step forward. But now to your point, the way that we consume that information is not printed and it’s for the most part, and it’s not big PDFs, but rather small chunks of information like a website. So how do we evolve our content into those websites? So then what does it look like to have a, and I think here we’re talking about the portal specifically, but what does it look like to have a portal for the end user that allows them to get a really good experience in accessing and using and consuming the content that they need to use the product, whatever it may be. What are some of the key things that you need to do or that you can do?

FL: Yeah. I would say that the main thing that a CDP is achieving compared to static HTML, because now we have to compare not with PDFs that are probably still needed if you want to print as well, I’m not saying that PDF is dead and we should get rid of all PDFs. Just said that it’s just when you need to print, then you can get the PDF version of a document. But if we compare static HTML with what a CDP brings, we’re trying to make content personalized and contextual. If you pre-generate static HTML pages, it’s one size fits all. It’s the same HTML pages for everyone. And if you have two versions of your product and one variant, and then you translate the same zip file exists in 20 versions, so to say, and you have to assemble that and let people understand how to navigate that and that should become super complex. What a CDP solves is like, give me everything, and I will sort out this notion of I understand the fact that the same document can exist in 20 variants, whether it’s product version, document version, capabilities of the product version A, version, B, Asian market, European market, American market. And then you have subtilities and some paragraphs are here, some paragraphs are removed, added. And so we are adapting the content so that it fits the profile of the user. And if you ask me what’s needed to make a CDP work, it’s mostly metadata, metadata, metadata. And I can tell you a story, what was fun? It’s like, few years ago, some years ago, more than few, we had customers reaching out or expecting customers to reach out and say, “Oh, show me three topics.” And then we’re showing the capability and say, “Oh my God, it’s exactly what we need.” And then those guys disappeared for two years. And in fact, what they did during these two years is like adding metadata to the content. It was not about the product, but through this discussion we had with them and showing that you can put facets for the search and then varianting content and let people switch between variants and versions of the content through metadata and all that, and they realized that, oh my God, that’s exactly what we need. And then through their questions, they understood that they needed to have those metadata on the content and those metadata were not existing and still they were working with the CCMS. But if your output channel are PDFs, if you don’t put PDFs, you don’t care about putting this metadata on the content inside the CCMS. That’s a lot of work to do to maintain those metadata. But if at the end of the day you print a button and you generate a PDF, those metadata are lost, they are not used, they’re not leveraged by the PDF. So that becomes flat pages of content. So they had transitioned to a CCMS but never made this investment of tagging content. And when I mean tagging content, it’s not just the map, it’s like the section, the chapter, this is for installing, this is for removing, this is for configuring, this is for troubleshooting, this chapter is about this, this topic is about that for this version of the products. You know what I mean? Fine-grained tagging at different level of the documents. And because they were generating PDFs, they didn’t see the need of making that tagging at the right level, and they realized that suddenly the sheer value they could get from PDF is when the content is tagged because that’s using those tags and those metadata schemes that the CDP can adapt the content to the context profile of the user. So I would say, what’s needed to leverage the capabilities of a CDP? It’s mostly granularity of content and tags, metadata that let people, and you can design your metadata from a user perspective. As an end user, how would I like to filter the content? What are the tags I need for filtering the content? It’s like, if I run a search, I have these facets on the left side of the search result page, what would I like to click on to refine my search and spot the content that fits my needs?

SO: And I think, going back to our flat file PDF or static HTML, if we need to do this kind of thing, if you need context in a flat file, what you have to do is say something like, if you have product variant A, do this. And if you have product variant B, do this. Or if you are installing and the temperature, the ambient local temperature is greater than X, then do these extra steps. If you are baking and you are at high altitude, you have to adjust your recipe in these ways. So you end up with all these sort of if statements that are, hey, if this is you do these things, but it’s all in the text, because I have no way, maybe I can do two variants of the PDF like variant A for regular altitude and variant B for high altitude. But I can’t do one per country, right? I mean, I guess I could, but ultimately, what you’re describing is that instead of putting it into the text explicitly, “Hey Fabrice, if you meet these conditions, do these things or don’t do these things or do these extra things,” the delivery portal, platform is going to say, “Okay, what do I know about this end user? What do I know about Fabrice? I know he is in a certain location with a certain preferred language and a certain product. I know which products you bought.” So therefore you don’t get an if, if, if, if, you just get, here’s what you need to do in your context with your product.

FL: Exactly. When we deliver the content, whether it’s through the APIs or the portal that you’ve built and that is served by the platform, we render the content in a way that we can remove or hide dynamically parts of the content that would not apply to the context, the profile of the user. And that’s the magic of CDP. It’s making that content dynamically. It’s also called dynamic content delivery. You remember we had this concept, the dynamic part is, how can I dynamically leverage the metadata on the content side or the conditions that I adapted, read through metadata schemes and make that applicable to the situation and the user profile? So that’s the magic part of it, and that’s a huge improvement compared to a static document that lists all the conditions and then you put the burden on the reader to figure out, sort out inside the document what should be skipped and what to do depending on the product configuration.

SO: Which can of course get very complicated. Now you mentioned product help, in-app help, context sensitive help. So what does it look like to use a Fluid Topics or this class of tool to deliver context sensitive help or in-app help?

FL: We are back again to this granularity and the metadata. So imagine you are a software vendor, you design a web application that you have created and you want to do the inline help for your application, your web product. What would you do? You would say in that page, when people click on that question mark or help button, we should open a pane and display that information. That information needs to be a topic, it needs to be written, and the granularity should be a topic because that’s what you pull from the system. So that’s where we need the granularity that’s matching what you want to display inside your app, whether it’s a tool tip, maybe a small tool tip when you move something in the app and then that becomes some fragment of content you need to get from the CDP dynamically. That can be one page of explanation that you display in a pane that opens in your app, but you need to pull that content. So the same way that that’s how you would do it, you were embedding the content inside the application itself. You would write each part of the explanation, the help that you want to display as fragments of information. If you are doing it statically inside the application, but the problem is that if you want to fix something or enhance the content, you have to edit the application, change the… So it’s part of the development. Here, you want the app to pull the content dynamically because the same content can be not only used to be displayed live in the screen, real time. But can be the same content that is used on the doc portal or then you print a PDF on how to do this. That’s the same. You don’t want to maintain the same explanation, in the application, in the portal, in PDFs. So one source. So it’s exactly that. And then you’re pulling through metadata. The app will say, “Oh, give me what goes into that page.” So it’s metadata-driven as well.

SO: Right? So there’s an ID on the software or something like that, and it says, “Give me the content that belongs with this unique label.”

FL: Exactly. Behind each button you give an ID to that button, which is the question mark in that page. When people click pull content, inline content help, ID number 1, 2, 3, 4. And on your CCMS, you have a metadata, which is called content ID for inline help, whatever. And then you tag that piece of content, 1, 2, 3, 4, and then that’s it. Magic is done. So it’s that simple.

SO: So what I’m hearing, and this is in fairness, exactly what you started with is, you have to have metadata, right? On the content.

FL: You have to have metadata.

SO: And without the metadata there is, well, let’s talk about magic. So if you have a front end that is some sort of a large language model that bought something, what does that mean in terms of this content delivery platform? I mean, can’t you just use ChatGPT and call today?

FL: Yes, that’s a good one. I think most of the project AI project we’ve seen in large companies when they started to do, oh, let’s build a chatbot. That’s the magic dream of any company like building the chatbot that replies to any question. Okay, so how does the project start usually? You have the IT, some people in the IT team or the IT team is hiring external people specialized in AI and they realize that they need content. So the first thing they do is they come usually to the TechDoc team and say, “Give me all the content that you have.” And the TechDoc team says, “Okay, we have all these DITA contents.” You say, “No, I don’t want DITA, I want PDFs.” That’s huge to see that. Why? Because they use technology like something from Microsoft, you can build your chatbot in five minutes, but then the only content types you can fit this ready to use platform is with PDFs and Word. So all the magic you’ve put in your content and the tags are lost and you see people getting PDFs out of you wanting PDFs from your content, which is the exact opposite of the investment you’ve made. Putting PDFs somewhere on the storage place and say to Microsoft Chatbot, blah, blah, this is the content, this is the knowledge of the company. And then when you have 20 variants of the same product, then no metadata anymore. Then the chatbot is always mixing all the content. And when you start asking real questions about how to do this, how to do that with this version of the product, everything is lost. And then the chatbot start hallucinating, not because the LLM is hallucinating, because the LLM just the system, the chatbot does not know what PDF to use because it’s implicit to know that this PDF applies to that version of the product or that version. It’s even worse if you say, “If you have product A, do this, if you have product B, do that and start mixing conditions and then just the knowledge becomes barely readable by humans that make mistake reading it. So can you imagine how an LLM can make sure that it’s putting the right information from that complex text structure?

SO: Okay, so make PDFs out of DITA, dumb it down, send it to the chatbot, that’s bad.

FL: And then it’s guaranteed failure.

SO: So what’s the good version of this?

FL: But that’s how it works. I guess, I write that you’ve seen this sort of projects where people were asking for the content, thinking that the more they have, the better it’s going to be. And suddenly they realize that, that chatbot is not working and doing many mistakes. And they call that hallucination, because if the LLM was hallucinating, but it’s not, it’s just able to feed the LLM dynamically with the right retrieval, augmented generation scheme to dynamically provide the information for replying to the question because it’s difficult to pull from the PDF the right information that applies to the context. And we are back to, what is the context? What is the machine? What is the profile of the user? What is the variant, the version, the whatever you have in front of you? So that’s the complex part. So what’s the relationship? What is the successful AI? What’s the relationship between CDP and AI? All AI projects I’ve seen start regardless of us, regardless of Fluid Topics, start with we need to gather content. We need to take the content that we have, put it in one place, create this sort of unified repository of content. The promise that usually, as I said, they do it using static document, PDFs, to analyze blah blah. If you look at what a CDP is, that’s exactly what it is. It’s already your repository of content. At least everything around the product, because we’ve been talking about CCMS published to CDP. What also makes a CDP very special is that, not only can we ingest this DITA content, but also this legacy PDF and markdown content, API documentation knowledge bases. So the CDP is here to ingest all the knowledge that you have around your product, not just necessarily the formal techdoc, the proper techdoc that has been well written and validated. So we have already, well, the CDP is exactly that. It’s building, that’s the purpose of it. It’s building that unified repository and that’s where you should start from. And it’s fine grained, and we have the metadata and we have everything, so we know how to feed the LLM. So there are two things in an AI project. One is the LLM, but now people use generic LLM, you don’t fine tune, train an LLM anymore for this sort of use case that is just a chatbot for replying to questions and solving cases automatically. You use a generic LLM and you feed the LLM dynamically with the fragments of content of knowledge that you have in your repository. And that’s where just as a human, when you run a search, you look for content, you know what part of content, what are the fragments, the topics, the chapters that contain the knowledge for replying to that question? The tough part is, extracting that from the repository. Am I extracting the 2, 3, 4 pages around the question that are matching the version, the situation that I’m in? So that I can then feed the LLM and say, “This is the 10 pages of knowledge that we have, or 20 or 50 pages of knowledge. This is the question replied to the question using that knowledge.” That’s exactly what a chatbot does. You’re giving the question of the user, you give 5, 10, 20, whatever number of pages of knowledge that you have in your repository and you ask the LLM say, “This is the question, this is the knowledge, please reply.” So the test part is extracting the 5, 10, 20 pages that are really adapted to the situation, to the context.

SO: And the metadata helps you do that.

FL: And the metadata. Nothing else than metadata for doing that.

SO: Right. Okay. So we’ve talked a lot about metadata as I guess a precondition, right? A prerequisite. Yeah, it is. If you don’t have metadata, none of these other things are going to work. And I wanted to ask you about other, maybe, challenges or prerequisites. So other than people coming in and saying, oh, right, we need metadata, and then they go away for two years and then they come back and they have some metadata, what are the other issues that you run into when you’re trying to build out a CDP like this? What are some of the other… What are the top challenges that you run into other than clearly metadata? So we’ll put that one at number one.

FL: Oh yeah, clearly number one. I would say the second one now is the UX UI people want to design. Because modern platform have unlimited capabilities in designing the front end, the UI that you want. It’s like what do you want? What makes sense for regarding, based on your product types, the user that you have, the content that you have, what is the UX you want to build? That’s interesting, because probably five, no, let’s say 10 years ago, we were providing default interfaces out of the box with the product, with three topics to build your portal. And you could just brand that, put your colors, logo, tweak it a bit, and everybody was happy with that. And then we’ve seen a big evolution because now for many companies, marketing everywhere to say on UX, you have now UX director of VP of user experience that were not existing five years ago, 10 years ago. See what I mean, everybody was working is on swim lane. The techdoc department was in charge of writing the content and probably generating the PDFs and then setting up a doc portal. But many companies have realized that this tech doc portal is instrumental to the performance of the company. And now it says, “Oh, we need to have a look at that.” So it becomes a shared place. See, you’ve seen that I guess in your project.

SO: Yeah. Yeah.

FL: Five years ago, 10 years ago, the only people you had to work with and educate and discuss with were probably the tech dog team. And now you’ve got marketing and you’ve got customer support, and you’ve got customer experience people. And because they’ve realized the value there is in this content, but as well as how important it is to design the writer’s experience that fits with the other touch points of the company to create a seamless journey when you go from the corporate website to the documentation website to the help desk tool to the LMS. And you need some consistency around that, not only in terms of just branding colors and logos, but you go beyond that. And we see this as a new place where people struggle a bit. Our customers struggle is what do we want? In fact, they know that marketing says we need something that is more modern, more like this, more like that. But we start opening the discussion, what is it really that you want? Some companies are very mature, they got the Figma mockups and they come to us, “This is what we need to implement. We’ve spent two years with UX designer crafting the UX of our portal.” And some come and say, “Oh my God, you’re right. We don’t know what you need. Give us a default, something to start with and we’ll see.”

SO: Well, you’ll appreciate this. I had a call not too long ago with a very, very, very, very large company, very large. And they said, “We need a front end for our content, this tech content that needs to go out into the world, we need a design for it.” And because it’s a very large company, I said, “Great, where’s your UX team? And do you have a design system?” Because, I mean presumably they do. And the person I was talking to said, “I don’t know. I don’t think so.” And so I consulted the almighty search engine and discovered that not only did this particular company have a design system, they had something that is publicly available, that is their design system that you can go get all the pieces and parts and all the logos and all the behaviors and everything. It is all out there in the world. And yet, the people that work at this organization and in their defense, there are many, many tens of thousands of them did not know that this thing existed. And so all of their requirements in terms of what they had to do for their portal design were right out there in the world accessible to me.

FL: They didn’t even know about it.

SO: And they had no idea that it existed. And so we had to be the ones to make that connection and say, okay, we have to talk to the people or at least download all these assets and then figure out what to do with them and then make sure that we’re following the rules and all the rest of it. So to your point, the enterprise issues, and we also run out into this with metadata and taxonomy, that that is typically an enterprise problem, not a departmental problem. And actually making those connections across the departments for the first time is a task that very often falls to us as the consultants on the outside who are asking, “Do you have a taxonomy project? Do you have design systems? Do you have these enterprise assets that we need to align with and be consistent with?” And they’re not ready for that question, because it was until recently, put a pile of PDFs somewhere.

FL: That’s just a known and you don’t know what you don’t know. And when they start moving up to more capable tools, they discover that it comes with more capabilities, but they have to make choices, they have to invest in metadata, UX design and all that. And it’s probably some of those companies are not ready yet. I mean, they didn’t foresee that coming. And that’s where the project lag a bit in terms of complexity as well, because they realize that it’s not just buying the tool as well, making the investment on their content, their UX strategy, their design system and all that. That may be missing in some cases.

SO: And I think that probably saying it’s not just about buying the tool is really a good summary of this whole situation. Because we started with you’re really going to need metadata, and if you don’t have metadata, that’s a huge problem. And we’ve landed on, and there are all these other connections and pieces and parts that you have to think about. So Fabrice, thank you very much. This was a great discussion and I appreciate all your information and we will wrap this up there. Are there any parting thoughts that you want to leave people with?

FL: It was an absolute pleasure having this discussion with you, Sarah. I think it could have last another hour easily, so we need to stop somewhere. Maybe we’ll have another opportunities to keep on chatting about some of the subjects.

SO: Yep. Sounds good. And thank you again, and we will see you soon. 

Christine Cuellar: Thank you for listening to Content Operations by Scriptorium. For more information, visit scriptorium.com or check the show notes for relevant links.