Tekom thoughts
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.
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.
Ellis Pratt of Cherryleaf is delivering Beyond Documentation this Thursday, July 9th, at 11 a.m. Eastern (US) time. Ellis gave a similar presentation in Vienna, which was the basis for Tom Johnson’s post, How to Avoid Extinction as a Technical Communicator, and led to a lively discussion in the comments. Join us to see if you agree with Ellis’s point of view.
In the category of “what’s old is new again,” we have Writing to STOP from Tony Self of HyperWrite in Australia.
STOP – Sequential Thematic Organisation of Publications – was developed at Hughes Corporation in the 1960s. The purpose of STOP was to improve the speed of document production, and to allow multiple authors to work simultaneously on the same document. […]
The STOP approach still resonates in the age of online documentation, as we still have the same needs to reduce document creation times and to work collaboratively. In this session, we will look at how the STOP approach worked, and how it might be re-applied even more effectively in the 21st century.
That presentation is July 15 at 5 p.m. Eastern time. (Note the time change. Our usual 11 a.m. time slot is 1 a.m. in Melbourne, Australia. That seemed impolite to our presenter.)
Finally, Jack Molisani of Prospring and Lavacon is delivering How to Build a Business Case on August 4 at 11 a.m. Eastern time.
If you’ve ever submitted a purchase request that was not approved, chances are it lacked one or more of the vital components management looks for when allocating resources.
In this segment, Jack Molisani will present a fun and practical session identifying the components of a successful business case, how to identify what is important to management, how to maximize your chances of approval, and more.
Jack usually rewards questions with chocolate, and I’m going to be impressed if he manages that in a webinar.
Don’t miss your chance to hear from these guys. You can register through our store; recordings of previous webcasts are now available as well.
PS Our presenters are based in England, California, and Australia. Registrants could be anywhere. The sessions are yours for $20. I love the Internet.