In our latest Cherryleaf Podcast episode, we look at one way the Institute of Scientific and Technical Communicators (ISTC) used to promote technical communication at the University of Cambridge’s Careers fair:
Below is an interview with David Farbey of the Institute of Scientific and Technical Communicators, where we discuss training, accreditation and CPD in technical communication.
- Becoming a technical communicator is different from becoming a lawyer, doctor, developer or an accountant in that, in the UK, there is no standard career path from school. How does that affect the profession and starting a career?
- What training, if any, do you need to be a technical communicator?
- The ISTC’s Professional Development and Recognition
- Certifying technical communicators
- The ISTC certified courses
- What does a undergraduate or post-graduate course offer someone?
- Where does CPD fit into this?
- What are we likely to see in the future with regards to training and certification?
See also: Cherryleaf’s ISTC accredited training course: https://www.cherryleaf.com/training/technical-author-basicinduction-training-course/
Last month, we were asked by a client to deliver our API documentation course to their team as a classroom course. Following on from that, we are now able to offer this one-day course to other companies, in this manner. The course currently varies from our online API documentation course. It includes more content on information design, and research into the different types of users and their needs.
Contact us to find out more.
Technical Authors work in a profession where they must be able to adapt to changes in the technology sector. Often, the changes relate to the outputs they need to create or the authoring tools they use, and most Technical Authors adapt quite easily to the new situations.
However, sometimes there are also changes to writing styles or the type of subject matter, and these can take a little while to get used to.
One significant development has been with the growth in Web-based, Software as a Service applications. In this environment, the User Assistance often fulfils a pre-sales and a training function, as well as providing the help when users get stuck. We’re working on a project at the moment where the writers have had to include this additional type of information, going against their natural inclination to be as succinct as possible. This has involved providing information on why you should use a particular feature, as well how to use it. For the writers, this have meant they’ve needed to gain a better understanding of the context in which the application is used, and deeper understanding of the users and their working day.
The other area that can cause challenges is writing API documentation. This is often written using different authoring tools than usual, and it often requires the writing of more factual, reference information. This can mean the writers need to have some understanding of the programming languages used to create an application, and be able to write for a more technical audience.
These differences is something I’ll be discussing in depth at the free Write the Docs London all day mini-conference on Friday, 4th March. In Aye, Aye, API – What makes Technical Communicators uneasy about API documentation, and what can we do about it?, we’ll look at the challenges mainstream Technical Authors face when writing API documentation.
If you have any insights or thoughts regarding the differences between writing end-user documentation and API documentation, please share them via the comments box below.
Happy New Year!
A quick update on the availability of places on our upcoming courses:
- We’ve just three places left on our advanced technical writing classroom course on the 28th January.
- We have free places on our advanced technical writing live Web course, for delegates based outside the UK, which will be held on the 8th & 9th February 2016
We will be scheduling another policies and procedures classroom course. This is likely to be held in February.
As a technical communicator, sometimes it can be hard to explain to others what it is you do. In the olden days, it was simpler: you could say you wrote manuals. Then, in more recent times, you could say you wrote online Help and manuals.
Today, there can be uncertainty of what is and isn’t technical communication. It can be unclear if certain deliverables should be created by a technical communicator or by someone else. For example, if content moves from a Help page to an onboarding screen, is it still technical communication? If the text moves into the interface, should the technical communicator create it? Are walkthrough videos a function of training or technical communication?
Continue reading “What is technical communication, actually?”
Here’s the latest Interview, with John McNamara of IBM, on what it’s like to be a technical communicator:
For the ISTC’s YouTube Channel, Ellis Pratt (Cherryleaf) is interviewing a number of technical communicators.
Here is Adrian Warman (IBM Cloudant):
Here is Brian Harris (Red Gate Software):
There’ll be more interviews in the coming weeks.