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.
You’ll find a new case study on the Cherryleaf website, regarding a project we carried out for Affidea.
Affidea Group BV is a company that offers premium diagnostic imaging, cancer detection and cancer treatment services. It focuses on delivering prompt, thorough diagnoses and high quality treatments by working only with state-of-the-art technology and experienced medical professionals.
Affidea operates a network of Diagnostic and Cancer Treatment Centres in 14 countries across Europe. The company employs over 3,000 professionals, of which more than 750 are medical doctors.
Affidea required us to produce a so called “Blue Book” of company operations. Some of the material for the Blue Book already existed and had been documented; other material had not been documented. The existing material had been written by non-native English speakers and/or non technical authors, because of this there was a lack of consistency to the existing documentation. The information required for the new material was largely not documented anywhere and subject matter experts (SMEs) were based throughout Europe.
The project involved re-designing/writing existing content, interviewing SMEs in order to get the information required for new content, putting together new content and finally assembling all the information into the Blue Book.
For the full case study, see:
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.
What do you think?
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?
We’re looking for someone to take our Technical Author induction online training course, free of charge, in exchange for doing something that will help us develop future versions of the course.
This course was one of the first we developed, and, at that time, we didn’t use formal scripts in the creation process. In the next 18 months, we’re planning to re-record the course videos and revise some (approximately 5-10%) of the content. Having a script for the course will help.
So, in exchange for taking the course for free, we’d like that person to write a transcription for us of what the presenter is saying (which you’ll send to us). The document can be in .txt or Word format. You’ll benefit from having taken this couse, and having taken great notes for yourself as well!
Contact us if you’re interested in doing this.
UPDATE: We’ve found someone. Thanks to everyone who replied.
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.
Editor’s Note: This post has been written by Dr. Tony Self of HyperWrite. Tony will delivering DITA training during October at Cherryleaf’s training centre in London.
In the field of technical communication, an argument crops up from time to time saying that technical communicators shouldn’t have to know anything about XML, because writing is writing, and XML is coding, and never the twain should meet. Dissecting the argument, it appears that the underlying claim is “language first; technology and tools later”.
In many cases, it seems the logic gets a little lost. I have heard statements along the line of “if you can’t string a sentence together, knowing about XML elements and attributes won’t make you a technical writer”, as if those skills are mutually exclusive.
My first observation is that the debate is often poorly framed. XML is not precise enough a term; what does “knowing about XML” mean? XML is an enormous field, covering programming, writing, archeology, journalism, eLearning, spacecraft design, mathematics, chemistry, audio recording, banking, gambling, engine management, and pretty much every field of human endeavour. So in a discussion about the role of XML in technical communication, we need to define what we mean by XML. Bearing in mind that XML is principally a standard for creating XML languages, the XML languages (or applications, in XML terminology) of interest to technical communicators are probably DITA, DocBook, XHTML, SVG, MathML, and XLIFF.
Continue reading “Writers shouldn’t code… or should they?”
You’re welcome to join us on our upcoming free webinar, “The changing nature of content”, which will be held at 7pm (GMT+1) on 24th April 2013.
In recent years, technical communicators have focused on improving User Assistance through new technologies and systems, with the assumption that the nature of the content the tone of voice, the writing style should remain the same. In this free webinar, sponsored and hosted by Adobe, we’ll investigate whether the tried and tested writing methods from past decades still make sense today. We’ll look at the reasons why some organisations are “breaking the rules” with the User Assistance they provide.
The registration details will be posted to the Adobe online events Web page in the next few days.