Docs Like Code – Interview with Anne Gentle

Here is early access to the latest episode on the Cherryleaf Podcast – Interview with Anne Gentle, author of Docs Like Code and Product Manager at Cisco. It will be published on the podcast channel on Monday.

Topics covered:

  • What is docs as code?
  • Why do it?
  • When might this approach might be applicable?
  • The limitations
  • Docs like code in development sprints
  • Is it only for developer docs?
  • Do you you need to understand programming?
  • Why did you self publish?
  • The benefits of taking this approach
  • The future developments
  • Automating document builds

Links to topics mentioned:

Subscribe to Cherryleaf’s newsletter

Cherryleaf training course – Advanced technical writing techniques

https://www.docslikecode.com/

Conversation and Community: The Social Web for Documentation

Troy Howard Documentarian, Super Genius at Twitter

http://codewerdz.org/ Repository analytics for code and docs

Matt Fleming on Twitter

Docs Like Code GitHub repository

Jekyll

https://docs.openstack.org/pike/

WADL RAML OpenAPI

https://bitbucket.org/

http://docs.metacloud.com/

Liquid scripting

YAML

PrinceXML

Lunr Search Engine

Solr (Search Engine)

Why we use a ‘docs as code’ approach for technical documentation Jen Lambourne, GDS, GOV.UK

The Definition of Done

Learn Python the Hard Way

AsciiDoc

ReST

GitHub Flavoured Markdown spec

XML Press

REST API

Building Docs Like Code – article

Travis CI 

Jenkins

Circle CI

Webhooks

Bash scripts

An Introduction to Static Site Generators

GitHub Pages 

AI and chatbots in technical communication – A primer

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:

  1. What are chatbots?
  2. Making a chatbot
  3. What does this mean for technical communicators and for User Assistance?

See the Cherryleaf Podcast for podcasts on similar topics.

Help through AI, Help like Facebook

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.

The T-Bot: A new Help model from Microsoft

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.

T-Bot main screen

Users can watch videos:

T-Bot Help videos

They can read online Help:

T-Bot online Help

They can read an FAQ:

T-Bot 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:

:T-Bot Question and Answer

Do you think this way of helping users is good? Share your thoughts, using the comments form below.

GDS publishes its new design for technical documentation

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

Gov.uk technical documentation

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:

  1. Overview. This includes why you would use it, and the pricing plan.
  2. Getting started. This includes prerequisites and limitations.
  3. How to deploy
  4. Troubleshooting
  5. Managing apps
  6. 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.

 

March dates: Advanced technical writing and new trends in technical communication training course

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.

See:

Advanced technical writing & new trends in technical communication training

 

Farewell?

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:

  1. 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.
  2. While the writing can be straightforward, the publishing process for Markdown content can be complex.
  3. 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.
  4. 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).
  5. 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.