Q&A from Webinar on Modelling Microcontent for Chatbots and AI with Steve Manning
On December 12, 2017, Steve Manning, VP of Consulting Services at Precision Content discussed the growing popularity in chatbot, voice-enabled interfaces, and AI and how these new technologies will change the way we approach content. Forbes reports that by 2020, half of all searches will be voice searches and chatbots will power 85% of all customer service interactions.
According to Steve, we’re moving from a broadcast style of communication – publish and hope for the best – to a more conversational style of communication. This new approach imposes new demands on the content models you need to create if you want to exploit these technologies.
If you want to leverage these new technologies, you’ll need change the way we structure content. You’ll need to be more granular in your models. You’ll need to implement Microcontent.
Q&A with Steve Manning
Q: Are there times when using machine learning instead of chatbots is appropriate in documentation content? If so, when?
A: They are two different things. Machine learning is the ability for a computer to learn about content without specific programming. A chatbot is an text-based conversational interface the allows a user to “communicate” with software. Chatbots can have built-in machine learning capabilities as part of their programming. That is how they “learn” which answers are probably the best for specific questions.
Q: Can we use Microcontent for Online Help too?
A: Absolutely. We look at the blocks of content as a single fact or answer. That maps very well to the way that people use online help, where they are typically looking for very specific information. E.g., “How do I create a file?” or “What is the date format?”
Q: In the example “category table” you also had info about how to improve. Does a Reference Topic like “category table” need a task type of content too?
A: No, not always. There will always be some sorts of information for which you can provide “facts” in a reference topic and then be able to rely on the user’s own knowledge to use it as necessary. For example, you can present a reference topic detailing disk space requirements for a software product, but you probably don’t need a task topic telling them how to check available disk space. It will depend on what your user needs to know and what you can safely assume they already know.
Q: Sounds like as a start we should add more sections inside a DITA document?
A: Sections can work with the appropriate metadata. If you are planning or think you might need to feed your content to a chatbot, you will absolutely need smaller blocks of content. But there are other benefits as well. Breaking topics into smaller blocks and adding headings to those blocks makes the content much more scannable for users.
Q: If I want to move to this level from unstructured content, what is the course of action suggested?
A: You need to start by looking at your overall goals and develop an content strategy. Use that strategy to then develop content models that will allow you to capture the content that you need in the structures that you need them. That is ultimately the key: having a set of content models that will guide authors to create content while ensuring that users (whether human or machine) will get what they need.
Q: It’s likely that Industry 4.0 and thus Information 4.0 is going to need content broken into smaller blocks as well. Do you think the microcontent approach you’ve outlined will work for other delivery channels. Or will each one need a different approach?
A: Absolutely. Information 4.0 suggests maximum flexibility in content. We’ve seen that big chunks of content, even when limited to topic size, are still too big for many of the consuming interfaces. Chatbots, IoT devices, and all the other content consumers can require information in different sized packages. It is easier to assemble discrete blocks into a larger deliverable than it is to try and break an unstructure chunk into smaller pieces. Microcontent supports flexibie delivery in a way that straight, topic-base DITA can’t.
Q: In your example of category table (“from topics to chat” slide), you use sections. Why are each of those sections not their own topic? For example, why not an individual topic called “Example of a category table”? Do sections give you an advantage over separating or breaking down topics further?
A: You have to balance the authoring needs against publishing requirements when coming up with your content architecture. We prefer and recommend using topic as the smallest “unit of work.” That means a topic is the smallest chunk of content the we will put into workflow. Trying to manage all the blocks if they were managed as separate topics can become unworkable quickly.