Trends in Technical Communication: a review

The STC Trends in Technical Communication conference was in Birmingham, UK, 21-22 June 2008. Mike Unwalla reports on the presentations that he attended on 21 June, which all about change, and how to manage change.

Trends in technical communication

"What happens when change comes?" asked Sarah O'Keefe at the start of her presentation. She thinks that frequently, people are not good at reacting. At Scriptorium (www.scriptorium.com), most work is XML implementation, and most of that is with DITA. Therefore, much work is change management.

Sarah thinks that four trends in technical communication could cause large changes for technical communicators (she added that predicting the future is foolish). She thinks that:

Globalization will require technical authors who have project management skills and people skills.
XML will be the dominant method in five years.
The change to user-generated content will make the XML shift look small.
Technical authors will need to become skilled at working with motion graphics.

Globalization

Depending on how you look at it, globalization can be a threat or a benefit to technical communicators in the West. At one extreme, outsourcing to the lowest bidder is a threat. However, integrated international teams are a benefit. For example, at IBM, team members are chosen according to their skills, wherever they are in the world. That type of globalization is a benefit.

A competent technical author must have writing ability, domain knowledge, and skills with tools & technology. With consumer goods, for example, domain knowledge is critical, but it is usually not a large part of the skill set. However, for a technical author in the medical field, domain knowledge is both critical, and a large part of the skill set.

Sarah has very little domain knowledge. She manages workflow and information. She suggests that to be successful, technical writers need to identify their skills, and then map their technical communication skills to the industries that value them. For example, writing skills are important in consumer-facing areas.

A good technical communicator is sceptical of information that other people give, and questions authority to make sure that content is correct. In the US and the UK, questioning authority is acceptable. However, in many Asian cultures, it is not acceptable. Therefore, much outsourced documentation is of bad quality.

XML

XML brings with it structured writing, said Sarah. I disputed that claim. We have had structured writing for years. Information Mapping is structured writing, isn't it? No. According to Sarah, structured writing requires the programmatic enforcement of document templates.

Sarah spoke about levels of authoring:

Chaos. There is no consistency.
Documents match on paper. Therefore, there is document quality. However, in the word processor, styles are not used. Instead, for example, you have 'Normal' style with manual formatting to achieve a visual result.
Template-based writing. Therefore, there is technical quality. There is a repeatable process for creating consistently formatted documents. This is Neil Perlin's definition of structured writing.
Structured writing. Structured writing requires the programmatic enforcement of document templates. This is Sarah's definition of structured writing.

Technical communicators are moving from level 3 to level 4. XML is likely to be applicable to technical communicators in the next few years, but possibly not immediately.

The move to XML threatens old-school technical authors. Template compliance is not optional, so no more 'tweaking' of page breaks. Quality assurance is done on files, not on the final documents. Some technical authors will not like that change. However, benefits include new authoring tools, and new job roles, which many technical communicators will relish.

You can download white papers on XML from www.scriptorium.com.

User-generated content

User-generated content and Web 2.0 are the most important trends for technical authors, Sarah thinks. The change towards user-generated content will make the change to XML and structured writing look small in comparison.

Historically, publishing was one-to-many. That is, one organization published, and many people read the content. Now, anyone can be a publisher, and that affects technical authors. For example, many organizations do much work for search engine optimization of their web-based online help. They want their approved content to have a higher search engine rank than an unapproved review of a software product.

One threat to technical authors is that users document the product for free, and therefore, management sees no need to employ technical authors. However, opportunities exist for technical authors to become content curators, wiki organizers, and organizers of user participation.

Motion graphics

Sarah thinks that motion graphics and rich media will become more important than they are now.

Rich media and related tools bring new opportunities for technical authors to develop content. However, much rich media is not good for visually impaired people. (Sarah used the term 'visually impaired' both literally, and figuratively, to mean those people who prefer words to pictures.)

Implementing content management

CSR is a global company with more than 1000 employees. It designs Bluetooth chip technology. Shannon Milsom is a technical author at CSR. She explained the lessons learnt when CSR introduced XML publishing.

CSR has many different document types, for example, data sheets, application notes, software release notes, firmware release notes, user guides, and reference manuals. The content comes from sources such as the software development team, the R&D design team, the quality department, and operations/manufacturing.

The technical communication team at CSR was small, although the company was growing. They faced these challenges:

Authoring which used Microsoft Word. Engineers wrote source information using Word. Initially, this was fine, but as the company grew, so did the problems they had with this method.
Many contributors.
Style corruption in Word. Different writers used different style settings in Word, and writers did not comply with the style guide.
No version control. Documents could not be checked in and out of a version control system.

The technical communication team wanted to implement XML and content management so that they could:

Separate the content from the style (page layout, formatting).
Output the content in many formats (for example, PDF, HTML, XML) in a flexible manner.
Substitute common text such as product names, part numbers, document types, and product status.
Have building blocks for conditional text.
Have version control.
Use the content in many documents.
Have a robust system for reviewing documents.
Have cost-effective translation.

The team has achieved its goals. One specially notable benefit is that the marketing people can build documents from modules of information that are signed off.

The journey to XML

CSR initially considered building an in-house content management system before deciding to evaluate off-the-shelf products.

Evaluations took approximately four years, and they finally chose TCToolbox from Ovidius.

To achieve a successful implementation of an XML publishing system, Shannon recommends the following:

Get good training and support.
Involve everyone who will be affected, for example, suppliers, technical authors, contributors, reviewers, and the IT department.
Assign an information architect.
Identify the missing skills.
Test many evaluation versions of software.
Focus on business needs, and examine the process.
Allow sufficient time.

Shannon closed by saying that the management at CSR gave strong support to investigate the solutions.

Managing change

Ant Davey subtitled his presentation as 'challenges for the lone-writer in an SME-rich environment'. He spoke about his work at the Rail Safety and Standards Board (RSSB) (www.rssb.co.uk).

RSSB realised that information has value, and that knowledge is being lost. The web is changing people's expectations and the way that they find information. Single-sourcing is the most likely solution to the problems, but that is "not how we have always done it," so it is important to manage people's responses to change.

Effective change management means linking people and processes towards the desired change. You need to know where you want to be, not how you will get there.

Change means that people are doing things incorrectly, so they will take the change personally. Between approximately 5% and 25% of people cannot or will not work with the new processes. Some of those people are very valuable to an organization, and you need them for knowledge transfer.

Ant suggests that you carry people with you. Celebrate what is working. Explain what is not working, and why it is not working. Say how it will be with the new methods (what is in it for them, for the company, and for customers?).

Some people will be active, either in supporting change or in dissenting. Some people will passively support the change. The people you need to worry about are the passive dissenters. It is difficult to identify them and to manage them, but they will quietly sabotage your change programme.

Of course, you need a team to implement the change. A team of similar people will lead to quick results, whereas a team of dissimilar people will lead to better results.

Change management goes wrong for reasons such as the following:

Lack of power in the guiding team
No vision
Lack of communication
Allowing obstacles to block the vision
No short-term wins
Claiming victory too soon (not making sure that changes have bedded in).

Ant spoke about the importance of influence. Many strategies exist. People respond to different things, for example, logic, personal appeal, bargaining, and authority.

Ultimately, to support change, your senior managers will want a business case with real financial benefits. There must be a customer-led business reason for the change.

Paradigm shifts are never easy

Sarah O'Keefe's (www.scriptorium.com) second presentation was a fascinating discussion of the differences between two publishing models: desktop publishing, and XML publishing.

Desktop publishing is the current method, which was introduced in approximately 1985. It has these features for technical authors:

The development environment is WYSIWYG (What You See Is What You Get).
Compliance to templates relies on the cooperation of technical authors.
Technical authors can override templates ('tweak' the content).

The XML method for technical authors has these features:

The development environment is WYSIOO (What You See Is One Option).
Technical authors cannot override templates. The software enforces conformance.
Technical authors cannot control the final appearance of documents.
XML tools are not as well developed as desktop publishing tools.
The authoring experience is quite different from that with the traditional publishing tools.
Sometimes, much metadata is necessary.
The method is new, different, and challenging.

If an organization wants to introduce XML publishing, Sarah recommended some 'propaganda for writers' to give emphasis to the positive things such as freedom from formatting, the consistency of content, and the expansion of a technical author's skill set.

Professional technical writers are likely to have, as a minimum, an understanding of XML and its implications, and they are willing to think about the option of using XML. However, with less professional writers, a problem can occur. Sarah gave an amusing taxonomy of problem writers.

Sometimes, resisting change is the professional thing to do. For example, if a writing system does not meet the needs of technical writers, resistance is a good response. Sarah told us about one large (unnamed) company that spent hundreds of thousands of dollars on a new XML publishing system. But, it was unusable. The technical writers needed the ability to create PDF files, and the system could not do it (the technical writers had not been involved in the design of the system, and the designers made assumptions).

But, if an organization is building something useful, how does it manage the resistance of the problem writers? Sarah recommended this strategy:

Identify technophiles (people who love the technology), and use them for a pilot project.
Find sceptics. If the plan is practical, you can win them over. If the plan has flaws, the sceptics will find the flaws.
When you have a solid product, introduce it to the contrarians. These people say no to everything, but they can be won round.
Introduce the product to the technosaurs (people who think change is bad). They will either accept or reject the product.
Finally, manage the one-trick ponies. These people cannot learn new things. But, they are rare. An organization can keep these people, because possibly they have a large store of valuable knowledge. Sarah recommended assigning them to, say, a maintenance team that uses the old workflow.

Another strategy to manage resistance is to change the goalposts. Make working on a new system an advantage, instead of a requirement. Identify 'pain points', and show how the new system overcomes them.

Sarah concluded that resistance can break an implementation. An organization needs to rate the risk, and determine a suitable strategy. Do not change for the sake of change; you must have a strong reason to move to XML publishing.

RSS feed