Creating palaces of almost forgotten things

Museum of almost forgotten things brochure

This weekend, we went to the Fabularium on London’s South Bank, where the programme highlighted The Museum of Almost Forgotten Things. It struck me that this concept could also be applied to technical communication. The impetus to write things down, to document policies and procedures and to write user documentation for software written in a Sprint, is often due to organisations worrying that important information might be soon forgotten. Technical Authors often capture and record almost forgotten things. They might, however, object to the word “museum”, because they are working with how things are today much more than how things were in the past. So perhaps “palace” could be an alternative word to use.

Ben Haggerty, the storyteller whom we saw perform, started by trying to discover who we, the audience, were. He quoted a west African saying that there are four types of people in the world:

Those that know and know that they know. These are called teachers, and should be respected.

Those that know, but don’t know that they know. These people are asleep.

Those that don’t know, and know they don’t know. These people are students.

Those that don’t know, but don’t know they don’t know. And there are 630 of them sitting in the House of Commons on the other side of the Thames.

It’s interesting to see how close this old African saying is to competency models used in training today: unconscious incompetence, conscious incompetence, conscious competence and unconscious competence.

Content as an API – Google’s engineering documentation

Google’s Riona MacNamara presented at the Write The Docs North America conference on “Documentation, Disrupted: How Two Technical Writers Changed Google Engineering Culture“. In the video of the presentation below, Riona explains how she worked with a small team of writers and engineers to build a documentation platform in six months that is becoming a part of the standard Google engineering workflow.

What should be on our roadmap for training courses in technical communications?

We thought it would be useful to reflect on our plans for topics and courses in technical communications. In the past, some of the best suggestions have come from customers and prospects; it’s great to pick up useful ideas from others.

Today, you’ll find classroom or elearning training courses in:

We have a separate roadmap for business writing courses, which is where our policies and procedures training course (and again, Introduction to content strategy) fits in.

Our current thinking is to offer more topics around managing and planning technical documentation projects. In the past, we’ve offered an course on estimating projects. We also know managing project time is another important topic. Perhaps there are other topics that would fit under this category?

There’s also the issue of which courses should be online (recorded) courses, and which ones should be classroom-based (live) courses. Delegates say really like the two training venues we use in central London (we struck gold there), but online courses enable people to take a course pretty much anywhere and at any time.

If you have any thoughts, you can email us your thoughts, or you can use the comment box below.

How on earth could the Apple Watch be used in technical communication?

Apple watchWhenever Apple launches a new product range, there’s a great deal of buzz and excitement. There’s lots of speculation as to how the technology could be applied by different professions and by consumers. Yesterday’s launch of the Apple Watch was no exception.

The title of this post may give away the fact that this post contains wild guesses. We may well look back on in five years time and ask, what were we thinking?

Continue reading

Teaching non-readers to read

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:

IMG_2713Dyslexia teaching in Sierra Leone

Dyslexia teaching in Sierra Leone

27 February 2015: Trends in Technical Communication training course

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

Microsoft moves away from “robot speak” in its user documentation

DSC00498One of the highlights from the Technical Communications UK 2014 conference was the keynote presentation from Microsoft’s Doug Kim. Doug is Senior Managing Editor for Office.com, and leads guidelines and best practices for Voice in Office. By Voice, he means the tone of voice and style of English used in the User Interface and user documentation.

Doug Kim at TCUK14

The change in voice is something we explore on our advanced technical writing techniques course, so I was interested to see how Microsoft was addressing this topic. The good news for us is that Microsoft’s approach is consistent with what we advocate on the course (however, we will need to update the course before the next one in December to include some of the topics Doug discussed).

Continue reading

Why “What are good and bad examples of technical writing?” is a difficult question to answer

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:

  1. Adopting an action-oriented approach (to minimise the amount of reading)
  2. Starting immediately on meaningful tasks
  3. 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.