Transcript of Delivering technical documentation via an API

Below is a transcript of our podcast episode Delivering technical documentation via an API:

Welcome to the Cherryleaf podcast. In this episode, we’re going to look at documentation APIs.

In a previous podcast we looked at trends in technical communication, and we were debating whether to include documentation via an API as one of the future trends for 2018 and beyond.

We thought we’d explore it in a standalone episode, which is the episode that we have here. So we’re going to look at: What is a documentation API? Why you might want to use one some examples, and some of the tools and platforms that are currently available.

One of the challenges with this topic is there are actually a lot of content APIs around, and a lot of the information that’s transferred is content.

  • You have APIs for providing weather information: that the weather in a particular city is so many degrees, and it’s windy, or it’s cloudy.
  • And we have APIs for adverts. So there’s an API for Bing, where you can use that to get different adverts embedded onto a particular sites.
  • And there’s also APIs for platforms provided by organizations like the BBC and the Guardian,

And often this information is organized in pairs of data; a key and then a value for that data, stored in a text file, usually in a format called JSON. And in many ways this is what you might have previously called just “data”.

So we need to try and differentiate what we mean by documentation from that type of information. Differentiate the type of information and content that technical communicators provide. The type of information that you would see more in a instructional set of guides than in a weather report.

The definition that we’re going to use, or the focus that we’re going to take, is on the type of information that you might see in a user guide or an online help file, and that essentially is instructional, task based information, or reference, look up, information, and particular information that might be more than just a city and the temperature. So content that might need to be presented in tables, for example.

And again another challenge with this topic that can make it rather confusing is, of course, a lot of this can also be delivered if you wanted to automate it. And that’s one of the reasons why you’d use an API. You could automate it by using a chatbot, where that would be serving up the information, and potentially providing that information using voice rather than text, and we’ve done a podcast on chatbots previously; so we’ll leave that for this episode. Have a listen to our podcast on chatbots. We’ve also got a primer guide to chatbots as well, so do have a look at that.

So why would we want to use an API to deliver documentation? We can use a content management system today to deliver information. It will enable us to deliver it as web pages, as self-contained Help files, as PDFs, and a content management system can personalize content. It can narrow and filter the information to suit different users, individual users.

So what would an API give us over and above what we can use today with the content management system? To answer that question, a good starting point is to go back to what an API is. And in its simplest terms, an API, an application programming interface, is a way that two machines, or two pieces of software, can talk to each other automatically.

The use case or the situation where we might want to use an API is where we want our content to be used by another system. So that may be where there is a system that has a workflow and there is a need to provide the end-users with information and make decisions. A performance support role for the content. A number of examples of this might be that you have Salesforce.com as your platform for supporting end-users, for marketing and selling in your company, and you may have customized and adapted Salesforce to your particular situation; included the different products that you offer, the different prices, different types of customers, and so on, and you might want to provide specific information to your Support people or to your salespeople that can have on the page, as they’re going through a support call or a sales call, information from the instructional content, from the reference content, from what might have been in the past called a user guide.

Another example is one that was mentioned on another podcast, Scriptorium’s podcast, a case study on how they have worked with the American Joint Committee on Cancer. The AJCC provides a manual on cancer staging, related to whether somebody has Stage 1, Stage 2, Stage 3, Stage 4 cancer, and that information is used by providers of medical systems to help doctors make decisions. And the AJCC has converted that content into being an API, so that these providers of healthcare management systems can include this official content on what is defined by different stages and how you would make decisions to classify a patient. Having one of those, they made that information available as an API, so that the software providers can include it in there. And we will include a link to that podcast, that Scriptorium podcast, in the show notes.

Another situation may be that you’re using a platform like SAP, and that you have customized the SAP platform for your particular situation. So that it’s organized by the number of offices, or the number of factories that you have, or again the number of products. And to help somebody that’s perhaps defining the levels of depreciation in different countries for depreciating assets, or making decisions over a stock rotation, there is reference information in your system. Legal information they might need to be aware of company policies. Do’s and don’ts that that could be embedded into the SAP screens from an API.

So a common theme may well be that you want your information embedded into other applications. You might want information that describes different parameters as to when and where you’d make a decision. Issues around safety; it might be rail safety, it might be aircraft safety. Making sure staff conform to certain rules. Those are some scenarios where API delivered content might be useful. How can we use an API to deliver our content? Well, one approach is to use one of the platforms that’s used for content. A platform, for example, like a content API platform. If we’re using voice, we could look at the APIs that Amazon provides. And one of the ways in which Alexa is being used, is to provide instructions and information on recipes, or instructions on how to use a product.

But again we’re we’re veering into chatbots. Let’s move away from that.

Another platform might be the GatherContent API, which will interact with a number of systems. In particular, platforms that provide help desk type information. The team that have developed the ReadTheDoc’s platform for API developer documentation has a platform called EmbedAPI. And this enables you to embed content from your content if it’s on the Readthedocs website. And enables you to embed that content that’s hosted there into other platforms. And this is a way of making sure that’s API related documentation, which is often the type of content that resides on Readthedocs, is always up to date always there in these other applications.

What about platforms within the field of technical documentation more focused on user based instructional content? What do we have in that way?

Well, there are a few, but but not many at this stage. There is Paligo, and Paligo is a content management system in the cloud, and is based on DocBook. The content is structured in that way, and it’s possible to use the Paligo platform and its API, to have your content integrated with some of the most common help desk portals and with Salesforce.com. Mindtouch, which is a popular platform browser-based platform, again for providing help desk information and also user instructional information, that also comes with an API. And you can use the Mindtouch API to extend your product documentation so it’s included throughout the customer journey.

If you’re using Markdown to write your content, your choices are going to be more limited. Because there is this need to have this semantic wrapper around this content, this metadata, to say what information is there is. One platform that can do that, one called Forestry. The API for that is not publicly available, but there is a private API that’s available on request. So that may be worth considering if you want to write only using Markdown.

So that’s a very brief overview. We have these overlaps between other API systems that provide other types of content. We have overlaps with chatbots and voice based information. And it may be that documentation is API won’t really become distinct from those. But there may be, in the future, a need to distinguish like we have between those other forms, and provide our content via an API into other systems. It really depends if your content needs to be used by another system, if you need that situation of one machine talking to another.

We’d welcome your thoughts and your experiences on using documentation based APIs, and other content APIs, where they’ve been applied to technical documentation. So do share your thoughts. We have interviewed people in the past on the podcast, so there may be an opportunity to record some of your thoughts.

If you’d like to contact us, you can email us: info at cheryleaf.com.

If you want to see these show notes, with links to some of the topics that we’ve talked about, some of the products, you’ll find those at cherryleaf.podbean.com.

And if you’d like to know more about Cherryleaf, and our documentation services, the training courses, the recruitment side, and the project side, then you’ll find that on our website Cherryleaf.com.

So this is the last podcast episode for 2017. We wish you a happy New Year, and we’ll be talking to you again by podcast, and through other means, in 2018. Thanks for listening.

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 

Is your documentation AI and chatbot ready?

It seems likely Artificial Intelligence (AI) and chatbots will play a key role in helping users, in the future. Amazon, Facebook, Google, IBM and Microsoft, as well as smaller technology companies, are all developing platforms for simulating an intelligent conversation with human users.

This raises a question:

Will chatbots mean we’ll write a how-to task in the chatbot app, again in the Help, and again in the tutorials?

It’s not very productive to write the same content three times, in three different places. It makes even less sense if you need to update the content on a regular basis, or translate that repeated content into multiple languages.

One solution is to store different types of data in its native format until it is needed, and then serve that information to the AI or chatbot system. You write the content once, and “serve” it to the chatbot, the online Help, the tutorial, and so on.

This requires that content to map accurately to the chatbot’s information structure  –  the use cases; the user’s intent, role and sentiment; and the entity (i.e. the problem and product) that relates to the user’s question.

As a technical communicator, this means you can start by making sure your content is in a structured format. For example, it has metadata (and uses a taxonomy) that will help the AI system or chatbot know which piece of information to serve the user. This includes common metadata such as product, symptom, problem, version, user role and operating system. It may also include new metadata relating to responses based on the user’s current mood (“sentiment”),  and the context in which the question is made to the chatbot.

This approach makes it more likely that your documentation will AI and chatbot ready, at the time when it’s needed.


Tryo Labs has published a useful summary of the different approaches and technologies you can use for creating chatbots. See: Building a Chatbot: analysis & limitations of modern platforms.

See also:

Towards content lakes

Cherryleaf’s technical writing services

The ROI of user documentation: you could break even if you avoided 3 support calls per week 

We’ve been experimenting with another spreadsheet for calculating the Return on Investment (ROI) on User Assistance.

We wanted to look at: how many support calls an organisation needs to have resolved by users reading the Help content instead of calling Support, before it starts to see a return on the cost of creating the Help.

Using typical costs for an average sized software application, the figures suggest you could break even if you avoided 3 support calls per week.

Chart showing the ROI of user documentation

Contact us if you’d like a copy of the spreadsheet, so you can make your own calculations.

You also find a related Support call cost reduction spreadsheet on the main Cherryleaf website.

Just in time documentation – some pros and cons

Bri Hillmer has written two articles on Just-In-Time documentation (https://www.knowledgeowl.com/home/just-in-time-documentation-a-practical-guide and  https://www.knowledgeowl.com/home/just-in-time-documentation). This is an alternative to what she called Just-In-Case documentation. The idea is you write topics that answer real world queries users ask the Support team. This rather than writing a comprehensive user guide, just in case someone wants to know about topic X or topic Y.

This approach focuses on user needs, answering the questions user have. It also provides users with worked examples, each one aimed at solving a particular scenario. In a complex environment, users may need to combine a set of functions or features in order to solve their problems. Sometimes a topic-based approach doesn’t provide that type of information. Just-In-Time documentation could help users understand individual features and how to combine them. And it may be that 80% of the queries relate to 20% of the product’s functionality.

However, this approach does require the technical authoring team to be able to turn around these articles quickly enough. It’s likely that similar topics will come up a regular basis, so there also needs to be a way to reuse some passages of text, in order for the Technical Authors to work in an efficient manner. Also, there might be a legal requirement to provide a comprehensive guide.

Is this an approach you have used? If so, please share your experiences, using the comments box below.

Is documentation a dirty word?

Daryl Colquhoun has written an article in tcWorld about the international standard ISO/IEC/IEEE 26512. He explained the standard is going to be revised and renamed: from “Systems and software engineering – Requirements for managers of user documentation” to “Systems and software engineering – Requirements for managers of information for users”.

The reason for this, he states, is because, in many parts of the world, the term “documentation” is associated with a printed manual only. The neutral term “information for users” refers to all types of content: Online help, audio, video, and Augmented Reality.

The problem with “information” is it can mean many things. Information for users could mean the weather forecast. We may well need to move away from the word documentation, but I’m not sure we’ve yet come up with a suitable alternative.

 

Documentation as an API – the docsbot

In a recent presentation, Twilio’s Jarod Reyes and Andrew Baker mentioned their plans to make Twilio’s developer documentation available as an API. They plan to start with an API for code samples, stored in a github repository.

Making documentation available as an API means means users can create or remix their own versions of the documentation. For example, they could embed Twilio’s code samples. It also means those embedded code samples will be updated whenever Twilio updates those snippets of code.

Jarod and Andrew suggested something new that we’d not heard before – the API can also be used to create a “bot” in Slack, to help new users. The Twilio bot, currently in development, is called docsbot. If users type “lookup py” in the Slack command line, docsbot will reply with a message containing a code sample for the Python development environment.

Twilio's Slack docsbot

It relies on users knowing the relevant Slack commands, but it’s an interesting way of providing users with documentation when and where they need it.

See also: Advanced technical writing & new trends in technical communication training course 20th October

Documentation as Code

Tom Johnson has written two interesting posts on his blog on the “Documentation as Code” concept:

Documentation as Code can be interpreted in a few ways. Tom describes it as being able to store the documentation with the code:

From a technical angle, Etter argues that one should embrace lightweight markup languages, use static site generators, and store content in version control repositories with engineering code.

An other interpretation associated with this is that documentation should be seen as a design problem; it should be seen as part of the product (and seen in a similar way to the software code), rather than an add-on. If the documentation is stored with the code, it can mean that the requirements for documentation can be more closely linked to the code. When a requirement for a new feature is raised, so can a requirement for the related documentation. It can also mean that content that’s embedded in the UI, presented as on-boarding screens or presented as online Help, can be considered as different potential solutions to each user need.

Documentation as Code is a topic we touch on in our advanced technical writing training course. It’s an approach that we may see growing in popularity.