In episode 150 of The Content Strategy Experts Podcast, Alan Pringle and special guest, Patrick Bosek of Heretto talk about choosing a content model, factors to consider, and when you should think about customization.

“There’s a valid use case for almost every approach that’s out there. There’s no way around that. I think what it really starts to come down to is making sure that you’re matching the 18+ months [ahead] to the decision you’re making now.”

— Patrick Bosek

Related links:

Heretto.com
Demystifying content modeling
Is Content as a Service right for you?
LearningDITA — free, self-paced DITA training

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 talk about choosing a content model and the pros and cons of customizing it with Patrick Bosek of Heretto. Hey everybody, I am Alan Pringle, and today we have a special guest. It’s Patrick Bosek of Heretto. How are you, Patrick?

Patrick Bosek: I’m good. How are you, Alan?

AP: Good. Let’s talk a little bit about content models today, and let’s start really at the beginning, choosing one, do you pick a standard? Do you create your own? What do you do?

PB: I guess if you’re looking for my advice, which I suppose you are since I’m on this podcast.

AP: Correct.

PB: It’s obviously use-case specific, everybody goes into the process of creating a content model and the first step they look at is like, “What do we need this thing to do?” Well, not everybody, let me back up. People who make good decisions when choosing a content model start with deciding what they need it to do in the long run. And I think the thing that I’ve seen here over the what? 15 plus years that I’ve been working in this industry, is really that there are organizations which somebody chooses a content model, because they think it’s cool and it works for what they’re doing right now. And then there are organizations that look at the total scope of what they’re going to need to do both in their group and then probably beyond their group for the organization long run. And then they embark on a much more formalized process for choosing a content model.

Very often you’ll see that where you start, how you start is pretty impactful on what you choose. It’s not real common that the very iterative approach, it’s almost an Agile approach in a lot of ways, like, “Oh, this works for this, let’s move it forward and we’ll do it this way, this way, this way.” And it’s very iterative. Does that lead people or land people on structured content? Typically, that lands people on either proprietary tool sets that are built on whatever’s in their proprietary tool set. There’s a lot of wikis out there that have their own set of structure in the background, it could be either text-based or it could be HTML based. MadCap’s got their own proprietary standard. There’s a few other tools that are built on standards which are standards but proprietary.

But I think those are even probably more on the side of things that are intentionally selected. Very rarely do you see an organization that takes this iterative path go into it and then choose something which is structured, because that stuff is typically less available to just put your hands on and just start creating something that you can then spit out a PDF or spit out a website. I think that knowing how it is that you’re going to start and knowing what set of problems and what the time horizon you’re trying to cover are, that’s like getting ready to get ready to choose your standard if choosing your standard is your first step. And I think that knowing where you are there is really critical, how is it that we’re making this choice?

AP: No. And I think you’re right. This is like any kind of business decision, you’ve got to think about what your requirements are and it is not a situation where you were looking at or I would prefer that people not look at the next three to six months. Yes, you may be on fire and have something to do, but you’ve got to be careful and balance things out and think, “Are we going to go with something that’s much narrow and very focused on one use case? Are we going to go a little wider and accommodate things that might be say 18 months, two years down the road?” For example.

PB: Yeah. I think that’s fair. I think the thing I would add to that is that, there’s a valid use case for almost every approach that’s out there. There’s no way around that. I think what it really starts to come down to is making sure that you’re matching the 18 plus months to the decision you’re making. And so I’ll give you a really good example, I think it’s a really good example anyways, so if you’re just writing a README file for a microservice that you’re setting up and it’s going to be maintained with a code and nobody’s really going to be referencing it, who doesn’t actually have their hands on the code, using true structured content for that makes no sense.

AP: It’s overkill. 100%, yes.

PB: Yeah. And it doesn’t really integrate well with the delivery or with the end user. It would be a bad experience all around. That makes a ton of sense to just use what is supported by the repository that you’re putting that into, which is by and large, it’s either GitHub or Bitbucket or the other one, GitLab, so it’s one of those three, but they all support some Markdown. README files, by and large, if you’re choosing something other than Markdown, you should have a really special case. On the other end of the spectrum though, if you’re thinking about, “Okay, this is going to result in a large set of content, which is intertwined and pieces of it and move at different speeds throughout time and different audiences access it in different ways and potentially get different pieces of content based on who they are,” at that point in time, you can’t do that with Markdown without doing a lot of custom stuff.

AP: I was going to, say there’s some people who might tell you that you can do that, but I’m pretty sure you should not. How’s that?

PB: Okay, fair. That’s an important distinction. You shouldn’t do that with Markdown. This is a tangent, but I love tangents. I was looking through the software documentation, I can’t remember which company it was, it might’ve actually been one of the Git providers, and they’re still in Markdown with a lot of their content. But they’ve gone so far with pieces of this to customize it for this platform or this audience or that, they don’t have tags in there, but they have things that are tags in there. I think they’re square brackets with a percent sign or something, and then a name after it, and then an end one too. And I’m like, “These are just tags.”

The thing is, once you get to a certain level of sophistication with effectively having to put metadata in your content to tell your content how to behave in different circumstances or to just expose information to other systems like search systems or AI systems or whatever it may be that isn’t the same information you’re exposing to the end user, you have to do it with tags. There’s no other way to do it, because all tags are as a way of putting information into a document that isn’t rendered directly to the user.

AP: Yes. You’re adding intelligence into your content.

PB: You may not like angle brackets, but if you have this case, you’re going to use some kind of tag at some point. And this actually relates in a funny way, I’ll stop my tangent in a second, to another conversation I had, I promise, to another conversation I had with one of DITA’s founding fathers, or one of the longest standing people on the TC, Eliot Kimber, which you know and I’m sure everybo...