Why technical writers stop using XML editors
Technical writers adopt XML editors with conviction and quietly stop using them within eighteen months. The reasons are not what vendors think they are.
The technical-writing community adopts XML editors with more conviction than most software categories. The choice between Oxygen, XMetaL, and Arbortext is debated at conferences. Plugins are built. Templates are shared. The investment is real.
Then, eighteen months in, a measurable proportion of technical writers quietly stop using them.
Not all writers. Not in every team. But often enough that the pattern shows up across CCMS deployments, across industries, across vendor lines. The team that committed to structured authoring with full enthusiasm now has half its writers back in Microsoft Word, doing the conversion handoff to whichever colleague is still keeping the XML editor alive.
The reasons are not what XML editor vendors hear in their feature requests. The feature requests come from the writers who are still using the tool. The writers who quietly stopped don’t file requests, they switched tools.
What the disengagement looks like in practice
The pattern is consistent enough to describe.
Why the disengagement happens: the cognitive load of the XML editor on the left, against the calm of the word processor on the right. Technical writers can be trained on the left; subject matter experts give up.
Months one to three: enthusiasm. The technical writer attends the training. They customize their workspace. They build a personal cheat-sheet of XPath snippets and keyboard shortcuts. They post a screenshot of their setup to LinkedIn. The structured-content program is real, they are part of it, and the tooling is a badge of competence.
Months four to nine: the round-trip. The SME contributors (clinicians, engineers, regulatory specialists, the people who actually generate the source content) keep emailing Word documents. The technical writer’s day starts with a Word file, ends with a converted DITA component, and includes a lot of cleanup in between. The XML editor is still in use, but it is being used as a destination, not an authoring environment.
Months ten to fifteen: the second monitor. The technical writer starts keeping Word open on the second monitor for everything that is not strictly structural. The first paragraph of a new topic gets drafted in Word and pasted into the XML editor. Notes get written in Word. The XML editor is open, but it is no longer the center of the workflow, it has become a publishing-stage tool, the place where Word content gets formatted as DITA before being committed.
Months sixteen to eighteen: the quiet switch. The technical writer notices that they have not opened the XML editor for a week. The Word workflow has absorbed everything except the schema-level work, which the team’s structured-authoring lead handles now. The technical writer is still nominally a structured-content practitioner. In practice they are a Word author whose work gets converted by someone else.
This is not failure on the writer’s part. The migration to Word is rational at every step. Each step solves an immediate friction. The aggregate effect is that the structured-authoring practice the team adopted the XML editor to enable now sits on one or two specialists.
The reasons the disengagement happens
Three forces are at work.
The SME round-trip. The XML editor exists to make the technical writer productive at structured authoring. It does not solve the problem that SMEs will not author in it. As long as the SMEs are sending Word files, the technical writer’s daily work includes a conversion step. The conversion step does not need the XML editor’s structural power; it needs Word for the SME’s content and a fast way to map that content into DITA. The XML editor’s structural power is on display only when there is genuine structural work to do: which, in steady-state documentation, is a minority of the writer’s time.
The cognitive tax. Knowledge workers move fluidly between half a dozen apps in a typical day: email, Teams, calendar, Word, browser, project tools. The XML editor is the only one in that set with no Microsoft-365-style familiar surface. Every switch into and out of the XML editor has a context-load cost. The cost is small per switch and large in aggregate. After a year, the writer instinctively keeps Word open because the context-load cost is lower; the XML editor becomes a deliberate choice rather than a default.
Identity drift. Early in a writer’s career, identifying as “a structured-authoring practitioner” feels like a meaningful professional position. Mid-career, what matters is delivering documentation that the organization needs. The structured-authoring practice is one method among several. The writer’s identity migrates from “I work in XML” to “I produce documentation that meets the bar”. The XML editor was an identity signal as much as a tool. When the identity moves, the tool moves with it.
None of these forces are the XML editor’s fault. They are descriptions of how knowledge work actually shapes tool use over time.
What the alternative requires
The alternative is not “stop using XML editors”. The structural work the XML editors are designed for remains real work, and the team members who do it well should keep doing it.
The alternative is to remove the assumption that the XML editor is the authoring surface for everyone. CCMS architectures that treat Microsoft Word as a first-class authoring surface, not as an import path, let SMEs and most technical writers stay in Word for the day-to-day. The XML editor stays available for the structural work that genuinely needs it: schema modeling, complex content references, conditional-profiling logic, multi-target publishing pipelines, deep DITA work.
This requires the CCMS to maintain Word as a live authoring surface, not as a one-way conversion target. Specifically:
- The Word add-in writes well-formed DITA at save time, enforced by the CCMS, not retrofitted by a technical writer after the fact.
- The technical writer reviewing the same component in the XML editor sees the same DITA structure the SME’s Word session produced. There is no conversion step in the workflow.
- The structured-content program’s audit trail captures Word-based authoring as a first-class event, not as a side channel.
- The version history is on the component, not on the file format. Word and DITA are views of the same content, not separate copies.
Authoring in Word is the product page that walks how DitaExchange Dx5 implements this specifically.
Two CCMS products are built around this principle
The CCMS field is broad on most dimensions and narrow on this one. Two products treat Word as a first-class authoring surface alongside their dedicated XML editor support: DitaExchange and Quark Publishing Platform. Most others (Paligo, RWS Tridion, Heretto, IXIASOFT, Adobe FrameMaker as authoring-only) either require a dedicated XML editor or treat Word as an import/export integration rather than a live authoring surface.
The choice between the two depends on the substrate the rest of your organization runs on. Quark runs on its own platform. DitaExchange runs on Microsoft SharePoint, so for organizations already on Microsoft 365, the storage layer is also one you already operate.
What the data does not yet say
There is no industry-wide survey of XML-editor abandonment rates. The pattern described here is from accumulated observation across CCMS implementations, not from a published study. The technical-writing community has not measured it because abandonment is invisible, the writer stops using the tool but stays in the role, and the team’s spreadsheet of “active users of the structured-authoring environment” does not capture how active they actually are.
If you are a CCMS buyer evaluating the structured-authoring story your vendor is selling, the question to ask is not “how good is your XML editor?”. It is “how do your customer teams look eighteen months in?”. The answer separates the vendors whose architecture absorbs the tool-fatigue problem from the ones that ask you to wait it out.
For the companion argument from the SME side, why the SMEs were never going to adopt the XML editor in the first place, see DITA without an XML editor.
Frequently asked questions
Don't technical writers prefer XML editors?
The early-career or specialist-track writer who came up through structured authoring usually does. The technical writer who came in from journalism, marketing, or general documentation often does not. The split runs roughly along whether the writer's identity is 'I work with structured content' or 'I write documentation'. The first cohort is a minority and shrinking; the second is the majority and growing. CCMS adoption depends on serving both, the structured-content specialists keep the XML editor; everyone else gets a familiar surface.
Which XML editors are you talking about?
The category leaders for DITA authoring: SyncRO Soft Oxygen XML Author, JustSystems XMetaL, and PTC Arbortext. Some teams also use Adobe FrameMaker in structured-authoring mode, though FrameMaker sits a little apart from the pure XML-editor lineage. Visual Studio Code with the DITA extension is a recent entrant that some technical writers prefer for its lighter footprint. The pattern (initial enthusiasm, gradual disuse) appears across all of them.
Is this a tooling problem or a process problem?
Both, and the two reinforce each other. The tooling makes the technical writer feel separate from the rest of the organization's content estate. The process, where SMEs author in Word and hand work to the technical writer to restructure, makes the technical writer the bottleneck. Together they create a job that looks more and more like janitorial conversion work and less like the structured-authoring practice the writer adopted the editor to do. The disengagement starts there.
What's the alternative?
Architectures that treat Word as a first-class authoring surface alongside the structured editor, not as a fallback or import path. The technical writer keeps the XML editor for the structural work it is genuinely good at: schema-level changes, complex content references, conditional-profiling logic, deep DITA modeling. The SMEs author content in Word with a CCMS add-in that maps Word structure to DITA behind the scenes. Both populations contribute into the same content base. Neither is asked to adopt the other's tooling. DitaExchange and Quark Publishing Platform are the two CCMS products built around this model.
Doesn't this just push the problem onto the technical writer to clean up Word content?
It would, if the SME's Word content arrived as unstructured prose. The mechanism that prevents this is that the CCMS Word add-in writes well-formed DITA at save time, the structure is enforced on the way in, not retrofitted on the way out. The technical writer reviewing an SME's component in the XML editor sees the same DITA structure the SME's Word session produced. The conversion step is removed; the review step remains.
