In this episode of the Cherryleaf Podcast, we take a look at topic-based writing. We explore:
- What is a topic?
- Features of topics
- Why use topics?
- Why not use topics?
- Where can you use them?
- What happens if you don’t use it?
- Tools for topic-based writing
- What do you need to know
- Interacting with others
To record your questions and comments to the podcast team, use the green button:
This is a recording of a presentation from the February 2018 London Content Strategy Meetup.
“Content can often seem like jelly – messy and hard to manage. In this presentation, we’ll look at whether you can reduce this messiness through structured writing. In this overview of the topic, we’ll explore what is structured writing, what it promises to give its adopters, the different standards, and the challenges that come with using structured writing.”
While preparing for the upcoming presentation on structured authoring, we realised we didn’t have anything on that subject on the Cherryleaf website. To fix that, we’ve added a new page to the site, on structured authoring.
We plan to add a recording of the presentation, and some examples, after the event.
In researching what developers wanted to learn about writing documentation for users, the most common issue related to how much, or how little, they should write. One developer said:
“I would want to know what is the minimum I should write. If you can persuade me what is the necessity of each thing I’m capturing, and the voice I should use to make it most acceptable, I think I’d tune in.”
We’ll look at this question in the Writing Skills for Developers course, which we will be releasing soon. In general, you need to:
- Meet the legal requirements (which differ depending on the product, and the country).
- Provide enough information so that users don’t give up using your product, if they get stuck. For example, how to install the software, and how to get started.
- Consider the support calls, and whether you could avoid any of those by having good user documentation.
That might appear a bit too vague, so let me go back to one of the sentences above:
“If you can persuade me what is the necessity of each thing I’m capturing”
Before you start writing, you should define the purpose and audience for each deliverable you create. There should be a use case:
- Without documentation, is it clear what the user should be doing? is it clear what the user should be doing first?
- Is it clear how they should be doing the task?
- When they have to choose between options, do they have enough information to make the right decision?
- When they have completed a task, do they know what to do next?
- Are there any concepts or terms the user might not understand?
You can assess what topics to cover by doing some basic usability analysis. However, if you think about the tasks, the process (workflow), and any unfamiliar concepts, you will be on the right track.
Last week, we used the Hemingway app to highlight any unclear pages on our main website. The app highlighted four pages where we’d used the passive voice or very long sentences.
The first inclination was to think our readers are cleverer, our content is more technical, it’s not possible to rewrite those parts. We found, of course, we could rewrite them. We decided to write them in the same way we’d write user documentation. We found those passages were much clearer, as a result. A lesson learnt.
In his newsletter last week, internet psychologist Graham Jones mentioned research that had looked into what makes some web content more shareable than others.
The researchers had analysed articles on Medium, and found there were several key factors.
One was the length of the content – around 1,800 words ( approximately 7 minutes reading time).
Another was the the “reading age”.
“The study on Medium shows that the content that gains the most engagement has a reading age of 11.”
In terms of their reading age, how old are your readers?
Graham also said:
“Typically for most business websites that I examine the reading age averages around 17 years…The Times newspaper has a reading age of 12; the Daily Mail has a reading age of 10. The reading age of the script on the 10 o’clock news is about ten as well. It is no coincidence that the world’s most popular media have low reading ages. Whatever you might think of the BBC or the Times or CNN or your favourite magazine, one thing unites them all – low reading ages. Most websites have language which is far too complicated.”
Of course, it’s not always easy to describe complicated things using simple language. We may need to describe tiny differences and modalities. However, we should aim for clear and simple language as often as possible.
A related factor was the number of words in a sentence. Graham reported the study found that the most shared content was that which had sentences that were between 12 and 15 words. This matches with best practice at places such as the Government Digital Service, where the aim is to write 11 words per sentence.
Even if your readers are much, much older than eleven, it may be a good idea to pretend they are.
Mark Forsyth’s description of hyperbaton (putting words in an odd order) in his book “The Elements of Eloquence” is the subject of a tweet that is currently trending on Twitter:
See also: Making Rhetoric Relevant
Following on from our post Cutting and pasting content into Word documents – Is there a better way?, we’ve been looking at how organisations could use Markdown to create reports and proposals more quickly and consistently.
The objective was to:
- Create something simple for non-technical people to use.
- Have a collection of re-usable chunks of content that could be embedded into the document (no more cutting and pasting). If a chunk needed to be changed, then the documents where it is embedded would reflect that change automatically.
- Be able to generate the completed report as a .docx (Microsoft Word) file.
- Separate the content from the “look and feel”.
- Enable different people to work on different sections of the document simultaneously.
- Store the content in an open format, so there was potential to use some of the content in other places (such as on a website).
Continue reading “Using Markdown to create a boilerplate document for reports and proposals”