Trends in Technical Communication: a review

The STC Trends in Technical Communication conference took place in Birmingham (UK) on 21 and 22 June 2008. Mike Unwalla reports on the presentations that he attended on 21 June, which all dealt with 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 suggested that often, 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 predicted four trends in technical communication that could cause large changes for technical communicators (she added that predicting the future is a foolish thing to do). Her predictions:

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

Globalisation

Depending on how you look at it, globalisation 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 worldwide 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 globalisation is a benefit.

A competent technical author must have writing ability, domain expertise, and tools & technology expertise. With consumer goods, for example, domain expertise 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 deals with workflow, and management of information. She suggests that to be successful, technical writers need to identify where their skills lie, 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 low quality.

XML

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

Sarah spoke about levels of authoring:

1. Chaos. There is no consistency.
2. Documents match on paper (so, 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.
3. Template-based authoring (so, there is technical quality). There is a repeatable process for creating consistently formatted documents. This is Neil Perlin's definition of structured authoring.
4. Structured authoring. It requires the programmatic enforcement of document templates. This is Sarah's definition of structured authoring.

Technical communicators are moving from level 3 to level 4. XML is likely to be relevant to technical communicators in the next few years, but not necessarily 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 deliverables. Some technical authors will find that hard to deal with. 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/whitepapers.

User-generated content

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

Historically, publishing was one-to-many. That is, one organisation published, and many people read the content. Now, anyone can be a publisher, and that affects technical authors. For example, many corporate organisations now put much effort into search engine optimisation of their web-based online help systems. They want their approved content to be higher in search engine rankings than, say, 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 organisers, and organisers of user participation.

Motion graphics

Sarah's final prediction was that motion graphics and rich media would become more important than they are now.

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

Implementing content management

CSR (www.csr.com) 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 communications team at CSR remained small, although the company was growing. They faced these challenges:

• Authoring based on 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 communications 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 have been 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 about four years, and they finally chose TCToolbox from Ovidius (www.ovidius.com).

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, vendors, 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 existing 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 talked 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 wrongly, so they will take the change personally. Between about 5% and 25% of people cannot or will not work with the new processes. Some of those people are very valuable to an organisation, 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 clients?).

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 paradigm, which was introduced in about 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 paradigm 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.
• Complex metadata may be required.
• The paradigm is new, different, and challenging.

If an organisation wants to introduce XML publishing, Sarah suggested some 'propaganda for writers' to emphasise 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 consider the possibility of using XML. However, a problem may occur with less professional writers. Sarah presented 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. Unfortunately, it was unusable. The technical writers needed the ability to produce 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).

However, assume that an organisation is building something useful. How does it manage the resistance of the problem writers? Sarah suggested this strategy:

1. Identify technophiles (people who love the technology), and use them for a pilot project.
2. Find sceptics. If the plan is practical, you can win them over. If the plan has flaws, the sceptics will find the flaws.
3. When you have a solid product, introduce it to the contrarians. These people say no to everything on principle, but they can be won round.
4. Introduce the product to the technosaurs (people who think change is bad). They will either accept or reject the product.
5. Finally, manage the one-trick ponies. These people cannot learn new things. Fortunately, they are rare. An organisation should not necessarily get rid of these people, because they may have a huge store of valuable knowledge. Sarah suggested assigning them to, say, a maintenance team that uses the old workflow.

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

Sarah concluded that resistance could break an implementation. An organisation 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.

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

© TechScribe, Sheffield, South Yorkshire. Page created 2008/08/06