You can now sign up for all of Cherryleaf’s popular online training courses at a discounted price!
This bundle provides you with access to:
By purchasing this bundle, you’ll save £180 ex VAT. That’s a discount of 38%.
See: Cherryleaf training course bundle – all our online courses at a discounted price
It might seem like we’ve been quiet recently, but that’s partly because we’ve been working on an academic project that we hope to be announcing towards the end of the year.
As a spin-off from this project, we’re developing new training courses in technical communication. These courses are at a more advanced level than our basic/intermediate courses, and they include more references to academic research.
If you are considering any on-site training for your technical communications team, we can now offer these topics:
- What is technical communication?
- The business case for technical communication
- History of technical writing standards
- Usability and user centred design
- Project planning and its effect on writing documentation
- Researching and scoping documentation
- Information design and content organisation
- Writing the topics – overview
- Presenting different types of information
- Index, search and metadata
- Single sourcing and reusing content
- Post writing
- Researching technical communication – where to go
- Establishing standards
- Governance and maintenance
- What skills does a technical communicator need?
- Content strategy and technical communication
- Trends in technical communication
- Visual design
- Publishing and delivering information
- Managing the documentation project
- Metrics/Evaluating documents
We may develop online courses for some of these topics in the future as well.
Approximately 50% of a Technical Author’s day is spent writing. However, when Technical Publications teams look for efficiencies, they tend to focus on the 50% of time spent on non-writing activities, such as researching, reviewing and planning. They assume the content itself cannot be written more quickly. To an extent, they are right, as the
querty qwerty keyboard is not an optimal layout.
We’ve been going through a process of transcribing our early e-learning modules, in order to have scripts upon which we can base future course updates. As part of this project, we’ve been using a free application called Plover to help us write the content. With Plover, you have the potential to create content (in Word, RoboHelp, Flare, Oxygen XML etc) at up to 225 words per minute (wpm).
Plover is based on chorded typing. You press more than one key at a time to create words. Chorded typing isn’t new – for example, it was demonstrated in Douglas Engelbart’s famous “The mother of all demos“.
Below is a five minute lightning talk on Plover and some of the emerging hardware:
So far, in my case, I’ve been able to double my typing speed. Realistically, those of us participating in this project at Cherryleaf aim to get to 180 words per minute. The reason for this is that most people speak at 160-180 wpm. At that speed, you are able to transcribe subject matter experts in real time – which means there’s no need to record an interview and then type it up at a later date.
There is a learning curve to this method, but it is based on over 100 years of theory and practice. It is tremendous fun – a bit like learning to use a
querty qwerty keyboard for the first time.
Cherryleaf has been working on a project which shows people how to teach non-readers to read. We’ve been working with Elizabeth Ainley, who has written a book, go for it!, which can be used to teach illiterate and/or dyslexic adults.
Elizabeth asked Cherryleaf to help her re-write the existing instructions aimed at the adult coaches who will be using go for it! This involved making the instructions clearer, and clarifying the learning outcomes.
Schoolchildren in Sierra Leone have been the first users of the project. It means a 12 year old child who can read can now teach others. The school is run by Miriam mason-Sesay MBE for the Educaid, who sent Elizabeth these photos of the teaching materials in use:
Cherryleaf’s Trends in Technical Communication Course – Advanced Technical Writing Techniques will be held on 27th February 2015.
If you want to discover new approaches to technical writing, this one-day, hands-on advanced workshop is right for you.
You’ll find out how Technical Authors in leading companies are now applying techniques from other disciplines (such as psychology, copywriting, usability and elearning) into the information they create.
The course has been designed to be independent of any particular authoring tool, and to work in both a structured and unstructured authoring environment.
See Trends in Technical Communication Course – Advanced Technical Writing Techniques
Peter Norvig has some interesting statistics on word frequency in the English language. It turns out that four words – the, of, and, to – account for 16.94% of the words we write.
In field of technical communication, Technical Authors typically spend 50% of their time writing and the rest on researching, planning etc. If we adjust for the fact that these four common words are half the length of an average word in English, that means Technical Authors spend an average of 19 minutes every day typing those four words. In a 37.5 hour week, that amounts to 1 hour and 35 mins.
There’s an interesting discussion thread in the ISTC’s discussion forum regarding good and bad examples of technical writing. Incoming ISTC President Alison Peck has been asked by a researcher for a radio programme if she could provide some examples of technical writing: “well done, badly done and particularly innovative or strange”. As it’s a radio programme, these examples are likely to be read out.
This is not as straightforward to answer as you might think.
Firstly, most technical communicators work under non-disclosure agreements, so the best and worst examples often aren’t for public consumption.
Secondly, a lot of poor examples are from content that has been badly translated into English. They may have been well written originally, but they might have become mangled through the process of localising the content.
Thirdly, as Alison pointed out in her original message in the online forum, reading out very basic instructions out of context is not going to be particularly riveting or easy for the listener to grasp.
Fourthly, although technical communication is about clear communication – clear sentences – the role of technical communication is mostly about addressing the question, can the user do the task?
Minimalism, which most technical communicators use, focuses on:
- Adopting an action-oriented approach (to minimise the amount of reading)
- Starting immediately on meaningful tasks
- Supporting users in recognising errors and recovering from them
That requires more than clear and simple sentences; it requires information design as well. This means any examples ideally should show how well or badly they enable the user to complete the task. That requires an understanding of the task itself, and this makes it difficult to do this in a few seconds on the radio.