The airline safety video is about actions that could save your life, but it can be very dull and mundane if you’ve flown more than once. So airlines are using the third aspect in good design – emotion – to engage with their audience.
The latest video to follow this trend is from Delta Airlines:
Google’s Riona MacNamara presented at the Write The Docs North America conference on “Documentation, Disrupted: How Two Technical Writers Changed Google Engineering Culture“. In the video of the presentation below, Riona explains how she worked with a small team of writers and engineers to build a documentation platform in six months that is becoming a part of the standard Google engineering workflow.
Mozilla is an organisation that always seems to be doing innovative things with their documentation. One of the experimental functions it has introduced to its Kuma wiki platform for the Mozilla Developer Network (MDN) documentation is an experimental PUT API that makes it possible to create and update articles remotely.
Mozilla suggests a number of ways it can be used:
You can create a page for your project and update content in certain sections from automated build, testing, and deployment scripts. This can help you keep your community up to date with your project’s progress.
If your project offers documentation alongside source code, you can push HTML renderings into a subsection of MDN. This lets you maintain docs in a way that’s appropriate for your team’s workflow, while still contributing to MDN and allowing localizers to translate the content.
Fro example, Mozilla’s programmers are able to write scripts that automatically generate articles based on contents of header files they’re creating. The API uses HTTP, which means software engineers (and other writers) effectively have the freedom to use the application environment and libraries of their own choice.
Kuma itself is an open source platform written by Mozilla in Python, using the Django framework. Contributors can fork the Kuma repository on Github, make changes to the content, and push the revised content back to the wiki.
It will be interesting to see if this succeeds, and if this type of platform extends further out than its use for developer documentation.
It might seem like we’ve been quiet recently, but that’s partly because we’ve been working on an academic project that we hope to be announcing towards the end of the year.
As a spin-off from this project, we’re developing new training courses in technical communication. These courses are at a more advanced level than our basic/intermediate courses, and they include more references to academic research.
If you are considering any on-site training for your technical communications team, we can now offer these topics:
What is technical communication?
The business case for technical communication
History of technical writing standards
Usability and user centred design
Project planning and its effect on writing documentation
Researching and scoping documentation
Information design and content organisation
Writing the topics – overview
Presenting different types of information
Index, search and metadata
Single sourcing and reusing content
Researching technical communication – where to go
Governance and maintenance
What skills does a technical communicator need?
Content strategy and technical communication
Trends in technical communication
Publishing and delivering information
Managing the documentation project
We may develop online courses for some of these topics in the future as well.
We’ve a client looking for information on applying Net Promoter Score to user assistance documentation. If you’ve seen anything, please let us know.
Cherryleaf’s Ellis Pratt will be the guest speaker at June’s “Member Masterclass @ The IoD”. The topic is clever content creation in business. We’ll look at some of the most effective techniques for creating the types of content created in today’s business world. The event will be held at 6pm on 2nd of June 2015, at the Institute of Directors, 116 Pall Mall, London.
This was a surprise, as Atlassian has been a strong advocate for having user comments appended to user documentation. Sarah Maddox, when she was working at Atlassian, posted the reasons why the company encouraged comments on her personal blog:
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 →