Category Archives: Value

Lightweight DITA: I’ve seen the light

DITA logo being held aloft by balloons

Lightweight DITA doesn’t have a logo yet. The technical committee is welcome to use this one.

If you’ve taken one of my DITA classes, you’ve heard me extol the power of DITA. One aspect of that power is semantic tagging. In DITA, a piece of content isn’t boldface or italics. It’s a command name. Or it’s a citation to another document. Or it’s the name of a screen (a wintitle, in DITA parlance).

That’s a big selling point for DITA, you probably heard me say. Each DITA element represents what a thing is (hence the term semantic) rather than how it looks. Just think: you can take a big document and generate a list of all the command names, or all the screen names. You can’t do that when you’re just tagging things as boldface and italics.

Turns out there are a couple of problems.

  • First, I’ve never met anyone who wanted to generate a list of all the command names, or all the screen names. While it sounds good in theory, in practice it’s more like a solution in search of a problem.
  • Second, it’s a lot to remember. When is a command parameter a parameter? When is it an option? (DITA has tags for both.) Writers working side by side, writing content for the same help system, might tag the same object in different ways.

Just now, in fact, as I wrote this article, I couldn’t remember the name of the tag for citations. Even though I’m accustomed to using it, I couldn’t retrieve <cite> from my brain. I had to look it up.

Enter Lightweight DITA. Continue reading

Advertisements

Launching your technical communication career

Last time I wrote about the places you can go, or the different trajectories your career can take, when you work in technical communication.

But how do you get that first job? What qualifications do you need, and what are employers looking for?

Prompted by interview questions from a Tech Comm graduate student, and based on my experience working in the field and interviewing candidates, here are some thoughts.

montage of album covers from 1979

We listened to different music in 1979, and breaking into the field was different too.

I got my first technical writing job a long time ago — in 1979. One thing I know for sure is that your breaking-in story won’t be the same as mine. Things were a lot different then, and I’m not just thinking about the music we listened to. Companies, having realized that technical people didn’t necessarily make good technical writers, went looking for young writers who weren’t necessarily versed in the technology but who could learn it.

Armed with a double-major in English and philosophy, and having a tiny bit of experience with computers, I landed that first job with IBM.

You won’t have the same experience. Your résumé will need to look a little shinier than mine did.

What are the educational requirements for working in Technical Communication?

Follow-up question: Are certain degrees or backgrounds more sought after by employers? Continue reading

Why your idea didn’t fly — and how you can give it wings

Roseate Spoonbill in FlightRemember that great idea you had at work? You knew it would make a huge difference for the company and its customers, that it would pay dividends long into the future.

You pitched it to your boss, or to the C-suite. You put everything you had into it. But they just yawned. Nobody caught your enthusiasm. Worse, when a different, shiny idea caught their eyes, they forgot all about your idea and backed that one instead.

What happened?

Seth Godin provided some answers in his blog this past Super Bowl Sunday. Seth examined why cities spend hundreds of millions on stadiums while projects with a better return on investment — like building roads, improving education, or investing in technology — go wanting.

Learn the dynamics of corporate decision making

Seth sees 5 dynamics at play in decision making at the city or state level. I’m convinced that they also bear on your situation at work.

  • The project is now. It’s yes or no. There are no subtle nuances, no debating the pros and cons for years. We either build the stadium, or our team moves to Vegas.
  • The project is specific, easy to visualize — in contrast with, say, “investing in technology,” which each person is likely to visualize differently.
  • The end is in sight. When you build a stadium, the stadium opens and games are played. With other projects, it’s often harder to visualize the end state.
  • People in power and people with power will benefit. Enough said.
  • There’s a tribal patriotism at work. “What do you mean you don’t support our city?”

So what was your idea? Were you proposing that the writing team embrace structured authoring? Did you want the company to adopt a content strategy?

Why did your bosses toss your idea aside? Maybe you didn’t frame it in a way that took the 5 dynamics into account.

Make your idea fly

How can you improve your odds when it’s time to sell your next idea? Ask yourself these questions.

  • Is it clear cut? Can I create an unambiguous, shared vision in everyone’s mind of what will happen if my idea is adopted — versus what will happen if it isn’t?
  • Can they visualize the results? It might help to tell a story: meet Joe, who just bought our product. Here’s how my idea will improve his life and turn him into a more loyal customer. Or here’s Sally in Tech Pubs, and here’s how she’ll be able to create better content for Joe and others like him.
  • Is the end in sight? Can I describe what the results will look like in a year, or in 2 years? Or am I trying to sell something that brings only gradual improvement? Similarly, can I describe the win criteria: what specific things need to happen for this project to be measured as successful?
  • What’s in it for the executives? This might go against my altruistic nature, but the bosses won’t really listen (although they might pretend to) unless they see some benefit, tangible or intangible, for them.
  • Am I appealing to company spirit? Can I paint a picture of customers waving banners with the company logo, or of the CEO on a stage talking up this idea before a cheering audience?

Try framing your next idea around these dynamics, and you might see a better result. Because people are people, whether they’re a city council or the C-suite at a corporation.

Don’t give up

anoseate Spoonbill, Birding Center, Port Aransas, TexasYou’re probably thinking: my idea can’t score on all of these criteria. By necessity, it’s a long-term solution with no clear-cut success criteria. Or it addresses issues that are internal, “under the hood” — nothing that the CEO would ever talk about onstage.

In that case, go ahead and pitch your idea anyway. Just be aware of the forces that are at work, and be willing to address them. “I know this isn’t something we’ll be able to tout to our customers. But you (Mr. or Ms. CEO) will have the satisfaction of knowing that you’ve made your employees happier.”

Seth, unfortunately, used the word losers in the title of his post. He was saying, I think, that basing decisions on those 5 dynamics is a losing proposition — that cities would see better outcomes (better infrastructure, better education, better quality of life) if they could get past the limitations imposed by the 5 dynamics.

I look at it differently. I prefer to say that Seth has shed light on some basic aspects of human nature. Rather than simply abandoning our less-than-shiny ideas, we can succeed when we understand those aspects and turn them to our advantage.

What do you think? Has Seth given you a way to bring your ideas to fruition, or has he convinced you that your ideas will never gain traction?

Can you share a story of when you got an idea approved by appealing to these aspects of human nature?

Don’t twist the prose

It’s never too early to plan for next year’s gardening. I just got a new pair of pruning shears, and on the back of the package I found these illustrations:

garden_shears

….accompanied by these instructions:

Don’t twist the scissors in use. If the scissors are in the city Figure C in the way the clock pointer, the two shear bodies will squeeze each otherDamage: if it is twisted to the look of the clock in the opposite of the A, the time of the clockWill produce a gap between the two sides of the plane, and can not ensure smooth trim. Correct useShould be shown in figure B.

Yeah. Wow.

I was tempted to laugh and roll my eyes, and I confess that maybe I did. A little.

But it’s also worth pausing to make a few points — because someone wrote this, honestly thinking they were conveying useful information. Nobody sets out to make their readers’ eyes roll. So what happened here? Let’s think about it.

Don’t overthink

First, I’m pretty certain that the writer, despite the best of intentions, overthought the whole thing. Here’s what they wanted to say: For a smooth cut, always cut straight on. Don’t rotate the shears to the right or left.

But, anxious to make sure no one would misunderstand, the writer inserted cross-references to the pictures and added the convoluted text about what happens if you turn (twist) the shears clockwise or counterclockwise. The added detail, rather than clarifying, only muddled things.

My copy often goes from simple to complex, just like this writer’s. Then, after setting it aside for a little while, I can come back and make it simple again.

Translation matters

Then, when you’re writing content for translation, be sure it’s translated by people who know both the source and target languages. It sure looks like this company cut corners when it came to translation. (Maybe they twisted their shears counterclockwise while cutting. Who knows?)

I’m certain that this copy looked a lot better in the source language than it does in English.

Also, when writing for translation, be sure the writer and the translator are working with the same authoring tool. It’s likely that those crashed-together words, like otherDamage and clockWill, resulted from a writer saving the copy in one tool and a translator opening it in another.

Verify, verify, verify

The manufacturer knew they’d be selling their product in a large English-speaking market. Wouldn’t it be nice if they’d usability-tested their instructions — or even if they’d simply verified them with one English speaker?

Perhaps it seemed like an unnecessary expense, or too much of an inconvenience, to verify the instructions. Or perhaps someone simply said We don’t care — just ship it.  Whether that decision will have negative consequences, in the form of damaged customer loyalty or decreased sales, I don’t know. (Very possibly it won’t, which is why someone said We don’t care.)

The decision certainly has resulted in embarrassment for the manufacturer. Can you put a cash value on that?

Questions from the old year, questions for the new

Looking back over this blog’s performance in 2017, I see a pattern. The 3 most popular articles, in terms of page views, were ones that posed questions. The questions I asked in 2017 are still worth considering today.

Is augmented reality part of technical communication’s future?

While AR is popular for gaming, I asked, can it become a viable platform for technical communication? Nearly a year after I wrote the article, I still don’t see much enthusiasm.

screen shot of a sky map appThere are a few popular low-end AR apps, like the stargazing apps I mentioned in the article. Susan Carpenter, in a comment, envisioned using AR for museum interpretation.

But it’s still hard to see a business case for AR in mainstream product documentation. General Motors, attempting to break into this market, deployed its myOpel app a few years ago. While the app is still available, it’s getting only tepid reviews and it doesn’t seem to be spawning imitators.

Why is it so challenging to apply AR to product documentation? Partly, perhaps, because it’s so hard to know exactly what the user is doing — and trying to do — when they access the documentation. Mark Baker pointed that AR will work only if we can maintain our focus, remove distractions, and not introduce new distractions by, say, cluttering the user’s field of vision with “dashboards” full of irrelevant data.

As we turn the calendar to 2018, the vision of AR for technical communication remains gauzy, maybe somewhere in distant the future but not yet coming into focus.

Is “soup to nuts” what we need?

When I posed this question, I was thinking of authoring systems that combine under one banner all of the major steps of the content workflow:

  • Creating
  • Managing
  • Reviewing
  • Publishing

Vendors have been pitching these kinds of systems for a while. But I questioned whether very many real-world content-development teams were buying and using them.

Since I wrote that piece, my company has invested in one of those “soup to nuts” systems. We’ve begun using it to create, manage, and publish content — but not to review it. Just as I said back then, our subject-matter experts still prefer to mark up drafts using a familiar format like Word or PDF.

It’s too soon to tell whether our soup-to-nuts system will, as I feared, actually hinder cooperation and collaboration with other parts of the company. Service and Marketing, for example, use tools and processes that don’t play well with our the soup-to-nuts system we’re now using in Information Development. How big a hurdle will that prove to be?

People who commented on the article expressed skepticism, based on their own experience, about whether soup-to-nuts can work. One correspondent, however, reported being very happy with a tool I hadn’t considered when I wrote the article: Atlassian Confluence.

Will you still need me? (STC at 64)

Sgt. Pepper album with STC logo addedDuring the last Summit conference — and as Liz Pohland took the reins as STC‘s new CEO — I invoked a Sgt. Pepper song to explain why I thought STC, then marking its 64th anniversary, remains relevant in the 21st century.

I said that STC — which for decades has billed itself as the world’s largest professional society dedicated to technical communication — has stayed relevant by:

  • Providing a solid platform for networking and information exchange
  • Curating a body of knowledge
  • Connecting practitioners with educators

To stay relevant, I said that STC must:

  • Reach across to professionals in fields that involve content creation but that don’t necessarily fall under the rubric of technical communication
  • Make newcomers welcome and help them find their place in the organization
  • Find new ways to attract, train, and energize volunteers — because volunteers are the lifeblood of STC
  • Build its certification program into something that’s valued by practitioners and their employers — a process that’s likely to take a long time
  • Continue to operate as a worldwide society, retaining its place at the table alongside organizations like tekom in Europe

Now, in 2018, STC is spotlighting its age: its next conference is billed as the 65th Anniversary Summit. I think that its strengths, and its challenges, are much the same as they were in 2017.

What do you think — about STC, about soup-to-nuts systems, or about augmented reality?

What questions do you think our profession will need to focus on in 2018?

It’s not your text

Hey, wow. I was looking on the internet and — what do you know? — I found a list.

Yes, I realize that the internet is full of lists. Many of them exist simply to entice us to click. A few might entertain or inform, and then I forget them in 5 minutes.

A very few are worth recommending. One such is this list of rules for editors, compiled by the Baltimore Sun‘s John McIntyre. If you’re in any part of the writing business, hurry on over to The Sun and take a look.

I lingered long over Rule 4: It’s not your text.

You are in the middle of things. You have a responsibility to assist the writer in achieving their purpose. You have a responsibility to the publication to maintain its standards and integrity. You have a responsibility to the reader, the party most commonly overlooked in these operations, to meet their needs of clarity and usefulness. Your personal preferences are subordinate to these responsibilities.

quill penSo it is with editors, and so it is with technical writers as well. We have a responsibility to the company we represent, to maintain its standards and integrity (to the extent it has them), and to present its products in such a way that our readers can use them effectively.

We also have a responsibility to the reader, to meet their needs of clarity and usefulness. This is our paramount responsibility, because this is the one we have to get right. We might get away without perfectly reflecting the company’s style or brand image, or without perfectly describing the product’s features. But if we don’t meet the reader’s needs, so that they stop reading and walk away (or dial tech support), we’ve failed completely.

stone bridgeI’ve heard the technical writer described as the bridge between subject-matter expert and reader. I used to bristle at that metaphor: I thought it implied a passivity on the part of the technical writer, as if we were nothing more than a conduit carrying information from one actor to another. “People walk on bridges,” I remember complaining.

Now, in my old age, I’m more comfortable with the bridge metaphor. Maybe I have a higher opinion of bridges: some of them are engineering marvels, and even the simplest ones are mighty useful. But mostly, I think, I better understand that it’s not my text.

Yes, I play an important role in the transaction between expert and reader. But I’ve come to understand that part of my role in that transaction is to get lost. If I want my name on something, I should write a novel.

My job is to make the text good, and that’s nothing to sneeze at. But it’s not my text.

Yes, and: Helping you communicate better

When actor Alan Alda signed on to host the PBS show Scientific American Frontiers, in which he talked with scientists about their work, he did what most good interviewers would do. He read up on his subjects and their research, and he prepared a list of questions.

As Alda tells it, the first interviews were dull, dull, dull.

Cover for If I Understood You bookThen he tried a different approach. He did only cursory background reading. He didn’t prepare a list of questions. Instead, he sat down to have a conversation instead of an interview.

In his new book, If I Understood You, Would I Have This Look on My Face?, Alda describes what happened. The scientists, realizing they were talking with an interested layperson, started connecting on a personal level rather than delivering lectures. Alda, able to sense the scientists’ thoughts and feelings in the moment, let the conversation flow naturally and comfortably.

Instead of playing the role of a lecturer to a student, or an interviewee to a reporter, the scientists connected with Alda — and, by extension, with the PBS audience — as people talking with people.

Empathy: the key to communication

Alda’s book bears out a lot of things that technical writers already know. Empathy, he writes, is “the fundamental ingredient without which real communication can’t happen.”

Empathy comes from knowing your audience — whether it’s the person across from you in a coffee shop, an audience in a lecture hall, or a datacenter manager who reads your web page. Empathy comes from knowing who they are, what they’re thinking, and what they’re feeling.

Alda writes, “My guess is that even in writing, respecting the other person’s experiences gives us our best shot at being clear and vivid, and our best shot, if not at being loved, at least at being understood.”

He’s right.

He’s also right when he talks about connecting with an audience: “You make a connection by evoking emotions. A great way to evoke emotions is by telling stories. Stories are most effective when you establish commonality with the listener.”

Alda backs up his experience on Scientific American Frontiers with some impressive scholarship. He talks with an array of experts. (It’s easy to get a meeting when you say, “Hi, I’m Alan Alda and I’d like to chat with you about your work.”) He reports on a number of research projects.

Some of the projects were Alda’s own handiwork. He was and continues to be a guiding force behind the Center for Communicating Science at Stony Brook University. His contributions to the science of interpersonal communication are such that STC (the Society for Technical Communication) named him an Honorary Fellow in 2014.

Inprov: new insights for technical writers

Still, despite all of his scholarship and all of his hard work, Alda’s conclusions come as no surprise to most technical writers. We already know about analyzing the audience, about connecting with readers, and about telling stories.

Where Alda adds real value for me is when brings his life’s work – acting – into the picture. Much of the book describes his experience with improvisation, in which actors create scenes together without a script and without any expectations as to the outcome. Continue reading

A passage particularly fine

I’ve agreed to give a short speech at the STC Carolina chapter’s 50th anniversary celebration next week. It’s a special occasion, so I want the speech to be good.

Right now the speech is about twice as long as it needs to be. Which means that I’m right on schedule. It’s time for me to stop writing and start crossing things out.

I’m guided by this bit of wisdom from the great lexicographer Samuel Johnson (quoted by James Boswell):

Read over your compositions, and where ever you meet with a passage which you think is particularly fine, strike it out.

Portrait of Samuel Johnson

Samuel Johnson: not particularly noted for his sense of humor

I think I first encountered this quotation when I was in my twenties — perhaps even in college. That’s a good joke, I thought. That Dr. Johnson was quite the kidder.

He wasn’t kidding. But I wasn’t listening.

By the time I turned 40 I began to see wisdom in the doctor’s prescription. Stay vigilant, I took it to mean, lest your writing become flowery or overly ornamented. I was quick to deride those attributes in other people’s writing. Scoffing, I’d hand down my judgment: it’s overwritten.

Today, however, I’m a believer. Today when I write something cunningly clever, a phrase especially well turned — anything that’s particularly fine — I regard it with suspicion.

I don’t always strike it out, I confess. At least not right away. But l move it aside. Then I go back and see whether the piece is actually stronger with it gone. Almost every time, the piece is stronger.

It’s stronger because now, instead of pleasing me, it aims to please the people who’ll read (or hear) it.

You’re looking to be informed. It’s not my place to impress you.

Perhaps you’re looking to be amused or entertained. I’m more apt to do that if I write for your benefit rather than mine.

So (on a good day at least) I’ll furl my flowery phrases and instead deploy language that’s clear and direct. I’ll stop putting on a show and I’ll put you in the center of the story.

Many of us writers fell in love in our formative years with creative writing. It’s taken most of my life to understand that solving a puzzle — the puzzle of communicating effectively with my readers while keeping them engaged — is no less creative than making my prose dance on the head of a pin.

It’s no less creative, it’s no less fun, and it’s a lot more considerate of you, my audience.

(Update: Remember the speech I was writing? Here’s how it came out.)

Survey says: DITA’s benefits and challenges

DITA SurveyWhat are DITA‘s biggest benefits? Its greatest challenges?

The Content Wrangler is surveying DITA users, and last week Scott Abel — joined by DITA cognoscenti Rob Hanna,Mark Lewis, and Keith Schengili-Roberts — presented some preliminary results.

I’ve listed the rankings here, along with some thoughts of my own. Each numbered item is from Scott’s presentation; the commentary between the numbered items is mine.

(The survey is still accepting responses. If you haven’t yet weighed in, you can do so right now.)

What benefits does DITA provide?

This section was open to all respondents.

1, Consistency: content reuse/single-sourcing
Yes: when I think of single-sourcing, I think of consistency. But I also think about flexibility — of being able to publish the same content on the web, as integrated help, as PDF, and in other formats. For me that’s a big benefit, just as much as — and probably more than — consistency.

2. Usability: structure provides predictability

3. Translation: savings from reusing translation
The panelists remarked that they expected this one to score higher, and theorized that many of the survey respondents were content creators but were not the people actually responsible for translation. I think they’re probably right — and I’d also point out that a lot of organizations simply don’t translate their content. It would be interesting if the survey asked how many are currently translating DITA content.

4. Customization: segmentation, personalization
Nice to see this one crack the top 4. I think we (the community of DITA content producers) are just beginning to take advantage of features like metadata and keys. There’s so much more we can do to adapt content based on the audience’s geographic location, experience level, and so forth. (Key scopes and branch filtering in DITA 1.3 hold out even more promise.)

Rank the biggest challenges associated with using DITA

This section was open to respondents who said they use DITA.

1. Reuse: determining reuse strategy
Conref or keyref? What taxonomy to use, and where to put the metadata (in topics or in maps)? Who “owns” the library of reusable content? There doesn’t seem to be much consensus on best practices when it comes to developing a reuse strategy. Maybe, like the consultants always say, it depends — on what the writing team is
used to, on which groups are collaborating to produce content, and on what the corporate culture will support.

2. Usage: making DITA do what we want it to do

3. Training: equipping staff with skills needed
DITA logoThere’s a ton of training out there — in the basics of structured authoring, in DITA itself, and in the various tools. So I’m not sure what the problem is, unless it’s that companies don’t want to pay for training and want simply to hire people who already know everything (see #7 below). Even if you could hire fully-capable DITA writers off the street (and that’s a big if), they still need to be trained in how to use your local style, transforms, and so forth.

4. Technology: understanding software

5. Formatting: developing stylesheets and rules for content
This isn’t rocket science, but it is serious, hard work. It’s often not considered when companies plan a transition to DITA — which makes it even harder.

6. Governance: enforcing the rules
See number 5 above.

7. Staffing: finding experienced talent

8. Creation: understanding how to create DITA content

9. Measurement: what to measure, how to decide
Let’s be honest: rather than what to measure, don’t we really mean making the business case? We still struggle to quantify the cost savings and revenue enhancement associated with structured authoring and DITA. Translation savings, of course, are a big part of the story. But increased usability, customization, and brand consistency have value too. We just have a hard time quantifying their value.

10. Translation: issues associated with DITA content

So there you have it. What do you think? Do any of the rankings surprise you? Is anything missing from either list?

Do you agree with my take?

Thanks to Scott Abel for conducting the survey. Like so much of what he does, it’s of great value to the technical writing community. Thanks to Rob, Mark, and Keith for their contributions as well.

Will you still need me? STC at 64

Today, the first full day of the annual STC Summit, marks the 64th year that STC (the Society for Technical Communication) has been in business.

Sgt. Pepper's album cover with STC logo

Hmm…What if I Photoshop all of the STC staff and directors’ faces into this image?


Which brings to mind a Beatles lyric:

Will you still need me, will you still feed me,
When I’m sixty-four?

The “Will you still need me?” question is especially relevant as STC — a 20th century organization — copes with flat membership numbers and attempts to navigate the changing professional landscape of the 21st.

As I’ve said before, I think the technical communication profession — and the people in it — still do need STC. But the reasons are changing, and have been changing for some time. As a result it’s not a sure bet that STC will remain relevant over the next few years. Continue reading