No one talks about WREX (pronounced like the dinosaur name). 

WREX = writer experience. 

The experience of being a writer; the experience of writing. The lived experience of recalcitrant SMEs, moody authoring software, crash-prone publishing pipelines, and backward-shifting deadlines. That experience.

This, here, is a recounting of a few of my experiments with carving tunnels in the sky, making a writer's daily life better.

• Write in one file and make it appear in a thousand files simultaneously and automatically.  

Any serious writer will tell you this is a DITA feature, but what if you're not writing in DITA? The project I was working on was not using a modern HAT or CMS; it was written in plain HTML (about a decade and a half ago). Our team had to remember to, ahem, copy-paste the changes everywhere. Doing so was not only labor-intensive but also error-prone. My WREX solution was HTML transclusion. Put the reusable content in HTML files and call those files in other HTML files using a well-supported, community-driven Javascript library.

Several years later, I was on a team that used Markdown to author and Jekyll to publish the docs. The principles of transclusion were applied again, but this time, they were applied through the dynamic filtering capabilities of Liquid. With this WREX solution, UI text changes in the code (maintained in what developers call a 'strings' file) were automatically propagated to documentation.

• Auto-generate the message documentation.

Why would you need a messages guide, you might ask? You might say the errors and their solutions aren't displayed directly on the screen at runtime. Yes, they are, I'll respond, but remember, among our audience is our own support staff, and they love these message guides.

The time-tested way of creating these guides is to get the messages text from the engineering team and manually create the documentation files. This time-tested method takes anything from 30 minutes to a couple of days. The good-WREX method uses a script to generate the documentation files in one or two minutes.

• Identify duplicate content.

Sometimes, we create files. Other times, we inherit files. Many a time, we share files across products and services. In all this, what remains constantly, unwaveringly, unstintingly true is … bloat. Our documentation sets grow in size and keep growing, and before long, we're staring at documentation debt:

• Unused variables and conditions that are used as profiling attributes in single-sourced content

• Near-identical content in topics, especially in larger teams and in inherited files

• Repetition of cross-references because the same links were inserted manually by the writers themselves and also through relationship mappings by the authoring software

The good-WREX method uses scripts to identify the problem areas and lets humans take over thereafter to manually fix the problems. One example is documented in this blog post.

• Auto-generate release notes.

When are the release notes finalized? One day after the product was released.

In this day and age of intelligent devices, why, pray, are humans manually creating release notes? Why has the work not been delegated to machines?

What are your thoughts on WREX? What are some of the things that you have done to make your everyday writer's life easier? Share, no? Because,

मैं अकेला ही चला था जानिब-ए-मंज़िल मगर ; लोग साथ आते गए और कारवाँ बनता गया 

(Alone, I set off on the mission, but people kept joining in, and cohorts kept growing) 

- मजरूह सुल्तानपुरी  (Majrooh Sultanpuri)