Most people are risk-averse, and profound changes such as the move to structured authoring require new skills and workflows. To ensure a successful transition, XML implementers need to assess their team members, identify allies, and build their implementation strategy around the staff members who embrace change.
The term paradigm shift originally comes from Thomas Kuhn’s book,
The Structure of Scientific Revolutions. Kuhn defined a paradigm shift as a new idea that required a change in basic assumptions. Because of this, paradigm shifts are often difficult to accept. This difficulty is reflected in everyday usage of the expression; it carries connotations of a change in thinking that is hard to assimilate or even causes cognitive dissonance.
The move toward XML-based authoring in technical publications is a classic paradigm shift. It requires content creators to change their writing process and learn new concepts.
The Desktop Publishing Paradigm
The desktop publishing paradigm was introduced in the mid-1980s and is currently the dominant approach to content creation. Although exact details vary, desktop publishing environments usually have the following characteristics:
- WYSIWYG (What You See Is What You Get) — Authors see the final printed version of their document as they are creating it. They can manipulate graphic position, page breaks, fonts, and other formatting attributes.
- Template compliance through author cooperation — Authors are provided with style guidelines and templates, but they have the option of ignoring those guidelines. To enforce consistency, verification by a production editor is required.
- Template overrides are easy — Authors often use template overrides (“tweaks”) to manage page breaks and other special items.
- Powerful, feature-rich tools — Desktop publishing tools are mature (some might say “elderly”) and provide a huge set of features.
The XML Authoring Paradigm
XML-based authoring is a dramatically different user experience than desktop publishing. The XML paradigm has the following characteristics:
- WYSIOO (What You See Is One Option) — Content is displayed with some formatting, but that formatting does not show the final published document. A separate process is required to create final output.
- Template compliance is mandatory — Templates are enforced by the authoring software, and authors are required to conform to the structure that is loaded into the authoring system. Consistency is enforced by the authoring software.
- Authoring and publishing are separated — The final appearance of a deliverable is controlled by style sheets that are applied after authoring is done. Authors have no ability to fine-tune the layouts to improve the appearance of the final deliverable.
- Authoring tools — The XML authoring tools do much less than their desktop publishing equivalents. In part, this is because the publishing features are absent, but even the basic word processing features, such as change tracking and spell-checking, tend to be less fully featured.
NOTE: Structured FrameMaker provides both authoring and publishing environments for XML. As a result, some of the points here are not applicable to FrameMaker.
XML authoring changes the success criteria for authors. In desktop publishing, a successful author produces useful, well-written content that is nicely formatted. In the XML world, a successful author produces useful, well-written content that is valid (conforms to the required structure).
In the desktop publishing paradigm, successful technical writers need a combination of domain expertise (knowledge about the product they are documenting), writing ability, and proficiency in publishing tools. The first two do not change in an XML workflow, but the last item does. Instead of understanding how to make a document look pretty on a page, authors are now required to assign metadata to their content. After 20 years of desktop publishing with its WYSIWYG focus, the shift to an exclusive focus on domain expertise and writing ability is challenging.
The XML Paradigm For Managers
Given the generally unpleasant news on the authoring side, you might wonder why anyone would choose to move to XML. For managers, the XML paradigm provides the following improvements:
- Better content storage — Storing information in a text-based, application-neutral format allows managers to choose from a wide variety of authoring, publishing, and content management tools. Desktop publishing generally requires use of a specific, proprietary tool with a corresponding proprietary format, so groups are locked into a particular authoring and publishing environment. Using a proprietary file format greatly constrains the choice of a content management system.
- Automated formatting — In an XML workflow, authors are responsible only for creating content. The process of generating output from that content is shifted into an automated process. Setting up the publishing environment requires a significant effort, but once the process is created, it is automated. That is, the ongoing, repeated effort of document production is replaced by an automated process that requires significant upfront effort. This reduces overall document production costs.
- Better information — The programmatic enforcement of style and formatting rules results in more consistent information.
- Cost reduction — Although an XML-based process can result in improved document quality, the most common justification for XML implementation is cost reduction. In particular, companies that localize their content can show huge cost savings by moving to an XML-based workflow.
Managers face two significant challenges in implementing XML:
- Resource allocation — XML implementation requires significant resources, either from staff or consultants. Getting approval for those resources is often difficult.
- Writer resistance — Most of the benefits of XML go to managers; the problems affect the writers. Not surprisingly, this leads to skepticism about the use of XML.
Anticipating And Mitigating Change Resistance
For true writing professionals, change resistance is usually minimal. They have already read about XML, and they understand why the organizational benefits are compelling. Some professional writers are very particular about their authoring tools and environment. They may be concerned about the difficulties inherent in XML content creation, but they are willing to make the leap.
Change resistance is not always unreasonable. If a new implementation does not meet writers’ legitimate requirements, you can expect significant resistance. Thus, it’s important to put together an implementation that addresses the unique requirements of your workflow.
The best way to minimize change resistance is to adopt a publishing system that is demonstrably superior to the old system from the authors’ point of view. If the old system requires certain tedious, repetitive actions, and these actions are automatic in the new system, the vast majority of writers will happily switch over to the new system.
As you begin planning an XML implementation, identify the content creators who love new tools and technologies. The technophile group will support change simply because it lets them play with new and interesting software. (They are terrible at evaluating costs and benefits of a new solution because they only see the benefits. That is actually a plus when you are building support for the transition.) Get the technophiles involved in the earliest stages of the XML implementation with prototypes, and use them as testers. Because of their positive attitude toward new technology, their reviews will be relatively forgiving.
Once you have approval from the technophile group, you can move on to the writers who are open to considering new technology but whose reactions are not always reflexively positive. These skeptics will find every potential flaw in your plans. If you can win them over, they will be powerful allies and great testers.
When the project is approved by the first two groups, you can start introducing it to other writers. Most groups have a resident curmudgeon–someone who rejects change on general principle. You will receive pointed criticisms when you involve this person in your project, so be sure that you have something solid to show at this point.
Finally, you’ll need to approach the content creators who are most resistant to changes in processes and technology. Broadly, you can divide this group into two categories–those who can (and will) learn, and those who will not. It’s important to provide education and training on the new concepts and the new business processes to help those who are experiencing difficulties with the transition to adapt. With support, the vast majority of writers can learn to work in an XML-based authoring environment.
Rarely, you will encounter somebody who either cannot or (more often) will not adapt to the new workflow. You can defer their transition into the new system as long as possible to give them time to learn. Another option to consider is a “maintenance team” assignment. Some organizations choose to leave some documentation in the old, unstructured workflow rather than going to the effort of converting the content to XML. If this is the case, resources may be needed to make updates to the legacy documentation, and this could be a good fit for the person who absolutely does not grasp the new paradigm.
A corollary to the maintenance team strategy is that you can make working in the new authoring environment a privilege rather than a requirement. When joining the XML implementation team is presented as an opportunity available only to a select few team members, it becomes more appealing.
Because of the change in tools, you may be in a position to reduce or eliminate tasks that are tedious in the current authoring and publishing environment. This provides a direct benefit to the authors and will make the transition more palatable.
Conclusion
Paradigm shifts require a change in thinking, and most people don’t much enjoy change. As a result, change resistance is a nearly inevitable occurrence during an XML implementation. Taken to an extreme, it can cause your implementation to fail.
You can determine whether change resistance is a significant risk to your project by considering your authors’ attitudes. If they master new software easily, follow templates consistently, and are always looking for ways to improve the content creation process, your risks are low. If, however, the authors are hostile to new technology, refuse to follow existing style guides, and have arcane superstitions about how to make software work, you can expect grievous difficulty as you attempt to implement a massive paradigm shift.
About the Author
Sarah O’Keefe is founder and president of Scriptorium Publishing Services, Inc. The company develops and deploys structured authoring environments, and also provides classroom and web-based training for FrameMaker, XML, XSL, and other publishing topics. Sarah’s publishing credits include Publishing Fundamentals: Unstructured FrameMaker 8, FrameMaker 7: The Complete Reference, The WebWorks Publisher Cookbook, Technical Writing 101, FrameMaker for Dummies, and numerous white papers.
Related Articles
