I would be amiss if I were to begin without defining the word content. That’s because it gives both a purpose and a premise to the topic: being content is feeling satisfied with your possessions or situations. But why this play of words in the title, you may ask. Here is why I rant…
Let us go back in time. Not far back into the world of typewriters and hand-written manuals. A couple of decades ago: when the concept of single-sourcing originated. I hadn’t joined the technical writing workforce then. Back then, the requirements were simple: get a single-sourcing tool to create everything from within one source. Then, use that source to generate the content for all formats. A lot has changed since. Yet the idea is to have a single repository generate the content. Just that we have complicated the process of creating and managing that content.
When I first single-sourced my product’s contents, I felt the need of creating a central repository for storing and generating the content—the likes of PDFs and CHMs. With that was born my organization’s server where resided the content. But, my requirements didn’t stop at that. I continued to remodel (or so I thought) my work processes to redefine the way I maintained that content. Then came XML, which helped me to tool-proof the product’s documentation.
Who knows, someday I may even put my head into Application Programming Interface (API), Internet of Things (IoT), and others. Did you notice how the story is becoming more about the tools of the trade than about the traded content? Sooner or later it will be about some other “hot” technology. As I continue to choose a (better) combination of tools and methodologies, I continue to steer farther away from the focus on the content. This could be your story, too.
User Requirements are Progressive and Cyclical
A side note: a seamless user experience is easier to put on to paper than to put into practice. Agreed. Also, agreed that these days we have tools that we can use to instantly connect with our users. So, we can know which sections of our documentation get the most views. Or, which ones are the most or the least helpful.
From where I look, tools and methodologies originated to save our time and effort. But now, it looks like we have lost ourselves in managing them rather than the content. Let us not focus only on creating a content-management ecosystem. Instead, let us create a problem-solving ecosystem. Let us not forget that the users’ requirements are progressive and cyclical: the target for usability changes frequently.
It all starts with answering “why” and ends with exploring the answers for “what’s next”. Such content that continues to bridge this gap of “why” and “what’s next” is truly satisfying. A tool will only enable us to create quality content. It isn’t an end, but surely a means to an end. Let us solve users’ problems and be content with (the focus on) content.