Technical Authors are normally seen as masters of writing user documentation, but their skills are not often applied to other areas of the business. For example, it’s usually the case our clients for software documentation are different from our procedures writing clients.
However, we’re currently working for a client where we began by editing a white paper, and this has led us on to other projects across departments. Work has included developing customer journey maps, a terminology database, as well as the online Help. The role is morphing into that of a content editor role: checking for consistency, spotting errors in marketing copy, rewriting copy, and so on.
So what is different? What has led to this wider scope? It may be due to us being recommended to them by word of mouth, and they had greater confidence in our abilities. It may be because they are a start up. It could be because many of the staff are not native English speakers.
We suspect it’s because the first project was the white paper. They had something that was very useful to them, for promoting the company. They also included us in their in-house chat system, which meant we could see other areas where they had issues with content. This led to us intervening more than usual, making suggestions in a proactive way. The growth of chat systems, such as Slack and Socialcast, within companies could open up other opportunities for other Technical Authors, as long as they take the initiative.
In the olden days, every family had a record player (also known as a “turntable”), and pretty much everyone knew how to use it. However, if you look at the Customer Questions & Answers section for a turntable currently on sale on Amazon, it’s clear that many people today don’t know how a turntable works, or what it does. Common knowledge sometimes isn’t as common as people think.
Just a quick update on some recent training-related news.
We’ve scheduled some new classroom courses:
We’re also continuing to add more courses to WriteLessons – our bundle of elearning courses for technical communicators looking to expand their core skills. We’ve added courses called “Writing and designing embedded Help” and “Markdown”.
WriteLessons is a subscription service – a bit like Netflix. You pay for it for as long as you need it. You can stop when you want, and the subscription will finish at the end of that month. You have access to all of the courses, which you can take at your own pace.
We’re currently working on a module on post-writing and verification, which focuses on editing and proof reading, which will be added to WriteLessons. You might also see a course on Cascading Style Sheets in the upcoming months.
WriteLessons, from Cherryleaf, provides you with access to a range of courses in technical communication. You have access to all of the courses contained within WriteLessons, which you can take at your own pace.
Currently in beta, we’ll be adding extra courses over time. At launch, it contains:
- DITA fundamentals
- Single sourcing and content reuse training course
- Introduction to content strategy
- Documenting REST APIs
- Managing technical documentation projects
You have access to all of the courses in the collection under a Netflix-style subscription plan.
The Spring 2015 edition of Communicator magazine and its special supplement on the Value of Technical Communication was entered in both the IoIC (Institute of Internal Communications) Awards in 2015 and the APEX Awards in 2016. One of Ellis’ articles (“Creating videos: tips and tricks”) was part of that issue.
We’ve just learnt this issue has won an APEX Grand Award. This is the first time Communicator has won a Grand Award. It has also won an IoIC Award of Excellence in 2015.
“This clean, appealing layout offers attractive spreads, a crisp, legible type schedule, with effective use of callouts, sidebars and captions. Content is equally exceptional, with fully vetted, well written articles on a wide range of professional topics. And the supplement on the value of technical communication is an effective ‘selling tool’ for managements and other key audiences. This magazine is precisely the kind of first rate publication you’d expect from a professional association of scientific and technical communicators.”
Here is a link to a recording of an interesting presentation from Britta Gustafson on aspects of working on documentation in the US Government.
“What if U.S. federal agencies decided to reuse and contribute to open source software projects built by other agencies, since agencies often have similar technology problems to solve? And what if they hired technical writers with open source community experience to write documentation for these projects? That would be pretty cool. Also, that’s my work.”
Technical writing as public service: working on open source in government
The Language of Technical Communication book is a collaborative effort with fifty-two contributors defining the terms that form the core of technical communication as it is practiced today. Cherryleaf’s Ellis Pratt was one of the contributors.
Each contributed term has a concise definition, an importance statement, and an essay that describes why technical communicators need to know that term.
Creating user documentation and online Help in a Continuous Integration/Continuous Delivery environment can be challenging for technical communicators and developers.