“Trust me” isn’t a business plan
Knowing you can rely on someone is vital to professional relationships. But when it comes to proposing process change, the words “trust me” are never, ever enough.
Knowing you can rely on someone is vital to professional relationships. But when it comes to proposing process change, the words “trust me” are never, ever enough.
You know you’ve had a bad travel week when you cannot wait to compose the complaint letter to the airline. But sandwiched between flight problems, I had a great time in Wiesbaden at tekom/tcworld 2011.
Getting attractive PDF output out of XML is a serious technical challenge. But in some organizations, the PDF requirement is being used to prevent to unwanted workflow changes.
Predictions time! First, let’s review the 2010 post: cloud-based authoring begins to replace desktop authoring, increased adoption of XML alongside more sophisticated justifications, social media, collaboration, important new terms (content strategy [yes!] and decision engine [huh?]).
I’m not sure why I thought “decision engine” was going to take off, because it didn’t. Onward to 2011…
Let me qualify (heavily): this is, seriously, a rant.
I started at Scriptorium in June (2010), and since then I’ve learned more than I did in my entire time in the tech comm MS program I was enrolled in. And what’s more, the knowledge I’ve gained here has been useful.
This year is shaping up as the Year of the Many Datasheets. Several customers approached us with variations on this theme:
To understand how XML changes technical communication, we need to step back and look at how the rise of information technology has changed the content development process. Through the 1970s, most technical communication work had separate writing, layout, and production phases. Authors wrote content, typically in longhand or on typewriters. Typesetters would then rekey the information to transfer it into the publishing system. The dedicated typesetting system would produce camera-ready copy, which was then mechanically reproduced on a printing press.
In a desktop publishing environment, authors could type information directly into a page layout program and set up the document design. This eliminated the inefficient process of re-entering information, and it often shifted the responsibility for document design to technical communicators.
When you’re considering an overhaul of your publishing workflow, you may find yourself becoming a metaphorical version of Van Helsing, the vampire-hunting character from Bram Stoker’s Dracula (and the many, many movies based on the Dracula story). You need to find all the efficiency-draining aspects of your current process and eliminate them.
The rise of Web 2.0 technology provides a platform for user-generated content. Publishing is no longer restricted to a few technical writers—any user can now contribute information. But the information coming from users tends to be highly specific, whereas technical documentation is comprehensive but less specific. The two types of information can coexist and improve the overall user experience.
The Darwin Information Typing Architecture (DITA) is being positioned as the solution for XML-based technical content. Is DITA right for you?
This white paper describes the potential business advantages of DITA, provides a high-level overview of DITA’s most important features, and then discusses how you can decide whether to develop a DITA-based XML implementation.