Predictions for technical communication in 2017 and beyond

Our predictions for 2017 are…the same as they were for 2016! Having said that, there are a few adjustments we can make to the comments we made last year. Below, you’ll see our 2016 predictions In italics and some thoughts for 2017:

As documentation becomes to be seen more as part of product design, so the technical writing process will become part of the product development process. We’re likely to see reviews and version control follow the developers processes, and be managed via tools such as Git.

This trend now has a name: “documentation as code” (or “docs like code”). This is partly a reaction to more projects following the Agile methodology, with fast and frequent releases and a team-based approach to projects.

Markdown will break out from being an authoring format for developers and into the mainstream.

Markdown is now used for documenting some Cloud applications at IBM, so it’s gaining some well-known users now. We’re likely to see further developments with Cloud-based collaborative authoring tools (such as Corilla, Forestry and CraftCMS). We may also see more use of markup languages that have semantic capabilities as well, such as AsciiDoc.

More technical communicators will use Lean methods when working in an Agile environment.

It’s still early days for Lean in technical communication, but at last week’s “Agile the Docs” conference, we did see an example of how Lean had been used by Worldpay to identify where there were bottlenecks and waste in their writing process.

We’ll see greater use of the imperative voice in topic titles

This continues to be a trend.

The popular Help authoring tools will be able to generate embedded Help and on-boarding screens.

This was more a wish, and it didn’t happen. We also hoped for Markdown support, but that also didn’t come to pass. The popular authoring tools have added more support for Git and similar tools, and working collaboratively in the Cloud. They have improved.

What trends do you predict for 2017?

IKEA “How to Build” videos: a review

Although IKEA has been publishing instructional videos on how to build their products since 2012, we’ve only just come across them. The videos feature real people assembling the furniture, plus some tips on how to carry out certain tasks.

IKEA USA

IKEA USA has eight “How to build videos”, which you can access from the IKEA USA website or IKEA’s YouTube channel:

The videos are mostly visual, and there isn’t any narration. They are between 3 minutes and 12 minutes in duration. As with many videos, it doesn’t really get started until after the first 15 seconds.

Overall, they are very good:

  • The plain background helps you focus on the furniture.
  • The close-up instructional speech bubbles are informative.
  • The animated arrows do a very good job at  highlighting the location of holes.
  • There are zoom-in shots of specific actions.

While the paper instructions tend to stick to a single viewpoint, the video shows the assembly from different angles.

The last video was made in 2015. Why did IKEA stop making them? We don’t know if they have covered all the of the products that would benefit from video instructions, or they ran out of time/money/enthusiasm.

IKEA Italia

IKEA Italia has a similar YouTube channel. This contains translated versions of the IKEA USA assembly instruction videos, plus some assembly instructions from 2016 that have a British narrator.

These videos are much more driven by narrated instructions, and are shorter in length. I suspect this style was cheaper to produce. These videos also work well, as long as you speak English.

Fan videos

There are unofficial IKEA instructional videos on YouTube as well, some of which take a less conventional approach:

How common knowledge disappears – customer questions & answers for a turntable

In the olden days, every family had a record player (also known as a “turntable”), and pretty much everyone knew how to use it. However, if you look at the Customer Questions & Answers section for a turntable currently on sale on Amazon, it’s clear that many people today don’t know how a turntable works, or what it does. Common knowledge sometimes isn’t as common as people think.

Reviewing and Editing Technical Documents Course – Update

We’ve started work on the next course to be added to the WriteLessons bundle of online training courses – “Reviewing and Editing Technical Documents”. In this situation, we may try an experiment and release each module as it is completed, rather than publish all the modules in one go.

The modules will be: revising, editing, copy editing, proof-reading, getting documents edited, possibly measuring the effectiveness of documents, and managing updates. More news when we have it.

 

 

Have Amazon, Dropbox, Microsoft and Google got their information design wrong?

On an API documentation course we ran for a client yesterday, we showed a number of developer documentation websites, including ones from Amazon, DropboxGoogle and Microsoft. One common theme the delegates noticed was these sites contained a in-page table of contents, or a set of related links, on the right hand set of the screen.

Dropbox API documentation page

You will often hear Information Designers talk about F shaped reading, and that the right edge of the screen is ignored by users. If you put content there, they say, it probably won’t be seen by the readers.

So have Amazon, Dropbox, Google and Microsoft all got it wrong, by using the right edge of the screen to provide navigation? Have the improvements in screen technology and the introduction of tablets and smartphones changed which areas of the screen users notice?

What do you think?

Towards content lakes

One of the trends in both data and content management is the move away from silos. In data management circles, there is a trend towards the collection and aggregation of customer data into “data lakes”. According to Margaret Rouse, a data lake is:

A storage repository that holds a vast amount of raw data in its native format until it is needed. While a hierarchical data warehouse stores data in files or folders, a data lake uses a flat architecture to store data. Each data element in a lake is assigned a unique identifier and tagged with a set of extended metadata tags. When a business question arises, the data lake can be queried for relevant data, and that smaller set of data can then be analyzed to help answer the question…Like big data, the term data lake is sometimes disparaged as being simply a marketing label for a product that supports Hadoop. Increasingly, however, the term is being accepted as a way to describe any large data pool in which the schema and data requirements are not defined until the data is queried.

(source: what is a data lake?)

“Content lake” isn’t a word that’s used in the content management or technical communication sectors yet, and whilst it seems unlikely end user content will grow at the same rate as other forms of data, there’s a fair chance this phrase could catch on.

A content lake is likely to have similar attributes to a data lake:

  • Content will be stored in a native format that is then changed into other formats.
  • It will use a flat architecture to store data.
  • Content will be stored in some type of structured format. Perhaps XML, JSON or plain text (with AsciiDoc-like attributes assigned to certain sections). However, user documentation does not require the rigorous structure of other forms of content.
  • The content lake can be queried for relevant content, and that a smaller set of information can then be extracted to help answer questions. This might not mean publishing content on-the-fly, but generating PDFs, CHM files and web-based content from a single source.
  • Rather than content being simply archived, it will deliver the right information in very short timeframes.

See also:

Please share your comments below.

Documentation as Code

Tom Johnson has written two interesting posts on his blog on the “Documentation as Code” concept:

Documentation as Code can be interpreted in a few ways. Tom describes it as being able to store the documentation with the code:

From a technical angle, Etter argues that one should embrace lightweight markup languages, use static site generators, and store content in version control repositories with engineering code.

An other interpretation associated with this is that documentation should be seen as a design problem; it should be seen as part of the product (and seen in a similar way to the software code), rather than an add-on. If the documentation is stored with the code, it can mean that the requirements for documentation can be more closely linked to the code. When a requirement for a new feature is raised, so can a requirement for the related documentation. It can also mean that content that’s embedded in the UI, presented as on-boarding screens or presented as online Help, can be considered as different potential solutions to each user need.

Documentation as Code is a topic we touch on in our advanced technical writing training course. It’s an approach that we may see growing in popularity.