Back to the days when I was working as a technical writer, I remember myself working on two types of user documentation. One type was all kinds of user guides, and the second one was a context-sensitive help.
The context-sensitive help was a subset of the user guides and was supposed to appear whenever the user hit F1. Then depending on the window in which F1 was pressed, a description of what the user could do in that particular window was displayed. Sometimes, picking up the right description wasn’t an easy task because the actions the user should do depend on how the user got to that window, and this is obviously something that we couldn’t know in advance.
We ended up with writing a custom script that tracked the user’s path to the window and sending to the help engine a token that indicated where the user was before. Based on this token, our help engine knew what description should be displayed.
It was in early 2000’s, well before DITA and structured authoring began to gain traction. And of course, it was well before the smartphones era, when your mobile device knows about your search preferences, places you’ve visited, and pictures you saw on the Internet maybe even more than you realize about yourself.
The world has changed since then. Users have changed since then. Now they want to get information that explains how to reach their goals in their particular situation, which can be determined by multiple factors: user profile, current location, product model, previous interactions with the product, and so on. The information they want to get needs to be matched to all these factors.
For content creators, there are several consequences. First, the pieces of information that vary depending on the context need to be explicitly marked up so that they can be automatically retrieved when there is a match.
Second, the information needs to be written in a way that separates content from presentation because depending on the context and user’s preferences, the information might need to be displayed on a user’s tablet, desktop screen, smartphone, website, in a print output, or sent by email.
When these conditions are met (and you need to have your content in a structured format to make this happen), the context-dependent content retrieval and assembly can be automated:
Think about this scenario: a machine on a manufacturing plant needs troubleshooting. The error code along with other important information about the machine’s model, serial number, and configuration is automatically sent to the content server, where the matching engine automatically assembles the troubleshooting procedure that fits this particular problem for this particular machine with this particular configuration. Then based on the complexity of the troubleshooting procedure and maintenance engineer’s preferences, the troubleshooting procedure is dynamically transformed to an interactive flowchart which represents the troubleshooting information visually (by the way, we have a working example).
From this perspective, structured content and content automation can be seen as asset that creates an additional value for content consumers (end users) and thus, helps the company reach their business goals rather than as an internal tool for a technical publication department.
In the next post, I’m going to discuss how structured content can enhance the conversational user interface and chatbots.