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.

Advertisements

About Sarah Maddox

Technical writer, author and blogger in Sydney

Posted on 11 November 2017, in ASTC, technical writing and tagged , , , . Bookmark the permalink. 2 Comments.

  1. Hello Sarah,

    Thank you for sharing these summaries! I began following your blog after reading your book about Confluence, and have learned a lot from it.

    Just a small point of clarification – I’m guessing the eye tracking research is from Jakob Nielsen or the Nielsen Norman Group, and not the Nielsen company?

    • Hallo Susan
      Thanks for the correction. Yes, you’re right – I should have written “the Nielsen Norman Group”. Ah, the perils of liveblogging! I’ll make the correction in the text of the post.
      Cheers
      Sarah

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: