Tag Archives: skills

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

Technology for the gray at heart

My hair has long since gone from graying to gray. So I was happy to read Andy Patrizio’s article in CIO magazine debunking the myth that older workers struggle more with technology than their millennial counterparts.

handtech2.jpg

I’m an old hand but I know how to use the technology.

Citing research by cloud storage provider Dropbox and a marketing firm called Ipsos Mori, Patrizio finds that older people are just as likely to use a variety of technologies in their work — and are less likely to be stressed out using them.

For Patrizio, the findings reflect people’s level of frustration with their workplace technologies. And younger workers actually feel more frustrated because, being accustomed to really good technology in their personal lives, the have higher expectations when they come to the workplace.

Maybe that’s true. Another reason, I think, is that older workers tend to take a pragmatic view of technology. For us, technology is a means to an end. We evaluate it simply on how well it helps us get our work done. Not on how elegantly designed and shiny it is.

I applaud Patrizio’s assertion that older workers are just as effective using technology at work as their younger counterparts.

But I’m taken aback by the last thing he says. Quoting Rick Devine of TalentSky, a job-search website, Patrizio writes:

…the burden of keeping people’s technology skills up to date falls on the employer. “Employers need to see where your deficiencies are so they can provide for you. It is the moral obligation of every employer to see the deficiencies of their workforce, so if these older professionals are falling away in skills, shame on their employer for not providing them with the work experience to be employable,” [Devine] says. “And that’s a failing of the system and we all need to come together to right that wrong.”

Is it really up to my employer to make sure my skills stay current? Sorry: I might’ve believed that in 1986 — and then only because I worked for IBM, where the “you have a job for life” culture was still in place. But I’ve known for decades that no one but me cares about keeping my skills current. I’ve counseled countless colleagues and students to take charge of their own skills development. It’s why I encourage people to attend conferences, to get training, and to read up on what’s happening in the profession.

If the onus is on employers to keep their people’s skills up to date, many employers will use that as just one more reason to push out older workers and replace them with younger ones fresh out of college or grad school.

I appreciate it when my employer gives me work that hones my skills. I appreciate it when they train me in new technologies that I’ll need on the job. But I, and I think they, understand that I’m ultimately responsible for maintaining a skill level that makes me valuable to them and to potential future employers.

What do you think? Have you found older workers to be just as skilled as younger workers in using technology at work? Do you agree with Patrizio that employers are responsible for keeping their people’s skills up to date? Why or why not?

Get the name of the dog

Old-style picture of a news reporter at his typewriter

Yep, that’s me — more or less — circa 1978 (source: crayfisher.wordpress.com)

Take a moment and read this terrific article by Justin Willett, a content marketer who worked in a newsroom for 14 years. (The title, Get the Name of the Dog, harks back to a senior editor who advised reporters to get every possible detail for their stories.)

Willet explains how content creators — and I definitely count technical writers in this group — should think like reporters, especially in terms of honing these skills:

  • Interviewing
  • Research
  • Writing – both the inverted pyramid and the art of storytelling

Along with these skills Willett touches on others like attention to detail, critical thinking, and audience analysis. We need to know who we’re writing for, the context in which they’re reading, and why they’re reading.

Willet’s article resonates with me because I got my start in professional writing as a reporter, and because I’ve always thought that my journalistic experience prepared me extremely well for the career I ended up choosing.

Can you think of other reportorial skills that technical writers should master?

What skills did you develop in another field that have served you well in technical writing?

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.

Oh, the things we do

This week brought an amusing blog post by my colleague, Colum McAndrew, about how technical writers can handle the question “What do you do?” It’s a rejoinder, he says, to people who say “but I thought you just wrote stuff.”

So besides just writing stuff, what does a technical writer do? Continue reading