Tag Archives: Technical communication

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

The first all-emoji technical manual

This week the technical communication world is abuzz over the April 1 release of Remco Children’s Bedroom Suite: Assembly Instructions. Written by breakout author Julian Rebusser, it’s the first technical manual written entirely in emojis.

Recently I caught up with Rebusser, Skyping from a very hip coffee shop on the West Coast, for this exclusive interview.

Leading Technical Communication: Welcome, Mr. Rebusser, and thank you for agreeing to appear in my blog.

Rebusser: You’re welcome. I read somewhere online that your blog is influential, and I’m all about building my personal brand.

Tell me about your new book.

It’s got all the instructions for unpacking and assembling a full suite of children’s furniture: bed, night stand, armoire, desk, chair. For a few extra bucks you can even get a lamp

Assembling all of that must require a lot of complicated steps.

Yes. And when I wrote it as a conventional manual, it was like 20 pages of crap

What inspired you to write an all-emoji technical manual?

I had an epiphany one morning, waiting for the barista to brew my double-shot caramel macchiato

Wow. What was that like?

Well, for the first time ever, I thought about my audience.

You hadn’t thought about your audience before?

Of course not. Great writers don’t think about their audience. They think about cool, hip ways to express themselves. But for 2 or 3 minutes that morning, for some reason, I thought about my audience. And I realized something.

What did you realize?

Well, who usually assembles a furniture set for children?

Their parents, I suppose.

Right. And who are those parents?

I’m not sure I follow.

They’re Millennials! Digital natives. People who don’t read books

They don’t read books?

Of course not. They don’t like to read anything. I saw that in an article online.

And so the children’s parents….

Right. If I gave them words they’d never read them.

So, instead, you gave them….

Emojis! Millennials love emojis. I saw that online too. And I knew I was perfect for the job because I speak fluent emoji.

What happened next?

In no time my 20-page draft was down to 2.

Can you give me an example?

It used to take a whole page to explain how to bolt the legs to the bed.

And now?

Now it’s boltlegslegstwobed

I — I’m speechless.

I presented this last week at Write the Docs, and they were speechless too.

So now everyone knows you as the first all-emoji technical writer. What’s next?

Well, it’s all still hush-hush. Can you promise to keep a secret ?

Sure.

Next year when Remco rolls out its do-it-yourself flower garden, I’ll be there with an emoji-based augmented-reality experience. I’m calling it Pokemon Grow.

I can hardly wait.

It’ll totally blow your mind.

Yeah, I’m sure it w– mind blown

Welcome to your professional home

Close up of a graduation cap and a certificate with a ribbonThis week brought one of my favorite annual events: the celebration at which the students in our Technical Communication program at Duke University receive their certificates.

This year’s group was especially engaged and astute. Their capstone projects reflected their enthusiasm and skill.

Here’s what I told them during our celebration.

A person who aspires to become a doctor passes through a carefully prescribed series of steps: medical school, internship, residency. An aspiring lawyer goes to law school and takes the bar exam.

But people follow all kinds of paths into technical communication. I majored in the humanities and hoped to be the next Bob Woodward, until I discovered that technical writing paid better than writing news. Your other instructors were researchers, software engineers, and trainers. One even went to school to study technical writing. Each of us followed our individual path until we found our professional home.

You too came to this place from a variety of backgrounds. Your cohort includes an academic editor, a user-interface designer, a couple of teachers. You’ve worked in medical research, medical transcription, policies and procedures. We even have an actor and playwright.

Whether technical communication turns out to be your professional home, or you apply the skills and principles you learned in this class in other lines of work, you’ll always be part of the technical communication community.

It’s a diverse community that lives and works all around the world, encompassing many different disciplines in many different industries.

Despite its diversity, its members share a common belief in providing information — relevant, factual, truthful information — to the people who need it, when they need it, where they need it. That belief drives us to make a positive difference in the world.

The members of our community are also creative, and, in our own way, we enjoy having a good time. In fact, right after this we’ll adjourn to the bar and argue about the Oxford comma. Actually, I’m kidding. We don’t argue about the Oxford comma. Every technical communicator knows that the Oxford comma is indispensable.

How many spaces to put after a period. That’s what we argue about.

Read my message to a previous class from the same certificate program: You’re now a technical communicator.

Is augmented reality part of technical communication’s future?

While walking my dog last night I came upon a mother and her young son standing on the sidewalk. She was holding her smartphone high in front of her, pointing it toward the western sky.

As I came near she announced, “Mars and Venus.”

skymap_screenshots

The Sky Map map (Screen shots from Google Play)

I learned the names of the planets and stars the old-fashioned way: standing outside on cold nights with my dad, and studying the sky atlas he gave me. But today I guess there’s an app for that. There are actually several apps, as a cursory Google search will attest.

I think it’s cool that you can aim your phone at the sky and learn the basics of stargazing. I think it’s very cool that many of the apps are using augmented reality.

When I got home I downloaded one such app, Sky Map. True to its name, Sky Map immediately gave me a clear, easy to use map of the heavens. I haven’t yet sussed out what all of the icons mean. But I had fun using the Time Travel feature to see the positions of the moon and planets on the day I was born.

Do I sound like a space geek? Guilty as charged.

When it comes to augmented-reality apps, though, I’m still unsure about a couple of things.

No business case?

Number one: the stargazing apps are very low-cost. Many, like Sky Map, are free. So it’s hard to see whether there’s a business case for using AR in training and technical communication.

I write documentation for networking hardware — switches and routers. I can easily imagine how customers would like AR documentation that shows them how to attach brackets to switches and mount them together in a rack. But does customers would like translate to customers would pay for? Or to customers would choose my company over our competitor?

In the absence of clear answers, would my company invest in the tools, time, and training needed to develop such documentation?

Not ready for prime time?

Number two (and maybe this follows from number one): it seems so far that AR is mostly the province of gamers and app developers — not technical communicators or training developers.

skymap_screenshot2

Time Travel, Sky Map style. Recognize the date?

Most of the literature about AR in technical communication is still speculative. An article might say, for example, Here’s what AR is, and here’s how I think it could be applied to tech comm. Or: Everyone loves AR, and tech comm is on the verge of embracing it. I’ve seen only a handful of isolated case studies in which AR actually is being used for technical communication.

One such case study is General Motors’ myOpel app. GM began distributing the app to Opel owners a few years ago. Does anyone know if they’re still doing so? Or if they’ve expanded the idea to other brands? (A quick peek at Google Play reveals that myOpel is still available but it’s getting only tepid reviews.)

So, despite the star-struck articles (one of which — full disclosure — I wrote in 2013), I remain unconvinced.

What do you think? Do the stars say that AR will be a big part of technical communication’s future? Have you done AR work for technical communication or for training and if so, have you succeeded in making the business case for it?

Living and learning: 2016

Merriam-Webster picked surreal as its 2016 word of the year, and…yeah. At times this year I’ve felt like Alice in Wonderland, and I’ll bet you have too.

One thing remains as true as ever, though: if you’re not learning, you’re not living.

Here are some things I learned this year:

The future is technical communication

screen-shot-2016-02-25-at-6-07-54-pmTechnology is moving forward at breakneck speed. People want technology. People have different learning styles.

Who can deliver the information people need to make use of, and enjoy, the technology that’s all around them? Technical communicators, that’s who.

That’s the gist of Sarah Maddox’s keynote speech at tcworld India 2016.

I think Sarah is saying that we need continuously to hone the technical part of our job title, while not neglecting the communicator part. And I think she’s absolutely right.

We care a lot about our professional society

STC logoSome of my most popular posts this year dealt with the Society for Technical Communication (STC) and its role in a changing world. How can STC remain relevant when the traditional roles of professional societies are changing? How can it serve a community that’s growing ever more diverse, in terms of the kinds of work we do?

As 2017 begins, STC is looking for a new CEO. Whoever gets the job, and whatever things they choose to prioritize, I hope they’ll appreciate the passion and dedication of STC’s members.

DITA isn’t cheap (but it’s still worth the cost)

DITA logoEven as more organizations embrace DITA for developing their content, we hear that DITA is complex and hard to learn. Overcoming DITA’s acceptance hurdles was one of my most commented-on blog posts this year, as was my plea for greater sensitivity to the writers’ learning curve.

Yes, DITA is powerful. But it didn’t get that way by being simple. I’ve come to appreciate that writers need time to absorb the underlying principles, which happen to align closely with the principles of good technical writing, and they need time to learn the how-to aspects as well. It’s time well spent, I think.

A leader is a storyteller

monsterWe saw it in this year’s political news: for better or worse, people are drawn to the leaders who tell the best stories.

As technical communicators, we’re by nature good storytellers.

Does it follow, then, that technical writers have an edge when it comes to being good leaders? I think it does.

Don’t take things too seriously

The year truly has been surreal. Many of our deeply held beliefs — about leaders, about governments, about the course of history — have been challenged if not overturned.

Yet my most-read post in 2016, by far, was a collection of jokes. That taught me not to take things too seriously, and especially not to take myself too seriously.

It reminded me that we’re all human beings. We all need to connect with each other and, sometimes, share a laugh.

I hope I’ve connected with you, at least a few times, in 2016. I hope we’ll continue to connect in 2017. And even share a laugh or two.

Related: Living and learning: 2015

Showing the way in a surprisingly different world

leadwolfThe recent surprise election of Donald Trump as president of the United States has occasioned a lot of writing that I can sum up like this: Suddenly the world is very different than I thought it was. How do I (or we) deal with that?

One particularly poignant article came from technical communication blogger Danielle Villegas — TechCommGeekMom. Danielle pondered what the election results, and the conditions leading up to them, mean for technical communicators. Are we seeing the end of the trend toward globalization? How easy will it be to find work if you live in a rural area, away from a city?

Toward the end of her article, Danielle issued a call to action:

The proclivity of technical communicators, from my observations, is that they have big hearts. They have strong ideas, they are organized, and they know how to take action. They are generally open-minded, they think “outside the box” for solutions, and they understand the importance of reaching out and embracing the world because the proliferation of the internet has warranted it. We can make a difference in how we approach our work, both domestically and internationally, to set an example of best practices of being decent human beings trying to help each other progress and survive in this world.

How can technical communicators show the way, or “set an example,” in the way Danielle describes? How can we use our “big hearts” to bring progress, and perhaps bring reconciliation, to the fractured world in which we live?

Here’s my stab at an answer. I hope all of you will chime in with your comments. Continue reading

Where do the technical writers fit?

The other day Sarah Maddox posed the question Where do technical writers fit in an organisation? It’s a question my colleagues and I have bandied about for most of my 30-plus years working in technical communication.

The answer has evolved during those 30-plus years. And it’s tempting simply to throw up my hands and give the standard consultant’s answer: it depends.

smaddox

Sarah, like all of us, is looking for a place to fit in

Sarah doesn’t advocate for any one answer, either. Instead, she deftly states the case for including technical writers in each of these parts of the organization:

  • Engineering and product management
  • User experience (UX)
  • Support
  • Marketing
  • Developer relations

Here’s what I make of it.

We’re not an island

There’s one place in the organization where the technical writers definitely should not be, and that’s off by ourselves.

I didn’t always feel this way.

Early in my career, when technical writing was still being defined as a profession, it was important for the writers to establish an identity as a team and emerge from the backwaters of wherever they’d been placed on the org chart — usually in product development.

In companies that formed separate technical writing teams, the writers were better able to collaborate on tools, training, and best practices. Their managers could fight for a place at the table alongside development, marketing, and support.

The separate-team approach was what I experienced at IBM, and it wasn’t until maybe the mid-1990s that we, as a profession, had evolved past it. Continue reading

Back to school part 2: enhancing my technical communication skills

Back-To-School-Books-And-AppleJoe Welinske’s talk, Key Trends in Software User Assistance, has inspired me to learn new skills, or burnish my existing skills, so that i can continue to succeed as a technical communicator.

In my last article I described 3 of those skills: search-engine optimization (SEO), video production, and storytelling.

Here are the rest.

User communities

Our readers no longer live in isolation For help and guidance they look not to the official company-produced materials (like manuals and context-sensitive help) but to each other.

Smart companies, like the one I work for, host user forums and post knowledge bases on their websites. Customers can ask questions and get answers from each other and from experts on the company’s technical staff.

In many cases, online communities exist independently as well — on sites that aren’t affiliated with a product’s manufacturer. Those sites might have a lower signal-to-noise ratio, but they’re still popular. In some cases they’re preferred because, many believe, you’re more likely to find the unvarnished truth there.

I would be arrogant and a blockhead if I, as a technical communicator, chose to ignore these sources and insisted that my readers rely only on the official documentation.

I need to learn where my readers are seeking information about my products, and then I need to come alongside them — for example, by answering a question on a user forum and providing a link to the appropriate section of the documentation.

I also need to learn how people are interacting with my company on social media and be ready to step in when someone is looking for something I can provide. And when I step in, it should go without saying that the phrase RTFM is strictly verboten.

Designing and writing for the small screen

Joe noted that the most popular documentation format is still PDF, with web- and browser-based content cutting into its lead. However, the adoption of tablet- and smartphone-based formats like eBook remains flat. I think it’s because most technical documentation simply doesn’t lend itself to being read on a small screen.

MALE HAND HOLDING SMARTPHONE 2.jpgIt isn’t that people don’t want to read our content on a smartphone. It’s that we haven’t made it feasible. Yet.

We’re starting to see tools that can break up large technical documents into topics and push them to a tablet or smartphone in such a way that they can be updated automatically and the reader can make bookmarks and other notations.

So the technology is coming. Now we need the skills to create content for the small screen. Break large oceans of text into something more succinct. Find a better way to present content that exists today in large tables or complicated graphics.

How will we do that? I think we’ll have to pick and choose: figure out what content lends itself to a small-screen presentation and concentrate on that. Then provide download links to everything else. We’ll also need to evolve a skill we should already have developed: telling our story as succinctly as possible.

There’ll surely be demand for small-screen content. We have to figure out how to meet the demand.

UI strings and embedded assistance

The most direct way a technical communicator can show people how to use a product is to design the product’s user interface — or at least write the text strings in the UI. In the software world, more and more of us are getting to do just that.

When an input field is labeled in a way that makes sense for the audience, with a well-written help tutorial, the software becomes much easier to use and much less in need of detailed instructions.

Joe noted that in this area, technical communicators might have to fight to earn our place at the table. After all, there are already software developers and UI designers who consider this to be their jobs.

But some technical communicators have already gotten the chance to create UI strings and embedded assistance, and they’re making the most of it. As we — the technical communication community — develop a track record of success, with specific examples of how our work improved a product and made money for the company, we’ll get even more opportunities.

When those opportunities come, we need to be ready to seize them.

 

User communities. Designing and writing for the small screen. UI strings and embedded assistance. Have you been honing your skills in these areas? What other skills are you looking to update? What tips can you share with others?

Back to school: enhancing my technical communication skills

Here where I live it’s back-to-school time: a reminder that no matter how long I’ve worked in technical communication, there are always new things to learn.

Back-To-School-Books-And-AppleThe skills I’ve already mastered, while still valuable, won’t be enough for me to succeed in a world of new technologies and new ways of consuming information.

What will I be looking to learn this year? The following list is inspired by Joe Welinske’s talk, Key Trends in Software User Assistance, which
he gave last week to the STC Carolina chapter.

Search-engine optimization (SEO)

Joe’s succinct advice, to everyone in the room, was “Learn this.”

No matter what kind of technical content you create, it’s going online. Even the lowly (but still popular) PDF. And your readers will find it using a search engine.

So you need to understand how the right words and phrases, both in text and metadata, make your content bubble to the top of the search results. The best advice: don’t try to game the search engines. Make sure your content is relevant, and use terminology appropriately. Continue reading

An agile STC?

How well does the Society for Technical Communication (STC) provide value for its members? For others who are studying or working in tech comm?

STC logoWe had a lively conversation a few weeks ago on this blog. I’d like to move that conversation forward.

Today’s news stream brings an article by an Australian technical writer, Swapnil Ogale, titled The ASTC is failing us. In it, Swapnil shares an idea that might breathe new life into STC.

First, by way of background: ASTC is the Australian Society for Technical Communication. Despite the name it’s not part of STC. Like STC, however, it’s a membership organization that seeks to advance the profession through published articles, events and activities, and community building.

In his article, Swapnil airs some complaints about ASTC that might sound familiar to STC members:

  • Not enough effort to attract and retain members
  • Not enough communication from the society to the members
  • Not enough workshops and events, especially for people who aren’t located near major cities
agile_dog

Hey, if a dog can be agile so can we.

Then he makes a suggestion: Instead of relying on the traditional committee structure — a structure he calls “outdated and archaic” — the organization should adopt an agile methodology like software development teams use.

Agile, or “just-in-time development,” is a set of processes designed to make software teams more flexible and able to respond quickly to the needs of their customers. Agile teams produce frequent, small software updates rather than big roll-outs.

Here’s how agile could help STC. Continue reading