Writing micro-content – ASTC 2017
I’m attending the Technical Communicators Conference 2017, the annual conference of the Australian Society for Technical Communication (ASTC). This post is a live blog of a session at the conference. In other words, I’m writing as the presenter speaks. Any mistakes are mine, and all credit goes to the presenter.
Margaret Hassall presented a session entitled Writing micro-content, or Writing content for people in a hurry. She talked about headings, Twitter, and content.
We need to figure out whether people are reading our content, and how much of it they’re reading. Take into account the fact that people scan content. Margaret touched on Nielson’s research on eye tracking, showing the areas of a page on which people spend most time.
Even given the new technology like Twitter and mobile phones, the basic principles of content creation haven’t changed. Be concise, and consider your audience. People just want to get in, get the information, and get out. Push for plain language and fewer words. Add headings, shorten your sentences, add pictures. Most importantly, figure out your audience and write for them. Consider why they need the release information.
Margaret’s pet peeve is release notes. When reading release notes, readers want to know what’s changed and how the change affects them. Many release notes are full of content and make the relevant information hard to find. Margaret walked us through some examples of release notes, pointing out good and bad aspects of each, from a technical communication point of view. Comments that came up:
- The order of the issues listed in the release notes. Should the items be in order of the issue number, the description, other…?
- Grouping of issues by category.
- Clear indication of whether the item is about a feature or a bug fix.
- Inclusion of a bug number for reference.
- Link back to the issue tracker.
- Changing of the description, so that it no longer matches the original issue description. This can cause a problem for customers who can’t match the fix against the reported problem.
Margaret discussed the possibility of including tech writers in issue management. We could, for example, write better titles or better descriptions. Sometimes the title of the bug describes the problem as understood by the user, but when the issue is fixed, we find that the title no longer adequately describes the problem.
It all boils down to considering your audience and why they need the release information, then presenting the information to them in a clear, concise document.
Margaret also touched on headings in a document, and on subject lines in email messages.
Thanks to Margaret for these interesting insights into release notes and other documents that people are likely to read in a hurry.