Ah the wonderful world of the tech writer. Hello, Paligo. To be honest, Paligo is not a new tool in the industry. Interestingly enough, Paligo was founded in 2015, which is quite amazing considering how it has grown. Over the last year, I’ve been given the opportunity to learn so many new tools.
Most recently, I played around for a few weeks with Gitbook. That was fun. Before that, I worked a bit with readme.io. That wasn’t fun. Readme might have a niche, but complex or even not-complex but large documents is probably not it. So recently, I had another opportunity. This time, Paligo.
Almost immediately, I understood several things about Paligo. First, it’s in a completely different league as compared to most of the tools that I’ve worked with. Paligo is, without doubt, an enterprise solution. It’s robust. Only at the very end of the 6-month contract did I learn that the project that I was working with translated to a 380 page document. In a sense, I was shielded from the size by Paligo’s hierarchical structure.
The potentially vast repository of topics exists – all topics of all projects or books are accessed and available (potentially) to everyone. From this repository, you build publications and pull the topics you need into folders. There you can manage multiple books or help files or any size.
Structured authoring is a topic in and of itself. But to explain it in one sentence. A structured authoring tool such as Paligo (or FrameMaker if you choose to work with structured FM) imposes a structure on the author. For the good and the bad. Word is without structure. You can create any document and structure it as you want – as inconsistently and illogically as you like. Structured authoring enforces more than it forces. So logically, if you create what we call a ToDo statement, what should follow is a numbered list or procedure.
This is what we teach in our technical writing class. And yet, many students forget to put in the ToDo style that should proceed the procedure. Or they create a heading 3 because they like the size even though the immediately preceding heading style was a heading 1. Logically, only another heading 1 or a heading 2 should following. And yet.
Paligo and other structured authoring tools prevent this from happening. I’ve worked with structured authoring before and so this capability didn’t surprise or wow me. What did, was the content re-use options.
Content reuse is like the “holy grail” in technical writing [and let’s just use this definition for holy grail: “a thing that is being earnestly pursued or sought after”]. Many tools promise it, few come close to delivering it. In most cases, content reuse is created by taking the content you want to use again and again, and creating snippets. These snippets are placed in multiple files and can be easily changed with one single correction. That’s great, but it still means you have to know in advance what you want to reuse. Or, you have to think, “wow, I wrote something like this before”. And then you begin to search and hopefully find it. Then you tag it. Then you go back to the place where you wanted to reuse it, insert the snippet and you’ve achieved content reuse.
Paligo’s content reuse is insanely easier. Basically, you use the Content Reuse option and enter a few words. The entire repository is searched and you get the nearest results immediately. You pick the one you want and insert it. And if you want to change things, you do it simply and everywhere.
Here’s an example. Let’s say you are a new tech writer need to update someone else’s document. You start adding new procedures that begin with, “In the Start menu.” And you do this a few times. Until, you realize that the original author clearly preferred, “From the Start menu.”
In any other tool, you’d either have to search or remember where you have to look to correct it. With Paligo, you simply type “In the Start menu” in the Reuse Text section and you’ll see a full listing of where these words are located. Insert that text. Now, you select the option to edit reused text and you change In the Start menu” to “From the Start menu” and all instances will be corrected.
At a recent contract job, I wanted to adhere to the style of the current tech writers in the company. To do this, I often checked how they chose to phrase things. I found this incredibly easy to do in Paligo. With any other help authoring tool, I would have to search for a relevant topic. In Paligo, I simply searched for relevant text and quickly found the phrasing I needed.
More, in Paligo, there are multiple levels of content reuse. For example, you can reuse content from one publication to another, and you can quickly find an entire paragraph and insert it. And that paragraph can now be easily changed in one action, at any time. You can also, after the fact, select a large amount of text and decide to enable it to be reused. And, it has snippets and variables as well to allow even more granular content reuse.
In short, Gitbook was fun. But, Paligo was cool. Oh, I had my issues with Paligo. I have yet to figure out why sometimes the search finds what I wanted and sometimes it doesn’t. It’s a reminder that there is no perfect tool and that often a problem means the user needs to spend more time learning the application. Challenge accepted, when it comes to Paligo.
What I did learn was that Paligo is in its own league as a cloud-based solution. Given its pricing, it isn’t really intended as a small-company solution. On the other hand, if your company is growing fast, Paligo might be the right option because it scales easily. Interestingly enough, Paligo at only 6 or so years in the market has come a shockingly long way. It’s one tool I hope to see again in the future.
To learn more about Paligo, check out their site here.