Increasing website response times

There is a constant pressure for websites to be fast and good looking across all devices. It’s better for users, and Google has a habit of favouring these types of websites in its search results.

We’ve made a few changes to the Cherryleaf website in the last few days that mean the web pages on the main site should load three times faster than before. We tracked down some JavaScript and images that were slowing down the response time, and we’ve made some other changes behind the scenes.

We’ve also added support for AMP – Accelerated Mobile Pages. Google is encouraging web developers to support AMP, as it provides a straightforward way to create web pages for mobile devices that are smooth and quick to load. If your website doesn’t support AMP at the moment, you might want to look at the AMP Project website , and consider adding this functionality.

Transcript of Trends in Technical Communication in 2018 and beyond

Below is a transcript of our podcast episode Trends in Technical Communication in 2018 and beyond:

Welcome to the Cherryleaf podcast. Towards the end of each year, normally on the Cherryleaf Blog, we make predictions for technical communication in the next months and beyond. Because we’ve been doing the podcast, in many ways we’ve been looking at future trends as the year has gone on – through the podcast itself. So, in this podcast, we’re going to look at some of the current trends. Trends that we’ve predicted in the past that have become, or are starting to become, mainstream. And, also, we’ll look at potential future trends. But this year what we’ll do is, we’ll be a bit more ambitious. We’ll look at some more potential trends that we might see in documentation. These ones may have less certainty than some of the predictions we’ve done in previous years.

Our predictions in 2017 were that we would see Docs Like Code and the growth of storing content in repositories like Git. And we did an interview with Anne Gentle who’s written a book on Docs Like Code on a previous podcast. It’s still growing. We’re seeing more of that going through.

Another prediction that we had was that Markdown would break out from being an authoring format for developers and into the mainstream. Well, we have seen some browser-based content management systems introduced for writing documentation based on Markdown. Again, that prediction that trend has come to pass in many ways. However, in terms of a prediction for the future one thing that we may see is that another lightweight language, an alternative to Markdown, may start to grow. And that is AsciiDoc. And AsciiDoc is a lightweight language markup language like Markdown, but it has a basis upon a semantic XML schema called DocBook. And what that means is, it has extra capabilities that you don’t see with Markdown. It gives you the opportunity to mark-up topics semantically. And by doing that, have the ability to filter content for different audiences.

Another prediction we made last year was that technical communicators will use Lean methods when working in an Agile environment. And it’s still early days. I would say however we are seeing more and more presentations on Lean techniques and other ways of doing Agile authoring at conferences.

Another of the predictions from last year was we’ll will see the greater use of the imperative voice: create…open…close… That’s what we mean by the imperative voice. Compared to: opening…closing… , which is the gerund approach that you’d see traditionally. And certainly, that one has been growing more and more over the year.

And we also predicted that the popular Help authoring tools will be able to generate embedded Help and onboarding screens. Well, this one was a wish last year. I think it’s still a wish for future years.

So those were our predictions back in for 2017 and beyond. Let’s look at what we can predict for 2018 and beyond.

So, let’s start off with Every Page is Page One. This is the idea that you have users who search on Google for an answer. They go from Google to a web page and that’s their starting point. That’s their page one. And you need to write your content on the basis that they’ve not read anything prior to going from Google to that particular page. And our prediction is that that technique of Every Page is Page One will grow – and it will be misinterpreted and misunderstood by many people.

So a next prediction is what you might call “left field”, and that is that blockchain, the technology that supports Bitcoin, will be used in the workplace in different situations in addition to having it as a means to support a currency. And that we will see it used within the workflow to do with content and documentation. So the main areas that we’re likely to see this, is within the process of getting contracts and other legal documents approved. And also, within situations relating to the documenting of policies and procedures.

So what do you get with blockchain? You have the ability to commit decisions to a blockchain. You have the ability to verify against a blockchain that what you’ve received hasn’t been changed, hasn’t been interfered with. You can control who can and cannot commit changes to the blockchain. And you can make the process of changing things secure, by using keys.

How can we apply blockchain to documentation? Well, there are situations where you want to prove compliance. You want to have security, and you want to have auditing. And these relate to information security and governance. This can be, for example, to do with contracts between you and a third-party. Typically, what will happen is you’ll send a contract out to somebody to sign, and it may come back, and they might have taken out a clause or added a clause in there. So often, within the process of approving legal contracts, there’s a lot of checking that needs to be done to make sure that nothing’s been slipped in unexpectedly. With blockchain you can identify or prevent those changes from happening. So, within legal documentation, there may need to be a case of who made a change. With the auditing side of things.

But we also have that auditing side with compliance documentation. In a previous podcast, we talked about a situation where IKEA might want to get information from suppliers on the materials that have been used in the furniture that IKEA provides. Information on the amount of formaldehyde, the amount of glue, whether it’s from a sustainable forest. And again with other policies and procedures, you can track when and who made a change to a document at some point. Blockchain is offering a way of minimizing the information overload by making it easier to identify when changes have happened and to approve any changes that go through.

Another prediction for a future trend in technical communication is again one we’ve covered in the podcast before. And that is the application of artificial intelligence and chatbots in technical communication. And we’re now seeing from IBM, from Amazon, from Facebook, from Google, from Microsoft, services which mean that you can take your content, apply it to the platforms they provide, and enable them to start instigating machine learning and to develop intelligent chatbots.

Well, the background noise might give away that I’m in a different location. I am in one of the places we use for meeting people for informal chats, and the Members’ room at the British Museum.

A lot of the development going on in the software sector, at the moment, is in the field of APIs, and that growth in APIs is leading to a number of trends in the documentation field. So having to create documentation aimed at developers rather than the general public. And this may be where we’ve seen the growth of systems like Docs Like Code. We need more input from developers to contribute to the documentation. We need to align it more closely with the help of development and therefore use the tools that they are using.

This is also linked to a general theme covered and mentioned in “Information 4.0” and elsewhere: the single sourcing and the molecular element of content. Breaking things down in that way. But this, of course, has been going offer for many years. This is also leading to the different means by which content is delivered. But I think what’s coming through that’s new is the adding of an additional semantic layer.

But what about the trends we’d like to see in the future? One would be to have the testing of user documentation. Testing that it’s appropriate to the audience, that is what they want. And there has-been very little testing in the past. One of the interesting things with the development of the Government Digital Service in the UK is their underlying philosophy is to test and test the test again. Interestingly, when you talk to them, there is, actually, very little reuse of content across their different documentation sets at this moment in time. Now that may change, that may grow, but it may be that, actually, when it comes to providing almost appropriate information for users, there may not be as many opportunities to reuse content as we think.

So those are our predictions for and beyond. We’d be interested in what you think do share your thoughts on our predictions; which you think we’ve missed, and whether you think we’re right or wrong. You can share your thoughts via info at There’s also a comment section on the podcast hosting platform You can share your comments there as well and on You’ll also find the show notes.

If you’d like more information on Cherryleaf ourselves, then have a look at our website There you’ll find information on our writing services, training courses and consultancy. But apart from that, I just like to thank you for listening to this podcast episode.

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 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 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

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

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

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

Conversation and Community: The Social Web for Documentation

Troy Howard Documentarian, Super Genius at Twitter Repository analytics for code and docs

Matt Fleming on Twitter

Docs Like Code GitHub repository



Liquid scripting



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



GitHub Flavoured Markdown spec

XML Press


Building Docs Like Code – article

Travis CI 


Circle CI


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.