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.

 

Your policy and procedures manual as software

Jared Spool tweeted this morning:

HyperCard was a hypertext program that came with Apple Macintosh in the 1980s. It allowed you to create “stacks” of online cards, which organsiations used to create some of the first online guides. It also contained a scripting language called HyperTalk that a non-programmer could easily learn. This meant HyperCard could do more than just display content: it could be used to create books, games (such as Myst), develop oil-spill models, and even dial the telephone.

Continue reading

Writing documentation for the games industry

Flickr Creative Commons image Marco Verch

Last week, I visited Gamescom in Cologne. Gamescom is the largest exhibition and trade fair for computer games in Europe, with over 335,000 people attending this five day event. We visited for social rather than business purposes, but it led me to reflect on the work we and others have done in writing documentation for the games industry.

Continue reading

Writing troubleshooting topics

It’s a fair bet that the introduction of the new Troubleshooting information type into the DITA 1.3 technical authoring standard will affect how all Technical Authors write troubleshooting topics, regardless of whether they use DITA or not. That’s because the proposed elements for troubleshooting topics make good sense, and it offers a standardised approach to writing these types of topics.

According to the Oasis DITA standards committee,

Troubleshooting topics provide descriptions of and solutions or workarounds for problem situations that users might encounter. Users refer to troubleshooting information to understand what condition or event generated their problem situation and to find out what they need to do to recover from or work around a problem, or to prevent a recurrence of the problem.

The user would see a topic that looks roughly like this:
Continue reading

Reputation Management – Can user documentation help quash rumours?

Photo of a tiger in the streetIn the ‘Whispers’ episode of BBC Radio Four’s Digital Human programme, Aleks Krotoski explores how rumours spread both online and in the physical world.

As an example, she looked at how two people were able to spread a rumour that a tiger was running loose in London during the 2011 riots.

Aleks claims we are now in a world of misinformation. For organisations, this means they now have to pay attention to any misinformation or rumours about their products and services, an activity that is often called ‘reputation management’.

Seven minutes into the radio show, Nicholas DiFonzo of the Rochester Institute of Technology states groups believe rumours typically because there is a lack of information from official channels, they don’t trust official channels, or because their friends believe it. People use rumours to figure things out.

This means if there is a gap in information, then rumours may fill that gap. For this reason, it’s important organisations publish their Help files or equivalent on the web, so that there isn’t any uncertainty over what your product can and cannot do. If you don’t, whatever Google serves as an alternative source of information will fill in the gap.

Where people might not trust the official marketing content, they are more likely to trust the technical, instructional information. It’s seen as more ‘truthy’.

What do you think?

Please share your thoughts, using the comments box below.