For a few years now, I’ve been worrying about the future of technical communication as a career. Not that user docs will disappear (as much as most people might want that), but techcomm as a unique job title, as opposed to one of many tasks that someone might have. I remember hearing Noz Urbina telling us that we were doomed, back at Lavacon 2012. And I attended a few webinars at that time that were also very negative about future prospects.
They’re right: We’re doomed. Pack up your pens and find another use for that English degree.
I’m exaggerating. Right?
Technical writing/tech communication is going to be around for a while. But I think it’s going to be more common to see that job title in legacy industries. You know, those places where writers still write *manuals*.
So industries where there’s lots of rules and regulations and everything must be thoroughly documented. Those rules change slowly, after all. And larger software companies that have huge, complex products (databases, for example), which are going to stick around for a few more years, at least.
At least in some form, and for an increasingly limited number of pure technical writers. To be honest, I’m seeing more job postings than now, mainly for senior technical writers. So there’s still jobs to be had.
But apps really scared us, right?
Apps are the worst, right?
Apps are utterly horrible things that don’t require documentation. Or at least not nearly enough documentation to justify a full-time writer. Apps provide a simple, targeted workflow (ideally), with streamlined UI that doesn’t need a lot of explanation.
Which also means that you’re not going to do full database administration or build a billing system on your phone, but more people using apps instead of desktop software means fewer people reading manuals.
And I think we’re the only ones who worry about that. Unless we’re the ones using the apps, and then we admit to a small amount of pleasure that we won’t have to read yet another poorly-constructed manual.
But apps aren’t replacing enterprise software. At least not entirely. Not yet.
But I still think we need to adapt to a changing world.
What have we done to deserve this?
We’ve walled ourselves off, building a fortress of complex tools that no other teams can penetrate. At the same time, we’ve seen successive waves of programming languages, each one easier to use than the last. What are we seeing? Simplification. Ease of use. A learning curve that gets less steep every time. Languages that drop features that aren’t used, or aren’t used often.
And what has techcomm poured resources into? DITA. An arcane, overly complex language with a massive learning curve that requires specialized tools.
Why are we doing this? Because we’ve been trying to cram every possible feature into it that will allow tech writers to rewrite those massive manuals that we’ve been writing for years.
We’re retaining complexity when we need to reduce it. We’re holding on to features that don’t make sense in a modern, mobile world.
What are our coworkers going with? Wikis. WordPress. WYSIWYG editors and tablet apps.
Throw it away
When I switched from Structured Framemaker to a wiki, I was shocked by how much I couldn’t do. I lost an enormous amount of control over the structure of my documentation, from the overall layout to smaller things, like picture captions (I tried; they never worked well).
And then I learned what I could do, encapsulated starting with a single reference topic. The basic syntax was…well, basic.
But it worked. And here’s the thing: My audience didn’t complain. Our customers (yes: customers) aren’t looking for the perfectly-styled documentation that follows strict rules that make sense to us and no one else.
Where’s our drag-and-drop documentation?
I need content reuse; I don’t need to write a manual. My customers don’t want manuals, they just want to know how to use the features in the product that they purchased (or that their bosses purchased and they have to learn to use).
Basically: What does this thing do? Ok, then how do I make it do that? And what else can it do that I haven’t even thought of?
I know DITA makes sense for many, many writers. You want to be able to reuse each and every piece, and enforce a very strict style? Yeah, DITA’s where it’s at. I just think it’s packed full of too many things.
I want drag-and-drop documentation. I don’t want arcane tags and references and IDs. Yes, I know how powerful those are; but so are pointers in C++, and those are a notorious source of frustration.
I want a clean, straightforward, easy to use documentation tool that, most importantly, won’t get in the way of the writing that I have to do. I don’t want think about every tag for every sentence. I just want to research, write, and publish as quickly as possible.
The treadmill is speeding up
Unlike the old days of writing manuals where projects were measured in months, even years, today my projects are measured in hours.
In the last week, I:
- Launched a massively updated knowledge center, with the help of contractors who designed and coded the CSS. It’s a really nice site, and I’m sorry it’s behind a login.
- As part of that, I needed to copy a lot of content, reorganize content, and fix every link in the docs.
- I needed to copy content to support a second product, and rewrite many topics to change the product name and small differences in functionality.
- I needed to write new documentation for that product (although that was just two new articles).
- I had to build a structure for project documentation on our internal site.
- And I had to answer support tickets.
“Become a DITA expert” does not fit into that schedule.
But it’s bigger than DITA
Yes, I’m ranting about how DITA isn’t absolutely perfect. Again. DITA won’t save technical writing, but it also isn’t killing it.
“Unnecessary complexity” is only one thing that’s hurting our profession. The real problem is this: What does a technical writer do for the business? What business problems do they solve?
We’ve been told, and have unfortunately accepted, that user documentation is a “necessary evil” that businesses must deal with. But that’s a stupid, self-defeating reason, and the obvious next question is: Fine, but what else do you bring to the company?
Being able to write good product documentation isn’t enough. Being a DITA expert isn’t enough (or not enough for more than a handful of people).
In the next post, I’ll tell you about what I see as some solutions to this problem.