The Sooner You Move to Structure, the Better

When I started Content Rules, Inc. way back in 1994, we were a writing company. We wrote technical documentation, created training courses, did a lot of editing, and created a lot of line art. We wrote about complex products. Being based in Silicon Valley, we were part of the birth of the Internet (alas, I did not invent it).??

The work itself was straightforward, even if the products were not. The tools and environment we used to create, store, manage, and publish content were relatively simple and well-known. To create a user guide (for example), you’d pull up your MS Word or FrameMaker 5.1 template and start typing. When finished, you’d save it to a PDF and off it would go to the printer.?

I get nostalgic when I think back to content creation in the 1990s and early 2000s. It was so quaint and simple writing each book individually. Copying and pasting to make another version was also straightforward. And we did not have the huge volume of content that we have today.??

Today, using simple tools and processes do not scale. And we need scale. Most of my customers have enormous corpora that quickly become unwieldy as they grow and never shrink.??

With more content to manage comes a great deal of complexity. When I look at the types of problems we are solving these days, my head spins. Lately, I find myself leaning over to Max Swisher saying, “Why is everything so complicated?” Since he didn’t work for the company back in 1994, he has no idea what I’m talking about. This is a good thing.???

The most common mistake when moving to structured content??

Most of my customers have moved from using monolithic content tools, such as MS Word, to structured content tools, such as DITA/XML. Structured content should simplify some of the complexities of huge corpora. In part, that is what they are designed to do. However, structured content is not without its complications and mistakes.??

The most common mistake I see over and over again is the misuse of structured content, even for companies that implemented component-based structured content years ago. The reason is that they never quite understood how to set up their information architecture or how to fully use the DITA/XML tools in front of them. They never changed the way they conceptualize content.???

These folks still think about content from a document paradigm. “Books” are written as monoliths, even though they are using structure to create and store the information. They have 15- and 20-page topics that go on and on, just like a chapter of a book. The content is neither nimble nor reusable. It is simply a really big blob component.???

When people deploy new structured content tools without changing how they think about and write content, they completely miss the point of moving to structure to begin with. Ultimately and inevitably, they complain that the tool isn’t doing what it promised to do. Somehow, they were duped. The new tools cost a lot of money and only made their jobs more difficult. Promises are left unfulfilled.??

The structured content process??

When we work with a customer in this position, our job usually gets complicated very quickly. There are so many tasks that must be done to set things straight. Here are just a few:??

• Create a new information architecture??

• Develop a suite of component models???

• Decide how granular to make the components??

• Figure out what type of reuse to use in each situation??

• Create a taxonomy??

• Modify the folder structure??

• Create metadata??

And so on. ??

Once we have set up the infrastructure, we need to transform the content itself. Transforming content is no easy feat. It is way more complex than converting the files from .docx to .dita. In fact, only converting the file type is what usually gets the customer into this position to begin with. If all we do is change the file type, and we don’t change the files, we have accomplished very little and we end up with 15- and 20-page monolithic blob components.???

Content transformation is where the content rubber hits the road. Where we apply the information architecture, reuse strategy, taxonomy, metadata, and more to the content. Each piece of content needs to be evaluated and structured appropriately.???        

Deduplicating content can be another big task. First, we need to locate all the places where content is repeated. Most often, the versions of the repeated content are not exactly the same, which can make locating all the duplicates tricky. Then we have to read the context for each of the versions. Finally, we have to come up with one single version that can be used in all of the contexts.???

It’s a good thing the benefits of using structured content far outweigh the complexity of making it happen. Structured content is the best way to create, store, manage, and publish content. I know of no better way. Structure? makes it possible to create all sorts of outputs from a single source of truth. It makes changing the content much easier since you only have one place to make the change. It makes translation faster, cheaper, and easier, too.???

And nowadays, perhaps the most important benefit of all this hard work is that it prepares your content to be ingested by artificial intelligence. Structured content, with all of its complications, makes the best training content for AI. All of the work that goes into structuring the content, including deduping and curating, benefits people and machines in the long run.? And the sooner you move to structure, the better. ??