Latest posts by techwriter (see all)
- 3 Ways to Add Copyright Free Images to Your Blogs, Books and Documents - September 19, 2016
- How to Delete All Hyperlinks in a MS #Word Document through VBA Macro - September 1, 2016
- How to View a List of All Open MS Word Documents through VBA Macro - August 31, 2016
© 2011 Ugur Akinci
There used to be a time when the question of whether to use FrameMaker or MS Word used to pass for a discussion on the future of technical writing. I’m guilty as charged as well but that was then and this is now.
Right now we are at the verge of such a momentous change in technical communications that which editor or platform we use should be the least of our concerns. This is the age of social sharing and communal experience where everyone is an expert. Whether we like it or not, the age of the solitary writer delivering pre-packaged expertise to absorbent masses is over. Now we writers (at best) start a discussion, and untold others take it over and carry it in any direction they please.
Technical documentation of the future will be built up and continuously edited not by only the developers, designers, and the technical communicators, but the users themselves as well. So in that sense every user will become a technical communicator, and for a good cause too. Who can know the ins and outs of a product or a service better than the person who uses it on a regular basis? Take the reader reviews away from Amazon and what’s left? Not much: only the products 🙂
There will also emerge many decentralized ways of building up the knowledge base from ground up, just like the case with Wikipedia.
When it comes to technical documents though, there are all kinds of liability, confidentiality and copyright issues. As far as I know, Wikipedia has never been sued yet for publishing the wrong information. Try doing that with your heart valve regulator user manual and see what happens. So I’m not sure if the legal infrastructure is there yet. But that kind of future is already here. Just check out the companies who have started to use Twitter and Facebook to keep in touch with their customers and build up their knowledge base rapidly. One day even airplanes might be built on a Twitter of one kind or the other.
Another important feature of future documentation will be the disappearance of legacy documents locked up in “document silos”. This will inevitably quicken the shift to writing “components” instead of books. We will see all kinds of single sourcing and structured authoring platforms adopted at all levels of documentation.
Although such a development will increase productivity and save time and money it will also have an unintended consequence: where strong narrative still counts (as in training materials and marketing presentations), such single-sourced documents will fail to engage audiences and create a backlash.
I noticed this when I was reading a recent volume on DITA. The delivery style was so stilted and so regimented that it almost felt like it was written by a “robot.” So was I surprised to learn at the end that the whole book was actually put together (and not “composed”) by the same single-sourcing XML algorithms that the author was explaining in his work? Of course not because it really felt like it was written by a machine instead of a human author.
This will increase the premium placed on the work of a decreasing number of “legacy” authors who rely on narrative power and couldn’t care less for multi-platform publishing efficiencies. Especially in training departments, I’d expect such masters of old-fashioned narration still make a good living in delivering materials that the audience (still composed of humans) can understand, relish and retain.
Buckle up folks! Bumpy ride ahead.
(Photo courtesy of Wikipedia Commons)