Paligo - Information types. An interview with Anders Svensson

In this post, I discuss the idea of information typing with Anders Svensson, CEO of Paligo. Before his work on Paligo, Anders was a DITA consultant for around 10 years, so he knows about information typing from inside and outside DITA fandom.

What are information types?

Before I get into the interview, I want to quickly explain what information types are.

Information types, as the name suggests, are a way of categorising your content according to its purpose. They give meaningful structure to your content.

You may have heard of the XML standard, DITA (Darwin Informational Typing Architecture).  The main three information types in DITA are concepts, tasks, and references. So each piece of content you create has to be in a concept, task, or reference structure. This modular approach means the different concepts, tasks, and references can be used in many different outputs, as required.

Many technical writers, and some content designers, use information typing and it is good practice. But it is not exclusive to DITA.

Now, on with the interview.

Why did you choose to avoid DITA with Paligo?

ANDERS: The choice of not using DITA was a very conscious one, and its information types were one of the reasons for that."

DITA has taken the path of strict data typing. Meaning that you have to choose, before even creating a topic, whether it should be a task, concept, or reference (or any of the other types that might be available in a customisation). This, in my experience, caused writers a lot of headaches.

CRAIG: What sort of headaches are we talking about?

ANDERS: With information typing, the problems are mostly to do with classifying the content consistently. Because while information typing is a good concept, it's wrong to think that all content fits neatly into those three categories. In reality, content doesn't work like that. The topic types in DITA are very restrictive. Should you ever have something that doesn't fit neatly, then the content model won't even allow you to add anything else in that topic.

CRAIG: There's always something that doesn't fit right, isn't there? So in those situations, I guess it comes down to the author's interpretation.

ANDERS: Yes and it causes confusion.  One writer will choose to use reference topics to write technical data, for instance, while another one will choose concept topics. So you'll often have a mishmash of different topic types (and elements) for no reason.

How does Paligo do it differently?

ANDERS: Paligo takes another approach, which is one of the reasons we chose DocBook to base it on, even though we turned it into a topic-based model. Because in this content model, instead of forcing the user to select topic types before even creating it, the content model includes what you need to create such information-typed content. But this is not enforced on the topic level. A topic is a topic in Paligo.

CRAIG: So the structure comes from the elements instead?

ANDERS: Yes, we have an element content model, where you have elements to create anything you need. So if you want to create a "task" (instruction/procedure), for instance, you use the "procedure" element to write a list of steps, not a regular ordered list. But you do it in a regular topic.

CRAIG: That's caught me out a few times, actually, when I've been working in a different tool and come back to Paligo.

You could also add your own structure by using taxonomies, right?

ANDERS: It would often not be necessary, but could be a complement in some cases. E.g if you re ally had some "tasks" that have no procedure in them (yes, they exist), but you would still need to be able to identify them easily, for organizational purposes, or for processing tasks a certain way. All that could be done. In DITA, you wouldn't even be able to create that task without a procedure (called a "steps" element in DITA). It's not allowed.

So that was why you created Paligo? To offer more flexibility.

ANDERS: Yes, this greater flexibility, while still having an element model that allows specific semantic elements to be used for the proper context, is what a lot of our customers appreciate. Especially the ones coming from DITA. They are usually the ones that complain most about DITA's unnecessary complexity.

CRAIG: I get it. In Paligo,  I don't feel like I'm having to spend a lot of time thinking about structure. Not until it comes to deciding where to chunk in the publication, anyway. But it's good that the structure is there and you can add to it with taxonomies. That's a good idea for a blog post, actually - that's going to be my next one.  

Thanks Anders.