When I started Content Rules 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). We worked with Netscape even before they had their IPO.
We worked with router companies, companies that made wireless APs, and we wrote about TCP/IP. I remember working on a product called the System 5000. I was certain that it was named for the 5,000 screws you had to take out and put back to set it up.
And yet, the work itself was straightforward. Here is the device. Open the box. Mount it in the rack. Plug it in. Watch the lights blink. And you’re off to the races. Sure, the configuration could get very interesting – some of the products I wrote about had complex functions that were brand new. But the work itself was somehow simpler.
While we still do a lot of technical writing, course development, editing, and line art, these days I think we are best known for our content strategy services. We work with customers (some of them are ginormous companies) to solve extremely complex content challenges. As technology has advanced, the things we can do with content have become more robust. And there are many choices for creating, storing, managing, publishing, and even sunsetting content.
With all of these choices 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 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.
Common mistakes when moving to structured content
One of the complications I am seeing over and over again is the mis-use of structured content. There are many companies that implemented component-based structured content years ago. But they never quite understood how to set it up or how to fully use it. 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.
Let us help you solve your complex content problems and prepare for AI.
Val is on the Advisory Board for the Technical Communications Program at the University of North Texas. When not working with customers or students, Val can be found sitting behind her sewing machine working on her latest quilt. She also makes a mean hummus.
- How to Make Conferences More Inclusive for the Hard of Hearing Community - December 2, 2024
- Preparing Content for AI: 6 Reasons Why You’re Not Ready - August 29, 2024
- How to Be Inclusive in the Workplace: My Experience as a Hard of Hearing Person - August 12, 2024
