Snack-size tech comm videos from STC13

Scott Abel talked several tech comm speakers, bloggers and other luminaries into short videos at this spring’s STC Summit in Atlanta. The results are now available as Adobe Thought Leader Interviews at STC SUMMIT 2013. Most videos pack an interesting, usually well-argued insight into a minute or two. Taken together, they’re a good survey of topics and trends that were bounced around the Summit – and a perfect excuse to relive some of the #STC13 spirit!

Here are some of my favorites and what I like about them.

Sarah O’Keefe: Tech Communicators Need to Focus on the Business explains why tech comm’ers need to see how their content and their deliverables fit into the larger business schemes of their organization or client. It’s not exactly the first time Sarah has put out this message, but I consider this a recurring theme and one of the most urgent challenges for our profession.

Ann Rockley: The Benefits of Content Modeling shows how and why single-sourcing and content reuse requires prior planning. You need to model your content to ensure it comes out useful in the different formats. I appreciate Ann’s message that you not only need to do it, but you need to do it right.

Bernard Aschwanden: Benefits of Structured Authoring offers a primer on DITA and neatly sums up why the separation into concept, task and reference topics makes sense in a lot of cases. I like the video because it’s quite a feat to summarise both DITA and topic-based authoring in 2:40 minutes – and with examples to boot!

Rahel Bailie: Reclaiming Content Strategy urges tech comm’ers to reclaim the content strategy turf from the marketing people who may sell themselves better and know about writing copy, too – but we tech comm’ers can add the badly needed technicial knowledge as well. I cherish Rahel’s vote of confidence that we can and should reach out into this neighboring discipline!

Andrea Ames: It’s Not Your Mother’s Tech Comm Anymore argues that tech comm has to change and is in fact changing as users consume it in ever-developing context which makes tech comm’ers, and in fact users, too, the curators of documentation. I enjoy Andrea’s enthusiasm that blends “must do” and “can do” in most of what she does.

Oh, yeah, and then there’s my own 1:17 minutes of fame, ranting about tech comm’ers who wait for instructions and tasks. My point is basically: “Don’t Ask for a Mandate“, but rather prototype what content needs you find and let the solution sell itself. (I stand by my argument, though I don’t like my overzealous look of a young lawyer fearing to screw up his first court case… 🙂 )

But I highly recommend checking out the entire series of interviews, because they cover a wide variety of topics, technologies and tools!

Advertisement

Top 3 fixes when editing topics

A few recurring issues distinguish the editing of structured topics from that of other content. Here are the top 3 issues I’ve recently found while editing topics for language, consistency and structure.

1. Topic heading is weak

A heading can seem appropriate when you’re writing the topic, but it may still seem weak when you see it in the context of the entire help system, for example, in a list of search results.

Write topic headings so they give your readers a precise idea what that topic is about. Yes, that can be challenge when you’re trying to be precise and concise at the same time:

• Indicate what kind of information a topic contains. For task topics, consider starting the heading with an imperative verb. For concept topics, consider using noun phrases.
• Offer enough context so your reader can identify what area or functionality in the product the topic refers to.

2. Purpose or user benefit is missing

A topic can look great and complete: It does whatever self-contained thing it set out to explain. But if it doesn’t also contain a why and wherefore, it’s harder for the reader to understand whether they’ve come to the right topic and how it helps them.

Include the purpose or user benefit of whatever the topic describes early on, in the first or second paragraph. Answer the readers’ potential questions:

• Why is it important to know about or do whatever the topic describes?
• How does this connect to my work?
• How does it make my job or my life easier?

Be careful to describe the purpose or benefit of the topic’s content, for example, the actual concept or task, not the purpose of the topic. Focus on: “This function helps you…”, not “This topic tells you…”

3. Topic mixes topic types

A topic can look complete, comprehensive, and self-contained, but if it goes overboard and describes both, functional tasks and underlying concepts at length, it tends to overtax the patience of those who only need to know one of the two. It also makes it harder to assign a clear heading, to structure the topic clearly and to reuse the topic in additional contexts you might not yet know about.

Stick (mainly) to one topic type per topic. If you’re using the traditional triad of concept, task and reference topics, divide them accordingly, but keep it pragmatic. Ray Gallon and Mark Baker have both shown how a little conceptual information in task topics can go a long way, but they shouldn’t replace entire concept topics. Also see my previous post When topics don’t quite work from two years ago.

Summary

These top 3 issues and several others basically have the same underlying reason: We tend to write topics in the context of a function or a window, but that context is not necessarily familiar or identifiable to our readers.

Issues with the same reason also share the same basic solution: We should focus on writing topics in the context of our readers, their environment and their tasks in it.