The four words that account for 19 minutes of a typical Technical Communicator’s day

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.

The need for empathy in technical communication

One of the subjects Doug Kim covered in his TCUK14 presentation, on the changes to Microsoft’s user documentation, was how Microsoft now normally begins its Help topics with an empathetic statement. The writers seek to understand the user at the moment they’re reading the content.

For example, if someone is reading the topic on auto save, it’s likely they’ve just experienced a crash and have lost some data. So they express empathy by saying, crashes happen:

Microsoft Help screen

By doing this, Microsoft is moving away from the norm – the generally accepted way to structure task topics in DITA and other standards is to dive straight into the task without any introduction.

We think Microsoft has go this right – there is often a need for empathy in technical documentation. Of course, this is difficult if your content could be reused anywhere – you lose the understanding of the user’s point of view. However, being empathetic, from the research Microsoft carried out, is what users, today, prefer.

See also: Trends in Technical Communication Course – Advanced Technical Writing Techniques

Not so cool tools for Technical Authors – speech recognition software

Our method for creating online courses involves making an audio recording of the presenter, transcribing it, editing the script and then recording the final, video presentation. We’ve tried using speech recognition software to create the transcribed script, and it has been a deeply frustrating experience.

While speech recognition is proving successful for searching and issuing commands (using Siri, Google Voice and Amazon Echo), we’re not sure it will replace the keyboard as the way we create written content.

Continue reading

Draftback – could it reveal how Technical Authors actually write?

James Somers is releasing an add-on for Google Docs, Draftback, that enables you to play back and analyse the creation of any Google Doc you have permission to edit.

It means you can see how a writer created the document, the sections they spent time rewriting and rearranging, the elements that were pasted into the document from elsewhere, and so on.

From an organisation’s perspective, the graphs Draftback that produces potentially could be used to show when and where the writer spent most of their time:

Timeline of activity

I could see this illustrating the impact of last minute changes to a product, review comments and other external factors. Potentially, it could also highlight areas where a writer might need assistance or training.

What do you think?

Stenography for Technical Authors?

Steno keyboard

This tweet caught my eye:

It linked to an article The 100 Year Old Trick to Writing at 240 Words Per Minute:

About four years ago, stenographer Mirabai Knight came to the conclusion that stenography had been a walled garden for too long — controlled and marginalized by big companies. She set about creating her own affordable hardware and open source software designed to set stenography free to the masses…

Note that this keyboard does need to be able to recognize multiple simultaneous keystrokes, so gaming keyboards (starting at $50) are the norm.

This could really help us when we’re transcribing the scripts for our online training courses. We’re not aware of any Technical Authors who use stenography – is there anyone out there?

Microsoft’s “No more robot speak” in action

 

Our post about how Microsoft is changing its writing style (Microsoft moves away from “robot speak” in its user documentation) generated a lot of interest, so I thought it might be useful to post some examples of it that we’ve spotted.

These examples are from Office 365 Premium Edition.

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

Topic-based authoring: The undiscovered country

NT Live Hamlet Many software companies, when they start out, provide user documentation as downloadable PDFs or as web pages. As they develop more products and versions, and as they expand into countries that use different English spellings, the amount of documents can grow until it becomes hard to keep all of these documents up to date.

It’s at this point that they tend to call a specialist technical writing company (such as Cherryleaf) to see if they can fix the problem for them. We find they’ve usually had a brief look at a Help Authoring tool, such as Flare or RoboHelp, and can see that it would solve a lot of their problems. However, they’re often not really sure how to use these tools in the best way.

Although topic-based authoring has been around for over twenty years, for many people it’s a completely new concept. It is, to quote from either Hamlet or Star Trek VI, an undiscovered country. Our meetings with them often end up focusing on the benefits of topic-based authoring.

Topic-based writing is an approach where you write a piece of text (or topics) that typically contains a paragraph or two about a single topic. These topics can be combined to create a page in a PDF document, and they can be organised in a sequence to create an online Help system ( See topic-based authoring page in Wikipedia). It’s a modular approach to creating content. The main advantage of this approach is the topics are often reusable; you can save time by reusing topics across different documents, and you can publish the same content to different media. For example, you could use a topic in training courseware, in a user guide and in marketing information.

As each topic is usually about a specific subject, and has an identifiable purpose, it can also help the writer write more clearly. If you need longer articles, you can build these up from the topics you’ve created.

It’s easy for professional Technical Authors to forget sometimes that many people have never come across this approach to writing before.