Tag Archives: tools

Is “soup to nuts” what we need?

For almost as long as I can remember, pitchmen (especially on late-night TV) have been selling all-in-one gadgets that slice, dice, puree, and do pretty much everything.

In our world of technical communication we have something similar: “soup to nuts” authoring systems that combine all the major steps of the content workflow under one banner:

  • Creating content
  • Managing content
  • Reviewing
  • Publishing
breakfast_gadget

This is actually a thing — but are you using it in your kitchen? (Source: Nostalgic Electrics)

Vendors have been offering systems like this for several years. The sales pitch is alluring: unify all of your content under the banner of one integrated toolset. Lots of content, a multi-step workflow, and one brand to rule them all.

Yet I don’t think I’ve ever seen a company, or even a decent-sized organization within a company, use one of these single-vendor systems for its entire content workflow.

I’ve used parts of these systems. For example, I’ve used easyDITA for content management and publishing, but not for content creation and reviewing. I’ve used XMetaL, but only for creating and publishing content.

In fact I’ve never used these systems for reviewing. All of my SMEs have said the same thing: “Give me a Word document or a PDF that I can mark up. Don’t make me learn a new tool.”

Do any of you use a single, soup-to-nuts system to create, manage, review, and publish content? If so, I’d like to hear from you. Is it working well for you? How easy was it to set up, get buy-in from content producers and SMEs, and train everyone? Continue reading

Advertisements

Overcoming DITA’s acceptance hurdles

dita-bird_0This is an appeal to the DITA community: the experts and the evangelists, and possibly the tools vendors as well.

We’ve done a good job selling DITA: after years of slow growth it’s gaining momentum. As it does so, paradoxically, I’m hearing more and more anti-DITA rhetoric. While some of the rhetoric reflects a lack of understanding or even a hidden agenda, some is worth listening to.

I’m thinking of two things in particular that the DITA community often touts as selling points: authors no longer have to worry about formatting, and their DITA content can readily be used for adaptive content — output customized for the audience.

As good as those sound, I don’t see content authors raving about them. We need to understand why that is, and find a way to address it.

Leave the formatting to us

I’ve proudly touted this in every DITA class I’ve taught: Freed from having to worry about fonts, indentations, and other formatting issues, authors at long last can concentrate on content.

Except that a lot of authors like to worry about formatting. Continue reading

Hot Lead to Hot Technology: Whither Technical Communication?

This month I was called in to assist on a technical-writing project that uses old technology. Really old technology. Which got me to thinking: the variety of output formats for our content, the number of tools for developing that content, and the range of skills needed to master all of the above, have never been greater. What does that mean for the people in our profession?

I began working in technical communication around the time that disco died (thank heaven) and Jimmy Carter was wearing cardigan sweaters. Everything we produced took the form of printed documents. At IBM we used a relatively new markup language called SCRIPT/VS, with which we could control indentation and vertical spacing. The U.S. Government, then as now one of the most prolific publishers on the planet, had embraced MilSpecs (military specifications).

Most technical communicators at that time were still in the “hot lead” world, composing on a typewriter (usually) and than handing their content over to be typeset and printed on a literal printing press.

1980: A gently-sloped pyramid showing a limited set of tools and formats

1980: Print, print, print

I’ve drawn a pyramid to represent the output formats and tools we worked with then. There weren’t very many of them, and the distance from the bottom of the pyramid to the top — in terms of training and skill set — was pretty small.

1995: Taller pyramid showing new tools like HTML and PageMaker

1995: Brave new online world

By the time I’d settled into mid-career, desktop publishing was all the rage. Microsoft Word (introduced in the mid ’80s) was already a staple of most Tech Comm departments. The World Wide Web, as it was then known, introduced many technical communicators to a new kind of writing: semantic-based tagging, in the form of HTML. We were excited to see our content displayed on computer screens and not just on printed pages.

The old formats and tools were still in place — although “hot lead” was fast fading from the scene. But the pyramid had become more crowded. The distance had increased from the top, where the cool kids got to play, to the bottom.

2014: Still taller pyramid, showing older tools at bottom and new ones, like HTML5, at the top

2014: Publishing everywhere

Nearly 20 years later, the pyramid has grown again. Many Tech Comm projects are still done in Word — probably more than with any other single tool. MilSpecs are still in common use. Hard-copy (or at least PDF) still predominates.

I used to tell my students they could do practically any job if they knew an authoring tool (besides Word), a help-authoring tool, and a graphics tool. But today’s jobs increasingly require new skills like structured authoring and mobile-app development.

But we’re also creating content that’s integrated with the technology, and content that displays on tablets and smartphones, using new tools that are both text-based and graphical. Today, there’s a sizable leap from the skills needed to work with the old technology to those needed to work with the new.

2020: The steepest pyramid of all, with new technologies (like wearable technology) included

2020: To infinity and beyond

In the not-so-distant future, I see us making use of even more new formats and tools. Augmented reality. Wearable technology. Things we don’t yet have a name for. Yet the demand for Word, for PDF, for the older technologies, won’t go away. The pyramid continues to go higher.

So what will our profession look like?

  1. Are we evolving to a place where everyone is a specialist and no one is a generalist? After all, while anyone can master a few technologies, it’s impossible to be proficient in them all.
  2. In light of #1, how will we buck the trend toward recruiters who seek candidates based on the tools they know?
  3. Will certain parts of the Tech Comm business — particularly the parts that rely on the older technology — become commoditized? (For that matter, there’s significant support for the idea that the whole profession is becoming commoditized, and I can’t say for sure that it isn’t.)
  4. What’s the best way to train people who are entering the profession? People who are already in the profession and who want to burnish their skills?

I very much want to hear what you think. So please drop me a line (or several lines) in the comments area.