I’ve had some time in the last few days to initiate some the ideas mentioned in my post Marketing the technical communication profession. This relates to improving the marketing of the Institute of Scientific and Technical Communicators. Most of the work we do for clients is confidential, so it’s a pleasant change to be able to talk about a project as it’s progressing.
I’ve been asked to join the ISTC’s Council and take on the responsibility for marketing the organisation. The ISTC is is the largest UK body representing information development professionals (it’s the UK version of the STC or tekom), and this is a volunteer, unpaid, part time, role.
Happily, I’m building upon the work carried out by Rachel Potts (who was the previous ISTC Marketing lead) and other ISTC volunteers.
Increasing the awareness of the technical communication profession
In addition to encouraging people to join the ISTC, it’s important to increase awareness in the wider world of the profession. If the ISTC can encourage companies to use technical communicators, it’s likely there will be more technical communications who could potentially join the ISTC. This should also benefit Cherryleaf and others who provide technical writing services.
Below are some initial ideas I’ve had for how the ISTC can increase the awareness of the profession.
I’ve uploaded a video onto YouTube that I put together about the TCUK14 conference. As I’ve just taken over the role on the Institute for Scientific and Technical Communicators (ISTC) Council for marketing, I don’t think it would be appropriate for me to enter the conference video competition that’s running at the moment. This is just for fun, and something that hopefully encourages other delegates to create a video.
The quotation in the title is from Roger Hart’s presentation at last week’s TCUK14 conference. Roger is a product marketing manager who spent a few years as a Technical Author. In his presentation, Collateral damage: do marketing and tech comms have to fight when users get informed?, he explained some of the most powerful marketing content today is high quality user information – especially the content that Technical Authors produce.
One of the highlights from the Technical Communications UK 2014 conference was the keynote presentation from Microsoft’s Doug Kim. Doug is Senior Managing Editor for Office.com, and leads guidelines and best practices for Voice in Office. By Voice, he means the tone of voice and style of English used in the User Interface and user documentation.
The change in voice is something we explore on our advanced technical writing techniques course, so I was interested to see how Microsoft was addressing this topic. The good news for us is that Microsoft’s approach is consistent with what we advocate on the course (however, we will need to update the course before the next one in December to include some of the topics Doug discussed).
There’s an interesting discussion thread in the ISTC’s discussion forum regarding good and bad examples of technical writing. Incoming ISTC President Alison Peck has been asked by a researcher for a radio programme if she could provide some examples of technical writing: “well done, badly done and particularly innovative or strange”. As it’s a radio programme, these examples are likely to be read out.
This is not as straightforward to answer as you might think.
Firstly, most technical communicators work under non-disclosure agreements, so the best and worst examples often aren’t for public consumption.
Secondly, a lot of poor examples are from content that has been badly translated into English. They may have been well written originally, but they might have become mangled through the process of localising the content.
Thirdly, as Alison pointed out in her original message in the online forum, reading out very basic instructions out of context is not going to be particularly riveting or easy for the listener to grasp.
Fourthly, although technical communication is about clear communication – clear sentences – the role of technical communication is mostly about addressing the question, can the user do the task?
Minimalism, which most technical communicators use, focuses on:
- Adopting an action-oriented approach (to minimise the amount of reading)
- Starting immediately on meaningful tasks
- Supporting users in recognising errors and recovering from them
That requires more than clear and simple sentences; it requires information design as well. This means any examples ideally should show how well or badly they enable the user to complete the task. That requires an understanding of the task itself, and this makes it difficult to do this in a few seconds on the radio.
Jared Spool tweeted this morning:
PLEASE, PLEASE! Tell me that Apple is going to release Hypercard for the iPad!
— Jared Spool (@jmspool) September 9, 2014
HyperCard was a hypertext program that came with Apple Macintosh in the 1980s. It allowed you to create “stacks” of online cards, which organsiations used to create some of the first online guides. It also contained a scripting language called HyperTalk that a non-programmer could easily learn. This meant HyperCard could do more than just display content: it could be used to create books, games (such as Myst), develop oil-spill models, and even dial the telephone.
Most of the Technical Authors I have met don’t have a good thing to say about Microsoft SharePoint. In many ways, it represents how not to publish content online. It is seen as encouraging people to move print-optimised documents (Blobs) around, rather than units of content (Chunks), and users are typically left to rely on search to find which document contains the information they are looking for.
For all those issues, SharePoint may still have its place – for managing documentation projects.