Here is a pdf document we’ve created – a primer on chatbots in technical communication. It is based on a post we’ll be publishing on tekom’s Intelligent Information blog:
It seems likely artificial intelligence (AI) and AI-driven chatbots will play a key role in helping users in the future. So what does this mean for technical communicators and for User Assistance?
This podcast is based on an article we’ll be posting to tekom’s Intelligent Information blog. The article is currently out for review, and it should be published in the next two weeks.
The podcast has three chapters, or parts:
- What are chatbots?
- Making a chatbot
- What does this mean for technical communicators and for User Assistance?
See the Cherryleaf Podcast for podcasts on similar topics.
Reviews of two presentations at the UAEurope 17 conference.
Kristof Van Tomme (Pronovix). Software support and Artificial Intelligence.
Pawel Kowaluk (3di Poland). Knowledge Feed: Make your Online Help More Like Facebook
Interspersed with interviews from at the UAEurope 2017 conference:
Dr Tony Self. HyperWrite
Willam van Weelden. Adobe
Mike Hamilton. MadCap Software.
This month, Microsoft has added Microsoft Teams to Office 365. It’s a instant messaging collaboration tool, similar to Slack. Teams contains the T-Bot, which provides help and assistance to users.
Users can watch videos:
They can read online Help:
They can read an FAQ:
They can ask the T-Bot a question and receive an answer. The T-Bot initially provides the same answers as the FAQ. If it doesn’t know the answer, it will suggest some articles from the Help:
Do you think this way of helping users is good? Share your thoughts, using the comments form below.
The Government Digital Service has been working on establishing a standard design for its technical (i.e. developer) documentation. This content is for systems architects, developers and users of the GOV.UK platforms and APIs.
You can see an example at: GOV.UK Platform as a Service
Cherryleaf was given a preview of the new design a few months ago, when we ran an API documentation training course at GDS. We made a couple of suggestions, which look like they’ve been included in the final design.
The documentation has these main sections:
- Overview. This includes why you would use it, and the pricing plan.
- Getting started. This includes prerequisites and limitations.
- How to deploy
- Managing apps
- Managing people
Elsewhere on the website is information relating to support, the product features, and the product roadmap.
As with other GOV.UK content, the team carried out research into what developers wanted, and they carried out usability testing. I understand the researchers discovered developers preferred content to be on a long, single page, and that they would be working in a two screen environment. Using long pages enables users to search and navigate with the keyboard, rather than the mouse. GDS also looked at other developer websites, such as WorldPay and Stripe, for best practice.
GDS is highly regarded in the technical communications community for its excellent work on the GOV.UK website. This means it is likely other organisations will copy GDS’s design for their own developer documentation.
Discover the advanced new writing styles emerging in technical communication by attending Cherryleaf’s popular training course. Don’t get left behind: past clients include technical communicators from Citrix, GE, IBM UK, Lloyds Banking Group, Sage plc, Schlumberger, Tekla and Visa International.
The next public classroom course will be held on Wednesday 29th March 2017 at our training centre in central London (WC2R).
For overseas clients, we will hold a class live over the web (on 22nd and 23rd March), if there sufficient interest.
Advanced technical writing & new trends in technical communication training
Adrian Warman has started a series of posts on his blog about the future of technical writing. In today’s post, Farewell to the technical writer, he argues the traditional role of a technical writer is no more:
“Marketing and sales specialists, designers, developers, developer advocates, support and operational people – indeed almost anyone associated with the overall creation and delivery of a service or product – are all perfectly capable of creating content that might not be perfect, but is good enough.”
There are many good points in Adrian’s post, and we look forward to the rest in this series. However, there is a counter argument to be made:
- Why do organisations still buy Flare or RoboHelp, when they could use Markdown? We would suggest it’s because projects often become more complex over time. You start to need support more than one version of a product (the professional and the standard version, for example); you need to support more than release version; you end up developing bespoke versions for your biggest customer; you need to localise the content for international markets. As the products become more complex, so can the documentation, and it can be a struggle to manage this complexity in an efficient way with Markdown.
- While the writing can be straightforward, the publishing process for Markdown content can be complex.
- If people have two responsibilities (code and write user content), one of those tasks may be not given the time and attention it needs. It might be better to have one person focusing on a single task.
- Only half the time in a documentation project is actually spent on writing. There’s a lot of planning and research that should go on before that into what users need from the content. Programmers may struggle with that aspect (although UX developers less so).
- A Technical Author might be cheaper than a programmer or a UX developer. If you can free their time, by delegating the writing activity to a Technical Author, you might enable them to focus on more productive activities.
The traditional role of a Technical Author is certainly changing, and there is likely to be a more collaborative authoring process. However, the Technical Author can still add value.