Chatbots are not the future of Technical Communication

And suddenly every tech comm and content strategy conference seems to be about getting your content ready for chatbots. Makes sense if you are a conference organizer. Chatbots are sexy and sex sells, even if the definition of sexy is a grey box with a speaker sitting on the counter.

But chatbots are not the future of technical communication. Here’s why:

Chatbots are stupid

No, I don’t mean that they are a stupid idea. I mean they are actually stupid. As in they are not very bright. As Will Knight writes in Tougher Turing Test Exposes Chatbots’ Stupidity in the MIT Technology Review, current AI does barely better than chance in deciphering the ambiguity in a sentence like: “The city councilmen refused the demonstrators a permit because they feared violence.” (Who feared the violence?) Human do this so easily we rarely even notice that the ambiguity exists. AI’s can’t. read more

One Answer, Many Questions

It is often appealing to think of technical communication as a process of answering user’s questions. The difficulty with this view is that one answer can have many questions. If you answer each of those questions, you would be providing substantially the same answer over and over again.

This is very easy to see on StackOverflow, a question and answer site for programmers. Privileged user of StackOverflow can mark a question as a duplicate of another question. Here’s an example:

A question marked duplicate on StackOverflow.

The question here is “How to check if a variable is a dictionary in python”. This is a question that programmers are going to ask themselves many times. It is a specific instance of a more general question, which is, “how do you check if a variable is of a specific type in Python?” read more

The other thing wrong with the DIKW pyramid

I took a side swipe at the DIKW (Data Information Knowledge Wisdom) pyramid the other day, and included a link to David Weinberger’s excellent debunking of it, which concludes:

The real problem with the DIKW pyramid is that it’s a pyramid. The image that knowledge (much less wisdom) results from applying finer-grained filters at each level, paints the wrong picture. That view is natural to the Information Age which has been all about filtering noise, reducing the flow to what is clean, clear and manageable. Knowledge is more creative, messier, harder won, and far more discontinuous. read more

Taxonomy Won’t Save Us

One of the great hopes of content management is that taxonomy will save us. Developing a consistent and rigorous taxonomy, it is hoped, will remove inconsistencies from how describe and label things, enabling us to find and reuse content much more easily. It is a lovely vision, and it is doomed to failure.

The underlying assumption of this confidence in taxonomy is that differences in terminology are accidental and that if we simply assign clear and well defined meanings to the terms we use, we can all use the same vocabulary and communicate more clearly and with less ambiguity. read more

Reference vs. Learning in a Bottom-up Information Architecture

Do reference and learning require different organization in a bottom-up information architecture? This is another in the series of posts addressing questions from my TC Dojo webinar on Bottom-up Information Architecture.

Q: Is there a difference in looking for a specific information fact (such as the depth of the manacougan crater) versus a search for understanding a larger information set, such as the development and formation of craters in general? Would the latter type of search merit a more hierarchical mini-TOC to navigate through the content? read more

The role of the TOC in a bottom-up information architecture

Is there still a place for a TOC in a bottom-up information architecture? Yes, but its role is different.

This is another in my series following up on the questions asked in my TC Dojo webinar on bottom-up information architecture.

Q: Is the TOC dead then? I’m used to structuring content based on an analysis of user tasks, presenting the product secondarily. That becomes the structure? Where do you put the topics?

A: In a very real sense, it is top-down architecture that has killed the TOC. Bottom-up architecture might actually save it, but in a different form and playing a different role. read more

Bottom-Up Information Architecture Behind the Firewall

This is the second of the questions from my TC Dojo presentation on Information Architecture Bottom Up.

Q: What happens when the information is behind a wall, such as proprietary applications? How is a bottom-up approach better in that type of scenario?

A: The Web is the ultimate bottom-up information architecture. The Web is far far to big and too complex to ever be navigated top down. Yahoo’s top-down directory of the Web, created when the Web was still relatively small, was recently shuttered, after having been irrelevant for many years. read more

You can’t size topics for specific information needs

One of the biggest traps in topic-based writing it the attempt to size topics so that each one meets exactly one user information need. It is tempting to suppose that this is the point of topic-based authoring. If the book is the wrong size because people only use them to look up bits of information, rather than reading them through, isn’t the point of writing topics to make the topic contain just the information the reader needs in the moment (so that they will read it through)? Thus we envision our reader’s needs mapping to our topic sets like this: read more

Subject First; Context Afterward

In communication, they say, context is everything. Actually, “everything” consists of context and subject. Useful information is subject in context. The question is, which comes first: context or subject?

In the book era, the content search pattern was: context first, subject afterwards. That is, suppose you deliver three different products and have released three different versions of the product. Assuming only a single manual per product/version that meant you had 9 manuals, each with a page on feature X. read more

Any technology you use should be “Googlable”

‘Any technology you use should be “Googlable”‘. These are the words of Bill Scott,  VP Engineering, Merchant | Retail | Online Payments at PayPal, as reported by the amazing Sarah Maddox. (I say amazing because Sarah manages to lucidly and intelligently blog just about every conference session she attends. Having just helped cover the LavaCon conference, and not achieving anything like Sarah’s level of productivity or swiftness, I can only marvel at her ability.) read more