This online training course teaches the basic skills in single sourcing and writing content for reuse. The ten learning modules in this course contain videos of the trainer with supporting slides and images. The course includes exercises for the delegates to complete and review.
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.
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:
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.
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.
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:
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.
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?
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.