Book – Current Practices and Trends in Technical and Professional Communication

This week, the Institute of Scientific and Technical Communicators published a book, called Current Practices and Trends in Technical and Professional Communication. Cherryleaf’s Ellis Pratt is one of its co-authors.

book cover - Current Practices and Trends in Technical and Professional Communication

“Technical and professional communicators are experts in making complex systems and worlds understandable to those who need to access them. However, both the concepts we are communicating about and the tools we are communicating with are changing at a rapid pace. To communicate effectively, we need our own knowledge and understanding to remain current, identifying best practice and learning from the experience of others.

Current Practices and Trends in Technical and Professional Communication is a valuable source of collective knowledge from our community of practice. Experienced practitioners and innovators (from the UK and international) are sharing what they know for the benefit of both the communicator and the end user.

The topics in the book cover important issues affecting the work we do (including globalization, localization and accessibility), and the tools and processes we can use to resolve some of the issues we encounter. Changes in technology are described, and ways of harnessing that technology are identified, including both current and future possibilities.

Whether you work in relative isolation, as the sole technical or professional communicator in a multidisciplinary team, or with other technical or professional communicators, you will find plenty in this book that is thought-provoking, interesting and useful.”

 

Review: Modern Technical Writing by Andrew Etter

Andrew Etter has written a short, Kindle ebook called “Modern Technical Writing: An Introduction to Software Documentation“. The book is Andrew’s personal view of technical communication, based on his experience of being a technical communicator in Silicon Valley.

It neatly describes the “Docs-like-code” approach to technical writing, and it challenges the impulse to write about everything. It describes Andrew’s experience of creating documentation in lightweight markup languages, such as ReStructured Text and Markdown, and using GitHub and static site generators to manage and publish the content.

Overall, I enjoyed reading the book. Andrew describes the benefits from following his approach. Ideally, I’d like to have seen more information and evidence to justify his opinions against other authoring tools. Microsoft Word might be a better choice than Markdown if you need to include complex images, tables or numbered lists. A Content Management System might be a better choice than a static website generator, if you want to provide intelligent content that modifies content to suit different users. The need to manage localised content (in multiple languages) might be easier to accomplish in DITA or MadCap Flare than by using GitHub and Markdown files.

Having said that, the book provides a useful insight into a increasingly common approach to documenting software applications.

The Language of Technical Communication book has been released

The Language of Technical Communication book is a collaborative effort with fifty-two contributors defining the terms that form the core of technical communication as it is practiced today. Cherryleaf’s Ellis Pratt was one of the contributors.

Each contributed term has a concise definition, an importance statement, and an essay that describes why technical communicators need to know that term.

61QTrFMxn1L

A 2015 book list for Technical Communicators

Two years ago, we asked which books should Technical Authors read, and we received some great responses. It’s always worth revisiting this topic, so please let us know what we should add to this list:

  • Author Experience: Bridging the gap between people and technology in content management; Rick Yagodich
  • Best Practices for Technical Writers and Editors (IBM Press 3 book collection): DITA, Quality, and Style; Francis DeRespinis, Peter Hayward, Jana Jenkins, Amy Laird, Leslie McDonald and Eric Radzinski
  • Central Works in Technical Communication; Johndan Johnson-Eilola and Stuart Selber
  • Content Everywhere: Strategy and Structure for Future-Ready Content; Sara Wachter-Boettcher
  • Content Strategy for Mobile; Karen McGrane
  • Content Strategy for the Web; Kristina Halvorson and Melissa Rach
  • Conversation and Community; Anne Gentle
  • DITA for Practitioners Volume 1: Architecture and Technology; Eliot Kimber
  • Dynamics in Document Design: Creating Text for Readers; Karen Schriver
  • Enterprise Content Strategy: A Project Guide; Ann Rockley and Kevin Nichols
  • Information Space; Max Boisot
  • Letting Go of the Words; Ginny Redish
  • Managing Your Documentation Projects; JoAnn Hackos
  • Microsoft Manual of Style; Microsoft
  • Single Sourcing: Building Modular Documentation; Kurt Ament
  • Technical Communication; Mike Markel
  • Technical Editing; Judith Taritz
  • The Insider’s Guide to Technical Writing; Krista Van Laan
  • The Language of Content Strategy; Scott Abel and Rahel Bailie
  • The Nurnberg Funnel: Designing Minimalist Instruction for Practical Computer Skill; John Carroll

Book review: Every Page is Page One

Every Page is Page One book coverThere’s a joke in education along the lines that students are taught the notes their teachers wrote down at university 20 years earlier…without going through the heads of either.

I mention this because there have been a number of technical communicators who have started to question the technical writing best practices that have been taught to student Technical Authors for the past 30+ years. At Cherryleaf, we show on our advanced technical writing techniques course how some of the largest websites have been breaking the generally accepted rules for writing User Assistance – companies that test and test again to see what works best for their users. Ray Gallon of CultureCom has been developing his cognitive approach to User Assistance, and Mark Baker has been developing and promoting the idea of “Every Page is Page One” (EPPO) Help topics.

Mark has published his ideas in a new book called “Every Page is Page One“. I was asked to review an early draft of the book, and, over Christmas, I was sent a copy of the published version.

In a nutshell, Mark’s argument is that, with Web-based content, you don’t know the context in which people are reading a Help page. You cannot assume that they have read any other pages prior to reading this topic. Therefore, you need to treat every page as Page One, the starting point, and include more introductory, contextual information in your topics. He argues that most Technical Authors have misunderstood minimalism, and the EPPO approach is actually more consistent with how John Carroll (the creator of minimalism) recommended User Assistance should be written.

The book provides recommendations on the level of detail you should include on a page before you need to create a new topic, and when and where to create links to other pages. He also compares EPPO to Information Mapping and DITA, and outlines how EPPO can complement these standards.

Reading the early PDF draft with a reviewer’s eye was struggle at times, but reading the final version in printed book format was an easy and enjoyable exercise. Perhaps reading some sections for a second time helped, as well.

We agree with a great deal of Mark’s ideas. We agree with the general idea of self-contained topics that provide the context for a task. We agree with the need for mini-Tables of Contents and a bottom-up approach to writing. We agree that tasks should include some contextual information. We agree online content can be atomised too much. We also liked his analysis of why screencasts are so popular, and the secrets to their success.

We have a few minor issues. Mark cautions against duplicating content on more than one Web page, because it’s bad for Search Engine Optimisation. We believe you should write efficiently in a way that’s best for the user, and that it’s up to the Search Engines to improve their algorithms so they can differentiate between “good” duplication and “bad” duplication. Google should be adapting and learning from the way good content is written, not us having to create sub-optimal content in order to satisfy Google.

It’s a book for people involved today in writing online User Assistance. Although the book is very clear and well structured, you probably need to have some experience of creating User Assistance to fully understand everything that’s covered in the book. It’s an important contribution to the discussion over whether technical communicators have focused too much on production efficiencies to the detriment of creating content that’s actually of value to their users. It’s worth getting a copy of this book.

Which books should Technical Authors read?

Woman reading bookThe bookshelves here at Cherryleaf are double stacked, and we’ve received another book this week to read and then store.

So it seemed like a good time to mention which books we’d advise Technical Authors to read.

This most recent book was published by XML Press, and their publications are well worth looking at. We have quite a few books from them. Some were review copies (i.e. free), and others were ones we bought.

Most Technical Authors use style guides, and both Microsoft and IBM publish style guides you should consider buying. Style guides help you make sure you’re using the right terminology. They can also help your manuals complement the big vendors’ documentation.

Cherryleaf offers a couple of Kindle books for a just a few pounds.

Then there are the technical writing “classics”. In this group, we’d recommend you look at books by Ron BlicqJohn Carroll, JoAnn HackosKaren Schriver and Joe Welinske.

Specialist books like these are not cheap, unfortunately; a decent collection of technical writing books will set you back at least £100.

Which other books and authors would you recommend to Technical Authors? You can use the comments box below to share your opinion with others.

(Flickr image: Will Ockenden)

The best book for Technical Communicators in 2012

The best book I’ve read in 2012 wasn’t written for Technical Authors. It wasn’t even published in 2011. It was written by one my fellow speakers at the STC Conference in Chicago, and it was one that was the most thought provoking books I’ve read this year.

One of the subjects it explores is curiosity:

Continue reading “The best book for Technical Communicators in 2012”

How software users become champions

Matthew Syed is a British sports journalist and former three times Commonwealth Games gold medallist, who has been investigating what is needed to make people excellent at doing any task involving complexity.

He argues that natural talent, your genes, are far less important than many people think. What’s important is practising what you can’t quite do. He argues we grow if we test our limitations, because our body adapts.

So what on earth does that have to do with developing software and Technical Authors? Syed argues there are two opposing views regarding success:

  1. One “school” believes talent is what makes success. This means that if you fail, you believe it’s because you don’t have enough talent. Therefore, you’re likely to give up.
  2. The other “school” believes success is all about practice – the quantity of practice, the quality of teaching and the willingness to test our limitations. This means that if you fail, you believe you can succeed with more perseverance and effort. It’s an opportunity to adapt and grow.

I would argue the whole philosophy of User Assistance is based around the belief that talent is all about practice. It’s easy to forget that others may think it’s all about talent – your developers may believe some users fail because they are stupid, and some of your users may believe they’re just not good enough to succeed. It’s worth checking what they believe.

Another implication is that we should provide assistance and guidance to users as they are doing the task. We should try to avoid interrupting their flow. This suggests providing Help and advice within the application screens themselves.

Thirdly, we should praise people for their effort rather than for their talent.

Bounce

BBC Radio 4 Four Thought

What do you think?