Last week we put out a call for questions about Sarah O'Keefe’s article, “XML & Lone Writers: Can They Go Together,” in the December Intercom. You can read the article again at the Intercom site (don’t forget that you must be logged in to view the PDFs) before reading further for the questions and Sarah’s answers below. Come back next week and we’ll have another call for questions to an Intercom article for you! I’ve heard from other lone writers who say that they avoid XML because they think it makes them a little easier to replace. How do you counter that thinking? That question should have come with a beverage warning. In early 2009, nearly 30 percent of respondents in Scriptorium's structured authoring survey said they were working in XML. It seems to me that any writer who avoids XML is greatly restricting future job options. But let's address the larger issue. A writer's job security should be built on three items: writing ability, domain expertise, and tools. If these “other lone writers” are seriously concerned that XML will make them easier to replace, that suggests to me that they need to improve their knowledge about the products they write about. And I'm having trouble envisioning a scenario where learning FrameMaker or Flare is more of an obstacle than learning XML publishing. If your reason for existence as a lone technical writer is primarily your tools expertise, you are doing something seriously wrong. What are the first things I should try to explain to someone who doesn’t even know the first thing about XML when attempting to justify it? Try to relate it to something that they do understand. For example, in talking with engineers, I often explain that reusable content objects are quite similar to object-oriented code. For creative types, you might compare the move to an XML workflow as being similar to the industry shift from word processing to desktop publishing—it's a different approach to content publishing and requires a different set of skills. If you're talking to a management type, you should probably focus on process efficiency and all that money you're going to save with the new process, which will allow you to a) deliver more content, b) publish faster, c) save money in localization, or d) all of the above. You state that there’s a discrepancy in the percentage of lone writers versus writers in larger groups who use structured authoring—20 percent versus 30 percent. Given the rest of your article, would you suspect that discrepancy is right about where it should be? Or do you think it should be a closer number? I'm not surprised at the discrepancy, and I think that the adoption rate accurately reflects the reality that the business case is generally less compelling for a lone writer than for a workgroup. That said, some lone writers do have strong businesses cases for XML but have not been able to convince their management. I'd guess that the disparity is something like seven percent “not compelling” and three percent “failure to communicate.” Can you play devil’s advocate for a moment and give some arguments a project manager might come up with in response to my forthcoming request? I think that would help to be able to quickly counter them. By the time you talk to management, you have presumably done your research and have a solid justification for XML. (By the way, “I think it's cool, and I want it on my resume,” does not count.) Here are some common objections and some possible responses:
- We don't have time for that. Actually, I'm proposing this because of our time constraints. In an XML-based workflow, we will save umpteen zillion hours [insert actual number based on your situation] because we eliminate all this manual formatting, rework, whatever. I'll be able to use the hours freed up there to accomplish Something This Manager Really Wants.
- It sounds risky. XML is an open standard, and we can use a variety of tools to create and edit XML files. Isn't that less risky than our current, proprietary tool? Also, I intend to create a prototype to verify that this works for our content before I commit. I think it's riskier not to move forward.
- It's too expensive. But look at my business case. We're already spending this money on [inefficient manual formatting, inefficient reuse, content duplication]. We'll recoup the initial investment in less than a year.